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

[Zane Kaminski]

I think we can rectify the problem with the USB connector being too hard to plug in and too easy to knock off by changing the WarpSE design so it can powered through the USB port:

Now there's a diode from the USB power to the card's +5V plane. The diode could drop as much as 0.5 volts, so this would be out of spec for the MC68HC000, which requires 4.75 volts or more to run. This doesn't matter when powered just from USB. But when plugged into the Mac, the WarpSE actually has to work properly. So we can't just use another diode from the Mac's +5V powering the card's +5V chips. Instead we must use an "ideal diode" which is a chip that sorta emulates a diode but has much less forward voltage drop. I've chosen the Analog Devices (formerly Maxim) MAX40200AUK for this purpose. This thing will only drop 0.175 volts in the worst case at a forward current of 0.5 amps. Much better.

One problem is that theoretically, the WarpSE can use up to 0.6 amps in the worst case, more than the usual USB maximum of 0.5 amps. However I have not seen nearly that much with the board in the programming test fixture. So it should be okay.

Edit: Hmmm actually I don't think this is a good idea. I forgot to consider the situation where the Mac is powered off, the WarpSE is installed in the PDS slot, and the USB cable is plugged in, connecting the WarpSE to a PC providing +5V power. In this case, the WarpSE will output some "1"s onto the PDS bus, which is not allowed when the Mac is off. Hmmmmm I knew this would be too good to be true. Maybe the CPLD can gate its outputs and only enable them when the Mac is on, but it's still not a great way to do it for various reasons. Oh well.

 

[JDW]

Zane, I've been following the posts. Tracking info says the package you kindly shipped to me may arrive tomorrow. At this stage, there's no meaning for me to do any firmware update, correct? I should just proceed with testing the card as is, right? (Ignoring the sound issues, of course.)

UPDATE: WarpSE arrived this evening but I didn’t install it yet because I wanted to hear back from you first regarding whether or not I should do a firmware update.
but I do have a second question.

In an earlier post you wrote:

“MC68HC000 requires 4.75 volts or more to run”

What is the maximum voltage your card can handle?

The reason I ask is because I upgraded my main wiring harness with a 16 gauge wire and the motherboard voltage jumped to 5.1V. I should probably back it down inside the power supply, but it just got me curious what the low and high voltage specifications are for WarpSE. The Levco SpeedCard I have installed right now is handling the 5.1v just fine.

 

[Zane Kaminski]

More prototypes are being made!

@techknight I will send you another to replace your WarpSE with the broken port.

And new firmware! As I said before, the issue was with SCSI devices, not with sound per se. The reason it was crashing in the sound control panel was that the sound control panel has to read the sounds from disk. The latest firmware is attached. @JDW @techknight @ppuskari @Crutch I recommend everyone flash it before doing any further testing. I think the new firmware is likely to fix any remaining SCSI issues and also fix floppy disks but I'm not sure.

The main new thing in this release is the new I/O slowdown strategy. Not sure if anyone noticed, but sampled and four-voice sound actually worked in the earlier firmware versions. The strategy to fix sound was to add 16 wait states to each read/write for a while after writing to the sound buffer. However this was not a good way to slow down for I/O. Therefore SCSI and floppy devices frequently did not work and the sound control panel would crash while reading sounds from disk. Therefore in this build, I have introduced a new slowdown implementation.

Slowdown is still triggered whenever the fast CPU writes to the VIA, IWM/SWIM, SCC, or SCSI chip. During I/O slowdown, all RAM and ROM accesses which would be local to the accelerator card are put out on the PDS bus and the fast CPU waits for the PDS transaction to complete, even if data is already ready from the fast RAM or ROM on the WarpSE's internal bus. Adding this was enough to fix the crash in the sound control panel, at least for me.

Here's the latest benchmark:

It is a bit slower since we are triggering slowdown for a little bit after the I/O devices are accessed, but it's only like 1%.

I permanently enabled slowdown and then did a benchmark with Speedometer 3:

Mac SE without accelerator:

Much closer in speed than the previous slowdown method! The old method was faster at some things and slower at others. This way still has that problem but it's better. But alone it is not enough to fix sound! It sounds a little better but it's not perfect. So we must keep inserting the fixed number of wait states during sound generation. I have the WarpSE set up to trigger both the old and the new kinds of slowdown concurrently when the sound buffer is being filled and both have to complete before each memory access is allowed to continue.

