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

JDW said:

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.

Click to expand...

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 said:

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 ?

Click to expand...

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 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.

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):
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:

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!

@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.