-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
My SE/30: w/ Turbo 040, ROM-inator, Ethernet and 8.1
- Thread starter pb3623
- Start date
JDW
Well-known member
@pax Thank you for your quick reply.
Your 1st link I already knew. Please note that on that page there is a USER MANUAL icon but no link to the actual user manual!
Your 2nd link is helpful for making ROM images. That's one of things I was looking for. Thank you for that link!
The biggest unanswered question I still have is about *.BIN files vs. *.ROM files. Again, my question is this...
Must we convert *.BIN files to *.ROM files when programming? If so, how?
Why do I even wonder about this? Please read through Your 2nd link and you will see it talks about *.ROM files. But the OldPigeon ROM (Turbo040 patched) is actually a *.BIN file, not a *.ROM file, hence my question. Thoughts?
Your 1st link I already knew. Please note that on that page there is a USER MANUAL icon but no link to the actual user manual!
Your 2nd link is helpful for making ROM images. That's one of things I was looking for. Thank you for that link!
The biggest unanswered question I still have is about *.BIN files vs. *.ROM files. Again, my question is this...
Must we convert *.BIN files to *.ROM files when programming? If so, how?
Why do I even wonder about this? Please read through Your 2nd link and you will see it talks about *.ROM files. But the OldPigeon ROM (Turbo040 patched) is actually a *.BIN file, not a *.ROM file, hence my question. Thoughts?
pax
Well-known member
@JDW Yes, I also noticed the user manual icon but no link. I don't know that I've ever seen a pdf manual, but it is curious nonetheless.
In any case, I don't think the file suffixes matter. The ROM image is a blob of binary data and some people append ".bin" to indicate that it is binary data, while some people append ".rom" to indicate that the binary data is a ROM image. You'll notice that the @olePigeon patched ROM image is the exact same number of bytes as the default BMOW base ROM image (524,288 bytes). If you examine both files in a hex editor you'll also see that large portions of them are identical.
In any case, I don't think the file suffixes matter. The ROM image is a blob of binary data and some people append ".bin" to indicate that it is binary data, while some people append ".rom" to indicate that the binary data is a ROM image. You'll notice that the @olePigeon patched ROM image is the exact same number of bytes as the default BMOW base ROM image (524,288 bytes). If you examine both files in a hex editor you'll also see that large portions of them are identical.
JDW
Well-known member
@pax
Thank you again for your quick reply.
Can I take your advice to mean that I can rename the extension of "olePigeonPatchedROM-normalchecksum_disabled.bin" to any of the following and program any of the following without error?
Thank you again for your quick reply.
Can I take your advice to mean that I can rename the extension of "olePigeonPatchedROM-normalchecksum_disabled.bin" to any of the following and program any of the following without error?
- olePigeonPatchedROM-normalchecksum_disabled.rom
- olePigeonPatchedROM-normalchecksum_disabled.txt
- olePigeonPatchedROM-normalchecksum_disabled.sillyme
pax
Well-known member
@JDW Yes, indeed. Just to clarify, I don't personally have any experience with the patched ROM image, but I quickly tried opening it—alongside the base BMOW ROM image—in the ODA web-based disassembler set up for m68k and they both sure look like valid ROM images to me. Again, they appear identical in places so I would feel comfortable just renaming the patched ROM and trying it. But that's me. No guarantees.
By the way, and apologies for going off topic, I watched a whole bunch of your YouTube videos yesterday. I wish I could be as helpful as they are. Wonderful work!
By the way, and apologies for going off topic, I watched a whole bunch of your YouTube videos yesterday. I wish I could be as helpful as they are. Wonderful work!
JDW
Well-known member
Good news. I've just programmed the patched ROM to my ROM-inator II MEGA and I can now boot my SE/30 with my 40MHz Turbo040 (ROM v.4.11)! Yipee! Thank you for the patched ROM, @dougg3!
The patched ROM boots from my internal HDD with System 7.1 just fine, even without the Turbo040 installed.
Now for the BAD NEWS...
My FloppyEMU from @bigmessowires will no longer boot in HD20 Mode (System 6.0.8), even if I disconnect, boot from my internal HDD, disable 32-bit addressing and restart. I get a skull and crossbones, and then it will eventually boot from my HDD. If I shutdown, disconnect power to my HDD, then restart with the FloppyEMU connected (HD20 mode), I get the skull and crossbones repeatedly. :-(
If I shutdown and remove the Turbo040 and leave the FloppyEMU connected and power-on, System 6.0.8 boots perfectly.
Thoughts?
The patched ROM boots from my internal HDD with System 7.1 just fine, even without the Turbo040 installed.
Now for the BAD NEWS...
My FloppyEMU from @bigmessowires will no longer boot in HD20 Mode (System 6.0.8), even if I disconnect, boot from my internal HDD, disable 32-bit addressing and restart. I get a skull and crossbones, and then it will eventually boot from my HDD. If I shutdown, disconnect power to my HDD, then restart with the FloppyEMU connected (HD20 mode), I get the skull and crossbones repeatedly. :-(
If I shutdown and remove the Turbo040 and leave the FloppyEMU connected and power-on, System 6.0.8 boots perfectly.
Thoughts?
Last edited by a moderator:
JDW
Well-known member
I've been running more tests. All my floppy images on the FloppyEMU boot my SE/30 perfectly with the patched ROM-inator II MEGA and the Turbo040 installed. It's only the HD20 mode that does not work with the Turbo040 installed. This seems to give evidence that whatever patching the Turbo040 is doing to the ROM is somehow eliminating the HD20 compatibility. Not sure if there is a workaround for this, but I would love to hear your thoughts.
Until now, I've been using my FloppyEMU to boot all my Macs from my 512K to my SE/30s (with different OS's, of course). It's been a great substitute for a SCSI2SD. Slow, but it works well. I suppose I need to buy a SCSI2SD one day, but I am quite curious if there is a fix for this current incompatibility. Thank you!
Until now, I've been using my FloppyEMU to boot all my Macs from my 512K to my SE/30s (with different OS's, of course). It's been a great substitute for a SCSI2SD. Slow, but it works well. I suppose I need to buy a SCSI2SD one day, but I am quite curious if there is a fix for this current incompatibility. Thank you!
pax
Well-known member
I'm glad it worked @JDW! I think you're right that the ROM patches Turbo040 applies at boot is the culprit. ROM disk support like in the base BMOW ROM image also don't work with Turbo040. 
Have you seen that forum member @ZaneKaminski is creating a new ROM SIMM with many of the same features as ROM-inator? Maybe Zane's new ROM code can fix HD20 support with Turbo040 sometime in the future.
Have you seen that forum member @ZaneKaminski is creating a new ROM SIMM with many of the same features as ROM-inator? Maybe Zane's new ROM code can fix HD20 support with Turbo040 sometime in the future.
JDW
Well-known member
@pax
I actually don't mind the lack of ROM disk support too much in the Turbo040-patched ROM because I could just buy the ROM-inator II ATOM which doesn't have enough memory for a useful ROM disk anyway and use that with my Turbo040 SE/30. The big problem I have at the moment is the lack of HD20 Mode support. I know from my testing that HD20 Mode is supported in the patched ROM without the Turbo040 installed, but the Turbo040 does something to unpatch the HD20 init in ROM, thereby preventing the FloppyEMU from booting an HD20 Mode disk. It would be great if there was a workaround for that problem.
Thank you for the link to that other thread. I posted there a couple hours ago. As I wrote there, I want to know what initiated that effort since BMOW already has a ROM built and on sale (albeit without a programmer now). Steve, Doug and many others all contributed to making that a real product, so I am quite curious what is to gain by reinventing that wheel. I don't seek to discourage the effort at all by asking this question. It's just a question. And hey, if that new ROM can work with my Turbo040 AND give my FloppyEMU HD20 Mode support too, that's GOLD! But for now, I am curious what can be done with my existing ROM-inator II MEGA ROM, since that is what I own right now.
Thanks, guys!
I actually don't mind the lack of ROM disk support too much in the Turbo040-patched ROM because I could just buy the ROM-inator II ATOM which doesn't have enough memory for a useful ROM disk anyway and use that with my Turbo040 SE/30. The big problem I have at the moment is the lack of HD20 Mode support. I know from my testing that HD20 Mode is supported in the patched ROM without the Turbo040 installed, but the Turbo040 does something to unpatch the HD20 init in ROM, thereby preventing the FloppyEMU from booting an HD20 Mode disk. It would be great if there was a workaround for that problem.
Thank you for the link to that other thread. I posted there a couple hours ago. As I wrote there, I want to know what initiated that effort since BMOW already has a ROM built and on sale (albeit without a programmer now). Steve, Doug and many others all contributed to making that a real product, so I am quite curious what is to gain by reinventing that wheel. I don't seek to discourage the effort at all by asking this question. It's just a question. And hey, if that new ROM can work with my Turbo040 AND give my FloppyEMU HD20 Mode support too, that's GOLD! But for now, I am curious what can be done with my existing ROM-inator II MEGA ROM, since that is what I own right now.
Thanks, guys!
Fizzbinn
Well-known member
I’ve newly acquired a Turbo 040, can someone tell me what the 4.11 ROM provides over the 4.01 ROM? Are there known issues or benefits to running the different versions?
Last edited by a moderator:
joethezombie
Well-known member
There’s a DayStar support document around I can’t seem to find right now, but I believe 4.11 brings System 7.5 support and fixes something with Virtual Memory.
