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.

 

[JDW]

First and foremost, what I'm about to say has nothing to do with the audio glitching when WarpSE is active and running ROBUST firmware. That has clearly been established, and Zane has written extensive thoughts about how he intends to proceed.

---

I will now provide more details about the "stuttering audio" that is clearly heard at times when I played Spectrum Holobyte TETRIS opening must on the stock 8MHz Mac SE booted into System 7.1. As per the two earlier comments that spoke about possible background processes, I ran the following tests:

TEST #1
1. I rebooted from my Kero's Mac Mods edition BlueSCSI v1 (mounted on the motherboard with Kay's Type-A SCSIrider and using a proven good 16GB V30 Gigastone MicroSD card) into System 6.0.8.
2. I disabled MultiFinder, and I killed most but not all of the startup INITs. I then rebooted.
3. Since I wasn't recording this time, I set the speaker Volume to 7 so I could better hear the music.
4. I launched Tetris, and it played the opening music to the end without a single stutter.

That test seems to prove that System 6.0.8 is okay, and to some extend my BlueSCSIv1 must also be OK too.

TEST #2
1. I used System Picker to boot my BSv1 into System 7.1, but this time I pressed Shift to Disable Extensions.
2. Speaker volume remained set to 7 from the previous test.
3. I launched Tetris, and it played the opening music with stutters, exactly like my prior audio recordings. (The stuttering only begins after the "ticker" text begins to flow left at the very bottom of the game screen.) This cannot be blamed on INITs or any known background processes not inherent to the OS.

TEST #3
1. I powered OFF and connected my fast IBM DGHS 4.5GB SCSI spinning platter hard drive (mounted inside an HD20 enclosure, with recapped PSU), to the SE and booted into System 7.1, with Extensions OFF.
2. I launched Tetris, and it played the opening music with stutters, exactly like TEST #2 and my prior audio recordings. This test seems to prove that my BSv1 is not at fault, and it even affects fast spinning platter hard drives too.

TEST CONCLUSIONS
You Mac SE owners running System 7.1 can now give Spectrum Holobyte Tetris a test yourself to see if your findings match mine in terms of "audio stuttering," which has nothing whatsoever to do with WarpSE. The stutters are NOT part of the WarpSE audio glitching problem. I merely noticed the stuttering in passing while doing the stock 8MHz test. Once others have chimed in saying it happens to them too while booted into System 7.1, even with Extensions off, then perhaps we can put the stuttering problem to rest and just say, "if you want to hear Tetris music in all its glory, use System 6."

NOTE: All my stock SE 8MHz tests until today have been done by completely removing the WarpSE, leaving no room for anyone to speculate about which clock speed was being used. But today, I tried out Zane's earlier advice (page 21 of this thread) for the very first time, which allows you to disable the WarpSE without removing it, which is a very nice feature to have when you have the back case screwed down. Here's what you must do:

1. Power OFF.
2. Press and hold the INTERRUPT SWITCH (switch closest to the back of the SE, NOT the triangle logo switch).
3. Power ON while still pressing INTERRUPT (not easy to do — press hard on INTERRUPT and don't let your finger slip).
4. There will be no bong and you will see vertical stripes on the CRT. Release the INTERRIPT SWITCH. You will then hear the Bong and stripes go away.
5. The SE will then do everything at the same slow 8MHz it normally does. I verified the clock speed in Speedometer 3. It gave me a CPU of about 1.09.
6. Even if you RESTART the Mac, it will remain in stock 8MHz Mode. Powering OFF and then ON again, without holding the INTERRUPT SWITCH will enable WarpSE again.

Lastly...

24-bit WAV files of the TETRIS MUSIC portion of my SONY D100 recordingscan be downloaded here:

TetrisAudioTests_WAVs_JDW.zip

drive.google.com

I did not edit them down to 5 seconds out of fear somebody else would later ask for the full recordings. Also, I did not adjust amplitude at all. These are the RAW audio recordings that only trim out any parts not related to TETRIS MUSIC. So you will need to Normalize the amplitude yourself in Audacity, TwistedWave, or your favorite audio editor. Otherwise the volume may be a bit too low during playback. (Yes, I did boost the amplitude when making my video in FCPX to ensure the playback volume was largely the same for all recordings.)

 

[JDW]

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

Here are 48kHz 24-bit WAV files using WarpSE-ROBUST and the Stock SE, recorded with my SONY D100 at the Headphone Jack:

PoP_WarpSE_AudioCompare_JDW.zip

drive.google.com

The Mac SE was booted into System 7.1 with extensions enabled. I used the TwistedWave audio editor to normalize both recordings to 0dB and made them mono (since I left my Stereo to Mono adapter at the office).

I listened to the audio via the Mac's speaker, via the Mac's headphone jack with cheap over-the-ear headphones, and later using my $429 AKG K702 Studio Reference headphones (with braided cable) on my modern Mac. To be honest, I really can't tell any noticeable difference. It's almost like there's no audio issue at all with WarpSE when playing back the Prince of Persia opening music.

 

[phipli]

Here are 48kHz 24-bit WAV files using WarpSE-ROBUST and the Stock SE, recorded with my SONY D100 at the Headphone Jack:

PoP_WarpSE_AudioCompare_JDW.zip

drive.google.com

The Mac SE was booted into System 7.1 with extensions enabled. I used the TwistedWave audio editor to normalize both recordings to 0dB and made them mono (since I left my Stereo to Mono adapter at the office).

I listened to the audio via the Mac's speaker, via the Mac's headphone jack with cheap over-the-ear headphones, and later using my $429 AKG K702 Studio Reference headphones (with braided cable) on my modern Mac. To be honest, I really can't tell any noticeable difference. It's almost like there's no audio issue at all with WarpSE when playing back the Prince of Persia opening music.

That is impressive.

All of my SE accelerators cause issues with Prince of Persia's intro music. Not like the issue you're having with Tetris, a different issue where the music keeps dropping out and notes hang. That's what I was checking for.

@Zane - historically there may have been two audio issues on SEs with accelerators. The one I've always struggled with is sample based music and audio recordings dropping out. Your card seems to be managing that issue well. Better than the Mobius and Total Systems cards.

 

[JDW]

[WarpSE] seems to be managing that issue well. Better than the Mobius and Total Systems cards.

And much better than the Levco (SuperMac) SpeedCard I own, and better than the Radius Accelerator owned by @techknight too!

At this point, I will tag @BFEXTU because he and I shared a lot of private messages in the summer of 2022 regarding the SpeedCard. He was a SuperMac engineer who had the unreleased copy of the v1.7 Control Panel. We discussion the audio glitching extensively, but nothing we tried worked to resolve the issue with the SpeedCard. He had originally thought the unreleased driver (v1.7 CP) might help, but it didn't. Anyway, maybe he would like to chime in after reading through our recent dialog in the last 2-3 pages of this thread.

 

[JDW]

Have a look at what's possible with WarpSE (and the original SE ROMs)...

 

[JTRetro]

So I have been doing some testing on Zane's new Mac SE accelerator as well, and have some results to post! One of the tests I did was to compare how Zane's accelerator performs in comparison to the Radius 16 and Radius 25mhz accelerators I have in my collection. Here is a screenshot of the test between the Radius 16 and Zane's:

As you can see, Zane's accelerator is as fast as a Radius 16, with the exception of the math part of the test. Very impressive in my book!

 

[JTRetro]

And here is a screenshot of the Radius 25 vs Zane's accelerator:

 

[JTRetro]

And finally, something fun: A quick video of the game "Creepy Castle" playing while running Zane's accelerator. Sound and graphics are all very smooth! I apologize for the slight over-exposure.

 

[JDW]

And just to clarify for others reading this. The Radius Accelerator 16 and 25 cards use a 68020 CPU and 68881 FPU. WarpSE uses a 25MHz 68000, but no FPU. Hence the impressive performance.

@JTRetro what is the minimum System Software required for your Radius accelerator?

As mentioned in my previous post (video), WarpSE has no drivers to install, allowing me to even boot from System 0.85 and Finder 1.0 (because my SE has the original SE ROMs only compatible with 400K & 800K drives).

 

[JDW]

In light of the past reports by @techknight about GCR disk incompatibilities with the first WarpSE firmware (which seem to have been fixed in the "ROBUST" firmware I am tested with now), I decided to do further GCR compatibility testing today, just to be 100% sure. I connected my Macintosh 400K external drive to the SE. This is a known good drive, fully lubed and cleaned by me, and is know to work fine with my Mac512.

To ensure the best read/write compatibility, I booted the SE from my internal BlueSCSIv1 into System 6.0.8.

With WarpSE active, inserting a 400K disk into the 400K drive results in a monotone sound (single drive speed, which is not normal). That known good disk was unreadable by the SE, so it asked if I wanted to Initialize it. I proceeded with Initialization, but it was a constant monotone sound the whole time, which again, is not normal. In the end, the Initialization Failed (of course).

I powered OFF, held down the INTERRUPT SWITCH pressed, powered ON, then released the SWITCH, to allow the Mac to be in stock SE mode. I repeated the same test, but this time, the drive worked normally, with its typical musical tones while initializing and reading and writing 400K disks.

I then did a test with a known-good bootable 400K floppy in the 400K drive. Stock SE mode would boot from it, WarpSE mode would not.

However, as I reported in my video yesterday, when I attach my 800K external drive and test 400K floppies in it, everything works fine with WarpSE enabled. I can read/write/Initialize and boot from 400K disks. So there appears to be a functional difference between the two drives, despite the fact both drives support 400K disks and GCR.

I don't see this as a flaw necessarily because I doubt many people will use a 400K drive with their SE. But it's clear that the 400K drive is more timing sensitive than the 800K drive. So my advice is to just make life easy and add a note in the WarpSE documentation mentioning that 400K drives cannot be used when WarpSE is active.

 

[Zane Kaminski]

Okay! I just got finished trying the slowdown method I described before with the clock gating. It’s much closer to stock speed!

Stock:

New slowdown always enabled:

The current method makes it hard to fix that last 0.001 but it shouldn’t matter. I’ll tweak it a little more soon.

However even with this very accurate slowdown, audio is not perfect! The reason was obvious once I thought about it. The sound manager generates new sound into the hardware buffer memory area after a vertical blanking interrupt. Slowdown is triggered for some 30 microseconds after any interrupt and also when writing to the sound buffer. 30 microseconds is enough to stay in slowdown until the next sound sample is written, but it doesn’t slow the CPU for long enough after vertical blanking but before sound generation. So the accelerated CPU executes that part of the vertical blanking interrupt too quickly. Therefore sound generation happens too soon and the buffer must actually be getting corrupted from the “beginning” instead of outrunning the sample pointer.

To test this theory, I increased the slowdown interval to 1.8 milliseconds after vertical blanking or any sound or I/O access. And the remaining sound corruption problem was fixed, at least to my ears! Now I just need to tune the 1.8ms interval because slowing down for that long at least once per frame reduces performance a lot, from 4.1 to 3.7 in Speedometer’s CPU benchmark. Should be able to get much of that performance back by tweaking the interval more.

@JDW regarding your last posts about the 400k floppy and System 0.85, the WarpSE doesn’t use the motherboard ROMs at all. Not sure if that bears on 400k compatibility.

@phipli Hmm, I wonder what the cause of the other sound issue is. The problem with overwriting the buffer contents at the wrong time never crashes the machine. It’d be interesting to know more

 

[JDW]

@JDW regarding your last posts about the 400k floppy and System 0.85, the WarpSE doesn’t use the motherboard ROMs at all. Not sure if that bears on 400k compatibility.

My mention of SE ROMs in my earlier posts was done merely to say that if you have newer ROMs that support the 1.44MB drives (e.g., an SE FDHD), then you cannot boot into Macintosh System Software versions older than System 6 because the new ROMs require System 6.0.3 or higher. I have the older ROMs in my SE, so I was able to boot the most ancient Mac System Software that was officially released: System 0.85 and Finder 1.0. And it's fantastic that WarpSE works even with such old operating systems. My video shows some trouble, but that's only because I left my BlueSCSI mounted. Very old OS's don't know how to handle SCSI or large drives like my 2GB BlueSCSI images.

Here are my complete notes on the subject...

LOGIC BOARD REVISIONS & ROMS

1. OLD board: 820-0176-B (1986), 630-4125
• 342-0352-A, HI ROM
• 342-0353-A, LO ROM
• 344-0043-A or 344-0041-B, IWM (floppy drive controller)
• Only compatible with 400K/800K drives, not 1.44MB
• RAM configuration set by resistors R35 & R36

2. NEW FDHD board: 820-0250-A (1988), 630-4250
• 342-0701, HI ROM
• 342-0702, LO ROM
• 344-0062, SWIM
• Compatible with 400K/800K or 1.44MB drives
• RAM configuration set by jumper J16
• SE Reloaded board uses this revision

NOTES on ROMs, SWIM & System Software

• You can use the newer SWIM chip with the older ROMs, but you only get 400K/800K drive compatibility.
• The old ROMs & IWM can be used in the newer revision motherboard. (including the SE Reloaded board)
• The newer ROMs & SWIM can be used in the older revision motherboard.
• The old ROMs & IWM chip are System 4.0 & Finder 5.4 (SSW2) compatible, but the newer ROMs & SWIM require System 6.0.3 minimum.

 

[phipli]

@phipli Hmm, I wonder what the cause of the other sound issue is. The problem with overwriting the buffer contents at the wrong time never crashes the machine. It’d be interesting to know more

The host doesn't crash - the audio just... stutters is an understatement. This is a particularly bad example with this setup. Perhaps it is pushing their audio fix to its limits and beyond.

Generally it works fine with short samples, but struggles with music. I've always found Prince of Persia triggers this issue more than most other software I use, so it is my go to "Is music messed up" program. Plus I like the intro music.

@JDW regarding your last posts about the 400k floppy and System 0.85, the WarpSE doesn’t use the motherboard ROMs at all. Not sure if that bears on 400k compatibility.

So are you using an FDHD or a 800k SE ROM? Does this (IWM aside) silently upgrade your ROMs??

However, as I reported in my video yesterday, when I attach my 800K external drive and test 400K floppies in it, everything works fine with WarpSE enabled. I can read/write/Initialize and boot from 400K disks. So there appears to be a functional difference between the two drives, despite the fact both drives support 400K disks and GCR.

I.... can't remember the specifics because it isn't something I've had to think about, but I believe the early model SE is the last compact compatible with 400k drives. 400k drives use basically an identical system to the sound buffer to set the speed of the motor in the floppy drive and have a PWM pin on their connector. The SE doesn't have this on the internal connector (the Plus did) but the 800k SEs do on the external connector.

I realise people probably know this, but the sound buffer is actually split between the sound and motor speed. Interestingly the Classic re-uses the PWM signal from the BBU that used to control one of the motor's speeds to control the screen brightness. But anyhow.... I think later machines (technically including the SE when it isn't doing old fashioned style motor control) use a different method to control motor speed for 800k disks. I think it updates the sound and motor speed once per line of the screen? Note that the sound/motor speed and screen refresh are very tightly linked.