So this technique is turning out well and we hopefully won't have to add that whole clock gated cycle-accurate slowdown thing to the CPLD logic. That would basically necessitate a rewrite and it wouldn't be extensible to future '030-based accelerators anyway.

Firmware is attached!

 

[JDW]

Because it's late here in Japan right now, I will begin my testing tomorrow on my lunch break and after work. In the meantime, please let me know if everyone is using Speedometer 3.06 or 3.23. That way I can make sure to use the same exact version everyone else is.

Since there was no comment regarding the maximum voltage for the WarpSE, I'll just leave the voltage as is (5.1v) and see how it goes.

 

[Zane Kaminski]

Here are some more firmwares with different slowdown options enabled.

"robust" is the same as what I just posted.
"slow" has PDS-synchronized slowdown enabled all the time. It should be only slightly faster than a Mac SE.
"fastscsi" is the same as robust except the machine doesn't slow down for SCSI
"nofixedwait" is the same as robust but there's only PDS-synchronized slowdown and the 16 wait state minimum is not imposed during sound slowdown

The most important versions to try are robust and fastscsi.

The goal is not to have a bunch of firmware versions but to use these to determine the source of any problems. Interestingly I can't get the crash to happen on "fastscsi" so maybe the sound control panel crash was from something else. If so, then we can switch to only using the fastscsi variant and speed SCSI back up!

Oh @JDW basically anything reasonable above 4.75 volts should be fine. Honestly it could even be lower and it would probably work. I think we will specify it for 4.75-5.25 volts though in the manual. Maybe 4.75-5.5 volts just so someone with 5.3 volts doesn't feel like they need to do anything.

Also it’s not super essential that we all use the same speedometer version. I think I was using 3.23 most recently but it doesn’t really matter. It’s just useful to get a vague idea of the machine’s speed. The main thing I’m trying to ascertain is whether there’s any compatibility issues that should be addressed

 

[JDW]

My first test, prior to flashing, confirms the audio crash, but only with certain sounds. Have a watch...

And here's a video of my first flashing experience, using FAST SCSI firmware, which seems to have cured the sound problem, at the expense of a mouse so jumpy it's not really usable:

I then tried reflashing with ROBUST firmware, but it failed 72.3% of the way through:



I then powered off, removed my BlueSCSIv1, carefully pulled out the USB cable from the WarpSE, then reinserted the cable and tried again. Flashing finished that time. Whew! Audio is not causing any crashing, and the audio sounds good too.

With ROBUST firmware installed in WarpSE, and while booted from my BlueSCSIv2 into System 7.1, I ran Speedometer 3.23 and got this result:

Norton System Info shows it to be faster than the 16MHz 68000 Levco SuperMac SpeedCard:

The SpeedCard has a 68881 FPU, but I have to disable it in the SpeedCard control panel or System Info will crash.

I just now flashed NoFixedWaitState. No problem flashing, but I had my BlueSCSI removed. No sound issues that I can find. Mouse seems to be working normally. Here's Speedometer 3.23...

Testing will continue tomorrow. Goodnight!

 

[Zane Kaminski]

@JDW can I ask what kind of system you were running the update program on when it crashed? What CPU and OS? Was it running in a virtual machine?

I think you'll find that on "nofixedwait", four-voice sound is slightly corrupted, maybe a bit better than without any slowdown but not perfect. I always test this with the folksy Russian music in Tetris. Like I said, in "robust", in addition to the PDS-synchronized slowdown, an extra 16 wait states are added to all bus transactions for the next few tens of microseconds after any write to the sound buffer. I wouldn't bother testing nofixedwait any more other than maybe to confirm that four-voice sound (e.g. in Tetris) doesn't sound great.

Also, I think it's important to note that the sound issue never crashes the computer. For example, the firmware originally had 16 wait state sound slowdown but no I/O-triggered slowdown of any kind. The slowdown was just for sound, so Tetris sounded the same as on an unaccelerated Mac but it crashed in the sound control panel. When I removed all slowdown, it still crashed in the sound control panel but the sounds sounded bad too.

Okay so I think sound slowdown is working well enough. Now we need to figure out which devices really need I/O slowdown. Here are all the devices that trigger I/O slowdown:

• Interrupt acknowledge ($F00000-$FFFFFF)
• VIA ($E00000-$EFFFFF)
• IWM/SWIM ($D00000-$DFFFFF)
• SCC ($900000-$9FFFFF and $B00000-$BFFFFF)
• SCSI ($500000-$5FFFFF)
• Sound buffer writes ($3FA100-$3FA3FF and $3FFD00-$3FFFFF)

