Overlocked Turbo040 in Macintosh IIci, 400K & 800K floppies don't work

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,577
1,373
113
53
Japan
youtube.com
I wish to thank David Cook for his excellent post over at the 68kMLA, as that served as my inspiration for overclocking the Daystar Turbo040 in my Mac IIci. Overclocking is done by a mere XTAL swap. (And the Hakko FR-301 desoldering gun makes the job easy, I must say.)

Because David was able to achieve an overclock of 50MHz, I tried the same by removing the stock 20MHz XTAL and soldering in a 25MHz version. I was then able to boot to the Desktop and verify with Clockometer that it was indeed running at 50MHz! Sadly, it froze shortly thereafter, and then froze during reboot. I pulled the T040 card, restored the stock 20MHz XTAL, and confirmed it worked perfectly again. Why couldn't I achieve 50MHz? Well, it could be the CPU on my T040 card won't overclock to 50MHz. Or it could be voltages at the CPU on the card itself (PSU & motherboard are recapped, mind you). Not sure. But if one argues it is voltages on the card, why then was David able to achieve 50MHz? So my guess it is my T040's CPU that is limiting the overclock.

I then ordered 5 XTALs (all 5V, which is a requirement!) from AliExpress so I could experiment with lesser overclocks. Note that product page says one XTAL of the 5 is 21MHz but in fact the slowest is 22MHz, so I tried that one. It works! I now get 44MHz speed! So far, I have tested for about 30 hours total, and it is rock solid stable. I ran about 230 loops of Snooper 2 (including the serial ports because I made loopback connectors). No errors except for PRAM (only 2 errors out of more than 100 tests total, each time I test in Snooper).

Sadly, I noticed one major problem last night. I cannot use 400K or 800K disks anymore. I cannot use real floppy disks or 400K / 800K images on my FloppyEMU. David confirmed the same problem saying 400K/800K disks stopped working after his overclock. 😥

David then reminded me that "400K and 800K disks are GCR encoded, whereas 1440K disks are MFM." That implies the T040 is messing with GCR. David speculates that "DayStar modifies disk timing for known configurations, but does not have a configuration for 040 @ 50MHz." But again, this is just speculation at this point.

By the way, my Turbo040 has the newest ROM. I paid Manabu Sakai of ARTMIX Japan a little money to do that update in the past. So it's not an issue triggered by an older T040 ROM.

It's also not heat-related at all. I have a thermal camera and have confirmed such. The T040 is running rather cool, actually.

I do know that the Turbo040 patches the ROM at boot. It patches it early on, such that I cannot even boot from a known good 800K floppy with the T040 overclocked. This leads me to wonder if the use of a custom ROM SIMM might be a possible fix. Naturally, I think about this because of my ROM SIMM video on that topic.

Back in 2020 when testing the Turbo040 on my SE/30 using a custom ROM SIMM flashed with Doug Brown's OlePigeon patched ROM (see "olePigeonPatchedROM-normalchecksum_disabled.bin" attachment), I discovered the opposite problem — 400K & 800K disks worked fine on my SE/30 with T040, but 1.44MB disks would not. I also reported that HD20 mode on my FloppyEMU doesn't work when I use the OlePigeon ROM.

To confirm what would happen with that OlePigeon ROM on my IIci, I used my CayMac ROM SIMM Programmer v2 (co-created with Downtown Doug Brown) to flash "olePigeonPatchedROM-normalchecksum_disabled.bin" to a 512K SIMM by GGLABS. I then tested in my IIci (after removing the little ROM SELECT jumper, of course). The "Arrrrrrr" boot chime scared me to death! I don't remember hearing that when I tested in my SE/30, or maybe i just forgot. That sound made me thing something had fried when I hit the power button! 😅 But the IIci booted right away. Interestingly, 1.44MB floppies work just fine with that ROM! So I guess it's only when used on the SE/30 that 1.44MB floppies stop working with the OlePigeon ROM. Anyway, sadly, 400K and 800K disks still don't work. 😭

There's one more incompatibility I should mention. I didn't test this prior to my overclock, so what I am saying now applies to my overclocked 44MHz Turbo040. With the T040 installed in my IIci, regardless of whether I use a custom ROM SIMM with the OlePiegon ROM flashed or the stock motherboard ROM, I cannot boot from my FloppyEMU while in HD20 mode. (I have a 381MB HD20 disk image on it.) But when the T040 is removed from my IIci, regardless of whether I use the motherboard ROM or the custom ROM SIMM, I can boot just fine from my FEMU in HD20 mode. Again, I didn't test HD20 Mode prior to overclock, so I don't know if the stock 40MHz T040 speed would have worked. I can only say that right now in the overclocked state, the IIci starts to boot from the FEMU in HD20 Mode but then it stops and the LCD shows this error:

tempImagepQHBcF.png

So I am creating this thread to ask if there might be a Custom ROM SIMM hack which could achieve these 2 things:

1. Re-enable 400K & 800K (GCR) functionality even for overclocked Turbo040 cards, when used in a Mac IIci.
2. Enable HD20 Mode on the FloppyEMU.


Thanks.
 

Attachments

  • olePigeonPatchedROM-normalchecksum_disabled.bin.zip
    296 KB · Views: 60

JeffC

Tinkerer
Sep 26, 2021
122
79
28
Seattle, WA
In both my accelerated Plus and accelerated SE my FloppyEMU will not work in HD20 mode, I get the same "READ STATE CHANGED" error. From what I have read the FloppyEMU does not work well with accelerated Macs.
 
  • Like
Reactions: JDW

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,577
1,373
113
53
Japan
youtube.com
In both my accelerated Plus and accelerated SE my FloppyEMU will not work in HD20 mode, I get the same "READ STATE CHANGED" error. From what I have read the FloppyEMU does not work well with accelerated Macs.
Thank you for the helpful feedback, Jeff!

Sadly, even if I ignore HD20 mode on the FloppyEMU, the fact remains that 400K and 800K disks no longer work on the overclocked Turbo040, which is a problem that I am not sure I want to live with. But if such could be fixed by a hacked ROM SIMM, then certainly that would be idea.