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

[Zane Kaminski]

Just sent the power boards to fab!

These will let us reflash the WarpSE prototypes outside of the Mac for greater convenience. Like I said, production versions will just be able to power themselves through USB.

Now some slightly bad news regarding the previous 0.7a version. Unfortunately there was a bug in the firmware that meant that the slowdown interval setting would not be respected by the WarpSE. So all of the "35us" firmware versions where the slowdown interval was reduced from 203us back to 35us (as it was before 0.6b) do not do anything different from their non-"35us" counterparts. Similarly only values 0 and 15 in the slowdown interval field in the slowdown control register are useful. The rest of the values you can write (1-14) just do the same as 15. So I will be addressing this in version 0.7b (again in all the variants) soon. All the existing versions should work fine, just the slowdown interval is stuck at 203us.

So @ppuskari the 0.7a-fastiack-fastscsi-35us-noclockgate version I suggested you try is actually identical to 0.7a-fastiack-fastscsi-noclockgate. Still should be a good troubleshooting step though. If 0.7a-fastiack-fastscsi-35us-noclockgate works (even though the slowdown interval is not 35us on there) then it must be the slowdown trigger on interrupt acknowledge that's causing the problem.

Soon I will redo the 0.7a series as 0.7b and the slowdown interval setting will actually work.

 

[Zane Kaminski]

@JDW I would keep the 74LS245s since that's the same as the original. The 74F-series parts however should not be replaced with 74ACT and instead 74FCT or 74AHCT would be better.

 

[JDW]

@Zane Kaminski
My intention was to drive to the office (the only place where I have access to a Windows PC) in order to flash “0.7a-fastscsi”, but should I wait for your “b” firmware instead?

(i’ve not driven to the office yet. I am actually on my iPhone away from home right now.)

 

[Zane Kaminski]

@Zane Kaminski
My intention was to drive to the office (the only place where I have access to a Windows PC) in order to flash “0.7a-fastscsi”, but should I wait for your “b” firmware instead?

(i’ve not driven to the office yet. I am actually on my iPhone away from home right now.)

@JDW don’t bother with it yet if you’re not going in to work anyway. I think it would be better for to get the slowdown register fully working first.

 

[ppuskari]

Just flashed my WarpSE to 0.7a and No Localtalk shares still.

Hit the debug button and did the SM for

• $F00FFC - same as previous but the clock gating is disabled, so slowdown affects only RAM/ROM access speed/latency, not CPU speed

Couldn't do ES but rather did G Finder since I guess I'm not running MacsBug in 7.1? get a error trap but restart button. click Restart and when it comes back after reboot I get LocalTalk working just fine!

So I guess that means the clock gating may be part of the issue? I will try other combinations too tomorrow.

I did a bunch of SCSI copies and duplications and everything was rock solid so far with the Scsi Director 3.1 Drivers in use.

0.7a-fastscsi-35us-noclockgate

~35 us

all but SCSI

No (25 MHz)

$F003F5

Works for me as well for LocalTalk access connecting to fileservers and pulling and pushing files to/from them. 35us works equally as well during scsi operations keeping the bus saturated on the zip 100 drives for 2-3 minutes solid. No issues on restarts or shutdown

 

[ppuskari]

I'm going to bed for a bit. Good testing of things tonight though. My last question then.... Which option is supposed to clean up the sound? Even using the sound control panel with the options above and a few others I tried I would get "scratchy" sound output from the system sounds in the control panel. the 0.7a seems to be the cleanest sounding as compared to stock no acceleration however. I tried turning back on clock gating and that helped but not fully. I tried with no iack, scc, scsi as well with gating off/on and it was better with gating on but still not perfect. Looks like I can move on from LocalTalk to sound now

 

[JDW]

@ppuskari
I have not tried any of the 0.7 versions yet. I can only say that with 0.6h, the intro music from Spectrum Holobyte Tetris sounds just as good to my ears as stock 8 MHz audio.

If you have not used Tetris yet, I would strongly advise you to do so because it helps you detect bad audio better than anything else.

 

[Zane Kaminski]

Hmm I have been working on a new build system that will let me generate all 31 or whatever versions at once, but maybe I can just "solve the puzzle" now...