And of course sound buffer writes also trigger sound slowdown which is an independent and concurrent mechanism. The key thing to remember is that slowdown occurs for all transactions for the next 28-43 microseconds after the CPU hits one of the trigger devices. I/O slowdown involves sending each read/write out to the PDS bus and waiting for it to complete, even if the data is coming from onboard RAM. This is kinda like asserting the MC68030's CDIS "cache disable" signal except it applies to the whole WarpSE accelerator subsystem. Sound slowdown is just that a minimum of 16 wait states are inserted into each read/write. Sound slowdown tends to slow the CPU more than than I/O slowdown, which was the point because just with I/O slowdown ( the "nofixedwait" firmeware), four voice sound still was messed up. With sound slowdown, it's important to note that since sound buffer writes also trigger I/O slowdown too, bus operations are slowed by the longer of the two.

Now there is just one main question we have to answer and address in the firmware before the WarpSE can be released:

Which of the I/O slowdown trigger devices are actually necessary? Which can be removed? If we keep the slowdown but it's not needed, then we lose out on some of the benefits. So I'd like to speed up SCSI if possible. IWM/SWIM should obviously stay slow. What about VIA? SCC? Interrupt acknowledge?

Soon I will make some more firmware versions that remove slowdown from one of those devices (int. ack., VIA, SCC, SCSI) and we will see which one brings back the sound control panel crash.

 

[Zane Kaminski]

@JDW Hmm yes we will have to fix this before the release. I think my SE has a larger hole there? I have bene using it exclusively on the bench though so I have not checked recently.

I think the easiest solution is to just let the WarpSE be powered by the USB port so you can flash it outside of the Mac. I will have to solve the remaining issues relating to tristating the bus if you do plug in the USB while the WarpSE is plugged in to the Mac and the Mac is not powered but that shouldn't be too hard.

 

[Zane Kaminski]

Well I guess there's actually another important thing I forgot about as well... how come fast SCSI makes the mouse jumpy? We will have to investigate this some more in the effort to speed up SCSI further.

 

[JDW]

Can I ask what kind of system you were running the update program on when it crashed? What CPU and OS? Was it running in a virtual machine?

I was using real PC. I believe it has an Intel processor running Windows 8 (Japanese language version), but I'll need to confirm that later since I'm starting my work day now.

I wouldn't bother testing nofixedwait any more other than maybe to confirm that four-voice sound (e.g. in Tetris) doesn't sound great.

Okay. This evening after work, I will test audio on Spectrum Holobyte Tetris and my mainstay, Winter Games.

But in terms of playing the System Beep sounds you saw in my video, those sounded pretty good, and a world better than how the Levco Supermac SpeedCard corrupts System Sounds and all audio playback.

Well I guess there's actually another important thing I forgot about as well... how come fast SCSI makes the mouse jumpy? We will have to investigate this some more in the effort to speed up SCSI further.

Yes. As shown in my "1st Flash using FAST SCSI" video, mouse movement was jumpy and problematic with that FastSCSI firmware, but I didn't have any mouse movement problem with Robust or NoFixedWait firmware.

 

[JDW]

Because "NoFixedWait" firmware is already flashed to my WarpSE, I spent my lunch break testing audio.

I really couldn't hear audible distortions through the speaker, so I wore headphones to check Spectrum Holobyte Tetris & Winter Games. Honestly, I really can't detect bad audio during the Winter Games Opening Ceremony. But it is horribly noticeable when I have the Levco Speedcard installed.

With Tetris, I had to listen to headphones 3 times, and reboot without WarpSE installed, to see the difference. It's subtle. At least, it is compared to the horrid SpeedCard audio. So yes, I do notice some distortions, but it's not too bad versus the Levco SpeedCard.

It's clear I need to re-flash the ROBUST firmware tonight after work, then give that a listen, then compare that to the stock audio (WarpSE not installed on the motherboard).

Lastly, here are the specs of the PC I am using to flash your firmware to WarpSE...

 

[JDW]

My audio tests are done.

In the video below, I compare the Stock SE audio with the Levco SpeedCard (terrible!) and WarpSE with NoWaitState and Robust firmware. Expand the text description on YouTube and you'll see it's fully indexed so you can jump to the individual timestamp sections with ease.

Audio was recorded with a stereo cable between the SE motherboard heaphone jack and my Panasonic GH5 with the audio set to -12 (as low as it would go). I set the Mac's audio to 1, but it still was a bit too hot. Even so, you can still hear the differences clearly. (If required, I can record the audio again using my SONY D100 recorder, which can better compensate for hot line inputs.)

