WarpSE: 25 MHz 68HC000-based accelerator for Mac SE

[iPhil64]

Not sure.

The website here only talks about:

1. New OLED display
2. New SD Card slot (I like the old push-to-eject slot better)
3. Black PCB color
4. New frosted case

The adapter you use to connect to the external drive connector is also a tiny bit different from Model B. But like I said, I've been doing most of my testing with the onboard drive connectors, which means I don't need that adapter at all.

Does not sound like major changes, unless the new display would behave electrically very differently.

When the double bong occurs, it looks like HALT is triggered pretty immediately after Vcc rise.
There is a condition that triggers it earlier than expected.

 

[iPhil64]

@JDW Did you have a chance to test without the power supply extension cable ?

 

[JDW]

When the double bong occurs, it looks like HALT is triggered pretty immediately after Vcc rise.

If you are looking at my scope screenshots, you will see the Power-ON happens, then Vcc rises to 5.0V. RESET/HALT remains low during that time. Then there is another 300ms with RESET/HALT remaining low, and after that it rises to 5v. That is normal.

In other words... With or without the double bong, what you see in my scope screenshots (except for the one where I press RESET), is exactly the same.

Implications for WarpSE is that when the double bong problem happens, it then becomes impossible to press and hold INTERRUPT to disable WarpSE and switch to stock 8MHz mode.

Tonight after work, I intend to test my Model C FEMU more to ensure it has no problems.

If anyone has a Model B and SE Reloaded, please connect your Model B to the LOWER DRIVE internal connector, power on, then see if you get the double bong. You don't need a WarpSE to do that test.

 

[JDW]

@JDW Did you have a chance to test without the power supply extension cable ?

No because I eat like a crazy lion so as to have more time to test, but I still don't have enough time on my lunch breaks. That's because I have to pull everything from storage, set everything up, test, then tear it all down and pack it back in storage because this is my workplace and we need to workbench during the day.

Tonight is my late night (Friday), so I won't have but 45 minutes to test after work, but I will try to fit in the "motherboard inside the metal chassis test" when using the Model B FEMU.

My biggest battle is against capacitors. To be honest, I really shouldn't do back to back testing. I need to wait 10-15 minutes for the motherboard to fully drain the caps. That's the ideal. But it wastes a huge amount of my valuable time to do that.

 

[iPhil64]

Oh ! I was fooled by the horizontal scale being different in the second screenshot... sorry about that.

 

[Zane Kaminski]

If you are looking at my scope screenshots, you will see the Power-ON happens, then Vcc rises to 5.0V. RESET/HALT remains low during that time. Then there is another 300ms with RESET/HALT remaining low, and after that it rises to 5v. That is normal.

In other words... With or without the double bong, what you see in my scope screenshots (except for the one where I press RESET), is exactly the same.

Implications for WarpSE is that when the double bong problem happens, it then becomes impossible to press and hold INTERRUPT to disable WarpSE and switch to stock 8MHz mode.

Tonight after work, I intend to test my Model C FEMU more to ensure it has no problems.

If anyone has a Model B and SE Reloaded, please connect your Model B to the LOWER DRIVE internal connector, power on, then see if you get the double bong. You don't need a WarpSE to do that test.

What I am wondering is, why does the WarpSE lose the enablement setting after the second bong? That should not happen unless power to the WarpSE is lost or the C8M clock is consistently high or low for 120 nanoseconds (it should only be high/low for 64 nanoseconds at the most). Can you re-check that the WarpSE is for sure getting re-enabled when the double bong occurs? Maybe it would be good to do a scope capture of the +5V, /IPL2 line, and /RESET lines with the WarpSE installed and the system powered up with the interrupt button pressed and through during the double bong.

Edit: Here's a picture of where you can probe /IPL2:

Best spots are pin B20 on the PDS connector (B means middle column and the pins count upward from pin B1 at the bottom of the card) or pin 25 of the fast 68k (second from the bottom on the left side of the 68k). It's also present on the motherboard in the filter pack B2 at pin 4, or on resistor R27 (the pin that's not connected to +5V).

 

[iPhil64]

