Made ROM SIMMs, wrote ROMdisk driver, need help debugging

[pax]

Thanks for sharing your thinking on Turbo040 support @ZaneKaminski. I'm happy to contribute to testing and QA using my SE/30. I'm in New York.

 

[davidg5678]

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.

 

[erichelgeson]

I'd love to test too - MN, USA. Just recapped my SE/30 and would be fun to test out.

 

[Crutch]

Definitely up for testing in an SE30. In Chicago. 

 

[CC_333]

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

 

[ZaneKaminski]

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.

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.

 

[Trash80toHP_Mini]

edit for page break discontinuity:

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

I've kicked around the notion of tinning the contacts on the thinner PCBs. Might doing that on one or both sides make up that 7 mil differential? Leaving off the solder mask for the contacts might just do it?

 

[ZaneKaminski]

I've kicked around the notion of tinning the contacts on the thinner PCBs. Might doing that on one or both sides make up that 7 mil differential? Leaving off the solder mask for the contacts might just do it?

There's some tolerance so I think it'll work okay. One danger with tinning the contacts is that gold doesn't corrode and makes better electrical contact than solder and other metals. For example, it takes some force to get an accurate resistance measurement using nickel-plated multimeter probes, but almost no force is required when using gold-plated probes. So I think we're best off with just the gold pads.

 

[Trash80toHP_Mini]

I agree completely when it comes to edge card connections, but I've rarely if ever seen 30-pin SIMMs in gold. OEM Apple ROM SIMMs are not gold plated. Dunno, maybe worth thinking about a bit? Gold's electroplated correct?

 

[pax]

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.

Speaking of System 7.5 and later, what about the patch to the System file required to get ROM-inator to work with those versions? Will the same patch be required with your ROM? Or is that the bug you're working to resolve?

 

[ZaneKaminski]

I agree completely when it comes to edge card connections, but I've rarely if ever seen 30-pin SIMMs in gold. OEM Apple ROM SIMMs are not gold plated. Dunno, maybe worth thinking about a bit? Gold's electroplated correct?

Hmm yes, I guess they are very rarely gold-plated. Either way, I don't think the layer of flux would be good for connectivity. We will look into what can be done about this, but as far as we can tell, good contact is being made.

Speaking of System 7.5 and later, what about the patch to the System file required to get ROM-inator to work with those versions? Will the same patch be required with your ROM? Or is that the bug you're working to resolve?

No, this is a separate issue, and yeah, the patch will be required for System 7.5 unless someone can tell me what the specific issue, and then maybe I can patch a fix into the IIsi base ROM.

 

[Trash80toHP_Mini]

Hmm yes, I guess they are very rarely gold-plated. Either way, I don't think the layer of flux would be good for connectivity. We will look into what can be done about this, but as far as we can tell, good contact is being made.

Cool beans, just thought I should stick my nose in about it in case it might be helpful. Still curious about any difference there might be in thickness between gold plated vs  whatever the silver stuff might be?

Is the difference in thickness really a mechanical problem the contacts or might it be in the retaining seat/clip interface? Offhand I'd think it was topside if rubber bands, clips and such solve the problem? Such would be a mechanical fix topside, no? So I'm wondering about it from both sides ()top to bottom) of the problem as I'm not convinced it's the contact thickness at the root of the problem? Forgot to mention that part. :-I

 

[ZaneKaminski]

The 7.5 bug is fixed! I I have been testing the driver in my IIsi for some time with no issues. And wow--System 6 boots up from the ROM disk extremely quickly. I measured something like 7 seconds from the "bong" sound to the desktop on my IIsi. I will be installing the ROM SIMM in my SE/30 and IIci soon and doing a bit more testing before sending out some boards to testers. 8MB SIMMs are currently in production.

any difference there might be in thickness between gold plated vs  whatever the silver stuff might be?

It's often the case that ENIG gold-plated finish is thinner than leaded/lead-free HASL finish. ENIG is electroplated (as you said), but HASL basically means that the pads are tinned and the excess solder scraped off. Inferior HASL jobs often leave the pads a bit lumpy, with not all of the solder scraped off. Thus the board thickness can be somewhat greater, but it's irregular and can create coplanarity issues when reflow soldering SMD parts. Thus ENIG was traditionally preferred for fine-pitch SMD stuff, though there are other contemporary options for "flat" finishes such as OSP (organic solderability preservatives). OSP is an orange-colored flat finish that's cheaper than ENIG (since OSP doesn't use gold) but only protects the pads from corrosion for a few weeks, so the boards must be assembled soon after they are made. OSP has become the preferred finish for cheap high-ish density boards such as in PC motherboards and game consoles.

