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

[JDW]

Petar,

Previously you said Local talk, and your recent post says Appletalk.

I’ve not tried networking, but I did find a couple PhoneNet adapters at home I could try. In what way did you setup yours?



If you have or can make loopback plugs for the Printer and Modem ports, I’d love to hear if you can pass the Snooper 2.0 tests because I was able to, with WarpSE enabled.

 

[JTRetro]

@Zane Kaminski -The power supply was so low on voltage that nothing would come on, except the fan. So I simply swapped the board from that machine into the machine that i have been using for testing all along. This is my SE SuperDrive:

And this time, I wrote a note to myself on the computer so I remember what it has.....and what needs fixing


This is the machine that I've been testing with, an original Macintosh 800k SE:

 

[JTRetro]

Also, I guess I should re-iterate that I am using stock Macintosh boards with the accelerator; I do not have any re-loaded boards. I now have both an original 800k and 1.44Mb Superdrive board available for testing purposes.

 

[phipli]

Petar,

Previously you said Local talk, and your recent post says Appletalk.

In this context you don't need to worry about the difference, apple changed their naming convention over time. AppleTalk can be used over multiple types of hardware, LocalTalk specifically means using the serial ports.

I’ve not tried networking, but I did find a couple PhoneNet adapters at home I could try. In what way did you setup yours?

There isn't a practical difference between Petar using LocalTalk boxes and if you used PhoneNet... But, if you're only networking two computers, it is easier to just run a regular, completely normal, mac serial cable between the printer ports on two Macs. This is the equivalent of using a crossover cable or null-modem cable. It just works. No boxes.

Great way of linking two macs for games or moving some files.

This is the machine that I've been testing with, an original Macintosh 800k SE:

Nice to see the old CD Remote

 

[Kai Robinson]

Ohhh hang on... @JDW did you bodge the power pins for the SCC as that board revision had an error there that stops things like System 7 working properly/at all.

 

[ppuskari]

Yes I’m very familiar with the naming issues since I’ve worked so much with netatalk and GlobalTalk on myriads of machines over the last two years and previously.
In this specific case I’m talking about using the actual Apple LocalTalk serial port connectors to connect to the three wire system which connects to another Apple LodalTalk serial port connector that is connected to my Cayman Systems GatorBox CS which bridges Appleralk packets from LocalTalk to EtherTalk on the 10bT side which hits the local switch and then to three raspberry Pi running three versions of my PiScsi base build of netatalk on them as well as two Intel hosted Virtual box instances where my giant 2 tb of netatalk Apple archives live.

I can test the ports with snooper 2.0 later this coming evening. But I do know it used to work but now it doesn’t.

 

[JDW]

But, if you're only networking two computers, it is easier to just run a regular, completely normal, mac serial cable between the printer ports on two Macs. This is the equivalent of using a crossover cable or null-modem cable. It just works. No boxes.

Well, like I said in my earlier posts, I have two serial loopback connectors that I made specifically for use with Snooper 2, and with those installed, Snooper 2 gives both serial ports a clean bill of health. So if that is a sufficient test, I’m happy to leave it at that.

Ohhh hang on... @JDW did you bodge the power pins for the SCC as that board revision had an error there that stops things like System 7 working properly/at all.

You can see the fix I did for the SCC in the first minute of my Part 3 video here:

I can test the ports with snooper 2.0 later this coming evening. But I do know it used to work but now it doesn’t.

Petar, I look forward to hearing the results of that test in Snooper 2.

My thinking is, if there’s a specific test we can all do on the serial ports, that makes our serial port test have more meaning because we are then all doing the same test.

 

[JDW]

For my fellow WarpSE beta testers having freezing or crashing problems, I strongly advise use of Norton Disk Doctor 3.5.3 and Disinfectant 3.7.1 to make 100% sure there are no oddball things going on with your drive structure or files. That remains true even if you seem to have no issues with WarpSE removed. I did scans with those apps on my BlueSCSI drive images shortly after starting my WarpSE testing, and it found some issues which I then was able to correct.