No because I eat like a crazy lion so as to have more time to test, but I still don't have enough time on my lunch breaks. That's because I have to pull everything from storage, set everything up, test, then tear it all down and pack it back in storage because this is my workplace and we need to workbench during the day.

Tonight is my late night (Friday), so I won't have but 45 minutes to test after work, but I will try to fit in the "motherboard inside the metal chassis test" when using the Model B FEMU.

My biggest battle is against capacitors. To be honest, I really shouldn't do back to back testing. I need to wait 10-15 minutes for the motherboard to fully drain the caps. That's the ideal. But it wastes a huge amount of my valuable time to do that.

Health is precious James ! I understand you want to get to the bottom of things... Thank you so much for the in depth time you take testing.

So you confirm there is some kind of persistence when the double bong occurs ? (which is why you are waiting those 10-15 minutes)

Zane you mentioned there was a possibility of partially corrupted RAM, breaking the power-on logic. Is there a way we could ensure clearing everything, or at least the critical values necessary for a single bong reboot ?


Also it seems that rev. B or rev. C do have a slight electrical difference (or timing difference) that triggers this condition.
Reading out a lot of articles on accelerator boards, overcooking of our vintage hardware, or the excellent video from James on power supply cable thickness, I can't help thinking there is a minor variation somewhere that causes all of this. It sounds to me more as an analog issue rather than a logic issue. Which does not mean that we can't correct it through a logic modification.

(I know I come late to the game and with an external sight of things... just trying to analyse)

 

[Zane Kaminski]

Zane you mentioned there was a possibility of partially corrupted RAM, breaking the power-on logic. Is there a way we could ensure clearing everything, or at least the critical values necessary for a single bong reboot ?

The Mac should clear the RAM on boot, but I think it only does this if it doesn't see a particular magic number. Like, if you reboot quickly (edit:slowly) you'll notice that the Mac repeats the RAM test routine and it takes a little bit longer before the 1/2 black/white pattern on the screen is replaced by the slightly lighter (more white pixels) pattern. So clearly the ROM checks some location in RAM or something to determine whether the memory test is necessary, and it likely keys off whatever magic number to decide whether to clear the RAM too. The best way would be just to swap the RAM between tests runs as I described to @JDW in my previous post.

 

[JDW]

Bad news​

FEMU Model C triggers the Double Bong too on this SE Reloaded motherboard.

I confirmed that after work tonight by connecting my SE Reloaded motherboard with WarpSE (firmware 0.6h), a mouse & Keyboard, and my Model C connected to the External Floppy Drive connector. Got the double bong on the first power on. (On my lunch break I had Model C attached to the "lower" internal floppy drive connector.) Everything was disconnected and put away for several hours since my lunch break. And yes, I did the test after work with the motherboard OUTSIDE the chassis because it's some much easier for me to test multiple configurations that way (with or without WarpSE attached, for example, or connecting my scope probes to the 68000 MCU).

After that major disappointment, I powered the SE OFF & ON in less than 1 minute. The second power ON there was no double bong. And this matches what I've seen with the Model B FEMU too. It usually triggers the double bong on the first power on (after the machine has been off a long time), but then if I switch it ON and OFF again, sometimes there's a double bong again, but other times not.

I then powered OFF, waited 30 seconds, pressed and held INTERRUPT, then powered ON, and there was no bong and I saw the CRT artifacts (this is a GOOD thing), and then I released INTERRUPT, it bonged once (normal) and then it was in 8MHz mode.

After that...

I powered everything off and put the SE Reloaded board inside the chassis (with WarpSE still attached). Same connections as I wrote in the first paragraph above, just with the motherboard inside the chassis this time. It had been powered off about 5 minutes while I did that swap and typed out the all the text of this post until right now. When I powered on, I did NOT get the double bong. But that's not saying a whole lot because 5 minutes of OFF time isn't enough. I know that from past experience.

It's hard for me to abide by the 15 minute rule normally because I can't test anything during that dead time and being an extremely busy person, I end up going off to another job and not being able to come back until much later (often several hours). But several hours of being off does ensure a truly fresh start. It's just that I can't repeat the tests with such a large amount of off time and make any reasonable progress in my testing! It's a very frustrating problem!