When playing Winter Games audio, the stock SE sounds almost exactly like WarpSE audio (regardless of firmware) to my ears. Can any of you hear a difference? The horrible sound of the SpeedCard though is evident.

But with Tetris, that all goodness changes. WarpSE sounds better than the SpeedCard audio, but even if I flash Robust firmware to WarpSE, it still doesn't match the stock SE's audio.

Separately from that...

In this post, @techknight said 1.44MB floppies worked okay for him but 800K GCR disks did not. You probably fixed that because I didn't find issues with 800K disks via my FloppyEMU connected by ribbon cable to one of the SE motherboard's internal drive connectors. I booted Winter Games off such a floppy (FloppyEMU).

I will halt testing until I hear back about this.

 

[phipli]

Audio was recorded with a stereo cable between the SE motherboard heaphone jack and my Panasonic GH5 with the audio set to -12 (as low as it would go). I set the Mac's audio to 1, but it still was a bit too hot.

Yeah, the sound out on the SE isn't line level, just to warn you. It was designed to drive an external (I assume unamplified) speaker.

The "Robust Firmware" sounds the same as the stock SE to me, although you are probably getting digital clipping on all recordings if you're overdriving the recorder.

 

[phipli]

I recommend testing Prince of Persia - that's the game my cards struggle with most.

 

[JDW]

The "Robust Firmware" sounds the same as the stock SE to me...

On the first few recordings of Winter Games, yes, I agree. But not with Tetris. I tested with headphones, my 5K iMac's speakers, and my 16" M1 MBP speakers, and while it's easiest to tell the difference with headphones, I can hear the difference even using computer speakers.

With that said, the stock 8MHz CPU speed seems too slow to play it back without a few stutters here and there. Or maybe it's that BlueSCSIv1 is too slow? Not sure, but if you listen to the stock SE and Tetris, you will hear it elongate brief parts every now and then. Except for the occasional stutters, the audio is clean and free of distortions. When it stuttered during my recording session though, I was watching the screen, and the movement of text at the bottom of the screen (Tetris) briefly stopped whenever those sound glitches happened. Could just be that it was reading from the drive during those parts. But even with those little anomalies, the stock SE still makes the Tetris music sound better than the WarpSE, so I would recommend you give that part of my video another listen, possibly with headphones. The line level on that was lower than Winter Games, and it wasn't excessively too hot for my camera to record it.

I will bring my SONY D100 professional recorder to work tomorrow, along with a stereo to mono adapter (to record mono audio that will playback in both speakers or both ears of your headphones. I could have fixed that in FCPX, of course, but I was extremely busy this evening after work and needed to get home.

I recommend testing Prince of Persia - that's the game my cards struggle with most.

Thank you for the game recommendation. I will be happy to try that.

 

[phipli]

But not with Tetris. I tested with headphones, my 5K iMac's speakers, and my 16" M1 MBP speakers, and while it's easiest to tell the difference with headphones, I can hear the difference even using computer speakers.

Yes, you're right, sorry, I didn't listen that far.

Part of the issue is that there is quite heavy distortion through the entire video, even on the stock config. Either the games you've selected have very crude sound (they're not games I play), or you're getting clipping on your recorder. This would mean that changes in volume alone would influence how much distortion you got. Prince of Persia and Lemmings use nice audio samples (and also, I know what they should sound like, which helps!).