@ppuskari the sound issue is due to the tight software-hardware timing relationship between the sound output and generation. If the CPU is too fast, it outruns the current sample being played, causing a skip in the audio. This is addressed by going into slowdown for a while after an interrupt is received and also every time the sound buffer is written to. This mostly addresses the problem, but there are still a few samples in the buffer where the CPU sound generation routine gets ahead of the playback pointer. Since the sound generation routine has lots of instructions where the 68k "thinks" for a while between bus accesses, the final bit of the problem was fixed by slowing the 25 MHz clock to 7.8336 MHz during sound generation. Evidently that is messing up LocalTalk for you though.

So thinking through this... "35us" didn't do anything in 0.7a due to the bug I previously wrote about, so the slowdown period was really ~203us. Fastscsi and no clock gating fixed LocalTalk but sound was evidently a bit worse (as is understood to happen without clock gating)... So what about slowdown enabled for all devices except SCSI, 203us slowdown period, and then the clock gating gets turned on after a sound buffer access but gets turned off immediately after any other I/O chip access? Let's try it! That will be the singular 0.6b version and I can keep working on the build system for 0.6c or later. Hopefully though 0.6b or a slight variation will be golden because the LocalTalk problem was the last significant issue.

 

[ppuskari]

Hmm I have been working on a new build system that will let me generate all 31 or whatever versions at once, but maybe I can just "solve the puzzle" now...

@ppuskari the sound issue is due to the tight software-hardware timing relationship between the sound output and generation. If the CPU is too fast, it outruns the current sample being played, causing a skip in the audio. This is addressed by going into slowdown for a while after an interrupt is received and also every time the sound buffer is written to. This mostly addresses the problem, but there are still a few samples in the buffer where the CPU sound generation routine gets ahead of the playback pointer. Since the sound generation routine has lots of instructions where the 68k "thinks" for a while between bus accesses, the final bit of the problem was fixed by slowing the 25 MHz clock to 7.8336 MHz during sound generation. Evidently that is messing up LocalTalk for you though.

So thinking through this... "35us" didn't do anything in 0.7a due to the bug I previously wrote about, so the slowdown period was really ~203us. Fastscsi and no clock gating fixed LocalTalk but sound was evidently a bit worse (as is understood to happen without clock gating)... So what about slowdown enabled for all devices except SCSI, 203us slowdown period, and then the clock gating gets turned on after a sound buffer access but gets turned off immediately after any other I/O chip access? Let's try it! That will be the singular 0.6b version and I can keep working on the build system for 0.6c or later. Hopefully though 0.6b or a slight variation will be golden because the LocalTalk problem was the last significant issue.

Sounds like a plan! I can then torture the clocks with playing a long sound resource over LocalTalk. That should be a good test for this at least.

 

[JTRetro]

@Zane Kaminski
So I have flashed and tried the.7a-fastscsi firmware in my SE. The good news: As expected, there is a very significant performance improvement in SCSI throughput speeds. The test with firmware .7a-fastscsi is on the right; on the left is a test with firmware version .6f:

Additionally, here is a quick audio test that I did using "Snooper":

These test were performed with an SE Superdrive running O.S. 6.0.8 that has booted off of an external SCSI2SD drive.

 

[JDW]

...here is a quick audio test that I did using "Snooper":

If possible, it would be great if you could test audio by installing Spectrum Holobyte Tetris and then listening to the opening music. You can disable or remove WarpSE to see how the audio sounds normally. Sometimes listening through the SE's speaker can be difficult to hear the differences clearly, so if you attach good speakers or headphones to the headphone jack, you'll get the best audio.

---

Today is a national holiday in Japan and I've not returned to the office, so no change for me to test 0.7 yet.

I've spent 5 hours+ in vain trying to get stupid Boot Camp 6.1.0 to install Windows 10 on my mid-2015 15" MacBook Pro running Mac OS High Sierra because Boot Camp apparently doesn't like the version of Windows 10 (64-bit) that MS allows you to download. I've tried the splitter app, to no avail, because Boot Camp then errors out by saying the 8GB OSXRESERVED partition lacks disk space necessary to do the install. So I'm not trying to manually create the OSXRESERVED partition to make a 16GB version instead.

Ooooooooh how I dislike WINDOZE!

UPDATE:
Making progress, in spite of Boot Camp 6.1.0 fighting me every step of the way!



Or maybe not...




Even though I was able to enter my WIFI password and even though it connects, it restarts Windows 10 every 40 seconds, regardless of whether I even log in or not.

