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

[lilliputian]

What may I ask contributes the most to the cost of the device? (Obviously I'm sure the labor involved in creating it is reason enough!)

 

[Zane Kaminski]

It would be cute to make a little badge that fits in the front panel like the old contemporary accelerators did.

Hmmm yeah good idea I'll have to think about this. But we have no good logo! So the badge would be kinda boring lol.

What may I ask contributes the most to the cost of the device? (Obviously I'm sure the labor involved in creating it is reason enough!)

The costs break down like so:

SMD capacitors and resistors - $2
(1) 3.3V voltage regulator - $1
(2) 2Mx8 DRAM - $5
(2) 512kx8 flash - $5
(13) 74AHCT573 latching buffer - $4
(1) Xilinx XC95144XL CPLD - acquired 2019 for $5, now $15+
(1) 68HC000 - $5? See below
(2) crystal oscillators - $2
Update system, misc. other parts - $2
PCB - $3
(1) PDS connector - $2
Consumables (solder, flux, cleaning agents, etc.) - $1
Packaging (esd bag, foam, mailer, box?) - $5
Domestic shipping - $5

So that’s roughly $56 in materials and then of course we have to do the assembly, testing, any possible rework, cleaning, and packaging. All of these parts have been rising in price but the cost for the 68HC000 and XC95144XL is particularly uncertain. 68k CPUs are not really made anymore. We would like to acquire new old stock 68HC000s but that’s a bit much to ask. So instead we are looking for nice socket pulls. We will have to purchase from multiple vendors and figure out who has the best MC68HC000 chips. The Xilinx CPLD has been discontinued since the beginning of the chip shortage and therefore is increasing in price. We have ~100 of these (I thought we had more but I guess not) and they were something like $5 a while ago but now the price for the Xilinx CPLD is $15 or more to get one that hasn't been desoldered form a board. The DRAM is also legacy but we have good sources for it. Eventually we would like to switch to a SDRAM-based solution for the RAM and ROM and at the same time switch to using a newer CPLD/FPGA than the Xilinx XC95144XL. But the first version is coming out with the legacy chips.

 

[mg.man]

Here's a simple PDF export from MS Word, though I do like the inverted colors for alxlab's version.

Couldn't help myself...

 

[jasa1063]

I am really looking forward to this. What will be the process to order one of these when available?

 

[Zane Kaminski]

I am really looking forward to this. What will be the process to order one of these when available?

We (Garrett’s Workshop) sell our products on eBay and Tindie, so you’ll be able to buy it on there as usual.

 

[jasa1063]

We (Garrett’s Workshop) sell our products on eBay and Tindie, so you’ll be able to buy it on there as usual.

Thanks for the info. I really like Tindie as an alternative to eBay.

 

[Zane Kaminski]

Thanks for the info. I really like Tindie as an alternative to eBay.

Tindie is okay but we actually pay less fees on eBay than on Tindie. Since we sell a good bit, we’ve gotten whatever eBay subscription gets you the reduced fees. We also list our (new manufacture) gizmos in categories like “PC Hardware - RAM” instead of “Vintage Computers - Parts and Accessories.” New stuff categories typically have lower fees. Thus the fee rate ends up being slightly lower on eBay than on Tindie.

I also have to say that I feel a little bit maligned about Tindie’s customer service. About a year ago, there was a particularly disturbing technical error in Tindie’s system. Multiple customers placed orders with us on Tindie and were told their orders were accepted, yet we could not see them from Tindie’s interface. It was weeks later, after receiving complaints about the missing orders, that we figured out the problem. Obviously this is a big deal since our customers were left feeling scammed and the only explanation we could offer to them, although true, would have sounded like BS… "Sorry we didn't do anything about your order for two months; there was some kind of glitch." So after uncovering the problem, which evidently affected other sellers as well, we politely requested that Tindie provide an apology to our customers and some kind of nominal discount on the items they purchased. We really wanted the apology to come from Tindie as well as us, since it's basically unheard of on eBay, etc. for an order to be "lost" for so long. It was quite hard to get in contact with anyone with any authority at Tindie, and when I finally did get in touch with someone, they were reluctant about the apology and discount. I had to threaten to quit selling on Tindie before they would agree to do anything for the affected customers. Eventually I was told literally, "okay we can do the discount, but don't tell anyone about it." Hahahahahah! I think part of the reason for all this--the glitch as well as the difficulty getting it made right from a customer service perspective--is that Tindie is like the fourth level down in a big corporate hierarchy. Siemens owns SupplyFrame owns Hackaday (media group) owns Tindie. Tindie doesn't generate a lot of revenue and so it's not really a priority for the organization as a whole.

Regarding eBay sellers, etc., eBay is not a great community although I don’t think I’ve ever felt truly ripped off as a buyer on eBay. Any time I’ve been the victim of some scam or counterfeiting or whatever it’s been easy to get the issue resolved or my money back. In my experience on eBay, honest people usually fix their mistakes and scammers seem to know to stay on the down-low and not put up a big fight so as to avoid drawing more attention to themselves.

 

[JDW]

Regarding upclocked 68000s, here's some data of the Speedometer 3.2 performance increase from my FDHD SE's 16Mhz 68000 SuperMac Speedcard vs. stock...

A very kind soul donated an entire SE motherboard with RAM and a SuperMac SpeedCard installed (16MHz 68000 with 68881 FPU!), and I had a chance to test it this evening. Two points of interest...

1. The card can be disabled without opening the Mac, simply by switching on the Mac's power, quickly pressing and holding the Interrupt Switch, then press and release Reset, wait for the bong, then release Interrupt. That reverts the machine to use the stock SE motherboard, just as if the SpeedCard was not installed. This is a very neat and useful feature, @Zane Kaminski. If your forthcoming accelerator has a similar means of being temporarily disabled (it remains disabled until you power off and on again), that would be outstanding.

2. Sound is distorted when the SpeedCard is enabled, at least on some games. I've only tested it on one floppy thus far — Epyx Winter Games. I made a short video so you can hear the sound distorted (with SpeedCard enabled) and with normal sound (stock SE board enabled):

@Ubik since you have the SpeedCard too, can you confirm if you have audio problems? If not, have you tested with Winter Games (booting from the disk)?

I do not have the SpeedCard control panel installed, if that matters. But it wouldn't be practical to install it on every floppy disk, since some game disks lack the space for it. (Assuming the presence of that control panel even solves the audio problem, which it may not.)

 

[Zane Kaminski]

1. The card can be disabled without opening the Mac

Yes, I would like to implement this. One of my final changes to the WarpSE was to tap the /IPL2 interrupt line which connects to the programmers' switch. This was in pursuit of the goal of eliminating the need for the DIP switch. Therefore I would like to support selection of one of the following options using the two programmer's keys:

• 25 MHz / fast ROM
• 20 MHz / fast ROM
• Accelerator disabled
• 20 MHz / motherboard ROM

Of course would have to include a programmer's switch with the accelerator if we were to eliminate the DIP switch. I'll look in to some new 3d-printed ones. This approach would also mean there would be a "default" speed of 25 MHz and to go to 20 MHz you'd have to do something with the buttons.

Anyway I think the method to select one of the options would be to hold the reset button, flip the power switch, then press the programmer's key some number of times while still holding reset. So you'd press nothing to use 25 MHz, mode, one press would select 20 MHz, two presses would disable the accelerator, and three presses would use motherboard ROM. I guess there could be an alternate firmware which has 20 MHz mode as default and then you press once for 25 MHz.

Sound is distorted when the SpeedCard is enabled

Yes, I think our hardware design addresses this. I wrote the following about the sound issue a few months ago:

We are also going to try and fix the sound issue in hardware... fingers crossed on this because I don't 100% understand it but I think I know enough to address the problem. What I know is that when using more intensive sound generation modes (i.e. four-voice mode), the Sound Manager of the Mac OS is programmed to update the sound buffer at a different point than in the simpler modes. Presumably in the four-voice mode, the point in the sound buffer where the rewriting begins is closer to the current sample being played, the idea being that the samples will take longer to generate and the current audio being played won't be overwritten. So I think what's happening is that with an accelerated CPU, the Sound Manager blasts through updating the sound buffer very quickly and starts overwriting the current samples being played, in essence suddenly "skipping" the playback a little bit. This happens 60 times per second since the Sound Manager updates the sound buffer every frame. So the sound you get is the audio you're supposed to hear but it keeps skipping around 60 times per second, and then because of the skipping around, the samples often line up so as to produce a 60 Hz sound. Of course the Mac's speaker has little bass so you only hear the harmonics of the 60 Hz fundamental frequency. That's what it sounds like to me--the right sound but all broken up and then some other tones superimposed on top. However, I have not really thoroughly analyzed it and I don't even have an accelerated Plus or SE myself. I'm just referring to YouTube videos on the sound issue that I've seen.

So if this is really true then the solution for the sound problem is to slow the CPU way down when writing to the sound buffer, enforcing a maximum MB/sec bandwidth on that area of memory such that the timing of existing sound drivers is the same as before. Unfortunately that basically means that whatever percentage of time is spent on updating the sound buffer will go unaccelerated, but that's okay. I will have to tune the bandwidth limit a bit but I think this is the right way to go. And of course the limit will just apply to the sound buffer RAM areas so as to avoid slowing down the other areas of RAM that are in use the rest of the time when the CPU is doing the program logic and GUI operations and whatnot.

I just have to determine the appropriate speed-limiting factor once I get the accelerator working. The aim is to achieve some MB/sec speed limitation on the sound buffer but the way you set the Sound QoS is not by supplying a MB/sec figure; the speed limiter has a bit of a strange way of measuring bandwidth. The way the current WarpSE firmware does the speed limitation is idiosyncratic to the implementation of the sound QoS block as an extension of the RAM refresh system.

On that note, one thing I need to change to support "push-button mode selection" is to switch the RAM refresh system to running from the Mac's 7.8336 MHz clock rather than from the 20/25 MHz 68k clock. The RAM refresh system is the only part of the WarpSE capable of measuring a long time period (more than a few clock cycles). This is by design; it takes precious macrocells in the CPLD to count out a long time period so we would like to share the long-period counter among all the subsystems that need to measure long time periods. Currently only the RAM refresh, sound QoS, and BERR timeout systems need to measure long time periods. However if we add push-button mode selection to the WarpSE, we have to "debounce" the button presses; a long-period counter is useful for this purpose. Since the push-button mode selection is supposed to allow changing between the 20 and 25 MHz clock signals, we can't have it run from the same clock it's controlling the switchover of. The way I have it currently, there will likely be a glitch when the clock is switched and that would mess up the push-button mode selection controller. So we will have to switch the long-period counter to running from the Mac's 7.8336 MHz clock. In doing so, sound QoS, RAM refresh, BERR timeout, and push-button mode selection will all move from the 20/25 MHz clock domain to the 7.8336 MHz clock domain and outputs from these systems will have to be synchronized back to the 20/25 MHz front-side-bus controller. A little more complex, I guess, but honestly it should have been this way all along. Counting the RAM refresh period from the variable-frequency 20/25 MHz clock meant that the RAM is refreshed 25% more often than necessary when running at 25 MHz. The WarpSE tries to hide RAM refresh during a ROM or I/O access but nevertheless this change will result in a tiny (<0.1%) speed boost.


Edit:
Oh also, since I posted that explanation about the distortion problem and sound QoS subsystem in the WarpSE, I did a little experiment about the source of the sound distortion, but it didn't yield any good results. If my theory on how the distortion is generated is true, the 60 Hz harmonics would be obviously present in the spectrum. So I captured audio of the distorted and correct sound from a video by Adrian's Digital Basement and did an FFT on it. I couldn't see anything of merit in the spectrograph though. But maybe @JDW you could capture both the correct and dirstorted audio directly from the Mac's 3.5mm jack. With that higher-quality sound capture, maybe the results of the spectral analysis would be more insightful.

 

[JDW]

...maybe @JDW you could capture both the correct and distorted audio directly from the Mac's 3.5mm jack. With that higher-quality sound capture, maybe the results of the spectral analysis would be more insightful.

I will try to make time to do that either tonight or tomorrow. I have a Sony D-100 Audio Recorder with a line level 1/8" input jack. It might work with the headphone output of the SE if I reduce the volume very low. I will experiment and see what happens. If the voltage level is low enough to make a recording on my D-100, I can record LPCM at up to 192kHz/24 bit.

 

[Zane Kaminski]

I will try to make time to do that either tonight or tomorrow. I have a Sony D-100 Audio Recorder with a line level 1/8" input jack. It might work with the headphone output of the SE if I reduce the volume very low. I will experiment and see what happens. If the voltage level is low enough to make a recording on my D-100, I can record LPCM at up to 192kHz/24 bit.

Thanks! Oh also, no need to do the whole 192 kHz / 24 bit. The Mac is only 22 kHz / 8 bit so (according to the well-known Nyquist-Shannon theorem) CD-quality 44.1 kHz (or 48 kHz) / 16 bit will more than suffice. The distortion is a digital artifact after all, not some kind of analog issue where there could be some useful information outside the range of the Mac's sample rate and depth.

 

[JDW]

Thanks! Oh also, no need to do the whole 192 kHz / 24 bit. The Mac is only 22 kHz / 8 bit so (according to the well-known Nyquist-Shannon theorem) CD-quality 44.1 kHz (or 48 kHz) / 16 bit will more than suffice. The distortion is a digital artifact after all, not some kind of analog issue where there could be some useful information outside the range of the Mac's sample rate and depth.

Per your request, I will attempt to record a 48kHz, 16-bit WAV or AIFF (LCPM) file for you tonight or tomorrow using my D-100 recorder.

If you are ultimately able to solve the distorted sound problem, it really would be magical. @Kay K.M.Mods has told me many times about his Carrera040 card with audio problems (Bolle's recreation), which mysteriously only has distorted audio in his SE/30 but not a IIci (if memory serves me correctly). Without good sound, an accelerator has diminished usefulness.

 

[Zane Kaminski]

Per your request, I will attempt to record a 48kHz, 16-bit WAV or AIFF (LCPM) file for you tonight or tomorrow using my D-100 recorder.

If you are ultimately able to solve the distorted sound problem, it really would be magical. @Kay K.M.Mods has told me many times about his Carrera040 card with audio problems (Bolle's recreation), which mysteriously only has distorted audio in his SE/30 but not a IIci (if memory serves me correctly). Without good sound, an accelerator has diminished usefulness.

The cause of the problem on the "Mac I" series (i.e. 128, 512, Plus, SE) and on the "Mac II" series (II, SE/30, etc.) is at least slightly different because the machines' audio systems work differently.

On the "Mac I," the vblank interrupt occurs every frame, during which the Mac redraws the mouse and also updates the sound buffer. In the Mac, the sound buffer is stored in a fixed location in main RAM and has 370 8-bit samples. The sound system runs in lockstep with the video system, outputting one new sample each for vertical line scanned out on the display: 370 samples in the buffer corresponds to 370 vertical lines on the screen (342 visible and 28 for retrace).

On the Mac II (and SE/30), it's different. The sound buffer is not stored in main RAM but is instead stored in a FIFO (queue) buffer in the Apple Sound Chip (ASC). This change is because the Mac II doesn't have integrated video, so there was no integrated video subsystem off of which to hang the sound generation. This is even true of the Mac IIci and IIsi, even though they have "vampire video." The ASC worked well and was part of the chipset by that point so there was no reason to take it out and put back RAM-based sound. Now the Apple Sound Chip supposedly implements a FIFO buffer which stores the samples. The cause could be similar to on the "Mac I"--the FIFO is getting filled up too quickly by the faster processor and we just need to apply the same rate limitation technique as in the WarpSE. Or the reason for the issue could be totally different. Or I could be wrong about the cause of the sound distortion on the "Mac I" series.

Hmm... Does the issue occur on the SE/30 with Carrera040 if you turn off the '040's caches in order to slow it down?

 

[JDW]

Does the issue occur on the SE/30 with Carrera040 if you turn off the '040's caches in order to slow it down?

I don't own that Carrera040, so I cannot say for sure. I sent Kay a message, asking him to reply to your question here.

I can only say my SE/30 doesn't have any sound issues with the Daystar Turbo040, or socketed Daystar PowerCache, or PDS DiiMO accelerator cards. Apparently, only the Carrera040 has the sound issues. And only the Carrera040 boots from the 030, and then switches on the 040 sometime after the boot sequence. Not sure if that CPU switching function is the cause of the audio glitches, but that is a fundamental difference from all other accelerators.

 

[Kay K.M.Mods]

I'm not as familiar with how sound works as you are, so I may not be able to answer if you mention this, but here's what I've tested...

- In my case, I sometimes want to run a Japanese hypercard stack, so the system installed Japanese OS(KanjiTalk). There was a sound bug in any Japanese OS, OS7.1, 7.5.3, 7.5.5, 7.6, 8.1. The sound is a large mixture of high-frequency sounds such as bells with the original sound.
I have made various attempts, but nothing has been resolved. I changed the version of QuickTime and changed the sound of the control panel.

- The 2nd cache on the card can be removed, but removing it has the same result. I also tried all the control panels of Carrera040, but I can't get any sound bugs except by turning it off.

- The only solution was that if I had a clean install of the US version of SYSTEM 7.1, I installed the Carrera 040 extensions and control panel there. There was no sound problem. I installed QuickTime there and it didn't cause any problems. In addition, I would like to verify which extension causes the problem.

 

[Zane Kaminski]

A lot of software compatibility issues could be worked around more effectively if we developed our own 68k core to be put on an FPGA. We could make it do single-cycle execution like the 68040 but would be software-compatible with the 68030. Nothing I'm aware of quite fits the bill to accelerate a 68030 machine. No cores have full '030/'040 compatibility and most require a lot of area or are not very fast.

I've been implementing a (non-pipelined) 6502-compatible CPU core and it's been going quite well so that's spurred my interest in doing a fully-pipelined MC68k core. It's such a big job though. It would be awesome if we could form a team to tackle the project so that some of our members could contribute a little bit without feeling like the project is doomed unless they spend a bunch of time on it.

 

[JDW]

Zane, here are the 16-bit 48kHz audio files for you (Mono). WinterGames "Opening Ceremony" audio. (SE volume set to 3, D-100 recording level set to 5.5.)

SpeedCard Enabled (bad sound)

SpeedCard Disabled (good sound)

(Right-click the ">>" and choose Download Audio from the popup menu. You may need to click Play first so it loads before you do the right click.)

 

[Zane Kaminski]

Thanks James for the audio recordings. Turns out all I needed to analyze was the first note!

Using Audacity's auto-correlation analysis, which I honestly don't understand at all, I was able to locate the 60 Hz artifact I was referring to. Here's the auto-correlation graph of the "good sound":

The Y axis is supposed to indicate some kind of correlation/anticorrelation with the history of the signal. As I said, I don't really understand this autocorrelation function, but this is what it looks like for the regular note.

Now here's the "bad sound":

Look at that! Again I don't really know what this means, but there's a clear repetition every 16-17 milliseconds. Hmm! So something is happening that often which is messing up the sound.

Well this data--which I cannot stress enough that I don't really understand--does seem to point strongly to some "once per frame" phenomenon, further substantiating the theory about the sound generation crossing over the current sample being played every frame.

 

[Zane Kaminski]

Just got the ATX/VGA/SE adapter boards:

Looks good, just gotta add the two 74LVC86 gates and the VGA port. Still waiting on those parts from Mouser or somethin.

And here is our new logotype on one of our other products:

This thing is a board but doesn't serve an electrical function so we can write the "GW" text on the mask layer. Much crisper and you get the gold background! Very Nintendo-style. Old Nintendo cartridge boards would never have silkscreen, just text on the mask layer. The "GW" on the WarpSE will not look as good since it's just written with silkscreen. Oh well.

 

[JDW]

Zane, I've never used that Audacity feature before, but I am now trying to understand it via the following process...

1. Launch Audacity.
2. New document.
3. Generate > Tone...
4. Sine / 100Hz / 0.8 / 30s / OK
5. Select All
6. Copy
7. Tracks > Add New > Mono Track
8. Paste
9. Analyze > Plot Spectrum... > Standard Autocorrelation

Peaks are every 10ms because 1/100Hz = 10ms.

Both waveforms are identical, so peaks of both in the Autocorrelation waveform will match.

Now, I do this...

1. Close the Frequency Analysis window.
2. Double-click in the lower track to select all of it.
3. Effect > Invert (to make the peaks of one waveform be aligned over the valleys of the other waveform)
4. Select All (which selects both waveforms)
5. Analyze > Plot Spectrum... > Standard Autocorrelation
6. Now there is no waveform at all shown because the two waveforms cancel each other out.

What this shows me is that AutoCorrelation is showing Y-axis differences between the two selected waveforms. But using that to find recurring noise patterns is something that would appear challenging. Even so, I posted on the Audacity forum just now to ask for their opinion. My post is awaiting moderator approval.