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

@JDW This the double bong problem is so puzzling. Does it reliably continue to happen after the WarpSE is removed unless you wait for a while?

I suggest maybe to test this that you go back to version 0.6b or 0.6a and see if it continues to happen. By the way, 0.6c, 0.6d, 0.6e, and 0.6g are not fully functional so the only versions in the 0.6 series I recommend trying are 0.6a, 0.6b, 0.6f, and 0.6h. 0.6a is similar to the 1.x and 0.5-series versions, 0.6b integrates a new startup sequence, 0.6c, d, and e had revisions to the RAM controller and PDS bridge but were not fully functional. 0.6f is the first version with the RAM and PDS revisions that worked for me and with which I could find no further timing or logic mistakes. 0.6g removed the fixed wait state sound slowdown and made some preparations for the next hardware revisions but had a mistake that caused it not to work on the current hardware. 0.6h fixed that mistake. So in the 0.6 series, I only think 0.6a, 06.b, 0.6f, 0.6h are worth trying.

You also said it did occur at least once on your stock SE motherboard. Is that correct?

Another thing you could investigate is, when the double bong occurs, does the reset signal pulse low? In that case, a chip on the motherboard or WarpSE must be driving it. There are only a two chips in the Mac SE that can drive the reset pin low. It could be the Sony sound chip, since it generates the power-on reset signal, it could be the onboard MC68000 CPU, since it drives reset low when executing the RESET instruction. The BBU and other I/O chips receive the reset signal but I don't think they can drive it.

So if you can get the double bong to happen while monitoring the reset signal with an oscilloscope, then we can see if it's because of the reset pin being pulsed low or because of a software issue.

If the reset pin is pulsed low when the second bong happens, we can temporarily remove chips capable of driving the reset signal. For example, we could take out the motherboard CPU and Sony sound chip. I believe the motherboard CPU and Sony sound chip are unnecessary when using the WarpSE. Of course, without the sound chip, then SE will not produce audio, but the WarpSE duplicates the other function of the Sony chip, which is that it drives the reset pin low until power is ready. Because the WarpSE's CPLD drives reset low for almost 0.3 seconds when it powers on, as long as the power supply is a reliable unit that ramps up quickly, the Sony chip's power-on reset function is not needed. Then the test can be repeated and more chips added/removed until the problem is isolated.

If the reset pin is not being driven low when the second bong occurs, it may be a software issue, perhaps relating to RAM retention.

I have a thought to test for this. Remove two of the four RAM sticks from the Mac SE such that it only has 2 MB of RAM. The WarpSE will be able to operate and will have 4 MB of RAM, although the framebuffer and sound data in the motherboard RAM may be corrupted. This corruption, if it occurs, is harmless and not even "visible" to software running on the WarpSE's CPU. It's just a visual issue and will in no way affect execution. I think moving the mouse over any corrupted spots will cause them to reappear. The underlying problem will be fixed in the next hardware revision so that you do not need any particular RAM quantity in the Mac SE, but for now any visual corruption will have to be ignored if if occurs during this particular test.

Anyway, with only two RAM sticks and the WarpSE installed, once you are able to get the double bong, remove the WarpSE and see if you can get it again. If so, then reinstall the WarpSE, reproduce the double bong, remove the WarpSE, but then switch the RAM sticks for the other two which were not recently used. Make sure to leave the WarpSE out of the system and reboot. Double bong occurs? Try switching back and forth between RAM sticks to see if that affects the ability to get the double bong.

@JTRetro Thanks for posting the video! My next step is going to be to develop a control panel and hardware-software interface to allow the slowdown parameters to be adjusted. I'm not sure if I will be able to retain this in the final version, since it may be budgeted out of the CPLD chip if more important functions are needed. But we can test with it for now. This will also let @ppuskari try faster SCSI and LocalTalk without a reflash. Plus if you don't care about sound you can turn off the sound fix and reclaim 1.5% of speed or whatever the overhead is. So that's my next step but that'll take a bit of time to make the control panel, plus I'd like to make more prototypes and figure out @JDW's double bong issue. I am gonna post firmware 0.6i soon which has very accurate clock-gated slowdown, but other than trying that, there are no specific testing goals for now. Thanks again for testing!!

@JDW, the curious thing is that the WarpSE should always “listen to” the /IPL2 line from the interrupt key when starting up. If it doesn’t and starts up anyway, that means that something along the lines of the WarpSE not receiving the signal or not receiving power is occurring. And if the WarpSE ever “forgets” the current enablement setting, that can only be triggered by a glitch of the +5V power or 7.8336 MHz clock as delivered to the WarpSE. In case of a brownout or 7.8336 MHz clock glitch the WarpSE always tries to reset the system by pulsing /RESET low.