I will bring my SONY D100 professional recorder to work tomorrow, along with a stereo to mono adapter (to record mono audio that will playback in both speakers or both ears of your headphones. I could have fixed that in FCPX, of course, but I was extremely busy this evening after work and needed to get home.

I'd recommend perhaps using a microphone and recording the sound from the built in speaker. Like I mentioned, the sound out port isn't line level at all.

Note 8v peak-to-peak - line level voltage is closer to 1v peak to peak normally, but can be as much as 3.4v peak to peak I think(?), but that is for pro hardware. On the impedance side things should be ok - a line input would apply a load of 10k or higher usually, although what this means is that you're more likely to damage the recorder than the SE.

If you know the input impedance of your recorder, you could put an inline resistor in the cable to drop some of the voltage? But making custom cables is probably more effort than recording with a microphone.

 

[Zane Kaminski]

Hmm seems like the WarpSE will need to slow down even more when filling the sound buffer. Or maybe there's some kind of regression because I didn't think "robust" sounded any better than "nofixedwait" even though it should. Hmm that 8 volt peak-to-peak thing... didn't know that! I don't know much about speakers though.

I just got a new idea about sound slowdown earlier. The reason I'm hesitant to increase the effect of sound slowdown is because, what if you fill the sound buffer and then immediately (within 28 microseconds) go to using the floppy drive? The system will be too slow and and floppy won't work. The solution is obvious but I didn't realize it at first. What we need to do is immediately disable sound slowdown when an I/O device is accessed. Then we can basically slow the machine as much as we want during sound generation and there will be no ill effects on I/O since the machine will go back to I/O slowdown speed once I/O is accessed.

On the other hand, maybe there is a way to make the speed even closer to stock during sound slowdown. The reason that I/O slowdown alone is not enough to fix sound is because when generating sound, the MC68k "thinks" a lot between bus accesses. If the workload is totally bus-dominated, like MC68k is doing bus cycles back-to-back, I/O slowdown is exactly as fast as stock. This is because MC68k has only very limited prefetching and pipelining and gets the same amount of work done during a bus cycle at 7.8336 MHz and no wait states as it does at 25 MHz but with wait states making the average RAM access rate the same as the 7.8336 MHz case. On the other hand, if the CPU does some processing between bus cycles, then this occurs at 25 MHz on the WarpSE and so it's faster. Previously when I was contemplating cycle-accurate slowdown, I wanted the accelerated CPU to skip clocks all the time, even when it was using the bus. But this shouldn't really matter since the CPU only does a fixed amount of work during a bus cycle anyway.

So what I'm thinking is that after a bus cycle, the WarpSE will run the MC68k for one more clock to see if another bus cycle is occurring, and if not, it will skip clock pulses at a rate matching the 7.8336 MHz clock. This should have a very similar result to "cycle-accurate slowdown" where clock pulses to the MC68k are skipped all the time, but will not require a dramatic rewrite of the WarpSE firmware.

The reason skipping clock pulses all the time would be hard to implement is that the clock-skipping mechanism has to be very well integrated with the RAM and bus controller state machines. Like, what if the PDS bus bridge has just finished writing data to, say, the IWM. It signals /DTACK to the CPU but at that time, the CPU's clock happens to be gated, so it doesn't catch the /DTACK signal and keeps /AS asserted. Then the next clock cycle, the PDS bridge will see /AS still asserted and start another write to the IWM. This would be more or less innocuous with RAM/ROM (although it would ruin the cycle-accuracy) but you can't just write the same thing twice to an I/O chip. That won't work. So every subsystem in the WarpSE controller CPLD would have to know about whether the 68k clock is going to be gated. This basically doubles the number of cases that need analyzed for functional and timing correctness.

By just skipping clocks while the CPU's /AS is deasserted, we avoid all this trouble and the speed should be just about the same. The bus stays idle and none of the subsystems need to know that the CPU won't respond to their /DTACK since the bus is idle and the CPU is not asking the subsystems to do anything.

 

[JDW]

@Zane Kaminski
Thank you for the extension technical explanation. Your knowledge of things is impressive. It just blows my mind. That is of course why WarpSE is mind blowing too. I have nothing but high praise for the work you've done thus far. Bravo!

I plan to do more testing on my lunch break and after work, although my after work time is limited because Fridays are my late nights at work.

Regarding my audio recordings though, they were a bit hot, but by no means unusable or misleading. I've been a volunteer audio engineer for the last 34 years, and I know when sound is off. Basically, what you hear in my video (in my previous post) is largely what my ears hear from the Mac SE's speaker.

The most significant finding is that "Robust" isn't perfect like stock SE audio. So that is the main point we get from my video.

Yes, I will make further recordings to satisfy the purists who may not be so trusting of me. But to supplement that, I would advise @techknight and all the other people who have been sent a WarpSE to do their own audio tests with Spectrum Holobyte Tetris to see if they too can hear what I am hearing (which they should).

For now, I shall leave you with these benchmark test results of my Levco SpeedCard (16MHz 68000 with 68881 FPU), so as to put the speed of WarpSE into perspective (Speedometer 3.23 while booted into System 7.1 from BlueSCSIv1, with the SpeedCard's v1.7 control panel loaded and both options enabled):


SPEEDCARD:

WarpSE (ROBUST firmware):

Both Cards Compared:

As you can see from the above, WarpSE kicks booty on CPU & Graf, and it yields the highest PR too, despite lower scores for Disk and Math. The 68881 on the SpeedCard no doubt influences Whet, which is much faster.