About the thickness, we checked today and all of the "1.2mm" thickness boards we have made (mostly 30-pin RAM SIMMs) measure around 1.24mm. Referring to TE AMP's recommended board drawing, they say the thickness can go down to 1.19mm, so I think we're good. But we will see how it goes, especially in the plastic clip-type SIMM sockets.

 

[Trash80toHP_Mini]

Thanks for the in depth explanation. I'm a bit curious about anything at all in general, but when it comes mechanical problems that curiosity goes into afterburner. Still curious about why clips, rubber bands etc. solve the thinness induced mechanical interface problems, but I'll be quiet now and mull that aspect over for a while.

I hope nobody reading any of this comes off thinking any criticism at all was implied. I was only trying to be helpful, definitely not critical. I'm loving this and the other development projects I've seen posted about by this amazing "little company" of two. Thanks much for all that you and your partner do, @ZaneKaminski

 

[ZaneKaminski]

I've fixed some more System 7.5 issues. After a long while debugging crashes and other issues on 7.5, I have finally figured out the root cause.

My ROM disk driver replaces the .netBOOT driver, same BMoW's and BBraun's drivers do. However, System 7.5 has special handling of the .netBOOT driver and removes it from the system driver database. Normally this is not an issue, but unlike .netBOOT, my driver actually creates a drive entry in the system drive queue. When the driver is removed, these drive entries are left dangling, with no driver to service read/write/control/status requests, causing problems. There may also be special assumptions about the drive queue entry of the .netBOOT driver, leading to "memory smasher" type bugs in system/toolbox code. My solution was to rename the driver so that 7.5 doesn't do anything special with it. The driver is working phenomenally now, and along with this change, I was able to eliminate a lot of "legacy" that I got from studying the BBraun and BMoW drivers. Those drivers remove the ROM disk virtual drive from the system drive queue, which is sort of an unnatural operation, but doing so prevents applications from making calls to the underlying .netBOOT driver which gets removed. My solution doesn't require these mechanics and has worked very reliably in my testing.

I will be sending out units to some testers in just a few days.

I hope nobody reading any of this comes off thinking any criticism at all was implied. I was only trying to be helpful, definitely not critical.

No offense taken--I think it's good for there to be a lot of discussion on the specifics of making this stuff. Forum threads (and USENET posts lol since this stuff is so old) are where I've gotten a lot of critical info.

 

[JDW]

First, I wish to thank @pax for bringing this thread to my attention. I currently am discussing here a caveat of the BMOW ROM that pertains to using a FloppyEMU in HD20 Mode alongside a Turbo040. 
 

I read through most of the posts in this thread, and one fundamental question has remained.in my mind. What is the incentive to build a ROM seeing that BMOW already has one?
 

I don’t ask this question to criticize the effort. Indeed applaud work done. But I am curious why you started to create something that already exists.

What I can say about my experience with the ROM-inator II MEGA in my SE/30 is that it is too thin so I had to add solder on all of the contacts on one side of the same for it to make proper contact in my SE/30s. But that isn’t the best solution when you swap it out a lot because the pins will eventually dent the solder and you might have to apply for solder on the contacts eventually which really isn’t desirable.

Another issue is there is currently no way to use the Turbo040 patched ROM for the ROM-inator II and have your own custom ROM disk too.

Another issue is what I just mentioned; namely, that I cannot use my FloppyEMU in HD20 Mode with the patched ROM and with my Turbo040 installed.  Please see my other thread for details about that.

So again, I look forward to hearing more about what the incentive was for creating this new ROM SIMM. 

THANK YOU.

 

[ZaneKaminski]

What is the incentive to build a ROM seeing that BMOW already has one?

Well, I think it started about a year ago, when I noticed that BMoW’s ROMinator was discontinued. I designed a similar board, which I called ROMBUS, that plugged into the Mac’s ROM sockets but was equipped with 64 MB of cheap serial flash memory as well as the parallel flash toolbox ROM. This would allow a very fast 64MB read/write internal disk for the 512 and Plus. I redid the hardware for that project several times, and now I have a design which interfaces an SD card to the Mac Plus and 512.

The ROMBUS languished for several months, but I came back to it recently. I figured that I should first work on getting a stable ROM disk driver before moving on to the SD card aspect, since the ROMBUS should have a ROM “recovery partition” anyways. My Mac Pluses are all broken though, and after a few stupid mistakes, I think the analog boards are basically busted. So I figured I’d do a Mac II ROM SIMM and driver to prepare for making the ROMBUS driver. In the meantime, I am also developing a crude VGA interface for the Mac Plus which will allow me to ditch the analog board for ROMBUS development.

