Jump to content
IGNORED

DIY 2600+ flash cart with a Raspberry Pico


karri

Recommended Posts

1 hour ago, ChrisKewl said:

@astroguy are you saying if we wanted wifi we'd have to have a separate power source to handle the additional load? Sure it sounds neat, especially if you gave it a USB-C header and find a nice USB power splitter to split the USB between the Atari 2600 and the cart.  Or am I misunderstanding what you are thinking? Thanks!

I don't think additional power is needed for the load, I was more worried about the wait time for the wifi to initialize then have the rom load.  The PICO can already handle two power supplies.  If USB and VSYS are connected the PICO will use whatever is stronger.  Thus you can use the 5V from the Atari and USB at the same time if you wanted to. 

 

The second problem is persistent storage so that you don't need to load a new cart on every boot.  The PICO does not have a file-system, so we use the EEPROM instead.  With a bit of work I'm hopefully to solve the ram problem.  It will be a fun puzzle to solve. 

 

 

  • Like 1
Link to comment
Share on other sites

okay.  The RAM issue seems to have disappeared.  I think my build directory got corrupted, so I cleared it and recompiled from scratch and now wifi + flash is working.  🤷‍♂️  The code takes up less that 600 kb of flash space.  I decided to park the 32K of EEPROM at the end of the 2MB flash.  So lots of room for more code. 

Link to comment
Share on other sites

Thanks for the ideas. I would like to store the cart in eeprom always and copy it to RAM at startup for the 7800 games. Unfortunately the 7800 games need much faster operations than the 2600 games. Even when run on the same Atari 7800 PAL unit.

Link to comment
Share on other sites

6 hours ago, karri said:

Thanks for the ideas. I would like to store the cart in eeprom always and copy it to RAM at startup for the 7800 games. Unfortunately the 7800 games need much faster operations than the 2600 games. Even when run on the same Atari 7800 PAL unit.

Is the problem with the 7800 the Pico start up time?  If the Pico was already powered up before turning on the 7800 would the ROM load with the pico running at 250 Mhz or slower?  With the Pico I see less than a 100 ns delay to read the address lines, deal with bank-switching and set up the data bus.  This should be more than enough for 2Mhz and meets specs for real EEPROM hardware. 

 

I agree that the best approach is to copy the ROM to RAM from the EEPROM.  This helps avoid potential problems from interrupts.

 

Right now I have a method that uses MQTT to get data to the PICO, but it's very clunky and slow (64 bytes/sec).  It was an early proof-of-concept as I use MQTT for other purposes.  It will take me sometime to figure out a different protocol for data transfer.

Link to comment
Share on other sites

There is two problems with Pico and the real Atari 7800. The easier one is powering the Pico from a powerbank before setting power on the Atari 7800 console. It takes care of the too long startup problem.

 

The other is the difference between 2600 and 7800 games. The screen looks ok for 2600 games when run from flash or RAM. But when you run 7800 games then the screen is garbled if you run from flash and ok if you run from RAM.

Link to comment
Share on other sites

I know the 7800 Game Drive allows you to change games when pressing the two fire buttons and pulling down. on the joystick. The system goes back to the Game Drive Menu and you pick a game then a reset signal must go to the 7800.

 

If there were a small 7800 boot strap flash screen could it allow enough time for bigger games to load, then reset the 7800 so the larger game rom loads?

 

This would only work for 7800 and not the 2600+ of course.

Edited by SuperZapperRecharge
Link to comment
Share on other sites

When the 7800 is connected to the Pico we have 3 new address lines A13, A14 and A14. There is also a new R/W line for writing to RAM or POKEY. A new HALT line needed for bankset cards. And a new exaudio for getting the sound out. Then there is still a CLK2 and an IRQ line. There is no RESET line on the 7800 connector. The Pico already has less pins available than we need for emulating the cart. By removing the LED from the board I believe we can barely emulate a 7800 cart.

 

The question is: how do we connect anything else to the Pico like a dip switch, screen, buttons?

Link to comment
Share on other sites

26 minutes ago, astroguy said:

Share the address/databus when A12 is low. 

That would work for the 2600 games. I am really more interested in 7800 games. So far I can run 16k and 32k 7800 games with TIA sound and no RAM only.

 