Rebooting into Windows "Safe Mode" (with networking) works and accesses my WIFI AND doesn't restart every 40 seconds. Not sure what this means unless it's the Boot Camp 6.1.0 drivers that are triggering the restarts, but that would a problem since Boot Camp version is tied to OS version. By the way, I am editing my post right now using Windows on that MBP! It's just in silly Safe Mode!

I can only guess that being in Safe Mode is causing the Firmware update app to fail like this...

 

[phipli]

Sometimes listening through the SE's speaker can be difficult to hear the differences clearly, so if you attach good speakers or headphones to the headphone jack, you'll get the best audio.

@JTRetro - carefully if you follow this advice. You're only meant to use high impedance headphones (a rare sight these days) {edit - I'm not sure what headphoes are appropriate, so advise working that out yourself} on the SE. Its way higher peak to peak voltage than a normal sound output. It wasn't intended for plugging into normal stuff. It is about 10x higher voltage than consumer line out - I don't mean this in a wishy-washy way - I mean it is close to ten times higher voltage.

Turning it right down to 1 will probably work, but realise that if some game automatically lifts the volume to max or something, it will be quite likely to damage something.

@JDW, The audio output isn't like later macs, really be careful telling people to plug stuff into it. The Classic for example, which has a similar overall design, has added (vs the SE) a potential divider for the output for the audio jack. It divides the output down a lot.

 

[JDW]

@phipli
I sincerely and humbly appreciate the cautionary words about the headphone jack output. I really do mean that. And I applaud your persistence and passionate on this topic. I also hold your opinions and work to better the vintage Mac community in very high regard. Thank you!

But in my defense, I must say for the record that I give advice on this one topic based on my decades of plugging just about everything into the headphone jack of all my compact Macs and not having problems. That includes headphones of all kinds. Never had a single device damaged, probably because when you hear distortion or excessive loudness, you automatically go to the Sound CP and turn it down to such a level that the sound is just right.

It’s hard to imagine that I’m alone in attaching headphones to the audio jack of the oldest Macs. It almost goes without saying many a Mac user has connected to the audio jacks of Macintosh 128K, 512K, 512Ke, Plus and SE machines through the decades. And yet, I’ve not come across threads where someone found their headphones destroyed or permanently harmed due to connecting to their compact Mac’s headphone jack.

The same goes for all recorders I’ve tried, not just my $800 SONY D100. You end up turning down the volume in the Sound CP to ensure the best recording, but I’ve not damaged a recorder yet. The same goes for my Panasonic GH5 camera when I ran a cable from the audio jack to it.

With that said, your repeated cautionary words about the jack make me very curious if Apple ever officially warned customers about the jack, and if Apple ever did, I’d certainly appreciate a link to that official documentation. I don’t ask that to diminish the importance of what you said. I ask to be better informed myself.

I see, for example, that the SE Owner’s Guide mentions the audio jack and its usefulness with headphones, but without any mention whatsoever of warnings, or even mention of the output voltage.

I understand about the output voltage being 10x higher than usual. And when you ponder that with a white lab coat on, it is rather concerning. But that makes one all the more curious as to why Apple seems to have been utterly silent on audio jack warnings for the SE and older compact Macs. It’s not like Apple was notorious to avoid warning customers about important matters when making connections to computers.

All said, i do advocate taking appropriate precautions by turning the Control Panel volume down to 1 before attaching your audio jack device, but I also wish to say to my fellow WarpSE beta testers:

PLEASE don’t become afraid to give the headphone jack a try in the event you are hard pressed to hear audio differences between WarpSE enabled vs. disabled.

The point of all this is that you won’t be able to hear nearly as much through the SE speaker as you will via the headphone jack.

 

[Zane Kaminski]

Okay, I have version 0.7b ready now which does not have any variants. I am trying to "solve the puzzle" now on 0.7b. Hope it works!

The slowdown policy in 0.7b is as follows:

