Made ROM SIMMs, wrote ROMdisk driver, need help debugging

[ZaneKaminski]

Hi everyone,

My friend and I recently made a batch of 2MB ROM SIMMs for the SE/30 and Mac II machines. We wanted a few of these ourselves as well as to sell through our little company (price will be $25 incl. domestic US shipping):



We have also finished a design for an 8MB ROM SIMM (actually it holds two separate 8MB images) using cheap 3.3V flash (price will be $35):



Before we can sell the 2MB SIMMs or try the 8MB SIMMs (or feel pleased about the project haha), I must implement our ROM disk driver, similar to what bbraun and BMoW have done. I've studied examples from IM: Devices as well as bbraun's source and have written a driver which I feel has a good structure. The driver compiles using the Retro68 toolchain and is automatically patched into a base ROM and concatenated with a disk image.

Everything seems to be in order, but my IIsi is getting stuck during boot and I am at a loss for how to debug the problem. The boot never completes but the mouse and VBL keep going. I fixed up bbraun's driver to compile with the new toolchain, and it is failing in the exact same way. I suspect a calling convention mismatch or other issue with the build and ROM patch process but I can't pin it down.

I have four logic analyzers but three are put away and the one I have been using needs its software reinstalled (big hassle) and a better SCSI upper byte terminator than my handmade one. So in terms of test equipment, I am stuck with just four-channel scopes and a 2+16ch MSO. I would rather not use that stuff anyway. I would like to print some stuff out over the serial port and see if my code is even getting called and how far it gets, but I am not sure how the boot process goes. I don't know if I can use the serial driver when the disk driver's open call and the first prime calls are made. Or is there macsbug in ROM?

We would be happy to reward those providing particularly helpful advice with some of our hardware, including the ROM SIMM and also our Apple IIe and IIgs memory expansion cards. Once we finish this project, we will be able to finish the ROMBUS for Mac Plus and 512K, which I consider to be much more interesting.

The driver is here: https://github.com/garrettsworkshop/MacIIROMDiskDriver (the ROM with our driver is in bin/rom.bin and bbraun's driver which I have recompiled is in bin/rom_braun.bin)

and the KiCAD files for the SIMM are here: https://github.com/garrettsworkshop/MacIIROMSIMM

Right now the RAM disk function and "R" key check are commented out, so the Mac should always boot from ROM.

Any help would be greatly appreciated!

 

[Dog Cow]

I would like to print some stuff out over the serial port and see if my code is even getting called and how far it gets, but I am not sure how the boot process goes. I don't know if I can use the serial driver when the disk driver's open call and the first prime calls are made. Or is there macsbug in ROM?

You can also use QuickDraw during boot. You may not be able to draw text, but you can draw lines or whatever to mark progress thru your code. You don't have MacsBug in ROM, but there's MicroBug. It has a stub for a serial port debugger. MicroBug uses some of the Managers, so it may not be accessible until later in the boot process.

By the way, it is possible to reboot your Mac with MacsBug loaded in RAM. I did it on a Mac 512K, but you could probably do it on newer Macs too. This allows you to step/trace thru almost the entire boot process.

 

[maceffects]

@ZaneKaminski I'd love to purchase at least a couple of the 8mb ROMs when you have them finished. 

 

[Crutch]

You can also use QuickDraw during boot. You may not be able to draw text, but you can draw lines or whatever to mark progress thru your code. You don't have MacsBug in ROM, but there's MicroBug. It has a stub for a serial port debugger.

Why wouldn’t he be able to draw text? Isn’t (at least) Chicago-12 in ROM on a IIsi? MicroBug uses it so it must be ...

 

[tommijazz91]

@ZaneKaminski sign me up for the 8mb as well!

Maybe I’m asking too soon, but will it be possible to order it with a pre-installed version of system 7?

 

[Renegade]

Zane, your comeback is great news.

Count me in as well for the 8MB variant.

Do you plan on selling a ROM SIMM programmer as well ?

 

[Dog Cow]

Why wouldn’t he be able to draw text? Isn’t (at least) Chicago-12 in ROM on a IIsi? MicroBug uses it so it must be ...

I don't know. I wasn't confident enough to say yes, because the text routines are on the "banned list" of routines that may move or purge memory. Yes, Chicago is in ROM since the Mac Plus.

 

[ZaneKaminski]

You don't have MacsBug in ROM, but there's MicroBug.

Thanks for the advice. The machine crashed when I did an A9FF trap, so I guess microbug was not initialized, but the experiment was informative enough in that it told me that the Mac was getting to the end of Prime(...). The issue turned out to be that I had forgotten to call the I/O completion routine when returning, thus the read was never completed. Bbraun compiled his driver in CodeWarrior or something, which evidently provides an entry point stub that takes care of this callback. Thus his driver was similarly affected when I compiled it. The fix was easy enough. I just used the entry point code from IM: Devices page 1-29. Now the machine briefly shows a happy Mac before going back to the “disk?” screen. I’m sure I’ll be able to resolve this soon. 
 

@ZaneKaminski will it be possible to order it with a pre-installed version of system 7?

Yeah, I think we will ship both the 2MB and 8MB SIMMs with System 7 plus as many useful tools/utilities as we can fit.

Do you plan on selling a ROM SIMM programmer as well ?

We would but we can’t find enough 64-pin SIMM socket connectors to justify developing a board design for a programmer. If someone can point me to >100 connectors for sale (TE part number 822033-2), I would almost certainly develop a programmer. 

 

