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

We have been investigating various possible issues impacting LocalTalk. We thought we had the cause figured out but maybe not... Basically, when the 68k CPU receives an interrupt, it executes an "interrupt acknowledge cycle" on the bus. Long story short, due to the interrupt acknowledge cycle using the /VPA cycle termination method, a long and variable amount of time is required to execute the interrupt acknowledge cycle. What was happening on the WarpSE was that the controller logic in the CPLD was waiting for the interrupt acknowledge cycle to finish on the PDS before then repeating the same interrupt acknowledge cycle on the fast bus. This was increasing the interrupt latency over the stock setup. Now in the latest version, 0.7c, interrupt acknowledge cycles are posted to the PDS bus and execute on both buses concurrently, so the interrupt latency on WarpSE should be the same or better.

However... it would be nice if this solved the LocalTalk problem but I am afraid that it won't. I read the serial port section in Guide to the Macintosh Family Hardware and it says that AppleTalk is actually not interrupt-driven and instead uses polling. Hmm. On the other hand, I guess an AppleTalk operation has to start by being triggered by an interrupt, right? Otherwise how would the Mac know it's happening? Checking once during vblank sounds too infrequent. So maybe the interrupt latency thing was part of the problem? But maybe not.

Anyway, now I have version 0.7c, which fixes the interrupt latency issue and also has a slightly revised slowdown policy. Now slowdown is not triggered by an SCC write or SCC interrupt, although either of those conditions occurring doesn't cancel slowdown. It just doesn't prolong it. Clock gating is only enabled after a sound buffer write or VIA interrupt, but is disabled right when an SCC interrupt or any other I/O access occurs. 0.7c comes in three variants, default, fast, and slow. Default has slowdown triggered as I described, fast never slows down (so it will crash in the sound control panel, for example), and slow is always in slowdown (with clock gating to 7.8336 MHz).

@ppuskari Can you try 0.7c and see if this fixes LocalTalk? If not, does 0.7c-fast work? What about 0.7c-slow? Also if you've had no errors while flashing in the past, it's probably safe to power-cycle the Mac after the firmware update gets to 55% to speed things up. After 53.something percent it's just verifying what was written, which takes like 4x longer than the first part where data is being written. Oh, one more thing, what Mac OS version are you using for your testing? If 0.7c still doesn't fix it, can you try the Network Software Installer to update your AppleTalk version to 58.1.4? There are some notes about the Brainstorm accelerator suggesting that version 56+ is required or something to that effect. I think 56 is included with System 7 though so I dunno if this will help if you're not using System 6.

We're super close but this issue is very hard to pin down! If 0.7c doesn't work then I have one more change in mind after studying the old "fastscsi." But if that doesn't work and if there are no obvious next steps then we will have to pause work on the WarpSE for a bit while I do some other GW-related tasks and free up space on my workbench for a little network of accelerated Mac SEs.

0.7c is attached! @JDW @JTRetro you guys can try it if you want (version 0.7c is recommended, not the fast/slow variants) but I say don't bother since it's really just aimed at fixing the LocalTalk issues.

@Kai Robinson As long as Petar's 15.6672 MHz clock is accurate, it should work. The 4-4-4-5 thing to get the 4.25x average divide rate does reduce the baud rate tolerance a bit, but it should be fine. Baud rates can be slightly off because the serial chip does 16x oversampling and can still count the pulses even if there's a small speed mismatch between the machines. The 4-4-4-5 thing basically just eats away a bit of that margin by sampling a bit later every once in a while. No big deal though and it shouldn't have anything to do with the WarpSE's clock or anything. The LocalTalk issue is probably just that something is happening too fast or too slow for some assumptions made when writing the software. Hopefully we can just analyze the situation more and refine the slowdown rules to fix the issue.


@JDW thanks for trying the TechStep! I think the reason it says you have a SWIM is because the WarpSE uses the SWIM (edit: FDHD) ROM. No big deal, I have been the WarpSE exclusively in a machine with an IWM and the IWM/ROM mismatch is no big deal.

The TechStep is mostly to check for board-level connectivity issues. So it does a lot of tests on the hardware but the goal is just to exercise every board-level circuit path. Its purpose is not really design validation. For example, it wouldn't necessarily find a subtle bug in the CPU or one of the I/O chips. So software which expects certain timing to hold is not necessarily gonna be compatible with an accelerator, but it's not like the TechStep is gonna check for every specific timing-dependent circumstance. If it did then it would fail on any accelerator. So the TechStep is good to check basic functions but it's not a great design validation tool and it's more for board-level diagnostic testing.

And thanks for trying AppleTalk! Too bad it didn't work lol though I guess then that means we would have to track down some obscure issue with Petar's machine hahah. In the future once it's working better you can try some simple file transfers (and maybe take the checksum using md5fl).


@JDW @ppuskari If AppleTalk works better in 0.7c, then either it's because of the VMA/VPA-related interrupt latency fix, because slowdown is no longer triggered on SCC accesses, or because slowdown is no longer triggered on /IPL1 interrupts (which are from the SCC). So if it's better in 0.7c and the reason is not related to the interrupt latency fix, then we still need more changes to robustly solve the problem. Serial communications on an AppleTalk network can happen at any time, so a packet could come in right as a previously triggered slowdown is still pending. In that case the remaining slowdown time could screw things up.

