WarpSE: 25 MHz 68HC000-based accelerator for Mac SE
- Thread starter Zane Kaminski
- Start date
I have an SE FDHD and I have booted it into System 1.0 running via Floppy Emu before. I can test it today on a real floppy to verify, but I'm pretty sure the SWIM and the newer ROM work fine with old System Software.
My guess would be that the Floppy Emu doesn't need the PWM speed signal because it doesn't have a physical spinning motor. This thread seems to be pointing towards the removal of the PWM related stuff in the SWIM itself, rather than the upgraded ROMs.
So your situation is that you probably couldn't boot System 1.x from a real floppy, but can from the Floppy Emu because it doesn't need the PWM signal on pin... 9? 10? I closed the document.
Edit - Pin 10 was PWM up until the 800k SE.
Yes I can confirm that my SE FDHD works with early system software. I found an image of System 0.97 with Finder 1.0, copied it to an 800k floppy formatted Single Sided, and it booted right up from the internal drive. I don't think there are any compatibility issues with the SWIM SE.
I don't have an external 400k drive to test, so I'm not sure if there's an incompatibility issue there, but I believe that the SE FDHD still routes the PWM signal to the external drive connector.
I don't have an external 400k drive to test, so I'm not sure if there's an incompatibility issue there, but I believe that the SE FDHD still routes the PWM signal to the external drive connector.
Attachments
Oh wow, unexpected. I didn't think that System 1 would cope with the non-PWM control system. Guess the routines are in ROM.
Another case of only primary evidence has value. Never believe accepted knowledge
Edit - Quite a surprise though - isn't the memory map different in the SE? Doesn't ADB trip it up? All sorts of questions!
How much RAM does it see?
Edit Edit - I just checked the memory maps. They remained fundamentally the same with the exception of the size of RAM and ROM growing, and SCSI being added. Thankfully the ROM was 4MB into the map from the beginning, so it didn't get moved to enable 4MB Pluses and SEs.
Last edited:
Hay @Zane Kaminski -I flashed the new Firmware before the tests that you see here, and I didn't see any issues! And as far as sound goes....well, here's another video of "Creepy Castle"!:
But I still have some more tests that I"d like to conduct. The only issues that I had is that it seemed like my SE was having a hard time reading 800k floppies....but that was before the firmware update.
@JDW -One of the images that I use (via a SCSI2SD adapter attached to the external SCSI port) has Mac O.S. 6.0.8, and the accelerator (both the Radius and Zanes's) works fine with it. The Radius 16 was introduced in 1988, I think around the same time that O.S. 6 was introduced, so my guess would be that it was originally designed to work with that O.S.
But I still have some more tests that I"d like to conduct. The only issues that I had is that it seemed like my SE was having a hard time reading 800k floppies....but that was before the firmware update.
@JDW -One of the images that I use (via a SCSI2SD adapter attached to the external SCSI port) has Mac O.S. 6.0.8, and the accelerator (both the Radius and Zanes's) works fine with it. The Radius 16 was introduced in 1988, I think around the same time that O.S. 6 was introduced, so my guess would be that it was originally designed to work with that O.S.
And just to be clear, that video of "Creepy Castle" is with Zane's accelerator in use!
It's pretty cool, they made the ROM forward compatible. I don't know how the ROM works in depth, but i assume the System Software is calling mouse routines and whatnot in the ROM that then call the ADB Manager. Key Caps shows the original keyboard, but everything lights up, and stuff like the keypad inserts numbers (though won't be displayed and lit up on the original keyboard image.)Oh wow, unexpected. I didn't think that System 1 would cope with the non-PWM control system. Guess the routines are in ROM.
Another case of only primary evidence has value. Never believe accepted knowledge
Edit - Quite a surprise though - isn't the memory map different in the SE? Doesn't ADB trip it up? All sorts of questions!
How much RAM does it see?
Booting up System 3, the about dialog shows my computer as having 2.5Megs of ram, which matches what i have installed. Considered upgrading to 4, but if the Warp SE contains 4+ MB built in then I'm not going to bother.
I believe we can conclude that the SE FDHD is compatible with every previous version of the System Software. Regarding drive compatibility, the FDHD is indeed not compatible with the old external 400k drive. Every other drive that is 800k and later does it's own speed control. There's a paragraph in Guide To the Macintosh Hardware 2nd edition on page 356:
It's interesting when @JDW used his external 400k drive on his IWM mac that it didn't work. Since the WarpSE uses the FDHD ROM it's very likely they removed any code in the ROM for that as well. ...but then I wonder if the SWIM could support PWM if the ROM did too, that's beyond my knowledge.
I did another quick test with one of my decades-old 400k disks; it didn't have a problem accessing it, although the disk itself sounded terrible!
I forgot to mention that this test and the test I did with "Creepy Castle" were done on an 800k SE running O.S. 7.1, off of it's original 20mb Hard drive.
I forgot to mention that this test and the test I did with "Creepy Castle" were done on an 800k SE running O.S. 7.1, off of it's original 20mb Hard drive.
Personally, I would tell Apple about that because (scroll down to "Mac OS Supported")...
Macintosh SE FDHD: Technical Specifications - Apple Support (English)
(Yes, I have actually reported inaccuracies on the Apple website to Apple via Feedback before, despite the fact I was attacked on FaceBook for having done so. Frady cats thinking Apple would "take it down" only because I offered a correction suggestion. Madness! So I now simply tell Apple in silence to avoid the flames.)
I know there are historical documents out there which said the same from all the way back when the machine first came out, but I can't find those documents at the moment.
Wish I had a SWIM and new ROMs to do that kind of testing. But even though I have more than one SE motherboard, I only have IWM chips and the old ROMs. I think that's probably fine for testing Zane's WarpSE because several other people are testing too (I think — we've not heard but from a select few in this thread).
Speaking of testing...
@Zane Kaminski
I would be happy to test your new firmware tonight after work, but it seems the filename is exactly as the previous "ROBUST"...
Of course, I can rename it something at random, but then how to I refer to it in a way you and everybody else in this thread can understand? If indeed that new download is a different "ROBUST" than the previous "ROBUST," can we agree to name it "WarpSE.GW4410A.1.1robust.exe"? If you dislike that name, tell me your preference so I can be sure to refer to it using your moniker.
Thanks!
Old one simply shouldn't be used for testing anymore. Maybe you can refer to it by date, but I am not inclined to come up with a versioning system at this time. We should never go back to the old firmware anyway since there have been a lot of changes under the hood. Just throw the old one away and it's preserved on TinkerDifferent and in GitHub in case we need to refer back to itPersonally, I would tell Apple about that because (scroll down to "Mac OS Supported")...
Macintosh SE FDHD: Technical Specifications - Apple Support (English)
support.apple.com
(Yes, I have actually reported inaccuracies on the Apple website to Apple via Feedback before, despite the fact I was attacked on FaceBook for having done so. Frady cats thinking Apple would "take it down" only because I offered a correction suggestion. Madness! So I now simply tell Apple in silence to avoid the flames.)
I know there are historical documents out there which said the same from all the way back when the machine first came out, but I can't find those documents at the moment.
Wish I had a SWIM and new ROMs to do that kind of testing. But even though I have more than one SE motherboard, I only have IWM chips and the old ROMs. I think that's probably fine for testing Zane's WarpSE because several other people are testing too (I think — we've not heard but from a select few in this thread).
Speaking of testing...
@Zane Kaminski
I would be happy to test your new firmware tonight after work, but it seems the filename is exactly as the previous "ROBUST"...
View attachment 18002
Of course, I can rename it something at random, but then how to I refer to it in a way you and everybody else in this thread can understand? If indeed that new download is a different "ROBUST" than the previous "ROBUST," can we agree to name it "WarpSE.GW4410A.1.1robust.exe"? If you dislike that name, tell me your preference so I can be sure to refer to it using your moniker.
Thanks!
Date references are easy to forget and confuse, so I shall rename it: WarpSE.GW4410A.1.0robust_OLD.exe
When and if I mention it in the future in this thread, I will call it "ROBUST OLD". That will make it 100% clear.
I've not had opportunity to test your new ROBUST firmware yet. I will do so tonight after work. But so far, the only firmware that has worked flawlessly for me (with only some oddities in the music playback in Tetris) is "ROBUST OLD."
Hoping the new ROBUST is the magic cure!
More tonight!
@Zane Kaminski
OK. I forced fed myself in 5 minutes on my lunch break so I could dedicate time to testing the "new" ROBUST firmware
My 1st boot attempt with my IBM DGHS 4.5GB SCSI drive (inside HD20SC enclosure) failed with a Sad Mac...
Fine! Don't like to play with read hard drives, eh, WarpSE? Well, let's see about BlueSCSI v1 then!
Alas, my SE is not a Happy Camper, as you can see...
Fine! Don't like SCSI at all? I will remove it and use my FloppyEMU instead!
And what do ya know? The SE booted fine from a System 6.0.8 & System 7.1 virtual floppy.
Interestingly, when I installed my BlueSCSI and left my FloppyEMU attached, this time the BlueSCSI booted. I was able to make this Speedometer 3.23 benchmark test, comparing it to the previous "OLD ROBUST" firmware.
But...
Mouse is much better. No clicking by itself anymore. It's significantly less jumpy but not 100% perfect. If I move the mouse around for a while, it eventually will just freeze the arrow pointer on screen for a second or so (even while I continue to move the mouse) and then suddenly it will jump to a far away location on screen. So I guess my mouse thinks it's playing in the Olympic games — previously doing a Sprint, but now doing a Long Jump!
I tried multiple times to boot from my external spinner drive, but I get a Sad Macevery time (and no, it's NOT Termination, SCSI ID, cable issues, etc.).
I have a known-good Apple stock SE motherboard (not an SE Reloaded), so I said, what the heck, and tested with that too. Same problem. No change. But it too has an IWM and old ROMs, if that matters.
Note that I also have PRAM batteries installed in both of these SE motherboards, just to let you know. It's a huge PAIN IN THE DONKEY to change Mouse tracking and so many other settings every time I yank the cord and then power on again, so I leave the batteries installed so as to maintain my sanity.
By the way, after testing many times, there are other Sad Mac error code numbers that appear too. So it's not only the numbers listed above in the screenshots. Although my spinner drive tends to trigger the 0000000F 00000002 code the vast majority of the time, and BlueSCSI triggered 0000000F 0000000A several times.
After all that, my lunch break was over, so I could not do my standard, "let's flash OLD ROBUST firmware so I can prove all is well again." But I suspect all would be well with it. That old version is truly THE most "robust" I've tested to date.
I can test more tonight after work if you reply before then. Otherwise, I need to go grocery shopping. (The Windoze Pee See is at the office, and I lack one at home, so testing at the office is best for me, since refreshing of firmware is required.)
OK. I forced fed myself in 5 minutes on my lunch break so I could dedicate time to testing the "new" ROBUST firmware
Summary: BAD NEWS
My 1st boot attempt with my IBM DGHS 4.5GB SCSI drive (inside HD20SC enclosure) failed with a Sad Mac...
Fine! Don't like to play with read hard drives, eh, WarpSE? Well, let's see about BlueSCSI v1 then!
Alas, my SE is not a Happy Camper, as you can see...
Fine! Don't like SCSI at all? I will remove it and use my FloppyEMU instead!
And what do ya know? The SE booted fine from a System 6.0.8 & System 7.1 virtual floppy.
Interestingly, when I installed my BlueSCSI and left my FloppyEMU attached, this time the BlueSCSI booted. I was able to make this Speedometer 3.23 benchmark test, comparing it to the previous "OLD ROBUST" firmware.
But...
Mouse is much better. No clicking by itself anymore. It's significantly less jumpy but not 100% perfect. If I move the mouse around for a while, it eventually will just freeze the arrow pointer on screen for a second or so (even while I continue to move the mouse) and then suddenly it will jump to a far away location on screen. So I guess my mouse thinks it's playing in the Olympic games — previously doing a Sprint, but now doing a Long Jump!
I tried multiple times to boot from my external spinner drive, but I get a Sad Macevery time (and no, it's NOT Termination, SCSI ID, cable issues, etc.).
I have a known-good Apple stock SE motherboard (not an SE Reloaded), so I said, what the heck, and tested with that too. Same problem. No change. But it too has an IWM and old ROMs, if that matters.
Note that I also have PRAM batteries installed in both of these SE motherboards, just to let you know. It's a huge PAIN IN THE DONKEY to change Mouse tracking and so many other settings every time I yank the cord and then power on again, so I leave the batteries installed so as to maintain my sanity.
By the way, after testing many times, there are other Sad Mac error code numbers that appear too. So it's not only the numbers listed above in the screenshots. Although my spinner drive tends to trigger the 0000000F 00000002 code the vast majority of the time, and BlueSCSI triggered 0000000F 0000000A several times.
After all that, my lunch break was over, so I could not do my standard, "let's flash OLD ROBUST firmware so I can prove all is well again." But I suspect all would be well with it. That old version is truly THE most "robust" I've tested to date.
I can test more tonight after work if you reply before then. Otherwise, I need to go grocery shopping. (The Windoze Pee See is at the office, and I lack one at home, so testing at the office is best for me, since refreshing of firmware is required.)
@JDW Hmm, seems like clock-gated slowdown is not ready for prime time. I think that's causing the crash. At least on my setup, the crash is random. I power cycled my SE test bench a bunch of times and was eventually able to get the same 0000000F 00000002 error to happen after a number of tries. If you can get the firmware from my previous post to boot and run Tetris though, I think you'll find that the sound is much better than the old "robust" firmware.
Okay, attached is a new firmware which leaves the clock enabled all the time and I suspect it should fix the crash on startup. Removing the clock gating has worsened sound quality but I can address that later. Sound still should be better than the "old robust." I've renumbered the version to 0.5, which I guess I can keep incrementing (0.6, 0.7, 0.8...) every time I post more firmwares until we get a really stable version that will become 1.0. I prefer to correlate when the firmware was generated with the git commits though, since I end up compiling the project a bunch of times during a single debug session.
Okay, attached is a new firmware which leaves the clock enabled all the time and I suspect it should fix the crash on startup. Removing the clock gating has worsened sound quality but I can address that later. Sound still should be better than the "old robust." I've renumbered the version to 0.5, which I guess I can keep incrementing (0.6, 0.7, 0.8...) every time I post more firmwares until we get a really stable version that will become 1.0. I prefer to correlate when the firmware was generated with the git commits though, since I end up compiling the project a bunch of times during a single debug session.
This firmware I just posted also has a refactor of the interface between the 25 MHz "slave port" and 8/16 MHz "master controller" of the fast bus-to-PDS bus interface. This was in the interest of reducing the size of the logic. The XC95144XL CPLD used on the WarpSE offers a fairly regular and easy to understand timing model but it is not very big, and the logic allocation is fairly coarse. The CPLD has been getting a bit congested as I did various experiments so I wanted to try and rewrite the logic to simplify things a bit.
Fortunately I was able to find a bunch of redundant logic in the interface between the fast bus slave port to the PDS bus master controller. Previously, I had these four signals, IORDREQ, IOWRREQ, IOLDS, and IOUDS going from the fast bus slave port to the PDS master. IORDREQ ("I/O read request) or IOWRREQ ("I/O write request") are signaled from the fast bus slave port to the PDS master controller in order to start a read or write on the PDS bus. After studying the reports from the Xilinx software, I discovered something fairly obvious. The logical rules for when to start a PDS bus transaction are fairly complicated and were duplicated between both the IORDREQ and IOWRREQ signals. Each of these was using like 16 "product terms" (sort of a logic allocation unit) out of the 720 available in the Xilinx XC95144XL. I was able to separate the "request" logic from the "read/write" logic, eliminating the duplication of the logical description of when to start a PDS transaction. Now I have IOREQ and IORW. IOREQ is still using 13 product terms since the request logic is complicated, but IORW only uses 3, since IORW just has to be valid during a PDS bus transaction request, but can have undefined/don't care behavior otherwise. I did a similar thing with IOLDS and IOUDS. These communicated the LDS and UDS data strobes from the fast bus to the PDS master and were also encoding the entire rule for when to start a PDS operation. So I was able to separate the logic for IOLDS and IOUDS similarly and also reduce them from 16 product terms to 3.
I think total savings simplifying the PDS bridge were like 40 product terms out of 720. This is especially important because in the XC95144XL architecture, each logic function is only allocated 5 of its own product terms. Additional product terms must be borrowed from adjacent logic elements. This incurs a timing penalty not only on the big function with a lot of product terms, but also the functions placed adjacently on the chip, since their product terms might have been borrowed so they themselves need to borrow product terms from the next function up. There were some complex logic functions adjacent to the /RAS signal to the onboard RAM, so it was was getting slowed down from 10 nanosecond delay after the 68k lowers the /AS signal to 11 nanoseconds. I'm considering going up to 26 or 27 MHz so I want all the timing margin I can get. Reducing the complexity of these functions reduced the congestion an now the /RAS signal is back to 10 ns worst case delay.
I think there's some opportunity to optimize the RAM controller in this way too. I'm gonna look at that soon.
Fortunately I was able to find a bunch of redundant logic in the interface between the fast bus slave port to the PDS bus master controller. Previously, I had these four signals, IORDREQ, IOWRREQ, IOLDS, and IOUDS going from the fast bus slave port to the PDS master. IORDREQ ("I/O read request) or IOWRREQ ("I/O write request") are signaled from the fast bus slave port to the PDS master controller in order to start a read or write on the PDS bus. After studying the reports from the Xilinx software, I discovered something fairly obvious. The logical rules for when to start a PDS bus transaction are fairly complicated and were duplicated between both the IORDREQ and IOWRREQ signals. Each of these was using like 16 "product terms" (sort of a logic allocation unit) out of the 720 available in the Xilinx XC95144XL. I was able to separate the "request" logic from the "read/write" logic, eliminating the duplication of the logical description of when to start a PDS transaction. Now I have IOREQ and IORW. IOREQ is still using 13 product terms since the request logic is complicated, but IORW only uses 3, since IORW just has to be valid during a PDS bus transaction request, but can have undefined/don't care behavior otherwise. I did a similar thing with IOLDS and IOUDS. These communicated the LDS and UDS data strobes from the fast bus to the PDS master and were also encoding the entire rule for when to start a PDS operation. So I was able to separate the logic for IOLDS and IOUDS similarly and also reduce them from 16 product terms to 3.
I think total savings simplifying the PDS bridge were like 40 product terms out of 720. This is especially important because in the XC95144XL architecture, each logic function is only allocated 5 of its own product terms. Additional product terms must be borrowed from adjacent logic elements. This incurs a timing penalty not only on the big function with a lot of product terms, but also the functions placed adjacently on the chip, since their product terms might have been borrowed so they themselves need to borrow product terms from the next function up. There were some complex logic functions adjacent to the /RAS signal to the onboard RAM, so it was was getting slowed down from 10 nanosecond delay after the 68k lowers the /AS signal to 11 nanoseconds. I'm considering going up to 26 or 27 MHz so I want all the timing margin I can get. Reducing the complexity of these functions reduced the congestion an now the /RAS signal is back to 10 ns worst case delay.
I think there's some opportunity to optimize the RAM controller in this way too. I'm gonna look at that soon.
I just finished testing "WarpSE.GW4410A.0.5robust.exe":
- At first power-ON, it booted from my BlueSCSIv1 without problem. Great!
- Mouse movement seems to be normal. Great!
- I rebooted with my external spinner drive, and was well with that.
- Tetris Audio sounds really good through headphones and through the speaker I cannot tell the difference with stock audio at all. I also tested Prince of Persia, and that sounded the same as stock SE audio to my ears (through headphones).
- Speedometer 3.23 shows these results...
"OLD ROBUST" shown at right below:
I will do further testing with this firmware later, but it's looking great so far, Zane!
@JDW Thanks!! I really appreciate your hard work testing.
I'm glad it's working well, but one thing I'm unsure of is whether the sound is completely fixed. I have increased the I/O slowdown interval from around 35 microseconds to around 200 microseconds (0.2 milliseconds). That's responsible for the slight reduction in Speedometer results but has improved the sound dramatically. But with the CPU processing at 25 MHz in between reads/writes during sound generation, it might still be a bit off. Can you make another recording of Tetris so we can compare?
I'm glad it's working well, but one thing I'm unsure of is whether the sound is completely fixed. I have increased the I/O slowdown interval from around 35 microseconds to around 200 microseconds (0.2 milliseconds). That's responsible for the slight reduction in Speedometer results but has improved the sound dramatically. But with the CPU processing at 25 MHz in between reads/writes during sound generation, it might still be a bit off. Can you make another recording of Tetris so we can compare?
I will do that on my lunch break today. After that, I will remove WarpSE from the stock SE motherboard and test it on my SE Reloaded motherboard. Shouldn't be a difference, but I've not tested the 0.5 firmware WarpSE on that motherboard yet.
What I can say is that when I flashed the 0.5 firmware last night, instead of a barcode looking display on the CRT, it was more along the lines of garbage. I had WarpSE installed in the stock SE motherboard at the time, and it was my first time flashing WarpSE while attached to that motherboard. When I previously had flashed WarpSE in my SE Reloaded motherboard, I got thick vertical lines, with straight edges and a few small white dots here and there, but otherwise a nicely formed vertical bar pattern. But again, with the stock SE motherboard, I got garbage on the CRT instead of bars. Perhaps it doesn't matter, but I just wanted to mention it.
On my lunch break now and experiencing something new.
The SE won't bong or boot anymore with the WarpSE installed, despite the fact it worked fine when I ended my testing last night and put everything away. I've tried it on both motherboards. Same on both. Pressing and holding INTERRUPT does nothing. Can't revert to stock SE when WarpSE is installed using that method.
If I remove WarpSE, both motherboards bong and boot fine. On my SE Reloaded board, it shows the standard clean looking vertical bar code bars. On my stock Apple SE motherboard, I see the normal garbage which looks like this...
So I am now reflashing the same 0.5 firmware again. But this is VERY ODD to say the least.
The only thing different I did last night was to use my stock Apple SE motherboard with the WarpSE when flashing the WarpSE. All prior flashing had been done with the WarpSE on my SE Reloaded motherboard.
The SE won't bong or boot anymore with the WarpSE installed, despite the fact it worked fine when I ended my testing last night and put everything away. I've tried it on both motherboards. Same on both. Pressing and holding INTERRUPT does nothing. Can't revert to stock SE when WarpSE is installed using that method.
If I remove WarpSE, both motherboards bong and boot fine. On my SE Reloaded board, it shows the standard clean looking vertical bar code bars. On my stock Apple SE motherboard, I see the normal garbage which looks like this...
So I am now reflashing the same 0.5 firmware again. But this is VERY ODD to say the least.
The only thing different I did last night was to use my stock Apple SE motherboard with the WarpSE when flashing the WarpSE. All prior flashing had been done with the WarpSE on my SE Reloaded motherboard.