WarpSE: 25 MHz 68HC000-based accelerator for Mac SE
- Thread starter Zane Kaminski
- Start date
You are speaking about my post here, under the heading: "I made a NEW DISCOVERY!"
The key difference in my testing at the time I wrote that old post and my most recent testing yesterday is that in my testing yesterday, I had the BlueSCSI completely removed. In both cases, I tested using my SE Reloaded board with SWIM chip. I had no SCSI devices attached in my recent test though. In my recent test, I tested with only a real 1.44MB drive mounted and connected internally and a Model B FloppyEMU connected externally.
Maybe BlueSCSI was the root problem?
To prove if indeed BlueSCSI is interfering with the booting of my 1.44MB floppy, I will need to try another boot test tonight after work with BlueSCSI attached.
For now I can say that I've done a lot of testing with firmware 0.7d-fastscc, and seems to be working well.
Zane, a couple thread pages ago, you said:
I don't recall seeing a reply from @ppuskari about that, and I myself don't really know what is involved with "streaming."
I can only say that I tested a launch of Photoshop 4.0 which took an eternity, and a lot of LocalTalk activity took place when doing that. It finally did load the app and all was well with it.
@Zane Kaminski
For the life of me, I can't get my 1.44MB floppy to NOT boot now, even with my BlueSCSI attached. It boots every time I try it! In fact, I can boot into System 0.95 and Finder 1.0 using that floppy, and both of my 2GB drive volumes on my BlueSCSI will mount. Takes a very long time for them to mount, but they mount. This floppy is a different floppy than I tested when my SE was at home, so maybe the other 1.44MB disk I tested with was bad. It's at home so I couldn't test that tonight. But the fact remains it's booting fine with this 1.44MB disk, even with BlueSCSI attached.
I'd also like to thank @iPhil64 once again for his suggestion about putting the SE Reloaded board inside the metal chassis because that resolved the mouse arrow pointer freeze-and-jump problem I have when using my extension cable to pull the board outside the chassis. The stock board doesn't give me trouble in or out of the chassis, so I can only guess that the stock motherboard must have great noise immunity. Not sure, but I'm scratching my head to come up with another explanation. Everyone will use their motherboard inside the chassis anyway, so it doesn't really matter, I guess.
For the life of me, I can't get my 1.44MB floppy to NOT boot now, even with my BlueSCSI attached. It boots every time I try it! In fact, I can boot into System 0.95 and Finder 1.0 using that floppy, and both of my 2GB drive volumes on my BlueSCSI will mount. Takes a very long time for them to mount, but they mount. This floppy is a different floppy than I tested when my SE was at home, so maybe the other 1.44MB disk I tested with was bad. It's at home so I couldn't test that tonight. But the fact remains it's booting fine with this 1.44MB disk, even with BlueSCSI attached.
I'd also like to thank @iPhil64 once again for his suggestion about putting the SE Reloaded board inside the metal chassis because that resolved the mouse arrow pointer freeze-and-jump problem I have when using my extension cable to pull the board outside the chassis. The stock board doesn't give me trouble in or out of the chassis, so I can only guess that the stock motherboard must have great noise immunity. Not sure, but I'm scratching my head to come up with another explanation. Everyone will use their motherboard inside the chassis anyway, so it doesn't really matter, I guess.
I'm almost done with the final WarpSE board and overclocking board! All of the issues and weaknesses I could identify have been fixed, and there are some new features on the WarpSE since the last version:
As I said before, the SiTime MEMS oscillator is as accurate as a crystal, but has better temperature stability and can handle higher peak G-forces which would shatter the crystal in a crystal oscillator.
In this version, the WarpSE can OR the power from USB and the Mac so that it can be programmed outside of the Mac. Since the CPLD can now be powered up with the Mac off, recent firmware versions since 0.6b have had a power fail detector that automatically tristates (disables) the signals going from the WarpSE's CPLD to the Mac's PDS bus when the Mac is off. The power fail detector works by measuring the frequency and duty cycle of the Mac's 7.8336 MHz "C8M" clock relative to the onboard 25+ MHz oscillator. If the C8M clock is not toggling, the Mac's power must be off or browning out, so in this case, the WarpSE disables its outputs onto the PDS.
Associated with the USB power input is a new fuse and inrush current limiter. The purpose of the fuse is obvious enough, but the inrush current limiter is interesting and less obvious. Per the USB specification, a device may not have more than 10 µF of capacitance directly on the +5V power line of a USB device. If there's more capacitance, when plugging in the device, the inrush current could large enough to brown out the PC’s USB power. The WarpSE has over 100 µF of capacitance on its +5V rail, so that’s not good to plug directly into USB. In order to have more than 10 µF of capacitance, you have to apply an inrush current limit circuit between your big capacitance and the USB power. The inrush current limiter ensures that the capacitance is charged up slowly to avoid browning anything out. So this has been added to the USB power input of the WarpSE.
The address bus remapping capabilities have been improved, although the full address remapping capability will not be enabled on production boards. This new board has the ability to do any remapping on the top four address bits going from the fast bus to the PDS. This would let us remap any address $YXXXXX to $ZXXXXX. However, on production boards, remapping for address bits A23, A21, and A20 will be disabled, and only A22 can be remapped. This is to save space in the CPLD, since one logic element in the CPLD is required to implement each address bit that's remapped. Recent versions of the WarpSE firmware have been using 125-139 of the 144 logic elements, so I don't feel comfortable spending an additional 3 logic elements for this function that might not be useful. We might need that extra space in the CPLD to fix a bug later. Just being able to remap A22 lets the WarpSE access 2496 kB of extra motherboard RAM (if you have 4 MB installed). It's not contiguous, but it will be useful as a ~2.5 MB RAM disk.
The "bleeder resistors" are probably not necessary, so I may not actually place them. They're just to help the WarpSE more quickly discharge its power capacitance when powered off. Disadvantage is they waste power while the system is on.
And finally there's the overclocking connector. It of course is for use with the little overclocking board which I described before:
I changed the 32 MHz setting to 33 MHz to even out the frequency spacing. I'm excited to try this overclocking board since I never got around to hooking my fast waveform generator up to the WarpSE and overclocking it that way.
Just bought all the parts for 50 overclocking boards from JLCPCB! Once they're in I'm gonna have the boards assembled by JLC. WarpSEs themselves will of course be made under my and Garrett's supervision in our little semi-automated factory.
One other change in the main WarpSE board is to how the ROM banking works. The total flash ROM size in the WarpSE is 1 MB. The top two bits of the ROM address bus come from the CPLD, so the ROM can be banked in certain ways. I plan to store the Mac Classic ROM (512 kB), Mac SE ROM (256 kB) and Mac SE FDHD ROM (256 kB) in the ROMs on the final WarpSE. Only one of these ROMs will be enabled at a time, selectable via firmware update. The USB update system is really slow so the key here is that all three ROMs are always in the onboard flash, and updating the ROM just changes the CPLD a little to select a different ROM. The FDHD ROM will be default but the non-FDHD SE ROM is also present in case there's a problem on systems without a SWIM. The Classic ROM works on the SE and it has the benefits of the ROM disk, but it's of course experimental on the SE.
So in order to select one of the 256 kB ROMs (original SE or FDHD), the CPLD sets the top two address bits going to the ROM. In the case of the 512 kB Classic ROM, the CPLD must set the top address bit but then pass the lower bit through from the address bus. The current WarpSE can do this but the two ROM bank bits are multiplexed with the RAM address bus. This works fine but it means that the CPLD has to react to whether an access is to RAM or ROM and send the right data on the lines that are shared between RAM addressing and ROM banking. That takes extra time and I neglected to include that delay in the CPLD in my overclocking wait state analysis. The extra delay in the CPLD might mean that even at 30 MHz, a ROM wait state is required for reliable operation. Therefore in the latest revision, the ROM bank bus has been separated from the RAM address bus. The ROM bank bus still comes out of the CPLD, but when using a 256 kB ROM like the original SE or FDHD ROM, the bits are set statically and never change, so the timing is not affected. This is as opposed to currently, where the CPLD would have to see the ROM address range and then drive the static bank for the current ROM. Unfortunately still when running a 512 kB ROM the CPLD has to buffer the lower bank bit, reintroducing the delay. So when running the Classic ROM, a ROM wait state may be required at all frequency settings, even 30 MHz. No big deal though.
Soon I'll get this board revision fabbed and the WarpSE will be on its way to release!
As I said before, the SiTime MEMS oscillator is as accurate as a crystal, but has better temperature stability and can handle higher peak G-forces which would shatter the crystal in a crystal oscillator.
In this version, the WarpSE can OR the power from USB and the Mac so that it can be programmed outside of the Mac. Since the CPLD can now be powered up with the Mac off, recent firmware versions since 0.6b have had a power fail detector that automatically tristates (disables) the signals going from the WarpSE's CPLD to the Mac's PDS bus when the Mac is off. The power fail detector works by measuring the frequency and duty cycle of the Mac's 7.8336 MHz "C8M" clock relative to the onboard 25+ MHz oscillator. If the C8M clock is not toggling, the Mac's power must be off or browning out, so in this case, the WarpSE disables its outputs onto the PDS.
Associated with the USB power input is a new fuse and inrush current limiter. The purpose of the fuse is obvious enough, but the inrush current limiter is interesting and less obvious. Per the USB specification, a device may not have more than 10 µF of capacitance directly on the +5V power line of a USB device. If there's more capacitance, when plugging in the device, the inrush current could large enough to brown out the PC’s USB power. The WarpSE has over 100 µF of capacitance on its +5V rail, so that’s not good to plug directly into USB. In order to have more than 10 µF of capacitance, you have to apply an inrush current limit circuit between your big capacitance and the USB power. The inrush current limiter ensures that the capacitance is charged up slowly to avoid browning anything out. So this has been added to the USB power input of the WarpSE.
The address bus remapping capabilities have been improved, although the full address remapping capability will not be enabled on production boards. This new board has the ability to do any remapping on the top four address bits going from the fast bus to the PDS. This would let us remap any address $YXXXXX to $ZXXXXX. However, on production boards, remapping for address bits A23, A21, and A20 will be disabled, and only A22 can be remapped. This is to save space in the CPLD, since one logic element in the CPLD is required to implement each address bit that's remapped. Recent versions of the WarpSE firmware have been using 125-139 of the 144 logic elements, so I don't feel comfortable spending an additional 3 logic elements for this function that might not be useful. We might need that extra space in the CPLD to fix a bug later. Just being able to remap A22 lets the WarpSE access 2496 kB of extra motherboard RAM (if you have 4 MB installed). It's not contiguous, but it will be useful as a ~2.5 MB RAM disk.
The "bleeder resistors" are probably not necessary, so I may not actually place them. They're just to help the WarpSE more quickly discharge its power capacitance when powered off. Disadvantage is they waste power while the system is on.
And finally there's the overclocking connector. It of course is for use with the little overclocking board which I described before:
I changed the 32 MHz setting to 33 MHz to even out the frequency spacing. I'm excited to try this overclocking board since I never got around to hooking my fast waveform generator up to the WarpSE and overclocking it that way.
Just bought all the parts for 50 overclocking boards from JLCPCB! Once they're in I'm gonna have the boards assembled by JLC. WarpSEs themselves will of course be made under my and Garrett's supervision in our little semi-automated factory.
One other change in the main WarpSE board is to how the ROM banking works. The total flash ROM size in the WarpSE is 1 MB. The top two bits of the ROM address bus come from the CPLD, so the ROM can be banked in certain ways. I plan to store the Mac Classic ROM (512 kB), Mac SE ROM (256 kB) and Mac SE FDHD ROM (256 kB) in the ROMs on the final WarpSE. Only one of these ROMs will be enabled at a time, selectable via firmware update. The USB update system is really slow so the key here is that all three ROMs are always in the onboard flash, and updating the ROM just changes the CPLD a little to select a different ROM. The FDHD ROM will be default but the non-FDHD SE ROM is also present in case there's a problem on systems without a SWIM. The Classic ROM works on the SE and it has the benefits of the ROM disk, but it's of course experimental on the SE.
So in order to select one of the 256 kB ROMs (original SE or FDHD), the CPLD sets the top two address bits going to the ROM. In the case of the 512 kB Classic ROM, the CPLD must set the top address bit but then pass the lower bit through from the address bus. The current WarpSE can do this but the two ROM bank bits are multiplexed with the RAM address bus. This works fine but it means that the CPLD has to react to whether an access is to RAM or ROM and send the right data on the lines that are shared between RAM addressing and ROM banking. That takes extra time and I neglected to include that delay in the CPLD in my overclocking wait state analysis. The extra delay in the CPLD might mean that even at 30 MHz, a ROM wait state is required for reliable operation. Therefore in the latest revision, the ROM bank bus has been separated from the RAM address bus. The ROM bank bus still comes out of the CPLD, but when using a 256 kB ROM like the original SE or FDHD ROM, the bits are set statically and never change, so the timing is not affected. This is as opposed to currently, where the CPLD would have to see the ROM address range and then drive the static bank for the current ROM. Unfortunately still when running a 512 kB ROM the CPLD has to buffer the lower bank bit, reintroducing the delay. So when running the Classic ROM, a ROM wait state may be required at all frequency settings, even 30 MHz. No big deal though.
Soon I'll get this board revision fabbed and the WarpSE will be on its way to release!
Last edited:
So the primary (or only?) benefit of using the Mac Classic ROM in WarpSE is to enable a 2.5MB RAM disk, correct?
Great!
So with the Mac Classic ROM enabled in WarpSE, we would then be able to press Command-Option-X-O and boot from ROM into System 6.0.3, just as a regular Mac Classic can do.
And when using the special System Extension you mention, we would then have a 2.5MB RAM disk (contents lost when power is switched OFF), if 4MB RAM is installed on the SE motherboard.
That combined with the Overclocking board, WarpSE being flashable when not attached to the motherboard at all, and other improvements like current limiter, fuse, ferrite bead noise filtering, and MEMS oscillator make this outstanding upgrade even more fantastic. Incredible work, Zane!
Perhaps - we'll find out.
There are a couple of enhancements in the Classic ROM, but it might be for nothing. Some of the Mac ROMs only offer the enhancements when booting specific machines - the Classic ROM is a series of patches on top of the base SE ROM - if those patches don't apply when you boot an SE using that ROM, then the advantages are smaller, but hey, there is only one way to find out!
At the very least it will contain some bug fixes versus the SE ROM.
Just put some BlueSCSI v2s together and tried one with the WarpSE. Wow, look at the disk speed benchmark now!:
2.719 disk speed!! Great. And of course with the slightly faster clock on the final version, speed should be increased by another 4% or so! I am hoping to slightly exceed the SE/30's CPU score.
Right now I'm looking over the final board design and trying to find any remaining areas where the reliability may be marginal before I get it made. I'm also trying to figure out if there are any parts placements that can be skipped. It's not so much to save money, since SMD caps and resistors are like less than a cent each, but to save time, since our pick and place takes like 20 seconds to place a single part. So if we make 325 WarpSEs, every part saved is like two hours saved supervising the machine. Unfortunately I'm not finding many parts to skip placing.
Maybe I can remove the bleeder resistors, since I don't think they really do anything useful, but that's only three resistors saved.
There are some pull-up resistors I'm using to save space in the CPLD, but I'd like to keep 'em. The idea of how this works is that on the ROM bank bus, for example, when running a 256 kB ROM, the CPLD outputs a constant 0 or 1 on both of the ROM bank bus pins. The CPLD can output a constant 0 without wasting one of its 144 macrocells (logic elements), but to output a constant 1, a macrocell must be used. With the external pull-up, we can get a constant 1 on the line without wasting a macrocell by setting the pin as an input and letting the pull-up resistor drive the line high. There are three places where I'm doing this, so that amounts to 2% space saved in the CPLD. So I'd rather place three resistors and save 2% of the CPLD.
Another important thing I need to do is figure out which macrocells in the CPLD can be put into the low-power mode. Low-power mode basically uses half the power as high-speed mode but increases pin-to-pin latency and limits synchronous (clocked) speed to about 50 MHz. Certain signals that should go through the CPLD as fast as possible and they must remain in high-speed mode. I should however be able to find some internal state logic that can be put into the low-power mode.
There are basically four areas where we want maximum speed and cannot use the low-power mode:
2.719 disk speed!! Great. And of course with the slightly faster clock on the final version, speed should be increased by another 4% or so! I am hoping to slightly exceed the SE/30's CPU score.
Right now I'm looking over the final board design and trying to find any remaining areas where the reliability may be marginal before I get it made. I'm also trying to figure out if there are any parts placements that can be skipped. It's not so much to save money, since SMD caps and resistors are like less than a cent each, but to save time, since our pick and place takes like 20 seconds to place a single part. So if we make 325 WarpSEs, every part saved is like two hours saved supervising the machine. Unfortunately I'm not finding many parts to skip placing.
Maybe I can remove the bleeder resistors, since I don't think they really do anything useful, but that's only three resistors saved.
There are some pull-up resistors I'm using to save space in the CPLD, but I'd like to keep 'em. The idea of how this works is that on the ROM bank bus, for example, when running a 256 kB ROM, the CPLD outputs a constant 0 or 1 on both of the ROM bank bus pins. The CPLD can output a constant 0 without wasting one of its 144 macrocells (logic elements), but to output a constant 1, a macrocell must be used. With the external pull-up, we can get a constant 1 on the line without wasting a macrocell by setting the pin as an input and letting the pull-up resistor drive the line high. There are three places where I'm doing this, so that amounts to 2% space saved in the CPLD. So I'd rather place three resistors and save 2% of the CPLD.
Another important thing I need to do is figure out which macrocells in the CPLD can be put into the low-power mode. Low-power mode basically uses half the power as high-speed mode but increases pin-to-pin latency and limits synchronous (clocked) speed to about 50 MHz. Certain signals that should go through the CPLD as fast as possible and they must remain in high-speed mode. I should however be able to find some internal state logic that can be put into the low-power mode.
There are basically four areas where we want maximum speed and cannot use the low-power mode:
- Anything where there's a pin-to-pin propagation delay should be fast. This is mainly the RAM address bus and the /RAS signal.
- Similarly, anything directly sampling external pins should be fast too.
- There are some areas where an asynchronous signal is sampled, for example the interface between the fast bus port to the PDS and the PDS master. In these cases, high-speed mode must be used as well to quickly resolve any metastable state caused by sampling the signal when it happens to be changing.
- And finally the high-speed mode should be used for any macrocells clocked by the fast clock but which sample something from the opposite fast clock edge. There are a few signals clocked by the fast clock falling edge but which sample stuff clocked out on the fast clock rising edge. For those, 25 MHz fast bus speed is like 50 MHz, so overclocking capability would be restricted if these were put into low-power mode.
Last edited:
Zane, you talk about the clocked speed being "limited" to 50MHz, so does that mean your CPLD is clocked higher than that now?
What could you achieve with that 2% that you could not without it?
That's achieved with your latest WarpSE board revision (not what we beta testers have), correct? Meaning, if you retest your BSv2 on the first edition WarpSE board which we beta testers have, is the speed much lower?
@JDW I haven't yet sent the new board revision to fab, so no, this is the same old board with 25 MHz CPU speed. I was just remarking that BlueSCSI v2 is fast.
About the macrocell low-power mode, what I mean is that the additional delay due to low-power mode makes the CPLD too slow to reliably operate at frequencies above 50 MHz. Of course, that 50 MHz figure is rising edge-to-rising edge or falling edge-to-falling edge. Since the WarpSE logic has some spots where synchronous logic samples signals clocked by the opposite clock edge, "50 MHz" speed capability is required even to run at 25 MHz, at least for those particular paths. So at 36 MHz, the maximum speed on the overclocking board, any rising edge-to-falling edge or falling edge-to-rising edge paths are more like 72 MHz speed. Thus the high-speed mode (which is currently applied to all macrocells) is required anywhere this occurs. But for state bits clocked at the rising edge whose logic equation is only a function of other state bits clocked out at the rising edge, we can enable the low power mode since 50 MHz is far above our overclocking speed target of 36 MHz.
About the macrocell low-power mode, what I mean is that the additional delay due to low-power mode makes the CPLD too slow to reliably operate at frequencies above 50 MHz. Of course, that 50 MHz figure is rising edge-to-rising edge or falling edge-to-falling edge. Since the WarpSE logic has some spots where synchronous logic samples signals clocked by the opposite clock edge, "50 MHz" speed capability is required even to run at 25 MHz, at least for those particular paths. So at 36 MHz, the maximum speed on the overclocking board, any rising edge-to-falling edge or falling edge-to-rising edge paths are more like 72 MHz speed. Thus the high-speed mode (which is currently applied to all macrocells) is required anywhere this occurs. But for state bits clocked at the rising edge whose logic equation is only a function of other state bits clocked out at the rising edge, we can enable the low power mode since 50 MHz is far above our overclocking speed target of 36 MHz.
Just found and fixed another issue with the WarpSE! Running firmware 0.7d-fastscc a while, Prince of Persia would freeze after a while. The cause is basically the same as the crash in the sound control panel. The fix was easy, just adding a little more sound slowdown time after an access to the VIA chip. Right now I have my Mac SE on the test bench, running Prince of Persia all night to make sure that the fix works.
@Zane Kaminski
Just tested with BlueSCSIv2 while booted into System 7.1, and I get pretty much the same Disk score as you...
I also tested Prince of Persia, both while booted from my BlueSCSI v1 and then the v2 (with the same SD card). I first booted from my BSv1 and got a freeze during the game about 1 minute into game play. And that was after I watched the full opening animation with sound. I then changed to my BSv2 using a ribbon cable attached to the SCSI connector on the motherboard. I was able to play 7 minutes (got my sword and was going back), and then I got a freeze while running. This shows it's not the BlueSCSI version, and it's not a fixed period of time.
I am still using firmware 0.7d-fastscc.
Just tested with BlueSCSIv2 while booted into System 7.1, and I get pretty much the same Disk score as you...
I also tested Prince of Persia, both while booted from my BlueSCSI v1 and then the v2 (with the same SD card). I first booted from my BSv1 and got a freeze during the game about 1 minute into game play. And that was after I watched the full opening animation with sound. I then changed to my BSv2 using a ribbon cable attached to the SCSI connector on the motherboard. I was able to play 7 minutes (got my sword and was going back), and then I got a freeze while running. This shows it's not the BlueSCSI version, and it's not a fixed period of time.
I am still using firmware 0.7d-fastscc.
Huh, that's interesting that it took so long for you. What if you just wait through the intro cutscene and watch the demo gameplay footage? The freeze always happened before the demo finished for me. I am working on version 0.8 which will incorporate the "Prince of Persia fix." However that's on the back-burner until I send the final WarpSE boards to get made. The new 0.8 firmware is also supposed to support both the new "final" board as well as the prototypes. Of course all testers are gonna receive the final board too, I just wanna keep the prototypes going as well.
I've already gone home and the WarpSE machine is at the office, so I shall test that tomorrow!
Problem confirmed while booted into both System 6 and 7.1. Rebooting with WarpSE disabled shows no problem at all, proving the problem is definitely WarpSE...
Just finished running the Prince of Persia demo for 24 hours with the new fix. Problem solved! That was easy enough.
Very interesting. Even though the problem is apparently fixed, it seems clear that we beta testers should probably test the Prince of Persia demo on every new firmware version release!