• Slowdown is triggered for 196-210 microseconds after an interrupt occurs or when the sound buffer is written to.
• When the VIA, IWM, or SCC are accessed and slowdown is not already occurring, slowdown is triggered for the next 14-28 microseconds.
• When the VIA, IWM, or SCC are accessed and slowdown is already occurring, slowdown is prolonged by up to 28 microseconds. The exact amount of additional slowdown is idiosyncratic and depends on the current value of the slowdown timer but the total slowdown time after a VIA, IWM, or SCC access will be at least 14 microseconds.
• Clock gating to 7.8336 MHz is enabled when a sound buffer write triggers slowdown but is disabled immediately after an access to the VIA, IWM, SCSI, SCC, or when an interrupt occurs.
• SCSI accesses never trigger slowdown but do disable clock gating. SCSI accesses are like RAM/ROM accesses in that they do not end slowdown either. After a SCSI access, the slowdown timer continues to count down, and slowdown ends at the same time as it would if there were no SCSI access.

Also the slowdown register is disabled in this version since its semantics need redone slightly to reflect the behavior that clock gating is enabled during slowdown and after a RAM access but is immediately disabled after and I/O chip access or interrupt.

Is this gonna work? Admittedly I don't understand the problems Petar was having with LocalTalk, so I'm just kinda guessing here at the combination of slowdown rules that will fix everything. Unfortunately my little Mac network setup is stalled since my personal lab bench has been reoccupied by some RAM2GS II cards of ours that need tested and added into inventory. So it will be a bit before I can get my three other SEs set up and verify LocalTalk functionality myself. Fingers crossed!

 

[Zane Kaminski]

@JDW I think the issue is that you're missing the Microsoft Visual C++ Runtime version 2017. This is required to run a lot of programs, so why they don't include this in Windows, I don't know... Here's the link: https://aka.ms/vs/17/release/vc_redist.x64.exe

Another beta tester on our TimeDisk card just raised the same issue with the update program. I will add this note to the manual for our existing products using the update system as well as the WarpSE.

 

[Zane Kaminski]

@phipli @JDW Hahah now thinking about it, I wonder if I broke a stereo using the Mac SE. While using it on the test bench, we had the SE audio going into a particular stereo receiver we used to play music in the Garrett's Workshop lab. Then we noticed the stereo was mixing the audio from two inputs, one connected to our Windows PC and one connected to the Mac, and with no audible distortion either. We kept trying to disable the mixing feature until we concluded that the stereo was mixing the inputs because it's broken, not because it had some feature to mix two inputs. Uh-oh. We swapped out the receiver for a spare one and it has no issues receiving the Mac's audio signal. I have also put the SE's audio into a circa-2010 Dell monitor soundbar and that has not sounded bad or damaged anything either.

 

[Zane Kaminski]

@JDW @ppuskari @JTRetro Since I'm going for the final slowdown rules in version 0.7b, I think there are several things to try:

• Audio sounds good? Maybe James can make another recording for us to compare
• LocalTalk works?
• No crash in the sound control panel? (I have determined this was due to the VIA being accessed too fast)
• 1.44M and 800k floppies work?

These are basically the four main bugs that have been reported, so if all these problems are solved, I think we're good to go! Then I can get back to the WarpLC and WarpSE/30 which are both very exciting.

One thing that bothers me is, why does SCSI slowdown mess up LocalTalk? Doesn't quite make sense. So in 0.7b, SCSI accesses do not themselves trigger slowdown. But should we be disabling any further pending slowdown after a SCSI access? That's not clear to me since I don't exactly understand the problem. I guess we will just have to rely on empirical testing by Petar and the other testers. Ooh, I just got an idea! At the GW lab we have an old HP LaserJet 4000-series printer with LocalTalk. I will hook that up to the SE and try printing with that. Printing requires a lot of data transfer so that should be a good test.

Edit: oh, never mind, I reread Petar's posts and evidently it's actually the clock gating that screws it up. Okay! That gives me more confidence in 0.7b.

 

[phipli]

With that said, your repeated cautionary words about the jack make me very curious if Apple ever officially warned customers about the jack, and if Apple ever did, I’d certainly appreciate a link to that official documentation. I don’t ask that to diminish the importance of what you said. I ask to be better informed myself.

I shared the warning from this page last time you said. This is page 429 from Apple's "Guide to Macintosh Family Hardware, 2nd Edition".

I'm confused, I'm unsure whether you think that the voltage isn't 8v peak to peak, or that it is OK to put 8 volts into consumer devices without it needing at the least, care.

Just because the plug fits, doesn't mean the signal matches the same standard.

I know this isn't a big thing, but this kind of thing really upsets me because I'm used to working in an evidence based environment where people accept things when you provide valid justification. I'm just... really confused.