I have been studying the differences between "fastscsi" where AppleTalk worked and subsequent versions. What stands out the most is that the slowdown time interval is really brief on fastscsi. It's not enough to fix sound all the way. That in combination with the fact that there's one less thing (SCSI) triggering slowdown again makes me think that slowdown and AppleTalk don't like each other. So if LocalTalk works on 0.7c-fast, then we know that we need to apply slowdown more cautiously. I wonder what happens on 0.7c-slow? It's supposed to be very close to the original speed. Maybe some serial-related routine measures the machine speed and compiles itself at boot?

Anyway, my current understanding is, we need a bit of slowdown after accessing the VIA, otherwise there's the crash in the sound control panel. We also need a little bit of slowdown after accessing the IWM, otherwise 800k floppies don't work. But we need a lot of slowdown after accessing the sound buffer and after receiving a VIA interrupt (because that ultimately triggers sound generation), otherwise sound is corrupted. But slowdown must be disabled once any SCC-related stuff happens.

So my new idea which will be implemented in 0.7d is... When the CPU gets get an SCC interrupt on the /IPL1 line or accesses the SCC chip, slowdown will be disabled for a little bit. But if this amounted to forcing the slowdown counter to 0, then if the Mac received a byte on the serial port right after the VIA's vertical blanking interrupt, the slowdown counter would be cleared and sound generation for that frame would proceed at full speed. That would corrupt the sound buffer. So instead, an SCC interrupt should set a separate "speedup" timer to inhibit slowdown for a little while. So for the next ~21 microseconds after an SCC interrupt is received or the SCC is accessed, the CPU should speed up to ensure the processing occurs in time, but then slowdown should resume if it was already ongoing. And then of course because we need slowdown for the VIA and IWM, accessing those should clear the speedup timer. If the VIA/IWM and SCC are accessed alternatingly, then slowdown will alternate from on after a VIA/IWM access to off after an SCC access. Should be fine though.

Thanks!!

@ppuskari Great news!! I think the WarpSE is almost ready for release. Soon I am gonna prepare version 0.7d which will come in two variants. I want to see, what in 0.7c fixed LocalTalk? Was it the interrupt latency or was it that we don't trigger slowdown on SCC accesses? So I will have 0.7d, which will be as I described in my post above, and then 0.7d-slowscc, where slowdown will be imposed on SCC accesses as was the case in previous versions. Then if 0.7d continues to work but 0.7d-slowscc doesn't, that means LocalTalk doesn't like slowdown. Otherwise if both 0.7d variants work then we know it was the interrupt latency.

Once we get this information, I think I can make the final slowdown policy! Then I will order the final board revision and we will go for version 1.0. Current testers are also gonna get at least one more WarpSE prototype too since the final board will be at 25.946 MHz, I think, and we will need to test that a bit. Maybe a few new testers will be needed to complete the testing too.

Okay! Here's 0.7d. There are three variants:

• 0.7d's slowdown policy does not reference SCC accesses at all. This is what I hope to ship since I think the problem was related to interrupt latency, not slowdown.
• 0.7d-slowscc is the same as the regular 0.7d but SCC accesses and interrupts trigger slowdown
• 0.7d-fastscc has the "speedup" timer. For a little bit after an SCC access or interrupt, the WarpSE is forced out of slowdown. Once speedup is over any previous slowdown can resume

So for @JDW and @ppuskari and anyone testing with a LocalTalk network, try 0.7d-slowscc first. Does LocalTalk work? If so then the interrupt latency problem was breaking LocalTalk, not slowdown. In that case regular 0.7d is recommended. But if 0.7d-slowscc doesn't work, then try 0.7d-fastscc, which inhibits a pending slowdown for a bit after an SCC access or interrupt. Hopefully 0.7d-slowscc will work though, indicating that regular 0.7d should have no problems.

If everything is working well then we can add back the slowdown control register and proceed to release candidate stage!!

Interesting! This means that triggering slowdown after an SCC access or interrupt messes up LocalTalk. But in 0.7d-slowscc, after slowdown is triggered by the SCC or its interrupt, the WarpSE should still be a little bit faster than the Mac SE because the CPU clock is still running at 25 MHz despite RAM accesses being slowed down to exactly motherboard speed. However, Petar says that LocalTalk works on 0.7c-slow, which is slow all the time! So the takeaway here is that the LocalTalk driver does something based on the CPU speed and doesn't like when the speed changes too dramatically. So since LocalTalk and slowdown do not like each other, we must ensure it's disabled for a little bit after anything relating to the SCC happens. That's the purpose of the "speedup" timer in 0.7d-fastscc. Soon I will have 0.7e, which will be exactly the same as 0.7d-fastscc but I will also add back a new version of the settings register. So there should be no compatibility differences between 0.7d-fastscc and 0.7e as long as you don't change the settings register.

Edit: James, can you try one more thing? What about accessing a floppy over LocalTalk (is this even possible? I don't think I have ever tried). Can you try this if it's even possible to share a floppy?