And so, it seems I won't be able to do another test until waiting another 15 minutes and twiddling my thumbs the whole time. (Or maybe I'll post something in a FaceBook Group...)

15 minutes later...

Powered ON with the same config (everything inside the chassis, WarpSE installed, Model B attached externally), and I got only a single bong, which of course is good. But I need to do MUCH more testing to see what is what. Because I know from past experience this double bong thing comes and goes. It's like a demon inside. And when the demon comes out, then it also presents me from using INTERRUPT to disable WarpSE.

I did more power OFFs & ONs with only 30 seconds between each attempt and they all worked fine. I was able to put it in 8MHz mode and did my standard MacPaint boot and test (no mouse problems found). I then powered OFF and ON and did the same with WarpSE, but this time I didn't have any mouse problems either! But again, I need to do a lot more testing to see how stable that is.

I then put the case back on and screwed it down (so I can pack it and take it home), but I did one finally test (10 minutes after my last power OFF). I had Model C FEMU attached at back. Powered on and got a single bong. Booted from BlueSCSI. Powered off and ON with INTERRUPT held down, then released when I saw the artifacts. WarpSE was disabled.

While all of this seems like...

GOOD NEWS​

It means I need to spend my weekend testing the same power on and off and INTERRUPT push sequence to see if the goodness continues over time. I'm highly skeptical it won't. But we'll see.

 

[Zane Kaminski]

@JDW I think one of the most likely possibilities is that there is an intermittent connection somewhere on your reloaded board.

I have seen this many times in the past for various reasons. For example, I have a WarpSE prototype where the CPU is socketed in a surface-mount PLCC-68 socket. The socket was reflowed on the board using a close-to-nominal temperature curve in our 3-stage conveyor belt reflow oven. Initially, it worked, but after many insertion and removal cycles, the socket has weakened somehow and does not work reliably. The solder joints between it and the board look fine, although they are hard to see through the inspection holes, and the socket's sidewalls are not warped or obviously damaged. Nevertheless the board does not work reliably unless I push down on the MC68k CPU in the socket. If I let up on the socket, either immediately or eventually. the WarpSE stops working. Hence why I am not going to use a socket on the production units. So maybe there is a similar issue somewhere on your Reloaded board.

On the other hand, on the subject of DRAM persistence, I have an interesting thought... a 256 kB or 1 MB SIMM made from SRAM instead of DRAM. It would be more expensive, but without the large internal capacitance of DRAM cells, it would lose its state almost immediately after power-off. I would more seriously consider making some of these (at least the 256 kB version) but unfortunately then you get into the "metric PCB thickness" issue we have discussed before in the context of the ROM SIMM. Even the slightly thicker boards I use for the ROM SIMM release version are not totally reliable. Of 70ish units sold so far, at least three or four customers had issues and had to further pad out the SIMM thickness using our fitment stickers. So let's not start making SRAM-based DRAM SIMMs unless we are really forced to track down a DRAM persistence issue. Would be better to just use different DRAM SIMMs that have less persistence or switch them out between test runs.

 

[iPhil64]

So........... @JDW Seems my cable extension theory was right in the end ? I'm lucky.... (or the fact it's inside, or 200 other small parameters)

And don't get me wrong, I still don't have an extension cable, and this is my next priority as I hate bring the chassis in and out. By the way, if I had one, I could have tested my reloaded board with the extension cable and FEMU Model C.

 

[JDW]

@JDW I think one of the most likely possibilities is that there is an intermittent connection somewhere on your reloaded board.

Could be. I just got back home. It's been just under 3 hours since I last powered on the SE. The machine is still fully assembled with the case on. I connected my keyboard, mouse, and Model B FEMU. Got a single bong and it booted from BlueSCSI just fine. I then powered off, pressed INTERRUPT, powered ON, got no bong and saw the artifacts, released, then got the bong and it booted in 8MHz mode also just fine.

So I will continue to test WarpSE this weekend, trying software I've not tried before. But overall, 0.6h looks to be a very good firmware version.