The most useful thing you could do right now to track down this issue is to see if the /RESET line pulses low right before the second bong occurs. If it does pulse low, the particular waveform is also useful. How long does it stay low? Is it between 220 and 290 milliseconds? Then it may be the WarpSE’s CPLD, although obvious the double bong occurs without the WarpSE installed. Are the high-to-low and low-to-high transitions clean, or is there a lot of “noise?” That could indicate a bad connection or solder joint.

I have not had a chance to watch your videos yet. Will do this in the next hour or so.


@iPhil64, thanks for helping to look into this issue! One tricky thing is that DRAM storage is based on capacitance, so the contents of RAM tend not to be erased immediately after power off but to slowly fade away to a “checkerboard” pattern over many seconds or even minutes. This can happen even if the power to the RAM is totally at 0 volts. For example, on new PCs, there’s the “cold boot attack,” where you can extract hard drive encryption keys from a computer by freezing its RAM while on (using freeze spray), then putting the RAM in another system, turning it on, and reading out the contents, including the key.

So one possibility is that the RAM is retaining some state but has become slightly corrupted. Then the software sees a magic number in RAM saying that the RAM is ready for a “warm boot,” but then it tries to use the data in RAM but it’s corrupted elsewhere and the system crashes. The WarpSE usually works exclusively out of its onboard RAM except when writing to the Mac’s screen framebuffer, but during slowdown, all writes are put out to the motherboard just as a byproduct of the logic design of the system. This will be rectified in the final version so we can possibly use the motherboard RAM as a ROM disk without it getting corrupted during slowdown. But the takeaway is that whenever the WarpSE happens to be in slowdown, which occurs for 0.2 milliseconds after an I/O chip on the motherboard is accessed, writes from the WarpSE will go through to the motherboard. So maybe a magic number like that is getting written through to RAM but then the other stuff it signifies isn’t. Hence why the WarpSE may trigger the problem and then it persists on the motherboard for a while. That’s just a theory though, and now James says the problem is not super related to the WarpSE, so we will have to investigate further.

@ppuskari Petar, thanks for your help testing the latest version! Glad to hear the address error issue has been isolated. I will try the SCSI Director 4.0 drivers myself and try to see exactly what’s triggering the address error with my logic analyzer.

As for the LocalTalk issues, there have been a lot of bugfixes and “under the hood” changes between “fastscsi” and 0.6h but not too many functional changes. Except on the builds where everything was broken lol but that was by mistake. The biggest functional change in that time is that the I/O slowdown period (which applied to all I/O chips except SCSI in “fastscsi”) went from 35ish microseconds to 203ish microseconds. I have firmware 0.6i ready which has almost perfectly cycle-accurate slowdown but I think I am going to skip this release and instead move on to the subsequent 0.7 which will have an address you can poke to change the accelerator settings. Eventually I may do a control panel like I said but if you have the Programmer’s Key then you can hit the NMI button to get the debugger, poke the address, and then quit the debugger and return to the Mac OS to try the new slowdown settings. Format will be something like this:

Slowdown control register is at address $F00XXX. Register is written using address bits 11 through 1:
A[11:8] - SlowTimeout[3:0] - Controls low long the accelerator is slowed down for in multiples of 14x 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

Hopefully I have room for all this in the CPLD, otherwise I may have to eliminate a few options. Not sure if it can ship in the final build either, at least not as an official feature, since I may need to reclaim space in the CPLD for other reasons. But anyway with this, you can play with the slowdown timeout and see if turning it back to setting 3 (28-42 microseconds) fixes the SCC. Plus you can also enable/disable fast SCSI, etc. The settings will stick through a reboot too, but not a power cycle since the CPLD just stores the settings in some registers and doesn’t write them to nonvolatile memory. I am probably gonna produce two builds of 0.7a, one with all slowdown features enabled and one with them all disabled (except maybe floppy). That way you can reboot with slowdown fully on or off and then see if changing the settings after that produces different results.

Anyway, I am working on a few more hardware things for testers, including some more WarpSE prototypes so everyone can compare between two units and also a little board that will let you reprogram the WarpSE outside of the Mac:

The WarpSE goes in the female header (will be a real DIN-41612 connector, this is just what I had for the 3d model). The you power it via USB or you could solder and zip tie banana cables to connect to a power supply (but not both at once!). The final production version will itself be able to be powered from the USB port so this shouldn’t be necessary on the final board revision, which I will send out eventually to all testers. I think the final version will be 25.946 MHz too since I just re-verified the timing for that speed.