Another thought I had was to cut power from the console. It could be sensed by the Pico and it might turn on the screen and buttons.

Link to comment
Share on other sites

I made some changes to my codes that improves code size on the flash, compile time and start up times.

 

I wasn't happy with the rom_contents setup that has thousands of lines with rom_contents[1] = 125, rom_contents[2] = ....    This used a lot of flash space to store the code, it's slow and can cause the compiler to fail on devices such as a Raspberry Pi.   So I changed everything to simple array definitions in a header.  The compile time is now very fast and the flash storage with 16 roms has gone from 1786 kb to 183 kb!! 

 

I've put my codes and scripts on GitHub if useful: https://github.com/jasonfrowe/atari2600cart/tree/main

 

This will make room for me to switch to the PicoW in my testing and hopefully allow for OTA ROM changes.  I may stick with MQTT as I think I can take advantage of sending long hex strings to transmit the ROM.  Then the Pico just monitors for MQTT messages on the 2nd CPU, and if it sees a request for a new ROM, it does it's thing.

  • Thanks 1
Link to comment
Share on other sites

I received the Otaku cart today and Strike Zone Bowling plays perfectly on it. I did notice that the audio on the 7800 side sounds bad but using the 2600 side sounds just fine. I have yet to try to make the uf2 files myself, relying on test roms from @karri.

 

I also started tinkering with the case concept by using the case from Karri as a template.

  • Thanks 1
Link to comment
Share on other sites

5 hours ago, astroguy said:

I made some changes to my codes that improves code size on the flash, compile time and start up times.

 

I wasn't happy with the rom_contents setup that has thousands of lines with rom_contents[1] = 125, rom_contents[2] = ....    This used a lot of flash space to store the code, it's slow and can cause the compiler to fail on devices such as a Raspberry Pi.   So I changed everything to simple array definitions in a header.  The compile time is now very fast and the flash storage with 16 roms has gone from 1786 kb to 183 kb!! 

 

I've put my codes and scripts on GitHub if useful: https://github.com/jasonfrowe/atari2600cart/tree/main

 

This will make room for me to switch to the PicoW in my testing and hopefully allow for OTA ROM changes.  I may stick with MQTT as I think I can take advantage of sending long hex strings to transmit the ROM.  Then the Pico just monitors for MQTT messages on the 2nd CPU, and if it sees a request for a new ROM, it does it's thing.

Would you have a custom client used to load games or would you load games via an html page and maybe web sockets with MQTT used in the web socket?

Link to comment
Share on other sites

4 hours ago, ChrisKewl said:

I did notice that the audio on the 7800 side sounds bad but using the 2600 side sounds just fine.

So obviously the resistors 10k and 1k should be removed for now. The resistors labeled exaudio. I have to have a look if I need a capacitor or something.

Link to comment
Share on other sites

8 hours ago, SuperZapperRecharge said:

Would you have a custom client used to load games or would you load games via an html page and maybe web sockets with MQTT used in the web socket?

Right now I'm using a Jupyter notebook to send the payload:
 

topic=f'home/atari-rom'
msg1=romsize_str
msg2=rom_str
result = client.publish(topic, msg1)
result = client.publish(topic, msg2)

 

Where msg1 contains the size of the rom and bankswitching info and msg2 is a 32kb zero padded rom.   The Pico is subscribed to rom/atari-rom.

  • Like 2
Link to comment
Share on other sites

10 hours ago, ChrisKewl said:

I received the Otaku cart today and Strike Zone Bowling plays perfectly on it. I did notice that the audio on the 7800 side sounds bad but using the 2600 side sounds just fine. I have yet to try to make the uf2 files myself, relying on test roms from @karri.

 

I also started tinkering with the case concept by using the case from Karri as a template.

ooh if you got yours mine should be here soon. I made a few uf2 files but have no way to test them to see if I did it right. 

Link to comment
Share on other sites

I just got my 48k cart build script to work for emulating Atari 7800 48k carts 

 

There is a strange thing with the 48k cart. For some reason it needs to have a powerbank connected also for the 2600+. Without the powerbank I get "game load failed" but when adding the power bank it will happily load the game from RAM.

  • Like 2
