Jump to content
ZaneKaminski

Made ROM SIMMs, wrote ROMdisk driver, need help debugging

Recommended Posts

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):

IMG_0832.thumb.jpeg.b3f392c5432c3e425da0c363fb1a83ea.jpeg

 

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):

FrontIsom.thumb.png.e1a9385f25b9c7ae0ec168f396b317f8.png

 

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!

Edited by ZaneKaminski

Share this post


Link to post
Share on other sites
9 hours ago, ZaneKaminski said:

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.

Share this post


Link to post
Share on other sites
9 hours ago, Dog Cow said:

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 ...

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites
On 6/24/2020 at 1:02 PM, Crutch said:

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.

Share this post


Link to post
Share on other sites
On 6/24/2020 at 12:04 PM, Dog Cow said:

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. 
 

23 hours ago, tommijazz91 said:

@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.

 

20 hours ago, Renegade said:

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. 

Share this post


Link to post
Share on other sites

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.

9 hours ago, trag said:

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

Edited by ZaneKaminski

Share this post


Link to post
Share on other sites
8 hours ago, ZaneKaminski said:

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...

Share this post


Link to post
Share on other sites
On 6/25/2020 at 11:36 AM, ZaneKaminski said:

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:

IMG_0907.thumb.jpeg.86ed9675260deaae8bdeceb65537c3f7.jpeg

 

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.

Edited by ZaneKaminski

Share this post


Link to post
Share on other sites
9 hours ago, ZaneKaminski said:

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.

Share this post


Link to post
Share on other sites

+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

 

Edited by pax

Share this post


Link to post
Share on other sites
21 hours ago, pax said:

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.

21 hours ago, pax said:

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.

Edited by ZaneKaminski

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
9 hours ago, ZaneKaminski said:

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.

Share this post


Link to post
Share on other sites

I'd be happy to do some testing for you! I have a restored SE/30 that I could test things out with. I'm located in Pennsylvania if you are interested.

Share this post


Link to post
Share on other sites

I don't know if you need any more testers, but I can volunteer for the 8 MB module when its design is finalized and the initial prototypes fabricated (I need an excuse to pull my SE/30 out of storage and exercise it).

 

I'm in California, near San Francisco.

 

c

Edited by CC_333

Share this post


Link to post
Share on other sites

There's one bug I'm aware of which I have yet to squash in my driver: System 6-7.1 work but System 7.5 crashes on boot. Once I fix this, I can send out some test units. In the meantime, I have just sent the 8MB SIMM off to production.

On 7/2/2020 at 3:37 AM, Trash80toHP_Mini said:

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

1.2mm thickness. Technically SIMMs are supposed to be 1.27mm (0.05 inches exactly) thick but 1.2mm works well enough. The usual thickness of 1.6mm is certainly too thick, I think.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×