On later machines, the PWM pin is just left at 5V.

All this said, some of this is half remembered stuff and I've only skimmed reference to grab the above extract. Please use this as a getting started point for research rather than take absolutely any of my rambling nonsense as being factually correct. The info will be in the "Guide to Macintosh Family Hardware".

 

[Zane Kaminski]

New firmware is attached!

In this version, the slowdown takes effect for longer as I previously mentioned. SCSI is also not slowed down so let's try fast scsi again.

@JDW @techknight @JTRetro @ppuskari @Crutch Can we find any issues with this firmware? Is the sound quality as good as stock? It's definitely better than before in Tetris. Is the mouse jumpy at all? Can we find any situations where the system crashes? CPU performance in speedometer is down another one percent or so, but SCSI should be faster. If there’s any residual issues with sound quality, I can increase the slowdown interval slightly but that will eat up a little bit more performance so I only wanna do it if it’s really necessary for the sound quality.

Also, in the newest firmware, you can enable and disable the WarpSE any time the system is reset, so you don’t have to power on the system while holding the interrupt button to disable the accelerator. You can start the machine as normal, then press the interrupt and reset buttons together at any time, release reset, and then release interrupt. This will disable the WarpSE. Next time the reset button is pressed without the interrupt key, the WarpSE will be enabled again. To be honest, I don’t think this is a great idea. The CPU can also “press” the reset button itself, which it often does when the system crashes. So if the system crashes and resets itself while the WarpSE is disabled, it will be re-enabled unless you happen to be holding the interrupt key at that time. Not great. So I will probably take this out before release.

