In-System-Programmable ROM SIMM

[zigzagjoe]

Is your next version going to have the lights embedded? Or will you stack this on the interposer?

This is intended to stack on the interposer board for use with in a quadra with bare metal code. So far I haven't come across much that would warrant a full revision of the board.... but very early days.

You could have a text log file shown on the emulated storage device? Could even include the latest status in the filename "log - failed.txt".

The problem is the emulated storage device's data is currently synthesized on the fly, so the file listing is fixed. I'm definitely thinking that I will at least have the internal log to a log "file", but the main problem is there isn't a graceful way to inform the host of changes (since the host rightly assumes storage devices don't just decide to change their contents for fun) nor is there a way to deal with the host caching data.

I think I'm going to have to do a full USB disconnect and reconnect, breaking the serial connection as well as making the host complain about the drive going away unexpectedly...

 

[uyjulian]

An alternative would be to expose MTP. Then you can change files without eject/reinsert...

 

[zigzagjoe]

An alternative would be to expose MTP. Then you can change files without eject/reinsert...

Yeah, that would be an option, though it'd be even more complicated and also impede use on Mac and Linux unless Mac picked up native MTP support finally. Thankfully, it seems like waiting a moment after transfer finishes then replying with SCSI sense unit not ready/media ejected one time is enough to cause it to be "gracefully" rescanned.

Honestly, though, I'm wondering how much additional functionality I want to put into the "UI" UF2 stuff.

Right now it's the basics; allow reading or writing of the current bank selected by physical switch, and cover the assorted edge cases/safety stuff. It'd be easy to make it able to arbitrarily read back either bank, writing either bank on demand, more difficult... but possibly doable, though you'd have to rename files first to cause the overwrite. Some logic could also be done to make it only read back as much as was written to the bank most recently (rather than the whole 8MB), but I'm not sure how much effort I want to put into that because - let's be honest - how often will one read back what is already on the module?

I've also confirmed my logic to detect VPP with analog circuitry to automatically disable Quadra onboard ROM works as expected too.... so that's it for the hardware validation.



Interestingly, Quadra 700 (420DBFF3 - Quadra 700&900 & PB140&170) and Quadra 950 (3DC27823 - Quadra 950) ROMs will boot a SE/30.

 

[zigzagjoe]

These have been posted for sale!

Support information is on github: https://github.com/ZigZagJoe/ISP-SIMM_public

 

[AndyMc1280]

Would these work on se30 ??

Nm, I've seen that they do..... meh lol.

 

[zigzagjoe]

Would these work on se30 ??

Yep It is universal and will work with any Mac II (including SE/30) or Quadra with a ROM slot.

On Quadra systems it will gracefully disable onboard ROMs. For the Mac II with onboard ROM (IIci and the like) you may need to set a jumper to disable the onboard ROMs. Not certain if that's the exact step, but it's the same as would be needed for any other third party ROM SIMM.

This was essential for creating my 30Video GS card, it literally would not exist without the ISP-SIMM. I was able to write some baremetal 68K assembly to the SIMM in order to flash the video board, then reboot with a Mac ROM in around 5 seconds total.

 

[obsolete]

This was essential for creating my 30Video GS card, it literally would not exist without the ISP-SIMM. I was able to write some baremetal 68K assembly to the SIMM in order to flash the video board, then reboot with a Mac ROM in around 5 seconds total.

That's cool!

 

[zigzagjoe]

That's cool!

It's very much a lifesaver when I'm up to over 1900 builds written to hardware in the course of developing that card

As part of the 30Video test and burnin process, each card gets fully exercised by a baremetal test program to test registers, CLUT, VRAM, ROM, and other aspects of the card.

I've always had an interest in 68k assembly and built a 68008-based SBC some years ago, so it's pretty fun to use a mac as a giant SBC even using some of the same code I wrote for that. With some minimal startup code you can get to running C quickly too, though of course you're responsible for everything. Also, I cop out and use the alternate VRAM buffer for my stack and RAM variables rather than initializing DRAM

 

[rplacd]

I'm curious... do you initiate reprogramming via transferring control to hardcoded ROM code (or a simple address going down the address lines)?

 

[zigzagjoe]

I'm curious... do you initiate reprogramming via transferring control to hardcoded ROM code (or a simple address going down the address lines)?

I've got some simple baremetal code that is just enough to write flash and send some simple messages over serial, with the DeclROM data being embedded in that code. So, the complete workflow looks something like this:

1) Utility on computer appends the new DeclROM data to precompiled flasher binary
2) Utility writes flasher+DeclROM to the SIMM
3) baremetal code writes DeclROM and signals success over serial (host's serial connected to the SIMM's serial interface)
4) Utility on computer captures the success message and writes back a Mac ROM
5) Now booting as a Mac again.

During all writes to the SIMM, the mac is held in reset and released when done. Total, about 5 seconds from start to finish.