So........... @JDW Seems my cable extension theory was right in the end ?

Seems that your suggestion of putting the motherboard inside the metal chassis is indeed the magic cure for "intermittent connections"!

Thank you, Philippe!

 

[iPhil64]

Could be. I just got back home. It's been just under 3 hours since I last powered on the SE. The machine is still fully assembled with the case on. I connected my keyboard, mouse, and Model B FEMU. Got a single bong and it booted from BlueSCSI just fine. I then powered off, pressed INTERRUPT, powered ON, got no bong and saw the artifacts, released, then got the bong and it booted in 8MHz mode also just fine.

So I will continue to test WarpSE this weekend, trying software I've not tried before. But overall, 0.6h looks to be a very good firmware version.

I'm not sure how many tests you did, but given all the modifications, insertions, etc... even your usual perfect solder joints could have suffered in the process.

Nevertheless, a board inside the case with shorter connections does behave slightly differently on the analog levels.
The ultimate question being is it worth making the WarpSE even more immune to those changes (hardware and/or firmware), or is it an edge case enough so it can be ignored.

From my understanding James, this is exactly what you are trying to rule out for all of us. !

 

[JDW]

I'm not sure how many tests you did, but given all the modifications, insertions, etc... even your usual perfect solder joints could have suffered in the process.

Nevertheless, a board inside the case with shorter connections does behave slightly differently on the analog levels.
The ultimate question being is it worth making the WarpSE even more immune to those changes (hardware and/or firmware), or is it an edge case enough so it can be ignored.

From my understanding James, this is exactly what you are trying to rule out for all of us. !

Thanks.

I did way too many tests and still have more planned. But the fact remains that I spent all last weekend testing with the machine fully assembled like it is now, and I had the various problems I've reported before. That was using a different firmware version for WarpSE, however. And that's why more testing this weekend is important. But I will keep it fully assembled with case back on the whole time.

I just booted into MacPaint again, from my Model B FEMU. I did my standard test and the Mouse and paint brush don't jump around at all. Very interesting how that was cured. But if indeed this is an "intermittent problem due to iffy connections," then perhaps letting the machine warm up for an hour or so will show me something different. So I turned down the screen brightness to avoid burn-in, and I'll watch a little YouTube for the next hour, then do my mouse testing again.

It's a never ending quest to root out all the bugs, even if the bugs I find are in my own system!

And you're right. It could be that somebody might buy WarpSE only to discover their system has a problem that really isn't related to WarpSE. It's just they either never saw it before or never noticed.

At the end of the day, I stand in awe of Zane's handiwork. Zane, you're truly brilliant. This product is just stunning, I must say. If it had been released back in the 80's, it would have blown away the other accelerators out there, because almost all the SE accelerators had bad audio. You've fixed that, and that's a big part of the WarpSE experience!

 

[JDW]

I ended up watching videos for two hours last night. I then went back to the SE (which had been powered for those two hours), and I turned up the brightness and tested. No problems found with the mouse. I then switched it off and went to bed.

This morning (after a good 8 hours of sleep), I fired it up. No double bong, which is great. I booted from my FloppyEMU Model B and the MacPaint disk just fine. My BlueSCSI drives mounted on the desktop. I did my "MacPaint by Bill Atkinson" paintbrush drawing test and then moved the mouse horizontally very quickly for a long time and no mouse problems surfaced.

It's a real mystery as to why all that cleared up, but it has for now. And while it can now be effectively argued that something is awry on my SE Reloaded motherboard to have caused the double bong and possibly mouse related issues, it does concern me as to WHAT that could be in specific terms. Even so, all is working well right now, including INTERRUPT switch disabling of WarpSE. Well, I should say "all except MacTest SE." I reported the serial port test failed for me before, and I just tested and confirmed it still fails that test by locking up when it starts that test. That is true whether WarpSE is enabled or disabled.

FYI: The proper way to do the MacTest SE serial port test is to take a normal Mac serial cable and attach one end to the Printer Port and the other cable end to the Modem port. Then you start the test. It will fail the SCSI test but just ignore that.