Link to comment
Share on other sites

Okay. I have a demo code that has WIFI + MQTT working and chatting with a Raspberry Pi while hosting ROM carts to a 2600+.  The messy code is on my Github (rom_wifi.c) if anyone wants to peak.  Shouldn't be too much more work get the ROM transfer completed and to add the persistent Flash for WIFI transferred ROMs.  I'll be using 2 cores.  One core to run the data and address bus and the other for MQTT. 

 

Code is using 517kb of Flash when compiled that includes ~132 kb for the 16 random ROMs I have loaded.   Not good news for running off RAM only.  But that's TBD right now. 

Link to comment
Share on other sites

47 minutes ago, astroguy said:

 I'll be using 2 cores.  One core to run the data and address bus and the other for MQTT. 

How do you determine what process is running on what core? Is this like Unix and perhaps Linux where when you start the app you tell it what core to run on? I'm familiar with Solaris, yes I'm old, and sometimes we would tie a process to a core so it wasn't thrashing processes / threads between cores.

 

I read up a bit on the Pico and saw that you need some sort of protocol to communicate between cores.

https://forums.raspberrypi.com/viewtopic.php?t=340588

 

@karri I may want to order the bits to build a cart so I can get into some development. I won't be near my soldering iron for two weeks though. I can PM with details if you still have the parts.

 

How close is this to the Plus Cart? Different processors I know but similar ideas.

Link to comment
Share on other sites

I used Solaris during my undergraduate days.  Then I tried Linux on a 486 and I was hooked!

 

The Pico has no governer or scheduler.  You load a multicore library and then assign a task to a specific core.  Nice and easy. 

 

Link to comment
Share on other sites

10 hours ago, SuperZapperRecharge said:

How close is this to the Plus Cart? Different processors I know but similar ideas.

The Pico cart here is more close to the idea of the Dragonfly than to the PlusCart/UnoCart

 

6 hours ago, karri said:

I have boards available still. But I have no knowledge about Plus cart.

 

 

Link to comment
Share on other sites

The next question is to see if the bankswitchin for the 7800 works. Unfortunately I ran out of pins for the needed RW wire so I am ditching the LED. It should allow us to use the GPIO25 for reading the RW pin. According to the schematics there is a TP5 conncted to the LED with just a small current limiting resistor to GPIO25. I did drill a small hole in the pcb for tying out this hack.

IMG_20240115_153149.thumb.jpg.ea97b02c78c4796427ed5e664c3cf773.jpg

 

The LED would also limit the maximum voltage the RW pin can output so the LED has to go. It is easy to remove by adding a little solder.

 

IMG_20240115_153230.thumb.jpg.50be49fa662f6f9a9ccc02f81ba1838d.jpg

 

Will this work?

 

At least I did not break the cart. Galaga PAL 48k game still runs fine.

IMG_20240115_155745.thumb.jpg.b17bdbee6ff04641d7bb9ec250ea2907.jpg

  • Like 1
Link to comment
Share on other sites

58 minutes ago, karri said:

Unfortunately I ran out of pins for the needed RW wire so I am ditching the LED. It should allow us to use the GPIO25 for reading the RW pin.

Could you use a NOR or AND gate to bring the RW and Halt pins together?  Or the RW with a different pin?

Changed my mind.. I don't think as stated this will work.

All my reading about TP5 simply states "do not use this". 

Edited by astroguy
  • Confused 1
Link to comment
Share on other sites

52 minutes ago, astroguy said:

Could you use a NOR or AND gate to bring the RW and Halt pins together?  Or the RW with a different pin?

Changed my mind.. I don't think as stated this will work.

All my reading about TP5 simply states "do not use this". 

TP5 is not really recommended to be used as it will only swing from 0V to the LED forward voltage (and hence can only really be used as an output with special care).

Nyttkuva2024-01-15171402.png.a50533b27b1507adac5d5a3127afe0d6.png

But if I remove the LED as I already did I should be safe :) 

 

Can someone recommend a simple 128k game using some well defined Super Cart bank switching? So no RAM, no POKEY. Would Commando be a good candidate?

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   1 member

×
×
  • Create New...