ROM emulator

[sage]

While on my way back from the Lynx Jam in Amsterdam, I had some rather stupid idea how to simplify a bit the development on real hardware in a way to be less intrusive to the hardware/carts/cartslot.

While flash cards (any of them) are rather nice for copying ROM, there are rather bad if it comes to development workflow. Depending on the cart, you have to switch off the lynx, remove the cart, plug usb, upload, unplug usb, replug to lynx. power on. (or at least change the sd card, flip dip switches on the cart etc). At least it it is not fitting the workflow and connector and cart suffer.

With the technology from last millenia (the BLL comlynx loader) it fits rather good into the development and can be completely automized (Makefile directly uploads on comlynx), this is limited to RAM only development.

So what i wanted is a ROM emulation which can be updated "over the air/cable) while still plugged into the lynx.

And ... evolution on uC even allow this with rather trivial hardware nowadays.

So, the only thing what you need is a rather fast uC, 5V/3.3V converters (can be skipped with the 5V version of the uC) and trivial software.

The uC is fast enough to provide data on it output pins when the lynx accesses its cart. The memory fits a 256kb cart without problems. even so until now i only tested 32kb due to having soldered only 24 level shifter channels)

 

Invested work:

- old cartridge to solder wires to

- two evenings of soldering

- microcontroller

- 24ch level converters (for 32kB, extend to 28 if you want 512kb roms, 29 if you want eeprom support)

- 2h software writing

 

Also here, my workflow now upload the rom directly to the uC (takes just seconds). Afterwards, only a power cycle of the lynx is needed.

 

 

r

[+karri]

Pretty good idea. Are you using some STM32 based module?

 

Perhaps Bluetooth serial port would be a simple solution for transferring the data.

[enthusi]

Very nice.

That's exactly what I use for the Watara Supervision development as there want even a half decent emulator at the time.

Maybe I should aim for Lynx as well for tight tests.

 

 

 

[Cyprian]

@sage cool idea, actually I was looking for something similar.

Are you going to share more details, or just produce/sell some pieces?

[sage]

9 hours ago, Cyprian said:

@sage cool idea, actually I was looking for something similar.

Are you going to share more details, or just produce/sell some pieces?

That is just a fun project (can this be done?). Unlikely that i start a production. soldering is just too much work. if you want to do it properly you would use other components ;).

[Cyprian]

anyway, would be cool to read more details about that

[+karri]

What about sharing the schematic? I might create a special cart with a controller, extra flash and BT serial interface.

The protocol could by intel hex. So you could transfer the changed blocks only.

Or perhaps use memory chips with jtag interface. Then you could program it serially and use the chips on the Lynx by wiring the memory directly as in usual carts.

A small run like 30 carts with 2M flash space and real eeproms. This could be a permanent part of a developers Lynx.

[Cyprian]

@karri cool idea

[sage]

Seems when I wired the remaining address lines, I messed something up ?

I can boot up to 4kb stuff from 512blocks,  but above it get stuck.

And it seems pad and button wont work when the cart is plugged in. really very strange. maybe side effect of the level shifters and i block the bus somehow ... have to check the lynx scb. Well, problem, the level shifters cannot tri-state and data lines are shared with button at suzy input ? .

 

 

Just a mess that my uC is not 5V tolerant, otherwise that would be stupid easy.

Edited November 13, 2021 by sage

[sage]

4 hours ago, karri said:

What about sharing the schematic? I might create a special cart with a controller, extra flash and BT serial interface.

The protocol could by intel hex. So you could transfer the changed blocks only.

Or perhaps use memory chips with jtag interface. Then you could program it serially and use the chips on the Lynx by wiring the memory directly as in usual carts.

The main issue in the design with writing to memory/flash is that you would need to share a bus. if you have chips with a second port (I2C, SPI, JTAG), you are fine.

[peekb]

Which microcontroller are you using for this? I've toyed with this idea for various systems but wasn't sure any uC would be able to toggle GPIO pins fast enough to actually emulate (EP)ROM speeds.

[+karri]

The fastest way to get things working could be to just duplicate the programmers HAT on a cart with some bus multiplexer. A Pi zero with built in WiFi so you can just ssh to the cart and run the programmer to change the content. The Pi runs on 5V.

 

You could also compile your code on the Pi. And run all editing on it. Actually the whole desktop over VNC. So essentially develop the code on your wireless Lynx using your phone as a desktop.

 

