Video demonstration and discussion about the "double bong" problem that currently only seems to be affecting SE Reloaded, not the stock SE motherboard. 
WarpSE: 25 MHz 68HC000-based accelerator for Mac SE
- Thread starter Zane Kaminski
- Start date
When testing WarpSE-0.6h on the stock Apple SE motherboard while booted into System 7.1 off my BlueSCSIv1, I get these results:
(Screenshot is in color because I saved the results file on my SE, then removed the SD card and put it in my modern Mac running Basilisk II, where I made the screenshot.)
Speedometer 3.23:
(Screenshot is in color because I saved the results file on my SE, then removed the SD card and put it in my modern Mac running Basilisk II, where I made the screenshot.)
Speedometer 3.23:
@JDW This the double bong problem is so puzzling. Does it reliably continue to happen after the WarpSE is removed unless you wait for a while?
I suggest maybe to test this that you go back to version 0.6b or 0.6a and see if it continues to happen. By the way, 0.6c, 0.6d, 0.6e, and 0.6g are not fully functional so the only versions in the 0.6 series I recommend trying are 0.6a, 0.6b, 0.6f, and 0.6h. 0.6a is similar to the 1.x and 0.5-series versions, 0.6b integrates a new startup sequence, 0.6c, d, and e had revisions to the RAM controller and PDS bridge but were not fully functional. 0.6f is the first version with the RAM and PDS revisions that worked for me and with which I could find no further timing or logic mistakes. 0.6g removed the fixed wait state sound slowdown and made some preparations for the next hardware revisions but had a mistake that caused it not to work on the current hardware. 0.6h fixed that mistake. So in the 0.6 series, I only think 0.6a, 06.b, 0.6f, 0.6h are worth trying.
You also said it did occur at least once on your stock SE motherboard. Is that correct?
Another thing you could investigate is, when the double bong occurs, does the reset signal pulse low? In that case, a chip on the motherboard or WarpSE must be driving it. There are only a two chips in the Mac SE that can drive the reset pin low. It could be the Sony sound chip, since it generates the power-on reset signal, it could be the onboard MC68000 CPU, since it drives reset low when executing the RESET instruction. The BBU and other I/O chips receive the reset signal but I don't think they can drive it.
So if you can get the double bong to happen while monitoring the reset signal with an oscilloscope, then we can see if it's because of the reset pin being pulsed low or because of a software issue.
If the reset pin is pulsed low when the second bong happens, we can temporarily remove chips capable of driving the reset signal. For example, we could take out the motherboard CPU and Sony sound chip. I believe the motherboard CPU and Sony sound chip are unnecessary when using the WarpSE. Of course, without the sound chip, then SE will not produce audio, but the WarpSE duplicates the other function of the Sony chip, which is that it drives the reset pin low until power is ready. Because the WarpSE's CPLD drives reset low for almost 0.3 seconds when it powers on, as long as the power supply is a reliable unit that ramps up quickly, the Sony chip's power-on reset function is not needed. Then the test can be repeated and more chips added/removed until the problem is isolated.
If the reset pin is not being driven low when the second bong occurs, it may be a software issue, perhaps relating to RAM retention.
I have a thought to test for this. Remove two of the four RAM sticks from the Mac SE such that it only has 2 MB of RAM. The WarpSE will be able to operate and will have 4 MB of RAM, although the framebuffer and sound data in the motherboard RAM may be corrupted. This corruption, if it occurs, is harmless and not even "visible" to software running on the WarpSE's CPU. It's just a visual issue and will in no way affect execution. I think moving the mouse over any corrupted spots will cause them to reappear. The underlying problem will be fixed in the next hardware revision so that you do not need any particular RAM quantity in the Mac SE, but for now any visual corruption will have to be ignored if if occurs during this particular test.
Anyway, with only two RAM sticks and the WarpSE installed, once you are able to get the double bong, remove the WarpSE and see if you can get it again. If so, then reinstall the WarpSE, reproduce the double bong, remove the WarpSE, but then switch the RAM sticks for the other two which were not recently used. Make sure to leave the WarpSE out of the system and reboot. Double bong occurs? Try switching back and forth between RAM sticks to see if that affects the ability to get the double bong.
I suggest maybe to test this that you go back to version 0.6b or 0.6a and see if it continues to happen. By the way, 0.6c, 0.6d, 0.6e, and 0.6g are not fully functional so the only versions in the 0.6 series I recommend trying are 0.6a, 0.6b, 0.6f, and 0.6h. 0.6a is similar to the 1.x and 0.5-series versions, 0.6b integrates a new startup sequence, 0.6c, d, and e had revisions to the RAM controller and PDS bridge but were not fully functional. 0.6f is the first version with the RAM and PDS revisions that worked for me and with which I could find no further timing or logic mistakes. 0.6g removed the fixed wait state sound slowdown and made some preparations for the next hardware revisions but had a mistake that caused it not to work on the current hardware. 0.6h fixed that mistake. So in the 0.6 series, I only think 0.6a, 06.b, 0.6f, 0.6h are worth trying.
You also said it did occur at least once on your stock SE motherboard. Is that correct?
Another thing you could investigate is, when the double bong occurs, does the reset signal pulse low? In that case, a chip on the motherboard or WarpSE must be driving it. There are only a two chips in the Mac SE that can drive the reset pin low. It could be the Sony sound chip, since it generates the power-on reset signal, it could be the onboard MC68000 CPU, since it drives reset low when executing the RESET instruction. The BBU and other I/O chips receive the reset signal but I don't think they can drive it.
So if you can get the double bong to happen while monitoring the reset signal with an oscilloscope, then we can see if it's because of the reset pin being pulsed low or because of a software issue.
If the reset pin is pulsed low when the second bong happens, we can temporarily remove chips capable of driving the reset signal. For example, we could take out the motherboard CPU and Sony sound chip. I believe the motherboard CPU and Sony sound chip are unnecessary when using the WarpSE. Of course, without the sound chip, then SE will not produce audio, but the WarpSE duplicates the other function of the Sony chip, which is that it drives the reset pin low until power is ready. Because the WarpSE's CPLD drives reset low for almost 0.3 seconds when it powers on, as long as the power supply is a reliable unit that ramps up quickly, the Sony chip's power-on reset function is not needed. Then the test can be repeated and more chips added/removed until the problem is isolated.
If the reset pin is not being driven low when the second bong occurs, it may be a software issue, perhaps relating to RAM retention.
I have a thought to test for this. Remove two of the four RAM sticks from the Mac SE such that it only has 2 MB of RAM. The WarpSE will be able to operate and will have 4 MB of RAM, although the framebuffer and sound data in the motherboard RAM may be corrupted. This corruption, if it occurs, is harmless and not even "visible" to software running on the WarpSE's CPU. It's just a visual issue and will in no way affect execution. I think moving the mouse over any corrupted spots will cause them to reappear. The underlying problem will be fixed in the next hardware revision so that you do not need any particular RAM quantity in the Mac SE, but for now any visual corruption will have to be ignored if if occurs during this particular test.
Anyway, with only two RAM sticks and the WarpSE installed, once you are able to get the double bong, remove the WarpSE and see if you can get it again. If so, then reinstall the WarpSE, reproduce the double bong, remove the WarpSE, but then switch the RAM sticks for the other two which were not recently used. Make sure to leave the WarpSE out of the system and reboot. Double bong occurs? Try switching back and forth between RAM sticks to see if that affects the ability to get the double bong.
Last edited:
@JTRetro Thanks for posting the video! My next step is going to be to develop a control panel and hardware-software interface to allow the slowdown parameters to be adjusted. I'm not sure if I will be able to retain this in the final version, since it may be budgeted out of the CPLD chip if more important functions are needed. But we can test with it for now. This will also let @ppuskari try faster SCSI and LocalTalk without a reflash. Plus if you don't care about sound you can turn off the sound fix and reclaim 1.5% of speed or whatever the overhead is. So that's my next step but that'll take a bit of time to make the control panel, plus I'd like to make more prototypes and figure out @JDW's double bong issue. I am gonna post firmware 0.6i soon which has very accurate clock-gated slowdown, but other than trying that, there are no specific testing goals for now. Thanks again for testing!!
@Zane Kaminski & @Kai Robinson & Steve Chamberlin:
After much testing, the root cause of the Double Bong Problem is the FloppyEMU, even with the newest 20240209 Mac Firmware flashed to it. (Mine is Model B.)
The Double Bong problem NEVER occurs on my stock SE motherboard.
The Double Bong problem almost ALWAYS occurs on my SE Reloaded motherboard, but only when the FloppyEMU is attached.
The implications for WarpSE are that when the FloppyEMU is attached, I cannot press INTERRUPT to disable WarpSE. If I press and hold INTERRUPT, then power ON, I get a bong! That shouldn't happen. But like I said, it NEVER happens on the stock SE motherboard.
I sent an email to Steve Chamberlin to invite him into this conversation only to ask for his speculation. This is not accusatory and complaining on my part. We just need to figure out why this is happening. That starts with educated guessing. If we don't know why it might be happening, it cannot be fixed.
Why does this even matter? How does it pertain to WarpSE now?
Well, I suspect that anyone willing to invest the 15 hours required to build an SE Reloaded board probably has more incentive to add upgrades like WarpSE to it. Maybe I'm wrong on that speculation, but it behoves us nonetheless to figure out why SE Reloaded isn't playing well with the FloppyEMU.
If we totally ignore WarpSE, the Double Bong issue doesn't matter so much. The double bong is strange and worrisome, to be sure, but I've not found it to in any way negatively impact the normal SE motherboard usage (without WarpSE). It's only when WarpSE is added that you suddenly can no longer use INTERRUPT to disable WarpSE, which is indeed a problem.
For the sake of Kai Robinson and Steve Chamberlin being better able to speculate on the root cause for the Double Bong problem, I've made two videos that show you everything you need to know:
After much testing, the root cause of the Double Bong Problem is the FloppyEMU, even with the newest 20240209 Mac Firmware flashed to it. (Mine is Model B.)
The Double Bong problem NEVER occurs on my stock SE motherboard.
The Double Bong problem almost ALWAYS occurs on my SE Reloaded motherboard, but only when the FloppyEMU is attached.
The implications for WarpSE are that when the FloppyEMU is attached, I cannot press INTERRUPT to disable WarpSE. If I press and hold INTERRUPT, then power ON, I get a bong! That shouldn't happen. But like I said, it NEVER happens on the stock SE motherboard.
I sent an email to Steve Chamberlin to invite him into this conversation only to ask for his speculation. This is not accusatory and complaining on my part. We just need to figure out why this is happening. That starts with educated guessing. If we don't know why it might be happening, it cannot be fixed.
Why does this even matter? How does it pertain to WarpSE now?
Well, I suspect that anyone willing to invest the 15 hours required to build an SE Reloaded board probably has more incentive to add upgrades like WarpSE to it. Maybe I'm wrong on that speculation, but it behoves us nonetheless to figure out why SE Reloaded isn't playing well with the FloppyEMU.
If we totally ignore WarpSE, the Double Bong issue doesn't matter so much. The double bong is strange and worrisome, to be sure, but I've not found it to in any way negatively impact the normal SE motherboard usage (without WarpSE). It's only when WarpSE is added that you suddenly can no longer use INTERRUPT to disable WarpSE, which is indeed a problem.
For the sake of Kai Robinson and Steve Chamberlin being better able to speculate on the root cause for the Double Bong problem, I've made two videos that show you everything you need to know:
Heh, I don't fully agree regarding reloaded vs original
. Some of us are very attached to the machines we've personally owned for 26 years 
Hi all !
So as @JDW kindly asked me, I did carry out a test with one of my SE reloaded boards (red one).
This was a quick and dirty test, will be more rigorous now.
The board is currently with 4 MB RAM, in an SE/30 enclosure, with a fully recapped Sony PSU, analog board not recapped at all, and I am on 230V/50 Hz here.
I plugged in a FloppyEmu model C, rev 1.7, connected through the external flat cable.
I did not get a double Bong on boot. I choose a 6.0.8 install image a few seconds after, and it booted straight with now issue.
First test was without mouse and keyboard.
Just did a second test with mouse / keyboard plugged in, no double bong.
The board is inside the case, with no extension of any sort.
Also, if you remember, my board is using modern coils, as you can see here :
Should I test in another enclosure ?
So as @JDW kindly asked me, I did carry out a test with one of my SE reloaded boards (red one).
This was a quick and dirty test, will be more rigorous now.
The board is currently with 4 MB RAM, in an SE/30 enclosure, with a fully recapped Sony PSU, analog board not recapped at all, and I am on 230V/50 Hz here.
I plugged in a FloppyEmu model C, rev 1.7, connected through the external flat cable.
I did not get a double Bong on boot. I choose a 6.0.8 install image a few seconds after, and it booted straight with now issue.
First test was without mouse and keyboard.
Just did a second test with mouse / keyboard plugged in, no double bong.
The board is inside the case, with no extension of any sort.
Also, if you remember, my board is using modern coils, as you can see here :
Should I test in another enclosure ?
Just tested from the internal ports as well, still no double bong.
Tested the new H. Things are okay, but I still get the address error on shutdown or restart and LocalTalk still not working. I reflashed "fastscsi" back to the board and Localtalk works again. Address error on shutdown and restart is still common. I am going to remove some of the stuffit deluxe pieces temporarily and maybe even take things back down to stock miniumum 7.1 and see if that makes a difference. When I boot with the accellerator off I do NOT get the address error stuff though in testing. I'll download the games and speedometer next and retry h again.
@iPhil64
Thank you for testing your SE Reloaded board with FloppyEMU Model C.
I’ve been testing Model B, but I have a Model C at home. I will bring it to work tomorrow and give it a test on my lunch break!
Thank you for testing your SE Reloaded board with FloppyEMU Model C.
I’ve been testing Model B, but I have a Model C at home. I will bring it to work tomorrow and give it a test on my lunch break!
The fact the issue persists for some time even after reboot then clears out would suggest some capacitor at work there.
I can not see how persistence would be possible if not caused by a cap somewhere.
Could also explain the issues you see with the WarpSE ?
@JDW For some of the weirdness I've been seeing is what I have finally isolated down to the Scsi Director Pro 4.0 drivers. I happened to test my same zip100 cart based 7.1.1.1Pro that I've been running with WarpSE testing today and noticed the address errors and some just weird stalls go completely away if I'm only running Scsi Director/Pro 3.1 Drivers. On Stock SE I didn't see the issue, but I just have seen the same on WarpSE and Radius 16 accelerator in the same SE I've been using.
I'm going back now with a fresh Scsi Director 3.1 on 7.1.1.1Pro to validate the WarpSE firmware.... At least I think we have part of the issues fixed up. If using the Apple or Scsi Director 3.1 drivers on boot partitions and other mounted media things seem to be okay restart and shutdown wise for me.
I know you were using 4.0 for a while JDW right? If you can test with 3.1 on a boot instance and see if that maybe clears up weird stuff for your mouse and other things?
Just validated on another Mac SE I have. This one is a 4 meg older motherboard with the resistor set cut, and then it also had 2 800k floppies and the original rom set. WarpSE shuts down and restarts just fine with "fastscsi" firmware now that I am using Scsi Director 3.1 drivers instead of 4.0
I'm going back now with a fresh Scsi Director 3.1 on 7.1.1.1Pro to validate the WarpSE firmware.... At least I think we have part of the issues fixed up. If using the Apple or Scsi Director 3.1 drivers on boot partitions and other mounted media things seem to be okay restart and shutdown wise for me.
I know you were using 4.0 for a while JDW right? If you can test with 3.1 on a boot instance and see if that maybe clears up weird stuff for your mouse and other things?
Just validated on another Mac SE I have. This one is a 4 meg older motherboard with the resistor set cut, and then it also had 2 800k floppies and the original rom set. WarpSE shuts down and restarts just fine with "fastscsi" firmware now that I am using Scsi Director 3.1 drivers instead of 4.0
Last edited:
@ppuskari
While I have been using SCSI Director Pro 4.0 exclusively “for testing,” I’ve never installed a SCSI Director Pro “driver” on any SCSI drive.
My BlueSCSI v1 drive volumes all have the Eric Helgeson recommended HD SC Setup 7.3.5 driver installed.
While I have been using SCSI Director Pro 4.0 exclusively “for testing,” I’ve never installed a SCSI Director Pro “driver” on any SCSI drive.
My BlueSCSI v1 drive volumes all have the Eric Helgeson recommended HD SC Setup 7.3.5 driver installed.
The only thing ona a Reloaded board that I think could be a problem is a trace being bridged somewhere on the PDS connector - it's insanely tight there, and may be causing the problem?
@JDW, the curious thing is that the WarpSE should always “listen to” the /IPL2 line from the interrupt key when starting up. If it doesn’t and starts up anyway, that means that something along the lines of the WarpSE not receiving the signal or not receiving power is occurring. And if the WarpSE ever “forgets” the current enablement setting, that can only be triggered by a glitch of the +5V power or 7.8336 MHz clock as delivered to the WarpSE. In case of a brownout or 7.8336 MHz clock glitch the WarpSE always tries to reset the system by pulsing /RESET low.
The most useful thing you could do right now to track down this issue is to see if the /RESET line pulses low right before the second bong occurs. If it does pulse low, the particular waveform is also useful. How long does it stay low? Is it between 220 and 290 milliseconds? Then it may be the WarpSE’s CPLD, although obvious the double bong occurs without the WarpSE installed. Are the high-to-low and low-to-high transitions clean, or is there a lot of “noise?” That could indicate a bad connection or solder joint.
I have not had a chance to watch your videos yet. Will do this in the next hour or so.
@iPhil64, thanks for helping to look into this issue! One tricky thing is that DRAM storage is based on capacitance, so the contents of RAM tend not to be erased immediately after power off but to slowly fade away to a “checkerboard” pattern over many seconds or even minutes. This can happen even if the power to the RAM is totally at 0 volts. For example, on new PCs, there’s the “cold boot attack,” where you can extract hard drive encryption keys from a computer by freezing its RAM while on (using freeze spray), then putting the RAM in another system, turning it on, and reading out the contents, including the key.
So one possibility is that the RAM is retaining some state but has become slightly corrupted. Then the software sees a magic number in RAM saying that the RAM is ready for a “warm boot,” but then it tries to use the data in RAM but it’s corrupted elsewhere and the system crashes. The WarpSE usually works exclusively out of its onboard RAM except when writing to the Mac’s screen framebuffer, but during slowdown, all writes are put out to the motherboard just as a byproduct of the logic design of the system. This will be rectified in the final version so we can possibly use the motherboard RAM as a ROM disk without it getting corrupted during slowdown. But the takeaway is that whenever the WarpSE happens to be in slowdown, which occurs for 0.2 milliseconds after an I/O chip on the motherboard is accessed, writes from the WarpSE will go through to the motherboard. So maybe a magic number like that is getting written through to RAM but then the other stuff it signifies isn’t. Hence why the WarpSE may trigger the problem and then it persists on the motherboard for a while. That’s just a theory though, and now James says the problem is not super related to the WarpSE, so we will have to investigate further.
The most useful thing you could do right now to track down this issue is to see if the /RESET line pulses low right before the second bong occurs. If it does pulse low, the particular waveform is also useful. How long does it stay low? Is it between 220 and 290 milliseconds? Then it may be the WarpSE’s CPLD, although obvious the double bong occurs without the WarpSE installed. Are the high-to-low and low-to-high transitions clean, or is there a lot of “noise?” That could indicate a bad connection or solder joint.
I have not had a chance to watch your videos yet. Will do this in the next hour or so.
@iPhil64, thanks for helping to look into this issue! One tricky thing is that DRAM storage is based on capacitance, so the contents of RAM tend not to be erased immediately after power off but to slowly fade away to a “checkerboard” pattern over many seconds or even minutes. This can happen even if the power to the RAM is totally at 0 volts. For example, on new PCs, there’s the “cold boot attack,” where you can extract hard drive encryption keys from a computer by freezing its RAM while on (using freeze spray), then putting the RAM in another system, turning it on, and reading out the contents, including the key.
So one possibility is that the RAM is retaining some state but has become slightly corrupted. Then the software sees a magic number in RAM saying that the RAM is ready for a “warm boot,” but then it tries to use the data in RAM but it’s corrupted elsewhere and the system crashes. The WarpSE usually works exclusively out of its onboard RAM except when writing to the Mac’s screen framebuffer, but during slowdown, all writes are put out to the motherboard just as a byproduct of the logic design of the system. This will be rectified in the final version so we can possibly use the motherboard RAM as a ROM disk without it getting corrupted during slowdown. But the takeaway is that whenever the WarpSE happens to be in slowdown, which occurs for 0.2 milliseconds after an I/O chip on the motherboard is accessed, writes from the WarpSE will go through to the motherboard. So maybe a magic number like that is getting written through to RAM but then the other stuff it signifies isn’t. Hence why the WarpSE may trigger the problem and then it persists on the motherboard for a while. That’s just a theory though, and now James says the problem is not super related to the WarpSE, so we will have to investigate further.
@ppuskari Petar, thanks for your help testing the latest version! Glad to hear the address error issue has been isolated. I will try the SCSI Director 4.0 drivers myself and try to see exactly what’s triggering the address error with my logic analyzer.
As for the LocalTalk issues, there have been a lot of bugfixes and “under the hood” changes between “fastscsi” and 0.6h but not too many functional changes. Except on the builds where everything was broken lol but that was by mistake. The biggest functional change in that time is that the I/O slowdown period (which applied to all I/O chips except SCSI in “fastscsi”) went from 35ish microseconds to 203ish microseconds. I have firmware 0.6i ready which has almost perfectly cycle-accurate slowdown but I think I am going to skip this release and instead move on to the subsequent 0.7 which will have an address you can poke to change the accelerator settings. Eventually I may do a control panel like I said but if you have the Programmer’s Key then you can hit the NMI button to get the debugger, poke the address, and then quit the debugger and return to the Mac OS to try the new slowdown settings. Format will be something like this:
Slowdown control register is at address $F00XXX. Register is written using address bits 11 through 1:
A[11:8] - SlowTimeout[3:0] - Controls low long the accelerator is slowed down for in multiples of 14x the Mac’s E clock rate.
A[6] - SlowVIA - slowdown triggered on VIA access
A[5] - SlowIWM - slowdown triggered on IWM access
A[4] - SlowSCC - slowdown triggered on SCC access
A[3] - SlowSCSI - slowdown triggered on SCSI access
A[2] - SlowSound - slowdown triggered on sound buffer write
A[1] - SlowClockGate - fast CPU clock reduced to C8M speed during slowdown
Hopefully I have room for all this in the CPLD, otherwise I may have to eliminate a few options. Not sure if it can ship in the final build either, at least not as an official feature, since I may need to reclaim space in the CPLD for other reasons. But anyway with this, you can play with the slowdown timeout and see if turning it back to setting 3 (28-42 microseconds) fixes the SCC. Plus you can also enable/disable fast SCSI, etc. The settings will stick through a reboot too, but not a power cycle since the CPLD just stores the settings in some registers and doesn’t write them to nonvolatile memory. I am probably gonna produce two builds of 0.7a, one with all slowdown features enabled and one with them all disabled (except maybe floppy). That way you can reboot with slowdown fully on or off and then see if changing the settings after that produces different results.
Anyway, I am working on a few more hardware things for testers, including some more WarpSE prototypes so everyone can compare between two units and also a little board that will let you reprogram the WarpSE outside of the Mac:
The WarpSE goes in the female header (will be a real DIN-41612 connector, this is just what I had for the 3d model). The you power it via USB or you could solder and zip tie banana cables to connect to a power supply (but not both at once!). The final production version will itself be able to be powered from the USB port so this shouldn’t be necessary on the final board revision, which I will send out eventually to all testers. I think the final version will be 25.946 MHz too since I just re-verified the timing for that speed.
As for the LocalTalk issues, there have been a lot of bugfixes and “under the hood” changes between “fastscsi” and 0.6h but not too many functional changes. Except on the builds where everything was broken lol but that was by mistake. The biggest functional change in that time is that the I/O slowdown period (which applied to all I/O chips except SCSI in “fastscsi”) went from 35ish microseconds to 203ish microseconds. I have firmware 0.6i ready which has almost perfectly cycle-accurate slowdown but I think I am going to skip this release and instead move on to the subsequent 0.7 which will have an address you can poke to change the accelerator settings. Eventually I may do a control panel like I said but if you have the Programmer’s Key then you can hit the NMI button to get the debugger, poke the address, and then quit the debugger and return to the Mac OS to try the new slowdown settings. Format will be something like this:
Slowdown control register is at address $F00XXX. Register is written using address bits 11 through 1:
A[11:8] - SlowTimeout[3:0] - Controls low long the accelerator is slowed down for in multiples of 14x the Mac’s E clock rate.
- 0 = always slow
- 1 = 7 microseconds avg. (range is 0 - 14.042 us)
- 2 = 21 us avg. (14 - 28 us)
- 3 = 35 us avg. (28 - 42 us)
- ...
- 15 = avg 203 us (196-210 us)
A[6] - SlowVIA - slowdown triggered on VIA access
A[5] - SlowIWM - slowdown triggered on IWM access
A[4] - SlowSCC - slowdown triggered on SCC access
A[3] - SlowSCSI - slowdown triggered on SCSI access
A[2] - SlowSound - slowdown triggered on sound buffer write
A[1] - SlowClockGate - fast CPU clock reduced to C8M speed during slowdown
Hopefully I have room for all this in the CPLD, otherwise I may have to eliminate a few options. Not sure if it can ship in the final build either, at least not as an official feature, since I may need to reclaim space in the CPLD for other reasons. But anyway with this, you can play with the slowdown timeout and see if turning it back to setting 3 (28-42 microseconds) fixes the SCC. Plus you can also enable/disable fast SCSI, etc. The settings will stick through a reboot too, but not a power cycle since the CPLD just stores the settings in some registers and doesn’t write them to nonvolatile memory. I am probably gonna produce two builds of 0.7a, one with all slowdown features enabled and one with them all disabled (except maybe floppy). That way you can reboot with slowdown fully on or off and then see if changing the settings after that produces different results.
Anyway, I am working on a few more hardware things for testers, including some more WarpSE prototypes so everyone can compare between two units and also a little board that will let you reprogram the WarpSE outside of the Mac:
The WarpSE goes in the female header (will be a real DIN-41612 connector, this is just what I had for the 3d model). The you power it via USB or you could solder and zip tie banana cables to connect to a power supply (but not both at once!). The final production version will itself be able to be powered from the USB port so this shouldn’t be necessary on the final board revision, which I will send out eventually to all testers. I think the final version will be 25.946 MHz too since I just re-verified the timing for that speed.
I will most likely as well tomorrow try out the dual mode MacRecorder setup to see how that goes with the serial ports too. I've been wanting to try the Stereo MacRecorder setup anyway since finally receiving a second unit recently. My Snooper card and box and software is now located and it comes with the serial dongles for testing too. I''m also planning on testing out a rarish early ProTools scsi based interface I have had for years with the SE as well. Should be fun to see how things work with SCSI throughput being heavily taxed.
Steve Chamberlin replied to me by email today suggesting I use my scope to probe Vcc and Reset/Halt on the 68000. I did that but couldn't find any issues, as you can see from my marked-up scope screenshots below.
Power-ON Timings (RESET/HALT goes HI about 300ms after Vcc rises to 5v):
Double-Bong Occurred with my Model B FEMU attached to the internal, lower drive connector (no WarpSE attached, no external drives attached, no BlueSCSI):
This shows what happens when I press the RESET switch and release it (normal, but I'm just showing you how the signals respond):
I tested my Model C FEMU, which is what @iPhil64 used. No double bong. I still need to test it more to be sure, but it looks for now like only the Model B FEMU triggers a double-bong, and only when used on the SE Reloaded board.
Last edited:
Not sure.
The website here only talks about:
1. New OLED display
2. New SD Card slot (I like the old push-to-eject slot better)
3. Black PCB color
4. New frosted case
The adapter you use to connect to the external drive connector is also a tiny bit different from Model B. But like I said, I've been doing most of my testing with the onboard drive connectors, which means I don't need that adapter at all.