When using my stock SE motherboard, the MacTest SE serial port test passes. There is no freeze. It's only my SE Reloaded board which causes that test to freeze. It passes the VIA test but then freezes at the serial port test. When using the stock SE motherboard, if I deliberately disconnect my serial cable to see what happens, it tells me no cable is connected and shows me a picture of what to do. But again, with my SE Reloaded board, with or without a serial cable attached, it freezes when the serial port test begins.

The odd part is, both of my motherboards pass the Snooper 2.0 Modem & Printer port tests when I use my homemade Serial Loopback Plugs! I guess I need to find a serial device to test serial ports in a more practical way, but I don't have printers or modems to do that.

All said, something has cured the double bong problem and the mouse problem, which is great. But whatever that magic is, it hasn't cured the serial port test failure in MacTest SE. I just want to mention that so as to report every little thing.

I will continue to test other software later today and tomorrow.

 

[Zane Kaminski]

Okay! I have just finished version 0.7a, which comes in an inordinate number of variants. I will explain...

The purpose of the 0.6 series was to get all the subsystems working reliably, but now we have to tune the exact parameters of slowdown in order to fix some of the remaining problems. Here are the remaining problems I'm aware of:

• Double bong and mouse issues on James's SE Reloaded
• Address error on reboot with SCSI Director 4.0 drivers
• LocalTalk not working, last worked in "fastscsi"

The issues on James's Reloaded are complicated so we will have to be patient and see what he finds. There's that old engineering joke--the hardest problem is the one that appears a little more often than every two weeks. Longer than that, you can get paid and go work on another project at some other company. More frequently and you'll be able to observe it enough that you can figure it out. But juuust under two weeks, that's the worst.

Okay, now the SCSI Director 4.0 address error. I will use the logic analyzer to see exactly what's happening before the address error but it doesn't seem like a huge problem. The drivers must just have some unusual speed dependence, like a game that plays faster on a faster CPU. Will investigate more but I don't think this one is a showstopper.

The LocalTalk issue is interesting. Did I introduce a bug since "fastscsi" or is it the increased slowdown interval introduced in 0.6b responsible for fixing sound the last bit? Or something else? This question is what the 0.7 version aims to answer. So attached I have version 0.7a, which has a new feature, the slowdown control register. You write to it by writing to an address of the form $F00XXX (so in the range $F00000-$F00FFF). The register is written using address bits 11 through 1:
A[11:8] - SlowInterval[3:0] - Controls low long the accelerator is slowed down for in multiples of 11x the Mac’s E clock rate.

• 0 = always slow
• 1 = 7 microseconds avg. (range is 0 - 14.042 us)
• 2 = 21 us avg. (14 - 28 us)
• 3 = 35 us avg. (28 - 42 us)
• ...
• 15 = avg 203 us (196-210 us)

A[7] - SlowIACK - slowdown triggered on interrupt acknowledge cycle
A[6] - SlowVIA - slowdown triggered on VIA access
A[5] - SlowIWM - slowdown triggered on IWM access
A[4] - SlowSCC - slowdown triggered on SCC access
A[3] - SlowSCSI - slowdown triggered on SCSI access
A[2] - SlowSound - slowdown triggered on sound buffer write
A[1] - SlowClockGate - fast CPU clock reduced to C8M speed during slowdown

With this, we can investigate which slowdown triggers are causing/solving certain issues without having to reflash the firmware. Here are some example addresses and how they affect the slowdown behavior:

• $F00FFE - these are the default settings. Slowdown interval is 15 (203ish microseconds) and is triggered by all devices. During slowdown the fast CPU clock speed reduces to 7.8336 MHz too by selectively gating 25 MHz clock pulses to the CPU
• $F00FFC - same as previous but the clock gating is disabled, so slowdown affects only RAM/ROM access speed/latency, not CPU speed
• $F00002 - slowdown always enabled, including CPU clock reduced to 7.8336 MHz
• $F00000 - slowdown always enabled, but no clock gating so only RAM/ROM speed affected
• $F00F00 - slowdown always disabled for maximum speed but may have compatibility issues
• $F00374 - equivalent slowdown policy as the old "fastscsi." Slowdown interval is 3 (35ish microseconds) and is triggered by all devices except for IACK and SCSI. Clock gating disabled