@JDW The WarpSE has the SE FDHD ROM with checksum B306E171 though and does not read from the motherboard ROMs at all. You could even leave the motherboard ROM sockets totally empty. So maybe it's just the SWIM that's incompatible with the early software versions? I think we confirmed a while ago that this ROM works even if you don't have the corresponding SWIM chip and only have an IWM but we will need to check that again later. As for 400k drives, I figured we'd just list them as not officially supported.

 

[Zane Kaminski]

Oops!! Wait a sec--the firmware I just posted is not the actual latest version. Here's the correct latest revision with the changes I mentioned in the above post.

Oh and one more thing. These recent firmware versions since I added "PDS-synchronized slowdown" require 4 MB of RAM in the Mac SE. I will rectify this in the final board revision but at the moment it's required.

 

[JDW]

@Zane Kaminski
I just flashed the firmware attached to your "Oops!!" post. I'm sorry to report it's bad news.

(I have 4MB of RAM installed, by the way.)

I had no issues booting prior to flashing this firmware. (I had been testing ROBUST without any booting issues before.) But my first attempt to boot (via BlueSCSIv1 into System 6.0.8) after flashing with your newest firmware resulted in this crash:

Moving the mouse didn't do anything. The arrow pointer was frozen.

I powered OFF, waiting a few seconds, then powered on again, only to be met with this error:

And while that "coprocessor not installed" dialog was displaying, I attempted click the Continue button. This time, moving the mouse moved the arrow pointer as expected, but while I moved the mouse, the content of that dialog shifted and ended up looking like this...

I powered OFF, disconnected my BlueSCSI, then powered on with no drives at all. I saw the flashing question mark disk icon and moving the mouse seemed to work fine. So I then powered off again and connected my FloppyEMU. I was able to boot from a virtual System 7.1 floppy. So instead of testing, I just powered down, and reattached my BlueSCSI, thinking I could boot from my FloppyEMU again. But of course, my hands weren't fast enough to set the disk on the LCD of the FloppyEMU, so it started booting from the BlueSCSI. But this time, it booted all the way to the Desktop. Very odd.

Anyway, further trouble began while booted from my BlueSCSI. Everything looked fine until I moved the mouse. Mouse movement seems to be smooth, but it will suddenly do a single click, for no reason at all! No, I didn't press the mouse button. If I put the Arrow Pointer over a clickable item like a folder and leave it, not touching the mouse, all is well. But if I move the mouse to may the arrow pointer move over that folder (say, in a circular fashion to keep the arrow hovering above the folder icon), it will do a single click and select the folder. When it does the click isn't fixed. Sometimes it takes 2 seconds, other times longer. But if you move the mouse a while, you will see it click by itself at random!

That is obviously a show-stopper, but I wanted to see if the Speedometer 3.23 Benchmark results were different, and sure enough my Disk score jumped from a measly 1.13 (with ROBUST firmware) to 2.09. I enjoyed seeing that! CPU scores didn't change much at all (margin of error).

I then launched Tetris and found the music to play very nicely. Seems the same as the stock SE playback to me. I checked by Speaker and Headphones.

I then rebooted several times, but I didn't get those crazy dialog boxes again. I used System Picker to boot into System 7.1, and again, no problem.

I even ran Norton Disk Doctor on my 2GB boot disk and it pass all checks just fine.

But the problem where the mouse clicks at random on its own remains (only when you're moving the mouse around, mind you). So if the mouse can be fixed without compromising anything else, we just may have a winner. But right now, the random clicking is too bad to be acceptable.

UPDATE: I kept the SE on for a long time running Norton Disk Utility and other things. No crashes or lockups, but the mouse behavior has changed. No more random clicks. Instead, movement is "jumpy." It's not too bad, but when I move the mouse, it will sometimes jump to a different spot at random. After that I powered off for several minutes then rebooted. Well, not the random mouse clicking problem is back AND movement is jumpy too. So there's something serious wrong going on with the mouse.

Well, drat. I powered off and on again, and now we're back to the crazy error dialogs during cold boot!

I refreshed the new firmware a second time, but the same exact kind of craziness remains. So it absolutely wasn't a flashing issue. (Oh and when using the newest firmware, Norton System Info reports the clock speed as being 22MHz.)

To confirm all is well with WarpSE, I flashed ROBUST firmware to it. Norton System Info reports 25MHz as the clock speed, and now the mouse is working fine again. So the mouse issues and System Bombs during boot are definitely specific to the newest firmware.

---

Also, in the newest firmware, you can enable and disable the WarpSE any time the system is reset, so you don’t have to power on the system while holding the interrupt button to disable the accelerator. You can start the machine as normal, then press the interrupt and reset buttons together at any time, release reset, and then release interrupt. This will disable the WarpSE.

I didn't test that because I agree with you about it being unnecessary. I think it's easier to use the regular method of powering on with INTERRUPT pressed, then you let go and it boots in Stock SE mode.

By the way, the Levco SpeedCard's method is to power off, then press-and-hold INTERRUPT, then power ON, then press and release RESET, and then release INTERRUPT. It's much more fiddly than the WarpSE method of only pressing INTERRUPT.

@JDW The WarpSE has the SE FDHD ROM with checksum B306E171... So maybe it's just the SWIM that's incompatible with the early software versions?

Please note that I have the IWM chip in my SE Reloaded motherboard. I don't have the new ROMs (the actually chips) or a SWIM to test if the SWIM is indeed what restricts you from booting into very old System Software. But since WarpSE apparently has the new ROMs onboard, I would only need a SWIM chip to do testing. Hmmm...