Note all the stuff above doesn't apply to the SE/30, Classic, Classic 2, ColorClassic, Mac II... etc. It is just the 128, 512, Plus and SE.

This is a warning to people reading - the voltage the SE can output can be extremely high. This is a fact. Plug what you like in, but take care. The SE doesn't care, it will handle pretty much anything on its output, but the thing you plug in might not like it if you have an accident.

Now I am done.

 

[JDW]

@JDW I think the issue is that you're missing the Microsoft Visual C++ Runtime version 2017. This is required to run a lot of programs, so why they don't include this in Windows, I don't know... Here's the link: https://aka.ms/vs/17/release/vc_redist.x64.exe

Another beta tester on our TimeDisk card just raised the same issue with the update program. I will add this note to the manual for our existing products using the update system as well as the WarpSE.

Because I really need a way to flash at home, I spent my entire today today working on this problem. I tried using a Windows app named "brigadier" in hopes of downloading newer versions of the Boot Camp drivers, but there seems to be only one for the 2015 15" MBP 11,5, And because it's impossible to install while in Safe Mode, I RESET the PC, which reinstalls Windows. Interestingly, that fixed it because it was before I installed any Boot Camp Drivers. I browsed the web and did various things for a long time without a single reset. When I was satisfied with that, I installed the Boot Camp Drivers (041-98143). The PC restarted, and then I was back to seeing it reboot every 40 seconds. On top of that, and something that happened before I did the PC RESET, is it would also show me an error dialog after I logged in saying "An error has occurred in the script on this page invalid character". So I RESET the PC again, and I'm now using it just fine without the Boot Camp Drivers. Brightness and Sound cannot be controlled by the keyboard, along with a host of other things, but at least it is usable.



I just downloaded 0.7b, launched and got the VCRUNTIME140.dll error again, so I am now installing Visual C++ using the download link you provided, and I will edit this post to update everyone once that is done to see if I can flash! Will reply back in a few minutes.

UPDATE #1
The ASCII text actually looks good on this MacBook Pro running Windows 10, unlike a real PC at the office, which has it all garbled up!



Proceeding to do a flashing test now...

UPDATE #2
More than half way through the flashing!


And this is how it should be! A Mac flashing a Mac!




UPDATE #3
Put everything back inside the chassis so the magic of @iPhil64 would do its thing once again, and it did... Got a single bong! Running benchmarks now, but it looks like I'm now good to go with flashing at home!

 

[Kai Robinson]

Because I really need a way to flash at home, I spent my entire today today working on this problem. I tried using a Windows app named "brigadier" in hopes of downloading newer versions of the Boot Camp drivers, but there seems to be only one for the 2015 15" MBP 11,5, And because it's impossible to install while in Safe Mode, I RESET the PC, which reinstalls Windows. Interestingly, that fixed it because it was before I installed any Boot Camp Drivers. I browsed the web and did various things for a long time without a single reset. When I was satisfied with that, I installed the Boot Camp Drivers (041-98143). The PC restarted, and then I was back to seeing it reboot every 40 seconds. On top of that, and something that happened before I did the PC RESET, is it would also show me an error dialog after I logged in saying "An error has occurred in the script on this page invalid character". So I RESET the PC again, and I'm now using it just fine without the Boot Camp Drivers. Brightness and Sound cannot be controlled by the keyboard, along with a host of other things, but at least it is usable.

View attachment 18221

I just downloaded 0.7b, launched and got the VCRUNTIME140.dll error again, so I am now installing Visual C++ using the download link you provided, and I will edit this post to update everyone once that is done to see if I can flash! Will reply back in a few minutes.

UPDATE #1
The ASCII text actually looks good on this MacBook Pro running Windows 10, unlike a real PC at the office, which has it all garbled up!

View attachment 18222

Proceeding to do a flashing test now...

UPDATE #2
More than half way through the flashing!

View attachment 18223
And this is how it should be! A Mac flashing a Mac!

View attachment 18224


UPDATE #3
Put everything back inside the chassis so the magic of @iPhil64 would do its thing once again, and it did... Got a single bong! Running benchmarks now, but it looks like I'm now good to go with flashing at home!

James - would you like me to send you a Windows 10 capable laptop for this sort of thing? We have plenty of basic 6/7/8/9/10th gen Intel stuff that gets chucked out for 'being old' at work.