[trag]

We would but we can’t find enough 64-pin SIMM socket connectors to justify developing a board design for a programmer. If someone can point me to >100 connectors for sale (TE part number 822033-2), I would almost certainly develop a programmer. 

https://www.connectorpeople.com/Connector/TYCO-AMP-TE_CONNECTIVITY/8/822019-2

 

[ZaneKaminski]

I fixed the driver and now it's working well in ROM disk mode. There's still a bit of work to do on the RAM disk function. I basically copied the idea of allocating the RAM disk in accRun from bbraun, but I think that approach is causing problems. I believe my IIsi tries to write to disk before accRun ever happens, and since the RAM disk is not yet allocated, that write cannot be completed. I have a good idea for a different approach which I will implement soon.

https://www.connectorpeople.com/Connector/TYCO-AMP-TE_CONNECTIVITY/8/822019-2

Great, only a buck each. We can do a programmer for $25-35, I think.

 

[cheesestraws]

Great, only a buck each. We can do a programmer for $25-35, I think.

That would be very cool.  The main thing that puts me off the existing offerings is the faff involved in programming them and/or the inaccessibility of programmers for them...

 

[ZaneKaminski]

I think we will ship both the 2MB and 8MB SIMMs with System 7 plus as many useful tools/utilities as we can fit.

Actually, there isn't so much room in the 2MB SIMM for System 7. It can be done, but would 6.0.8 be better on the 2MB and 7.0/7.1 on the 8MB?

Here's a picture of the control panel we are developing so far:



To accommodate these settings, I'm diverging from the driver lifecycle implemented in the bbraun/BMoW drivers. Their drivers remove the ROM disk drive entry from the system drive queue when not booting from it. I took that approach for granted as the accepted solution but it doesn't really match how other devices work; a floppy drive is not removed from the drive queue when the disk is ejected.

Instead, my driver will present the ROM disk as either inserted or ejected at boot, depending on the boot setting. Mounting the ROM disk when booting from a different volume happens in the driver's accRun routine, in which the disk status is changed to "inserted" and a disk insertion event is posted.

 

[cheesestraws]

would 6.0.8 be better on the 2MB and 7.0/7.1 on the 8MB?

probably, yes.  It's 6.0.8 in the Classic's built-in ROM disc, though I can't remember off the top of my head how big that is.

 

[pax]

+1

I agree, 6.0.8 makes sense. That's arguably preferable from a product perspective too; it further differentiates 2MB from 8MB and makes it more compelling to buy one of each.

By the way, are you keeping the ability to disable memory test in your ROM image? I think that's one of the most compelling features for enthusiasts who max out their RAM, arguably the same people who like custom ROM chips the most. Also, have you looked into making the ROM image compatible with Turbo040? The default ROM-inator image is great to get a 32-bit clean ROM, with a ROM disk and disables memory test. But it does not work with Turbo040. Turbo040 has its own (hidden) feature for disabling memory test and you can use a IIfx ROM to get 32-bits, but you lose the ROM disk. So an image with all of these features would is the holy grail.

See this thread: https://68kmla.org/forums/index.php?app=forums&module=forums&controller=topic&id=54723

 

[ZaneKaminski]

By the way, are you keeping the ability to disable memory test in your ROM image?

Yeah, I consider disabling the RAM test to be a must-have feature. We are also considering doing a software option to enable/disable the RAM test.

compatible with Turbo040?

It can maybe be done, but there seem to be several issues. Turbo040 puts its 128 kB ROM right after the 512 kB stock ROM. This space is currently used to store the disk image in my driver. At the very least, we would need to move the disk image or change how it's being addressed to dodge the memory area that the Turbo040 is using. However, it could be that the Turbo040 selects its own ROM for any access in the ROM space above the 512 kB ROM. If the Turbo040 is uncooperative like that, I don't think it would be possible to have a ROM disk without bank-switching circuitry in the ROM SIMM. So hopefully that's not the case. It's also not quite clear how the Turbo040 patches the ROM. Someone suggested that it patches a JMP/JSR to its own code into the ROM, but I would like to know some more details of how it's done. I can investigate this eventually but I think we will have to pass on implementing it in the first version. The 8MB SIMM can store two 8MB images though, so you can at least toggle the DIP switch to switch between the stock ROM and one with the ROM disk.

 

[ZaneKaminski]

Alright, I think I've got the driver working perfectly now. Only thing left to decide on is, what ROM checksum should I use?

Once I put the checksum in, we will be ready to send some 2MB SIMMs out to test before we do the commercial release. Who would like to test? We wanna give several units away to anyone who thinks they can do a thorough job testing. Please let me know if you're interested.

8MB SIMM will be coming soon. I've just gotta finalize the design files and send 'em to fabrication.

 

[Renegade]

Once I put the checksum in, we will be ready to send some 2MB SIMMs out to test before we do the commercial release. Who would like to test? We wanna give several units away to anyone who thinks they can do a thorough job testing. Please let me know if you're interested.

I would be willing to test with one of my SE/30s, but I live in western Europe.
I guess you would rather send to US residents . I'm ok to pay for postage fees though.

 

[IlikeTech]

I could probably do testing if you need someone!

 

[Trash80toHP_Mini]

Are you ordering full thickness PCBs? I'd assume so, but thought it better to ask than not.