So just write anything to these addresses and the slowdown settings will be changed according to the low 11 address bits A[11:1] (i.e. low three hex digits of the address). You can do this in the MacsBug debugger by pressing the interrupt key, then entering (using the $F00FFE address as an example):

SM F00FFE 0000
ES

The first line, "SM F00FFE 0000" means to write $0000 to address $F00FFE. The written data doesn't matter, only the address. After pressing enter to run the command, the slowdown settings will be applied. The second line "ES" means exit to shell. Basically quits the debugger and goes back to the Mac OS.

Slowdown settings will persist through reboot but not a power cycle.

However, what if we need to study something occurring when the Mac first boots, before there's a chance to change the settings? What if the ROM firmware like, measures the machine speed and stores that even between soft/warm reboots? So in addition to the register, I have a bunch of variants of the 0.7a firmware that have different speed control register settings applied at power-up:

Version name	Slowdown interval	Trigger devices	Clock gating?	Equivalent address
0.7a	~203 us	all	Yes (7.8336 MHz)	$F00FFE
0.7a-35us	~35 us	all	Yes (7.8336 MHz)	$F003FE
0.7a-noclockgate	~203 us	all	No (25 MHz)	$F00FFC
0.7a-35us-noclockgate	~35 us	all	No (25 MHz)	$F003FC
0.7a-fast	never	n/a	n/a	$F00F00
0.7a-slow	always	n/a	Yes (7.8336 MHz)	$F00002
0.7a-slow-noclockgate	always	n/a	No (25 MHz)	$F00000
0.7a-fastiack	~203 us	all but IACK	Yes (7.8336 MHz)	$F00F7E
0.7a-fastiack-35us	~35 us	all but IACK	Yes (7.8336 MHz)	$F0037E
0.7a-fastiack-noclockgate	~203 us	all but IACK	No (25 MHz)	$F00F7C
0.7a-fastiack-35us-noclockgate	~35 us	all but IACK	No (25 MHz)	$F0037C
0.7a-fastscc	~203 us	all but SCC	Yes (7.8336 MHz)	$F00FEE
0.7a-fastscc-35us	~35 us	all but SCC	Yes (7.8336 MHz)	$F003EE
0.7a-fastscc-noclockgate	~203 us	all but SCC	No (25 MHz)	$F00FEC
0.7a-fastscc-35us-noclockgate	~35 us	all but SCC	No (25 MHz)	$F003EC
0.7a-fastscsi	~203 us	all but SCSI	Yes (7.8336 MHz)	$F00FF7
0.7a-fastscsi-35us	~35 us	all but SCSI	Yes (7.8336 MHz)	$F003F7
0.7a-fastscsi-noclockgate	~203 us	all but SCSI	No (25 MHz)	$F00FF5
0.7a-fastscsi-35us-noclockgate	~35 us	all but SCSI	No (25 MHz)	$F003F5
0.7a-fastiack-fastscc	~203 us	all but IACK, SCC	Yes (7.8336 MHz)	$F00F6E
0.7a-fastiack-fastscc-35us	~35 us	all but IACK, SCC	Yes (7.8336 MHz)	$F0036E
0.7a-fastiack-fastscc-noclockgate	~203 us	all but IACK, SCC	No (25 MHz)	$F00F6C
0.7a-fastiack-fastscc-35us-noclockgate	~35 us	all but IACK, SCC	No (25 MHz)	$F0036C
0.7a-fastiack-fastscsi	~203 us	all but IACK, SCSI	Yes (7.8336 MHz)	$F00F76
0.7a-fastiack-fastscsi-35us	~35 us	all but IACK, SCSI	Yes (7.8336 MHz)	$F00376
0.7a-fastiack-fastscsi-noclockgate	~203 us	all but IACK, SCSI	No (25 MHz)	$F00F74
0.7a-fastiack-fastscsi-35us-noclockgate	~35 us	all but IACK, SCSI	No (25 MHz)	$F00374
0.7a-fastiack-fastscc-fastscsi	~203 us	all but IACK, SCC, SCSI	Yes (7.8336 MHz)	$F00F64
0.7a-fastiack-fastscc-fastscsi-35us	~35 us	all but IACK, SCC, SCSI	Yes (7.8336 MHz)	$F00364
0.7a-fastiack-fastscc-fastscsi-noclockgate	~203 us	all but IACK, SCC, SCSI	No (25 MHz)	$F00F62
0.7a-fastiack-fastscc-fastscsi-35us-noclockgate	~35 us	all but IACK, SCC, SCSI	No (25 MHz)	$F00362

