MicroSD2ROMSIMM - SRAM based ROM emulator card?

[Trash80toHP_Mini]

Has anyone looked into SD to ROM SIMM feasibility?

SRAM based - ROM emulator SIMM card (crazy notion comes from having developed DIP SRAM->DIP ROM version of same back in the day)

Battery backup for SRAM = non-volatile ROM emulation

Images on SD loaded into SRAM by onboard NanoComputer (anything suitable to task in a < PiZero kinda deal?)

Infinite (for all practical purposes) ROM images stored on Nano's MicroSD card

WiFi enabled NanoComputer would be controlled remotely from daily driver

Near-instant gratification achieved by uploading freshly downloaded ROM image remotely/immediately and then hitting power key. []

Customary over the top bits:

Could load excess addressable ROM space as ROM storage?

HotSwap same?

Ethernet connection to onboard NIC enables files stored on SD to act as mountable networked drives?

Dunno, coffee's kicking in, so I'm losing it.

One internal unit should cost less than a ROM SIMM/Programmer combo?

If more/convenience worth added expense?

No external cases or wire clutter.

Whatcha think? :blink:

 

[techknight]

the access time needed for something that parallel would be beyond what an SD card could do I think. 

The data would almost have to be shadowed. a simple CPLD/FPGA program would read the SD card and store it into RAM where it can be accessed in parallel without delay. 

 

[Trash80toHP_Mini]

Not surprising, sounds like a possible added feature?

Wi-Fi controlled NanoComputer based ROM Emulation ROM SIMM card/Programmer combo for SRAM is all that's really being proposed.

The rest is just habitual infusion of featuritis. :

edit: now that I'm almost awake (had a 6AM meeting to sleep through on my day off ) I'll block out a workable prototype for my SE/30 testbed.

As always, I can't do any of this crap myself. I just float whatever notions rise to the surface of the roiling visual cortex between dream state and a workable subset of consciousness. Coffee time is for building sand castles in my head, illusions unfettered by practical consideration = fun times!

 

[Trash80toHP_Mini]

That wasn't much Rube Goldbergian funtime at all. :-/

A prototype for the chassis unencumbered SE/30 testbed or open topped IIsi :

-  edge card SIMM profile on the bottom

-  header socket for the likes of my OrangePi at the top

-  "SIMM Card" extends within the 10x10 board form factor

-  everything in between is available prototyping area or just headers for breadboarding on the first go-round

 

[Trash80toHP_Mini]

The data would almost have to be shadowed. a simple CPLD/FPGA program would read the SD card and store it into RAM where it can be accessed in parallel without delay. 

I was a bit groggy, that's EXACTLY what I'm describing. Except that it would be the WiFi controlled NanoComputer loading the battery backed SRAM where it's accessed from the SIMM interface. The NonoComputer runs the CPLD/FPGA implementation remotely from your daily driver. The dumb emulator board/font card we did was controlled from a custom ISA card over a ribbon cable parallel interface.

What I'm proposing here would be the equivalent of installing that ISA card, wrapped up in its PC with HDD on board directly on the Font Emulator Card inside the target machine back in the day. WiFi network remote control of a computer that small was a bit far off into the future.

 

[Trash80toHP_Mini]

Could Rpi load the SRAM over GPIO w/o CPLD/FPGA support?

Pi Zero W is lookin' really good, WiFi's bee added to the Zero and the antenna can  be located a couple of places.

$24 kit includes RA headers and assorted goodies. If the ROM SIMM emulator can fit within the chassis, the Zero W can mount horizontally beside/over PRAM battery.

Pi Zero's good if still available, just trim away WiFi featuritis and run a USB cable through the backplane plate?

 

[Gorgonops]