Scanning large volumes is slow on your vintage Mac, but what I do is mount the SD card on my modern Mac with Basilisk II, then do the scans. It's much faster that way, and you'll be done in no time. Make sure you install the GUI app too, as that makes linking up your disk images very easy.

Also be sure to change the RAM allocation in the Get Info box for Disinfectant, or it may complain it lacks memory to check certain large files. You can do this easily in Basilisk II. I always allocate 9MB, and then it can scan just about anything.

 

[Zane Kaminski]

A bit about the project and verification status. In the CPLD there are five main subsystems:

• FSB: "fast-speed bus" or maybe "front-side bus" to borrow Intel's old terminology. This module controls the 25 MHz bus internal to the WarpSE card. Mainly it is concerned with looking at the /AS signal to see that a bus operation has started and then signaling /DTACK once all addressed subsystems are done with the operation.
• CS: "chip select". Decodes addresses on the FSB. This includes not just decoding RAM, ROM, and PDS addresses but also managing the "overlay bit" and decoding the slowdown trigger ranges.
• IOBS: "I/O bus slave". This module receives accesses from the fast CPU to the PDS bus (or "I/O bus" as I like to call it). When a read or write to the I/O bus occurs, the IOBS saves the relevant information and forwards the access to the IOBM module. For reads and writes to the Mac's I/O chips (VIA, SCC, etc.), the IOBS waits for the bus cycle to be completed on the I/O bus before telling the FSB module to signal /DTACK to the fast CPU. However, writes to the video framebuffer can be posted, and the IOBS and FSB can signal /DTACK to the main processor with zero wait states while the data written "trickles out" on the I/O bus. Two consecutive writes can be posted. The first is latched by the IOBM and goes out to the bus as soon as possible. If the IOBM is still busy with a previous posted write then the IOBS can enqueue a second write from the fast CPU in the posted write buffer queue.
• IOBM: "I/O bus master". This module receive I/O bus requests from the IOBS and puts them out onto the PDS bus with timing that matches the original 8 MHz MC68k as closely as possible. Once the I/O bus transaction is finished, it signals completion to the IOBS so that /DTACK can be asserted on the fast bus for non-posted reads and writes.
• RAM: "RAM and ROM controller". Controls the RAM and ROM. ROM accesses are totally asynchronous and unsequenced and occur with zero wait states. RAM reads and writes must be sequenced by the RAM state machine which controls the RAM's /RAS and /CAS lines. RAM reads and writes usually take four cycles (zero wait states) unless a RAM refresh is occurring. Refresh takes 4 cycles as well and occurs once every ~350 cycles, so the refresh overhead can be up to 1.14%. However the RAM controller tries to execute refreshes concurrent with accesses to the ROM or other chips. If a non-posted read/write to the I/O bus occurs in time, the entirety of a pending RAM refresh can be hidden during the I/O bus access. Similarly, if a ROM access happens in time, then three of the four cycles for RAM refresh can be hidden, since it takes one clock to recognize a ROM access. So two consecutive ROM accesses are required to hide all of refresh.
• CNT: "counter". This module is responsible for keeping track of long periods of time. It contains the initialization sequence, bus request sequence, RAM refresh counter, and slowdown function (which I call "quality of service" / "QoS"). Since resources in the CPLD are at a premium, the timers/counters for these things must be shared. So the initialization sequence and slowdown timer are both based on the RAM refresh counter. Hence why they're all together in the same module.

What's the status of all these modules?

The FSB module is really simple and it should have no bugs or timing issues that aren't originating from its interaction with other modules. Same for the CS module. The only thing that would need changed in there is to add/remove address ranges that are triggering slowdown. So no bug fixes in there, just sort of "policy" changes.