There are just a small number of the total 2048 firmware variants that could be generated. I mainly picked these so we could start investigating how to improve SCSI speed and fix LocalTalk without breaking anything else. The point of all these is not to try them all, but to pick the exact right combination to try so as to test for the cause of a particular problem.

@JDW @JTRetro I recommend you try version 0.7a or 0.7a-fastscsi since disabling SCSI slowdown is probably the most fun option here lol.

@ppuskari If LocalTalk doesn't work on 0.7a, try 0.7a-fastiack-fastscsi-35us-noclockgate. This is more or less equivalent in slowdown policy to the old "fastscsi." Might be interesting to first flash 0.7a, check LocalTalk, write to $F00374 to set fastiack-fastscsi-35us-noclockgate, try LocalTalk again, soft reboot, try LocalTalk again, flash 0.7a-fastiack-fastscsi-35us-noclockgate, try LocalTalk again. At least until you get success. That way we can get a little more insight into whether you can just change the slowdown speed, or if there are some compiled routines that are dependent on the speed measured at boot or initial power-on.

All the firmware variants are attached!

 

[Zane Kaminski]

@JDW @Kai Robinson @iPhil64 Another thing that could be an issue is the use of ACT and LVC-series parts on the Reloaded boards. I would exclusively use 74AHCT-series parts instead, because 74ACT and 74LVC series have sub-nanosecond edge rates that can lead to ringing and signal reflections. The older 74F and 74LS parts have slower edge rates so they can drive unterminated lines better.

For the RAM address multiplexers, I would use 74AHCT257s or 74FCT257s (rare) if absolutely necessary. 74AHCT257s are technically a few nanoseconds slower than 74F257 in the worst-case but it should be fine. I don't think this circuit needs all the speed of 74F. It just had to be a bit faster than 74LS. So 74AHCT will almost certainly suffice.

For the data bus buffers, I would use 74AHCT245s since originally 74LS245s were used. So AHCT245 is plenty fast but with slower output edge rates more like the original 74LS.

On the GLU replacement, I would use a 74AHCT1G125 instead of the 74LVC1G125. The 74LVC1G-series parts can be run at 5 volts but then they require CMOS input levels and also they have fast edge rates. So I'd switch for 74AHCT1G125.


@JDW is your SE Reloaded using a PAL/GAL/HAL GLU chip or a discrete logic based one? The GLU supplies a clock to the SCC, I think, so if there's ringing on that line due to sub-nanosecond edge rates, that could be causing a problem.

 

[phipli]

The issues on James's Reloaded are complicated so we will have to be patient and see what he finds. There's that old engineering joke--the hardest problem is the one that appears a little more often than every two weeks. Longer than that, you can get paid and go work on another project at some other company. More frequently and you'll be able to observe it enough that you can figure it out. But juuust under two weeks, that's the worst.

Interesting, in my circles they just say "f***ing intermittent faults". Your way is more elegant I have to admit.

 

[Kai Robinson]

@JDW @Kai Robinson @iPhil64 Another thing that could be an issue is the use of ACT and LVC-series parts on the Reloaded boards. I would exclusively use 74AHCT-series parts instead, because 74ACT and 74LVC series have sub-nanosecond edge rates that can lead to ringing and signal reflections. The older 74F and 74LS parts have slower edge rates so they can drive unterminated lines better.