You could even connect the pi to a hdmi monitor and use your wireless kbd+mouse for development for a more convenient setup.

 

I actually have a 4 chip cart design that extends the memory to 2 MB. The pcb would still fit in a Lynx as a flat cart. But the developers cart would extend out of the Lynx.

[42bs]

Cool idea. I recommend to add a reset button to the Lynx. It speeds up development also.

There are SD card emulators IIRC. Maybe these work with GD.

 

[sage]

5 hours ago, peekb said:

Which microcontroller are you using for this? I've toyed with this idea for various systems but wasn't sure any uC would be able to toggle GPIO pins fast enough to actually emulate (EP)ROM speeds.

Teensy 4.0 board with 600MHz and 512kb RAM, that is fast enough, has enough memory and plenty of IO pins

Unluckily, it is not even 5V tolerant, otherwise you just could wire it as it is

[laoo]

I've encountered one problem with putting anything "smart" into the cartridge - It has to have it's own power source. I've tested a configuration involving GameDrive, chinese SD to micro-SD adapter and Toshiba FlashAir - an SD card with Wi-Fi and generally it worked, but proved impractical, as booting new image involved power cycle, and FlashAir needed few second to boot and establish Wi-Fi connection. It's faster to remove microSD from GD, put it into card-reader, copy file and put microSD back to GD.

[42bs]

27 minutes ago, laoo said:

I've encountered one problem with putting anything "smart" into the cartridge - It has to have it's own power source. I've tested a configuration involving GameDrive, chinese SD to micro-SD adapter and Toshiba FlashAir - an SD card with Wi-Fi and generally it worked, but proved impractical, as booting new image involved power cycle, and FlashAir needed few second to boot and establish Wi-Fi connection. It's faster to remove microSD from GD, put it into card-reader, copy file and put microSD back to GD.

 

But if you add a reset button to the Lynx, FlashAir does not reboot.

[laoo]

44 minutes ago, 42bs said:

But if you add a reset button to the Lynx, FlashAir does not reboot.

Yeah, a reset button for this project would be great, as after reset the Lynx would just boot from new content.

For GameDrive+FlashAir I think it can be done in software - one just need to include in debug version of a game a code that will reload updated version of game image and jmp $ff80.

 

[+karri]

The way I thought of making it is instant after power on. So the Pi wakes up later but is not needed for playing the content.

 

I actually started KiCad and have most stuff done already.

[42bs]

26 minutes ago, laoo said:

Yeah, a reset button for this project would be great, as after reset the Lynx would just boot from new content.

For GameDrive+FlashAir I think it can be done in software - one just need to include in debug version of a game a code that will reload updated version of game image and jmp $ff80.

 

But a jmp means you have running code. A HW reset does work under all conditions means a crash.

[42bs]

27 minutes ago, karri said:

The way I thought of making it is instant after power on. So the Pi wakes up later but is not needed for playing the content.

 

I actually started KiCad and have most stuff done already.

So actually a PiHat connected directly to the card which is still inserted in the Lynx?

But the nice thing about Sage's approach is _RAM_. Which means it is likely a lot quicker to have a new image installed.

Edited November 14, 2021 by 42bs

[laoo]

8 minutes ago, 42bs said:

But a jmp means you have running code. A HW reset does work under all conditions means a crash.

Right... The thing is that resetting Lynx won't reset GD and most likely it will only boot from the image that is already in GD's RAM. So Sage's approach is better in this case.

[+karri]

2 hours ago, 42bs said:

But the nice thing about Sage's approach is _RAM_. Which means it is likely a lot quicker to have a new image installed.

A valid point.

[Sporny Kun]

A nice contraption...

[+karri]

My original thought was to steal the power from the Lynx and run the card without wires. But the RAM alternative means that the Pi will also reboot when you power cycle the Lynx.

 

Using a power bank with two ports could provide power for the Pi at all times and let you power cycle the Lynx without losing the data in RAM. This may be the most practical solution. The Pi could automatically load the latest content in the SRAM at boot. So when the Lynx boots up it will run the game as from a cart.

 

There seems to be 2M x 8bit chips available that would allow to develop games for the maximum ROM space that uses both ROM banks and AUDIN as an extra address line.

 

There is some new 2M flash chips that would fit the same space as the current 512k chip I am using. So by adding two small logic gates it is possible to create Lynx carts with 2M ROM's for the same price as 512k ROM's. (less than €4 per chip)

[sage]

15 hours ago, karri said:

A valid point.

upload takes a second