IOBS and IOBM have a complicated interaction. I just simplified the interface between them a bunch in version 0.6d, removing some redundant logic and freeing up space in the CPLD. I also spent a lot of time the night before last analyzing the latency between the modules, both theoretically and taking actual measurements with my logic analyzer. Since the IOBS runs at 25 MHz and the IOBM runs at 7.8336 MHz, latency between the modules is randomly distributed in a range rather than just being a fixed number of clock periods plus some temperature/chip-dependent propagation delay. The latency between the IOBS and IOBM is large. The IOBM must signal completion of the bus cycle to the IOBS a bit earlier than when the data is actually ready on the bus in order to cancel out the latency. Too early though, and the fast CPU will latch read data from the PDS bus too early and it could be invalid. Too late and a subsequent PDS operation from the fast processor will not get to the IOBM soon enough and there will be a gap on the PDS bus that wouldn't occur with an unaccelerated CPU.

For reference, at 25 MHz, the minimum latency from signaling completion of an I/O bus transaction to the fast CPU is 162 nanoseconds, and the worst case is about 210 nanoseconds. Going by the specs of the 8 MHz 68000 and the BBU ERS document, data is ready on the PDS bus about 137.7 nanoseconds after that same point. So there's 24.3 nanoseconds for the data to propagate through the WarpSE's buffers and for setup time at the 68HC000. These operations take only 12.5 nanoseconds in the worst case so we have 11.8 nanoseconds margin. Great.

However there's also the issue of the time required to go from the PDS bus, to the fast bus, and then back to the PDS to do a subsequent back-to-back transaction. The IOBM needs to hear from the IOBS about another transaction within 319.1 nanoseconds of it signaling completion of a transaction in order for them to be back-to-back on the PDS bus. The best-case delay for this is 284 nanoseconds but the worst-case for this is 320 nanoseconds. So unfortunately there is technically -0.9 nanoseconds of timing margin in the absolute worst case. Ideally this number would be nonnegative but that's at the maximum operating temperature, etc. If the time window is missed by that small amount then all that will happen is that the two transaction on the PDS will not be back-to-back. No big deal though since I don't think other accelerators like the 68000-based Levco SpeedCard and 68030-based MicroMac Performer can do back-to-back transactions in every case.

I will look into improving this latency more to solve that tiny 0.9 nanosecond worst-case timing violation. One thing we can do is increase the fast bus clock to 26 MHz. At 26 MHz, that 320 nanosecond worst-case latency will be reduced to 308.5 nanoseconds, giving 10.6 nanoseconds of margin. All other timings will still remain in spec. Another possible solution is to analyze the worst-case specs for the VIA, SCC, SCSI, and IWM chips. If I can confirm that Apple has left some extra timing margin in the system--i.e. that all of the I/O chips output valid data 10ish nanoseconds before 8 MHz 68000 requires it, then I can remove 1/2 of a fast clock cycle of delay between the IOBM and IOBS and all will be well. But like I said it's not a big deal in any case.

Another small issue with the IOBM is that the PDS read/write signal does not exactly follow the timing of an MC68000. Instead the R/W timing follows that of the address bus, which is not exactly what the 68k does. Looking at the SE schematic and the ERS specification for the SE's BBU chipset chip, I don't think it matters but nevertheless I have fixed this in the latest board design (which has not been fabbed yet).

The RAM controller was rewritten for version 0.6c after I discovered a small timing violation. This one was a bit worse than the IOBS-IOBM issue, -6.5 nanoseconds margin. I don't think it was causing any issues but nevertheless I had to rewrite the RAM controller to fix the problem. This was ultimately successful but unfortunately I introduced some dumb mistakes to the RAM controller in 0.6c and then again when I fixed thise issues in 0.6e. Ultimately all this stuff was fixed in 0.6f and I have been able to find no further timing/control issues in the RAM controller.

The CNT module has the init sequence and RAM refresh timer. These are both pretty simple and are working well. However it also contains the slowdown/QoS system. This is likely responsible for some of the issues we are seeing so I anticipate further changes to the CNT module and maybe these even have to propagate into the other modules a bit. We will see.

I will be posting version 0.6g for testing in the next 10ish minutes. (Takes forever to compile on my ARM MacBook under emulated Windows 7.) It has the following principal changes:

• "Fixed wait state" sound slowdown has been removed. Audio quality will likely still be the same as on the stock SE but we will need to check to make sure.
• In all previous versions, data from the FSB would be output to the PDS bus while the PDS was idle. This was just for my convenience when debugging. Shouldn't be anything wrong doing that but I eliminated the feature in case it was causing any problems. I can add it back in just for me if necessary.
• Revised IOBM R/W signal timing has been implemented (as mentioned above), although the change will not do anything until the next board revision because a schematic change to the board is also required.
• During slowdown, all operations are put out onto the PDS bus. This is good but 3 MB of motherboard RAM can be mapped to address $600000-$8FFFFF in the accelerator address space for use as a RAM disk. This is disabled now but I can enable it later. So during slowdown, the motherboard RAM was getting written to, which would corrupt a RAM disk stored there. Now these writes during slowdown are turned into reads on the PDS bus so that they don't mess up a RAM disk or anything else stored on the motherboard. However like the previous change to the IOBM R/W signal, we need a new hardware revision to actually fix it. So RAM disk using the motherboard RAM is unfortunately not possible on the current hardware version without some kind of trick.
• There have been some small changes to the RAM /OE and the ROM /OE and /WE signals. Nothing major.

However!! I have not yet been able to get over to the lab to actually test version 0.6g.

@JDW Can you try 0.6g but first record the Tetris music on 0.6f? (I understand this is the version is currently on your WarpSE.) Then we can compare the effects of removing "fixed wait state" on sound as well as mouse performance once and for all. We have some previous recordings you very kindly made which could hold the answer, but so many things have been fixed/redone that I would like to evaluate again to be sure.

 

[Zane Kaminski]

@JDW Here is firmware 0.6g! Let me know how it is after you record the sound on 0.6f. Hopefully there will be no sound regressions.

 

[Zane Kaminski]

Arghh!! More false positives from Windows Defender antivirus on 0.6g. I have just submitted the latest 0.6g updater .exe file to Microsoft as a false positive. Let me know if you have any issues running the program.

Ooh one more thing on the subject of viruses. Looking at the Disinfectant about screen in the link James posted, I noticed the name of my calculus professor from my freshman year of college in 2013... Dr. Zbgniew Fiedorowicz. He was obviously a computer geek haha, always super proud to hook up his Android device to the projector wirelessly lol. Funny to see his name in Disinfectant

 

[JDW]

Lunch break over.