For the RAM address multiplexers, I would use 74AHCT257s or 74FCT257s (rare) if absolutely necessary. 74AHCT257s are technically a few nanoseconds slower than 74F257 in the worst-case but it should be fine. I don't think this circuit needs all the speed of 74F. It just had to be a bit faster than 74LS. So 74AHCT will almost certainly suffice.

For the data bus buffers, I would use 74AHCT245s since originally 74LS245s were used. So AHCT245 is plenty fast but with slower output edge rates more like the original 74LS.

On the GLU replacement, I would use a 74AHCT1G125 instead of the 74LVC1G125. The 74LVC1G-series parts can be run at 5 volts but then they require CMOS input levels and also they have fast edge rates. So I'd switch for 74AHCT1G125.


@JDW is your SE Reloaded using a PAL/GAL/HAL GLU chip or a discrete logic based one? The GLU supplies a clock to the SCC, I think, so if there's ringing on that line due to sub-nanosecond edge rates, that could be causing a problem.

I did think that might be an issue, although I didn't have accelerators in mind. Luckily most things like that are socketed or easy to swap out, it was the lack of some AHCT parts during the pandemic that was the driving factor behind their choice.

 

[JDW]

@JDW @Kai Robinson @iPhil64 Another thing that could be an issue is the use of ACT and LVC-series parts on the Reloaded boards. I would exclusively use 74AHCT-series parts instead, because 74ACT and 74LVC series have sub-nanosecond edge rates that can lead to ringing and signal reflections. The older 74F and 74LS parts have slower edge rates so they can drive unterminated lines better.

For the RAM address multiplexers, I would use 74AHCT257s or 74FCT257s (rare) if absolutely necessary. 74AHCT257s are technically a few nanoseconds slower than 74F257 in the worst-case but it should be fine. I don't think this circuit needs all the speed of 74F. It just had to be a bit faster than 74LS. So 74AHCT will almost certainly suffice.

For the data bus buffers, I would use 74AHCT245s since originally 74LS245s were used. So AHCT245 is plenty fast but with slower output edge rates more like the original 74LS.

On the GLU replacement, I would use a 74AHCT1G125 instead of the 74LVC1G125. The 74LVC1G-series parts can be run at 5 volts but then they require CMOS input levels and also they have fast edge rates. So I'd switch for 74AHCT1G125.


@JDW is your SE Reloaded using a PAL/GAL/HAL GLU chip or a discrete logic based one? The GLU supplies a clock to the SCC, I think, so if there's ringing on that line due to sub-nanosecond edge rates, that could be causing a problem.

U2E & U2F chip locations use CD74ACT257E, as shown here.

U11F & U12F chip locations use SN74LS245NE4 as shown here.

U9D used the original HAL16L8ACN chip moved from the stock SE motherboard, as shown here.
Schematic page showing the GLU chip is attached as a PDF.

My complete BOM is here.

If I know what pins need probing with the scope and under what conditions, I can do that. However...

Ever since I put the SE Reloaded board inside the SE chassis, I've NOT had the double bong or mouse issues at all.

I spent another 6 hours testing today, running benchmarks, getting 1.2 million points in Crystal Quest, playing all the way up to level 53 on Lode Runner (I ended the game early because I was dead tired after that), working in PageMaker 5.0, doing Finder copies, file deletions, etc. It just worked flawlessly. No crashes, lockups or strangeness at all.

I tested with 0.6h firmware the whole time.

So if U2E, U2F, U11F and U12F are indeed "at fault" and truly need to be replaced with your recommended part numbers, how we can explain all my testing being problem free all of the sudden? Seems odd to me that putting the motherboard back inside the chassis would be the magic cure, but it has indeed cured the double bong and the mouse freeze and jump problem. The only thing it didn't cure was the freeze during MacTest SE, which still only occurs on SE Reloaded and not the stock SE motherboard, but like I said, Snooper 2.0 Modem and Printer port tests pass just fine on either of my motherboards.

So if I need to order new chips, per your suggestion, for the SE Reloaded board I can do that, but right now, I am not seeing the problems I had before. It's great but odd. I can't explain the "magic cure" at all.