There's a dingus called the PETvet for Commodore PET computers (I was involved with brainstorming the idea for it over on the VCF, but, as usual for me, had no part in actually buckling down to build it) that essentially does what you're asking about here; it uses a small ATMEGA microcontroller to load a segment of an SRAM chip (which in this case is used to replace both the ROM *and* the RAM) with a copy of the Commodore ROMs (in this case stored in the ATMEGA's internal flash) and sets up the small SRAM that's used as a crude MMU to write protect it while holding the RESET line on the CPU. Once it's finished it allows the machine to boot.

That's the major issue I see with this idea, really. Unless you have a battery in the system to make the SRAM non-volatile you'll have to load the "ROM" contents at power-on, and unless there's a way to hold the CPU in a halted state from the ROM socket while you're doing that you'll have the problem that the main CPU is going to try to start executing your uninitialized nothingburger when you flip the switch and crash horribly. Maybe a better idea would be to use flash chips (IE, basically the same as the existing ROM SIMM replacements) but simply build the programmer into the SIMM itself so you could tweak it at will just by leaving a USB cable hanging out the back. (You could always plug that into your Raspberry Pi if you wanted to program it over WiFi.)

 

[Trash80toHP_Mini]

Battery backup making the SRAM non-volatile on the ROM SIMM emulator is in the IP spec. []

Thanks for that PETvet link, I'll be checking it out. I know a full blown NanoComputer is overkill, but any excuse to get one inside an SE/30 or IIsi is a good one for additional playtime. I've got some more crazy excuses to make use of it once the Zero and its WiFi are in there. After all, how often will it be busy loading a new image into the emulator?

In the meantime, a no muss, no fuss, wireless, near instant upload of a downloaded ROM image to battery backed SRAM from the daily driver is the goal. No case opening, no wires hanging out (very far, a bit of antenna from vent to vent under the chin of the SE/30?) connected to anything at all and no chance of ESD sudden death syndrome.

Loading excess capacity as ROM disk remotely without fuss for playtime is the killer by-product. The programmer cycling we're doing now seems such a waste of time, it reminds me so much of swapping out font cartridges. Swapping images into SRAM on the emulator from the PC's fixed disk was the Bombe! []

Hoping some line conditioning and gating will be all that's necessary to load the SRAM-ROMs from the GPIO pins without anything fancy involved. That's how simple the font emulator was back in the day when you get right down to it.If it makes more sense to program an FPGA to handle everything over USB from the Zero W run form the daily driver, then fine. At least it's a fully contained system, why is CPLD running off USB the answer to EVERY problem these days. When all you have is a hammer  .  .  .

CPU/Socket wedgie time for making use of excess cycles and I/O comes later. A CPU is a terrible thing to waste. :lol:

 

[Trash80toHP_Mini]

https://hackaday.io/project/26224-msxpi-interface



MOAR GPIOs: https://hackaday.com/2014/07/24/adding-gpios-to-the-raspberry-pi-with-the-camera-interface/

GPIO RAM MODULE: https://www.raspberrypi.org/forums/viewtopic.php?t=114326

https://electronics.stackexchange.com/questions/56205/use-raspberry-pi-gpio-header-as-memory-mapped-interface

I doubt this has anything whatsoever to do with the project at hand, but it's a damn cool paper: http://www.cypress.com/file/46256/download

 

[Trash80toHP_Mini]

Is it possible to control a SRAM module via the GPIO pins?

 

[Trash80toHP_Mini]

My Orange Pi fits like a glove. The Pi Zero X header is unimplemented. Solder the RA Headers in the kit above and they'll slide right into header sockets on the SIMM-Emulator Card. Printing a multi-function clip-on PRAM battery cover that's chassis for the Pi to be screwed down after the header connection is made up topside. A small PCB is screwed upside down with SRAM's button battery holder, FDD power connector, Pi power plug pigtail, SIMM emulator power jumper pigtail and kitchen sink on board.

If it's not workable to load the SRAM directly from GPIO I'll settle for a CPLD/FPGA solution.

Physical spec worked out well, now if we can turn it into a fast WiFi NIC for the host directly or a WiFi server with local storage via crossover cable we can use a bit of the massive resource overage.

Dunno.  :blink: Once again I can't but a bit of this crap myself. But I thought the notion might make a good start for Macintosh Pi-ripheral development. It will definitely make ROM image/ROM storage play a lot more convenient.

edit: A more capable Pi is probably in order, I started out with the Zero because it was supposedly a $5 toy. But for the internal server thing you'd need one with Ethernet on top of WiFi. I hope the two are different channels or whatever so it can act as a server?

 

[Trash80toHP_Mini]

Forgot to mention, a IIsi/SE/30 NIC's breakout board wouldn't need to be hooked up at the backplane opening, only a drilled hole would be needed on the cover plate for the WiFi antenna. The crossover cable wouldn't need to be looped back to the Pi externally as it would for a NuBus NIC. That could easily be drilled in a VidCard's cover plate.

A printed plate for an internalized VGA adapter and the WiFi antenna would be better, especially for the RCPII/IIsi/SE/30 cable build which doesn't have a plate.

A little RFI shielding wouldn't hurt either. []

edit: once again I've been sucked into the SE/30 vortex, losing all sight of my IIsi projects.

 

[pb3623]

For the record, I LOVE this idea for all the reasons you mentioned in your OP. 

A similar but less functional approach (but also less involved, electrically) would be to load all of your ROMs up once and select them from a basic UI/menu, like a FloppyEmu, RetroPie, etc. Now this isn't my idea; Steve Chamberlin pitched that in his/Doug's ROM SIMM Programmer but I assumed it was more a suggestion of what could be possible with enough initial boot ROM hackery... and I can't find any mention of anyone taking that idea and actually doing it.

Seems like the software part of your approach versus this one are at least a little alike - you have a utility that either organizes and presents the ROM files on the SIMM or load from an incoming connection (listening on TCP 443) or network share, and a front end that loads the selected ROM for bootstrapping. Maybe an "add-on" section for custom accelerator or startup sound code that could be appended w/o an entire ROM.

I could also be way off and the two approaches are so vastly different that there's nothing in common.

Either way, good God this is going to be fun to watch!!!

 

[Trash80toHP_Mini]

THX. I'd love to watch it happen too. []

I've been thinking about the Pi-Power conundrum. Seems like it will be necessary to tap AC from the hot leg of the A/B power switch of the PSU while it's OFF in order to power an internal lump-onna-rope kinda deal for the Pi to load SRAM/ROM emulator while the target machine is offline.

 

[Trash80toHP_Mini]

https://www.raspberrypi.org/forums/viewtopic.php?t=114326



Re: GPIO RAM MODULE

• Quote
  

Sat Jul 04, 2015 11:09 am


The SMI is like the old Motorola/Intel bus: address, data, read and write strobes.
I would have to remember all the registers and their control bits on how to operate it and for some reason I can't.
Even if I could remember, I could not tell about it is am still under NDA from when I left Broadcom.