In my SIMM, I wanted to address some deficiencies of the previous designs. BMoW’s 8MB SIMM is made with obsolete 5V flash chips, so I wanted to do a new version with 3V flash chips and level shifters to interface to the Mac’s 5V bus. These cheaper 3V flash chips allow for a very inexpensive ROM SIMM capable of storing two separate 8MB images (selectable by DIP switch). Of course, the 2x8MB SIMM I designed does not have socketed chips, and I couldn’t get a ROM SIMM programmer, so I figured I’d do a 2 MB SIMM with socketed chips first, easing development of the driver, which can then port over to the 8MB SIMM very easily.

Regarding my driver software, I wanted to make some improvements to the build process. Previous ROM disk drivers have been compiled using Metrowerks or something. Mine is using Retro68, A GCC fork, and is automatically patched into the base ROM. I’ve also changed some aspects of the driver lifecycle which I think were not thought out so well in the previous drivers. 

no way to use the Turbo040 patched ROM for the ROM-inator II and have your own custom ROM disk too ... cannot use my FloppyEMU in HD20 Mode with the patched ROM and with my Turbo040 installed. 

Unfortunately I don’t have a Turbo040, so I think it will be difficult to troubleshoot this issue. As I said earlier about the Turbo040, I wanna know the hardware mechanism for patching the ROM, and then I could figure out the impact on the software and devise a workaround.
On the subject of HD20 support, I don’t believe my ROM has this, since it’s not in the IIsi base ROM (right?) I will investigate and add this to my ROM, but I don’t know how much I can help with Turbo040 support. I will look out for one on eBay and then maybe I can figure something out about how it patched the ROM.

What I can say about my experience with the ROM-inator II MEGA in my SE/30 is that it is too thin

I’ve had no issues with the SIMM in my SE/30, but my SE/30 seems to be a later model with metal locking tabs on the SIMM socket, as opposed to the plastic tab socket in my IIci. Would you like to try the 2MB SIMM in your SE/30? We are going to send out a few to some testers tomorrow. If you’re not interested in the 2MB SIMM, the 2x8MB is in production and will be ready for testing soon, barring a mistake in the board.

 

[JDW]

Would you like to try the 2MB SIMM in your SE/30? We are going to send out a few to some testers tomorrow. If you’re not interested in the 2MB SIMM, the 2x8MB is in production and will be ready for testing soon, barring a mistake in the board.

Thank you for the detailed reply.  If you think I can contribute something useful while testing in my SE/30, then I would be happy to test.  I can test in a stock SE/30, SE/30 with 3 different accelerators including the 40MHz Turbo040 (ROM rev.4.11), 50MHz 68030 DiiMO, and 50MHz socketed PowerCache.  I also have a Floppy EMU which can be used in normal floppy mode or HD20 Mode, which is great because it acts like a bootable HD20 hard drive, yet with much more space (as your SD card allows).  I also have Micron Xceed PDS video cards too, including a grayscale setup.  I think this would give your beta ROMs a good testing.  Be aware I am based in Japan though, if that matters.  Feel free to PM me on the details.  Thank you!

 

[Trash80toHP_Mini]

If I got that right, you'll be accessing SD on the memory bus at 16MHz, 20MHz, 25MHz and even 40MHz?  8-o

 

[ZaneKaminski]

If I got that right, you'll be accessing SD on the memory bus at 16MHz, 20MHz, 25MHz and even 40MHz?  8-o

Unfortunately I don’t yet have a Mac II ROMBUS design but I am thinking about it. Right now there’s just the Plus/512 version finished. The peak read speed on the Plus will be 2 bytes/12 cycles using a MOVE.W (A0), (A1)+ instruction. That’s 1.3 MB/sec. So it should be much faster than SCSI on the Mac IIci. Also keep in mind that SD cards can’t really go at the full speed of the IIfx bus. The maximum speed is around 3.125 MB/sec unless you use the proprietary and patent-pending 4-bit mode. The read speed of a ROM disk on the IIci as measured by Lido is around 8MB/sec, so SD cards are close in speed but not quite as fast. Also, SD cards have variable read latency, so there is a “seek time” imposed by the card of a few milliseconds or sometimes even more. This is frustrating compared to parallel/serial NOR flash, where there is a very small latency well under a microsecond. This will unfortunately eat into the read speed. Hence why the original ROMBUS had serial NOR flash, since the read latency is fixed at a few clock cycles. Unfortunately I had to scrap the original ROMBUS because the “wear leveling” algorithm needed to match the Mac’s 512-bytes-per-sector disk architecture to the 16 kilobyte erasable units of the NOR flash system was complicated and used like 256kB of RAM. So basically reads would have been very fast but writes would be complicated and every once in a while take a long time. So I switched to SD card, which has similar limitations but does all of the write leveling for you internally. It’s easier, and the disk will be larger as well.