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

[phipli]

The final word on "good recordings"...

But it largely shows you what my previous video did. And it makes the stock SE audio stuttering all the more clear. I supposed the rest of you hear that stuttering too, right?

In any case, it shows ROBUST doesn't playback the Tetris theme music as perfectly as the stock SE audio.

Good work - looks like setting the volume level to 1 brought it down into range. I was nervous to suggest that in case Tetris cranked it back up on launch and toasted your recorder.

Like @Andy said, the stuttering sounds and looks like a background task hogging the CPU. As a quick test, perhaps boot with extensions off and see if it still does it.

Could you upload a few seconds of the sound out jack recordings of the stock SE and of the accelerator as .wavs? Just like 5 seconds of each so I could have a quick look at the waveform. It might give some clues, although perhaps any filtering in the sound output circuit will smooth out any obvious dropped samples or anything.

Please feel free to say no if you're not set up to do it easily.

If I record it from the youtube video it will have been through compression.

 

[Zane Kaminski]

It really stood out to me in the original recording too. So much so that I dug out my SE and ran Tetris on it to verify. I noticed you were running System 7 and I wonder if there's a background task causing the stuttering.

On my SE with 2.5 megs of memory, running System 6.0.8 without Multi Finder, no extensions like After Dark, and using an old spinning hard disk, I hear no stuttering. If I turn on Multi Finder, I didn't hear anything, maybe a very slight stutter, but that might have been my imagination. I'm not setup to run System 7 on my SE at the moment, but I suspect there's a periodic task running, an extension, or just the system trying to do a lot more that is causing the stuttering.

Back on topic with the accelerator and sound, are there Sound Manager code differences between System 6 and 7 that might be affecting sound distortion? Could fixes for System 7 cause issues in System 6?

I think the ultimate solution is gonna be to develop a slowdown function in the accelerator that exactly mimics the speed of the Mac SE. That will fix any and all speed-dependent problems, no matter the OS.

The origin of the sound problem is that the CPU is too fast and writes to the whole sound buffer before the Mac can finish playing it. This causes a skip in sound playback 60 times per second and the audio output sounds chopped up with this ugly 60 Hz tone superimposed on top from the repeated “pop” that occurs when the skip happens.

More specifically, in the sound manager, when generating four-voice sound, the CPU starts generating samples after vertical blanking approximately in the middle of the sound buffer. This is to basically give the motherboard logic a head start because even an unaccelerated CPU generates samples twice as fast as the motherboard plays them. With an accelerated CPU, this head start is not enough and the corruption occurs. If the CPU is really fast then a large portion of the sound buffer ends up overwritten and the skip is more obvious. If the CPU is only a little faster than stock, less of the sound buffer is overwritten before it can be played and the skip is smaller and less objectionable. Our goal is to slow the CPU down to exactly the right speed so that it does not outrun sound playback. Or maybe it can be a bit slower but we have to immediately disable the extra slowdown once any other I/O chip is accessed.

So whenever the accelerated CPU touches one of the I/O chips or writes to the sound buffer, slowdown will be triggered for the next 28-42 microseconds (0.028-0.042 milliseconds). The slowdown timer is restarted every time another write to the sound buffer occurs so that slowdown happens continuously in the sound manager’s routine to fill the buffer. If we had the slowdown speed exactly right then there would be absolutely zero issues with sound or any I/O device. “PDS-synchronized I/O slowdown” is close but it’s still a little bit faster than the Mac SE in the case where the CPU “thinks” in between bus cycles. Hence the sound is still a little messed up.

You can see this in the Speedometer results where I permanently enabled slowdown. In the CPU test, which could more accurately be called the memory latency test, the CPU’s performance is bus-limited, so the results are almost identical between the Mac SE and WarpSE. That is, there are very few instruction sequences in the CPU benchmark where the bus cycles are not back-to-back. But in the graphics and math tests, the instructions used end up causing the 68k to read some data from memory and then chew on it for a few clocks before doing another bus cycle. So the increased frequency helps in the math and graphics tests and the performance is faster than stock, which is not desirable during slowdown.

Therefore I have developed a new slowdown technique. During slowdown, all transactions will still be put out on the PDS to equalize the bus speed to stock, but instead of also putting 16 wait states, which was fairly heavy-handed, I’m gonna have the WarpSE skip sending some clock pulses to the fast CPU when the bus is idle. The logic in the fast clock domain will watch the 7.8336 MHz clock of the Mac and only pulse the fast CPU clock right after a 7.8336 MHz clock pulse occurs. This is tricky because there are some statistical/discrete math kind of subtleties relating to the relative phase of the 7.8336 MHz and 25 MHz clocks so the accelerator could still be a hair faster than stock during slowdown but I think it will be fine.

That’s the idea, that during slowdown the WarpSE will get as close as possible to how a regular Mac SE performs. Overall performance during four-voice sound playback will be around 16 MHz speed since the WarpSE spends half of the CPU at 7.8336 MHz and the other half of the time at 25 MHz. So the average is like 16.4 MHz. Single-voice sampled sound will be much faster since a smaller amount of time is spent writing to the sound buffer. I’ve written the code for this and will be trying it soon.

 

[Kai Robinson]

I had a random thought - could you implement an SRAM buffer? CPU processes audio...forwards to buffer...buffer forwards to sound output at 7.83MHz?

 

[Zane Kaminski]

I had a random thought - could you implement an SRAM buffer? CPU processes audio...forwards to buffer...buffer forwards to sound output at 7.83MHz?

Yessss and it would improve performance but it requires a much more complicated bus bridge between the fast and PDS buses. Right now, the WarpSE can only put out an address/data onto the PDS that the fast CPU is driving at that moment. The bridge can latch the address/data and save it for later (posted write) so that the accelerated CPU can continue executing from onboard RAM/ROM. However the bridge cannot go out of order or mix writes from different sources such as a buffer with sound writes.

In the future, especially on a possible ‘030-based accelerator where you can’t slow the 68030 down precisely to 68000 speeds, we will have to do something like you’re describing. On a future ‘030 accelerator I would like the PDS bus bridge to have three sources from which it can get a transaction to do. There should be one buffer for video writes, one buffer for sound writes, and one other unbuffered input for everything else. The bus bridge will switch between these sources as appropriate. Video writes will go out at full speed in the absence of other writes, and sound writes will trickle out slowly so as to mimic the timing of a real 68000 writing to the sound buffer. Other writes will have priority and occur as soon as the ‘030 produces them. Of course a larger (BGA) FPGA is required for this since it needs to have enough pins to connect to all of the CPU pins as well as the PDS bus. Right now the WarpSE controller mostly only connects to the fast CPU, plus a few wires of the PDS bus, but none of either data bus.