I tested 0.6f once again (because I did not see Zane's prior two posts about "g" firmware). For some reason, I'm getting two bongs:

On top of that, when I have my FloppyEMU attached, with the power off, if I press and hold INTERRUPT, when I power on, it bongs and won't switch to normal SE 8MHz mode. But when I disconnect my FloppyEMU and try it again, pressing INTERRUPT works normally.

All that testing was done on my SE Reloaded motherboard.

I need to spend time tonight testing my stock Apple motherboard. Only after that will I flash "g" firmware and test that.

 

[Zane Kaminski]

@JDW very interesting and strange behavior! I think there is only one answer. Something is triggering the initialization sequence to occur twice, once at power-on and once later. Below is the code for the initialization sequence:

First there's nPOR (negative power-on reset). This signal is supposed to be 0 when a glitch in the 8 MHz clock has been detected recently. nPOR can update at every 25 MHz clock rising edge. It keeps its current value unless one of three things happens, all based on the historical state of the 7.8336 MHz clock as sampled on the previous 25 MHz clock edges. If the 7.8336 MHz "C8M" clock has been consistently high or low for the past four 25 MHz clocks, that means something is wrong with the C8M clock. The pulse width of the C8M clock should be 64ish nanoseconds high and then the same amount of time low. So the 25 MHz clock, with period 40 nanoseconds, should never see the C8M high or low more than twice in a row, maybe three times if overclocked to 33 MHz. So if C8M has been high or low four times in a row, that means that the 7.8336 MHz clock frequency is very wrong compared to the 25 MHz clock and the nPOR bit is reset to 0, meaning that more waiting is required before the WarpSE can be operational. nPOR is set to 1 whenever a rising edge of the C8M clock is detected, but that doesn't mean that the WarpSE is ready yet. A "1" merely means that an illegal C8M frequency has not been detected.

Next there's IS, the init state. This is a 2-bit counter that counts 0, 1, 2, 3 once the C8M clock has stabilized in frequency as indicated by nPOR. Whenever nPOR is 0, IS is forced to 0. Otherwise if nPOR is 1, indicating that there has not been a C8M glitch in a while, IS is allowed to advance from 0 to 1 and then 1 to 2 when LTimerTick is true (which occurs every 57ish milliseconds). IS advances from 2 to 3 similarly but only if the NMI interrupt button is not pressed. Otherwise IS2 is repeated until the button is released. IS stays in state 3 as long as nPOR is 1, indicating there has been no C8M glitch.

The startup sequence outputs are mainly a function of the IS startup state. In IS0 and IS1, the PDS address and control bus outputs are disabled, reset is held low, and the WarpSE requests the PDS bus. The IS sequence and nPOR are not controlled relative to LTimerTick. So if LTimerTick and nPOR line up correctly, WarpSE could be in IS0 for just one clock period, which doesn't give adequate time for stuff to stabilize if the C8M clock has only just righted itself. So IS1 occurs for another 57 milliseconds, giving extra delay time for everything to stabilize in case IS0 was left too quickly. IS2 is similar to IS0/IS1 except that the bus request output is disabled if the interrupt button is pressed. In IS3, the address and control bus outputs are enabled onto the PDS bus if the bus request was not disabled by a press of NMI in IS2.

This is the startup sequence logic. Why all this, especially the C8M check? Well, future revisions will take their +5V power from either the USB connector or the Mac. Currently, If the USB is plugged in and the Mac is off, the WarpSE is unpowered. However with the WarpSE also able to be powered via USB in future versions, we cannot let the WarpSE drive the PDS bus while the Mac is off. Hence we detect a power failure on the Mac side as a wonky C8M 7.8336 MHz clock and go back to IS0 where the PDS outputs are disabled.


So based on @JDW's description of the issue... two bongs and the WarpSE doesn't stay disabled even if the NMI button was pressed at startup, I am fairly confident that the C8M-based power fail detection is getting triggered. This makes the WarpSE reenter IS0, which results in reset getting pulsed low for a while, the WarpSE being enabled by default, and the Mac restarting. But why? Either that or the 5V or 3.3V power is somehow drooping low enough to reset the CPLD. That seems unlikely though because the +3.3V has its own regulation and the CPLD won't reset until you drag the voltage below 2.5ish volts. The screen stays working this whole time and the RAM retains its contents, which would not happen if the +5V fell below 4ish volts. So something happening as a consequence of connecting the Floppy Emu is likely messing up the C8M clock signal. Can you try reseating the BBU, WarpSE, and SWIM/IWM? Maybe there's a bad connection somewhere. Otherwise it's really a mystery. Maybe you have a bad WarpSE board? I will get those new prototypes done soon (still of the same hardware revision) and send you another.



Edit: Thinking about it more, if reseating the SWIM/IWM doesn't fix it then what about just removing the chip? The Mac will at least POST without it, right?

Looking at the SE schematic, three different chips connect to the floppy ports. Mainly it's the IWM/SWIM but the BBU produces the PWM motor control signal and the GLU PAL/GAL produces the internal drive enable signal as well as the floppy write data signal. We can seemingly rule out the enable signals because James says the issue occurs with all three ports. The external port drive enable is driven by the IWM and the internal ones are driven by the GLU PAL.

Interestingly, the GLU PAL also produces the 16 MHz clock signal, from which the 8 MHz clock is produced in the BBU as a simple divide by two. Maybe there's an issue with this?

Also, when the Floppy Emu is set in Apple II mode, the PWM signal is used to report the write protect switch status of the disk. So if the Floppy Emu is in Apple II mode, it can have a "bus fight" on the PWM signal. But surely that is not the cause since the Floppy Emu clearly said it was in 3.5" Macintosh disk mode in your video.

 

[Zane Kaminski]

Another update! Unfortunately due to a stupid oversight 0.6g was totally broken. Issue fixed and now we have 0.6h which is attached.

@JDW I just tried 0.6f and 0.6h with my Floppy Emu and could not reproduce the issue you're having with the double bong. Hmm...

 

[phipli]

I strongly advise use of Norton Disk Doctor 3.5.3 and Disinfectant 3.7.1 to make 100% sure there are no oddball things going on with your drive structure or files.

Take care running Norton Disk Doctor. It is very sensitive to what OS version you are running and can corrupt a disk as often as fix it. It is usually best to only run it in emergencies. Most of the "errors" it finds are hugely overstated. All the creation dates and bundle bits don't cause any issues for your machine running.

But that said, here is a handy dandy bootable compilation CD image of versions of Norton I made once

https://elephantandchicken.co.uk/downloads/norton/Norton%20Collection.zip

 

[JDW]

Here's my report for this evening...

====================
0.6f flashed to WarpSE
====================
1. Tested my stock Apple SE board in the stock condition, with no drives or WarpSE attached. No Mouse or Keyboard attached either Single bong. All is well. I know it would be, but I needed to establish a proper working baseline.

2. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Attached FloppyEMU, mouse & keyboard. Powered ON to hear a single bong. I booted off of MacTest SE and attached a Mac serial cable between the Modem and Printer ports (what you're supposed to do with MacTest SE, mind you). I then disabled the floppy drive test and then proceeded with the test. It initially complains about the lack of a SCSI loopback board, but because I don't have one (sure wish I did!) that cannot be helped. It passed all tests, including SERIAL PORT test, and then it stopped when it got to the SCSI test. So basically, this proves all is well with the serial ports.

3. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Attached WarpSE (0.6f firmware) with Mouse & Keyboard. Powered ON to hear a single bong, which surprised me. I repeated the MacTest SE tests and got the same good result.

4. Powered OFF. Disconnected Main Wiring Harness. Disconnected my FloppyEMU. Connected my BlueSCSIv1 with Mouse & Keyboard. Powered ON to hear a single bong. Disconnected the serial cable and connected my homemade loopback connectors. Ran the Snooper 2.0 Modem and Printer port tests. Both passed. I then ran Tetris and recorded the audio. Sounds just like stock audio to me.

5. Powered OFF and disconnected everything. Then connected my SE Reloaded board, with no drives or WarpSE or Mouse or Keyboard attached. Single bong. All is well. It should be, but just like in Step-1, I needed to establish a good working baseline.

6. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Attached FloppyEMU, Mouse & Keyboard. Powered ON to hear a single bong. Booted off of MacTest SE and attached a Mac serial cable between the Modem and Printer ports (what you're supposed to do with MacTest SE, mind you). I then disabled the floppy drive test and then proceeded with the test. FAILED/FROZE! Not sure if I've done this test before with my SE Reloaded board. After I built it, I did only the Snooper 2.0 serial port tests with the loopback connectors, which passed. Hmmm... Maybe @Kai Robinson has some thoughts. Unrelated to WarpSE, but concerning nonetheless.

7. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Disconnected FloppyEMU. Connected BlueSCSIv1 with Mouse & Keyboard. Disconnected the serial cable and connected my serial loopback plugs. Booted from BlueSCSI into System 7.1 and ran Snooper 2.0 Modem and Printer port tests. As always, they both PASSED. Hmmm...

8. Repeated Step-7 with FloppyEMU connected (but no disk mounted). Snooper 2 serial port tests passed again. And just to let you know, it does a Handshake test, followed by 300, 1200, 2400 and 9600 baud tests. So all that passed on both serial ports.

9. Powered OFF. Disconnected everything. Waited 30 seconds. Attached cables and WarpSE (0.6f firmware). No drives attached, but I attached Mouse & Keyboard. Power ON and got a single bong. All well so far.

10. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Attached my FloppyEMU (set to floppy disk mode, not HD20 Mode). Attached Mouse & Keyboard. Powered on and got a single bong. Interesting. This is good but different from the double-bong I got during my lunch break. Maybe disconnecting everything for 30 seconds really is important???

11. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Attached my BlueSCSI, Mouse & Keyboard. Powered on and got a single bong. Wow. Seems to be OK now. Booted to the Desktop just fine.

12. Powered OFF. Disconnected Main Wiring Harness. Waited 30 seconds. Left my BlueSCSI and FloppyEMU attached with Mouse & Keyboard. I then pressed and held the INTERRUPT switch and powered on. Got no bong and the CRT artifacts, as expected. Released INTERRUPT and then got the bong. It booted from BlueSCSI and I confirmed it is in stock 8MHz mode.

CONCLUSION:
All these tests seem to show my lunch break problem must have been the result of testing too quickly, with a residual charge still left in the motherboard. The only thing I can say is that I was switching between external and internal floppy drive connectors when I attached my FloppyEMU during my lunch break, so maybe that in combination with quick testing triggered the double-bong. I think I may have had my FloppyEMU in HD20 mode when I attached it to one of the internal drive connectors, and I know it won't work in that case, so I then reset my FloppyEMU to floppy disk mode and continued testing. Not sure if that triggered the double-bong problem, but it seems fixed now. (Note that I am doing all the board touching and removals with my ESD strap in place, so ESD cannot be the cause.)


====================
0.6h flashed to WarpSE (while on my stock SE motherboard)
====================
1. At first Power-ON I got the normal, single bong, and it booted from my BlueSCSIv1 just fine. I then ran Tetris and recorded the audio. Sounds like stock audio to me! Note that I am using my stock SE motherboard (not SE Reloaded).

2. I powered OFF and waited 30 seconds with everything still connected. I then pressed and held the INTERRUPT button and powered ON. No bong and the standard artifacts. I released the button and got the bong. It booted just fine in stock 8MHz mode.

3. Powered OFF and waited 5 minutes to type this post as I go along. I returned and disconnected everything. I then put WarpSE (0.6h firmware) on my SE Reloaded board, attached only my FloppyEMU, Keyboard and Mouse (with the main wiring harness, of course), then powered on. I got a single bong and then I started to press buttons on my FloppyEMU so I could choose the MacPaint disk and I got a second Bong! Blasted!

4. Powered OFF. Waited 30 seconds. Pressed-and-held the INTERRUPT switch. Powered ON and heard the bong. But it shouldn't bong in this case because I am pressing INTERRUPT. So this is the same as what I saw at lunch with 0.6f.

5. Powered OFF. Waited 30 seconds. Disconnected my FloppyEMU. Pressed-and-held INTERRUPT. Powered ON. Got the bong! But I shouldn't have gotten the bong. I released the switch, and it bonged a second time.

6. Powered OFF. Waited 30 seconds. Disconnected WarpSE. Powered ON. Got the standard bong, as expected. But 7 or so seconds later, I got the silly second bong! Again, without WarpSE attached! What the heck?


I'm so tired at this point, I almost can't drive home. Can hardly keep my eyes open. I need to call it a night. I will do more testing on my lunch break tomorrow.

 

[Zane Kaminski]

@JDW thank you for your hard work testing! Your diligence is really impressive and it is greatly appreciated.

These are very strange symptoms! Frustrating that the double bong issue is happening on your main board too. What could be the cause of this?? Were both boards using that new power supply kit? (I forget the name.) And neither the Floppy Emu nor the WarpSE were attached the final time you got the double bongs... We will have to investigate this further.



Anyway, @JDW's sound recording from 0.6f sounds very good but I was still hearing some artifacts on my system after comparing a number of times. I didn't hear the same thing on James's recent recording. So I reimplemented clock-gated slowdown. Previously this was broken due to a timing issue, which I identified and fixed. I verified the correct behavior of clock-gated slowdown using my logic analyzer:

This timing diagram shows two back-to-back accesses to the PDS bus followed by a period of PDS bus idle, and then the beginning of another PDS bus transaction. The most important signals are at the bottom: /FDTACK is the fast CPU /DTACK, FCLK is the fast CPU clock, C8M is the 7.8336 MHz CPU clock, and /AS is the PDS address strobe.

You can see for the first two accesses that the fast CPU clock runs continuously and the accesses are back-to-back. But then after the second access, the 68k "thinks" for a while, during which time the fast bus is idle. With a 25 MHz CPU, this "thinking" would get done much faster than at 7.8336 MHz. This was responsible for the slightly faster performance during slowdown than stock. So therefore in this diagram, we have clock-gated slowdown. You can see in the timing diagram that during the bus idle period that the fast CPU clock only pulses once for each time the C8M clock pulses. Once the 68k accesses the bus again, the 25 MHz clock continues running to make sure the bus operation completes quickly. This clock gating should get us very close to the stock performance of the Mac during slowdown.

Once clock-gated slowdown was applied, the remaining audio issues were resolved!

 

[JDW]

I did NOT use the new Baby Face PSU in any of my testing. I have been exclusively using the stock SONY PSU that Kai kindly sent to me, along with the entire SE machine, prior to my SE Reloaded build. I merely cranked up the voltage a bit (but not to max) using the blue POT inside that SONY PSU. I then added 16AWG wires to the Main Wiring Harness to ensure less voltage drop. And as I showed with my Mac-O-Meter attached to the external floppy drive connector. That yields a solid 5.09v and +12.6v.

Until yesterday, I did most of my testing with my SE Reloaded board, because I never had problems with it before WarpSE testing (even with the Levco SpeedCard attached), and because all the connectors and PDS are brand new, and because the SE speaker plays audio every time I connect my extension cable. (Extension cable allows me to keep the motherboard outside the metal chassis.)

My stock SE board works well, but for reasons I don’t understand, it doesn’t play audio through the SE speaker much of the time, although its headphone jack audio is flawless.

And so, the two recordings I made last night, given in my previous post, were made with my $800 SONY D100 audio recorder attached to the headphone jack of the stock SE motherboard.

I was booted into System 6.0.8 to avoid playback glitches in Tetris audio that sometimes occur when booted into System 7.1. Volume in the control panel was set to 2. My recorder was set to 48kHz 24-bit, with recording level set low enough to avoid any clipping at all. Cable used is new, and I had a Stereo-to-mono adapter at the SE end because SE audio is mono. That recorded mono audio into a stereo track. On my modern Mac, I used the TwistedWave audio editor to convert that stereo track pair into a mono track and then saved the WAV file. I did not adjust amplitude at all.

That is the method I used on all prior recordings, prior to my recordings yesterday.

But like I said. All my recordings prior to yesterday were done using the SE Reloaded motherboard.

Recordings last night were done using the stock SE motherboard.

Later today on my lunch break, the very first test I intend to do will be to test my SE reloaded motherboard without the WarpSE or any drives attached to see if that crazy double bong still happens.

But what I can say for now is that I never got any kind of double bong prior to using 0.6f firmware. After using that firmware, then my SE Reloaded motherboard started doing this crazy double bong stuff even after removing WarpSE, and I really don’t understand that at all.

My lunch break will be about 6 hours from now.

 

[JTRetro]

Hello All,
I did a quick video of my machine booting up, and tried to explain some of the things that I have done/seen and the equipment that I've been using. I had to break it up into two parts to get it to fit here! In this video, it is starting up with the .6f firmware.

 

[JTRetro]

I also did some more quick tests with the .6f firmware, including a perspective drawing using MacPaint 2, as well as running Speedometer. Again, these tests were done with the 1.44Mb Superdrive board while booting off of a 20Mb Hard drive running O.S. 7.1. Additionally, I used the Iomega drive as the test HD drive with Speedometer.

Also of note is the fact that I ran MacPaint 2 off of the 100Mb Iomega drive; I experiences no problems with the mouse while doing this:

Questions for you @Zane Kaminski : Do you have any specific tests that you'd like to see more of done?