Raspberry Pi Pico Multicart - 2600PicoCart

[electrotrains]

Hi All,

 

I thought it was time to post about my latest mini-project - I've ported my original UnoCart 2600 code to run on a Raspberry Pi Pico which is a very low cost (£2-£4) ARM based microcontroller board from the Raspberry Pi Foundation in the UK.

 

The idea is to make a very low cost (<£5) DIY multicart project, which really just involves soldering a pico to a PCB - there are no other components.

 

In theory the pico requires voltage level shifters to connect to the 5V atari bus, but there are rumours to the effect that most of the GPIO pins are 5V tolerant (and in practice others have not encountered problems to date), so I've skipped them on the basis that this is supposed to be cheap and cheerful. I've been running it for many hours so far without problems, but your mileage may vary.

 

There is no SD card slot - the Pico has a 2Megs of flash, so I've written code to expose it as a mass-storage device when plugged into USB. In practice that means you can plug it into your PC with a USB cable and drag and drop files directly onto the cart from Windows. The 1meg of flash allocated to ROMs is in practice enough to fit all my favourite stuff and more.

 

The PCB supports both the cheaper castellated edge pico version which can be soldered directly to the board surface mount style, or the Pico H with headers.

 

The firmware is basically the UnoCart 2600 firmware, and I haven't finished porting all the cartridge emulation code yet, but it basically seems to work great, though I do get a noticeable amount of RF interference on the TV compared to the original unocart - I'm waiting for some new PCBs to arrive from China that will hopefully improve matters there. The new PCBs will also have mounting holes, and a PAL/NTSC solder bridge for selecting the firmware.

 

When I've finished the firmware, if anybody wants a finished cart to help me do a bit of testing?

 

Initial Prototype

 

Version 1 PCB

 

 

Pico-themed green firmware (Pal)

 

 

Atari XL/XE Version

 

I've also made an Atari 8-bit version using a purple 16Meg Pico clone that has more GPIO pins than the original Pico (the Atari 8-bit cartridge port has slightly too many signal lines to interface to the original pico). I'll post about that in the 8-bit section seperately.

 

 

[Prizrak]

Awesome project, love it

[+fdr4prez]

Neat.

 

Are the holes in the board in alignment with the holes on the PICO, so i could use SIP connectors, instead of soldering the PICO directly to the board?

[electrotrains]

Yes, you can use female headers in between the Pico and the PCB, if you want to avoid losing the pico forever 🙂

I did that when the PCBs arrived, just in case they didn't work!

 

Robin

 

 

 

[electrotrains]

Just posted about the Atari 8-bit version here

[+x=usr(1536)]

Nifty project!

 

Allow me to suggest including a micro SD card slot regardless of on-board storage, or at least detailing how to add one.  Having a second method of being able to transfer files to and from the device would be a plus, and it would also allow for moving cards between this one and others (like, say, the FujiNet or SIDE3.x).  Handy if you have games that modify disk images to save high scores, etc.  I realise that last point is more something that would be relevant to A8 users, but at least having the option there wouldn't hurt.

 

Hmmm...  This should also be doable on the 5200.

[electrotrains]

29 minutes ago, x=usr(1536) said:

Allow me to suggest including a micro SD card slot regardless of on-board storage, or at least detailing how to add one.  Having a second method of being able to transfer files to and from the device would be a plus, and it would also allow for moving cards between this one and others (like, say, the FujiNet or SIDE3.x).  Handy if you have games that modify disk images to save high scores, etc.  I realise that last point is more something that would be relevant to A8 users, but at least having the option there wouldn't hurt.

 

 

It had crossed my mind, but I don't think there are enough GPIO pins left to add an SD card (on either version of the cart) - I'm not sure if there is much benefit anyway - in USB mass storage mode, the files on the cart are both readable and writeable by your desktop operating system. So you can copy files back from the cart to your PC, and onto any other media you want.

 

This is only really useful for the Atari 8-bit cart at present, since it can emulate a disk drive (using ATR files) which you can write to from the Atari. So you can write a program in BASIC, save to an ATR file on the cart, then copy the ATR back to your PC for e.g. use on an emulator.

 

Robin

[+x=usr(1536)]

9 minutes ago, electrotrains said:

It had crossed my mind, but I don't think there are enough GPIO pins left to add an SD card (on either version of the cart) - I'm not sure if there is much benefit anyway - in USB mass storage mode, the files on the cart are both readable and writeable by your desktop operating system. So you can copy files back from the cart to your PC, and onto any other media you want.

Understood   For this, I really see it more as a nice-to-have than a hard-and-fast requirement.

[+fdr4prez]

What if you use a microUSB adapter to microSD?

 

 

 

 

[+batari]

I'm developing one of these in parallel - the Piccolo cart, announced last year. The Pico is a great platform!

[+batari]

Oh, and by the way, the Pico is not 5v tolerant. You should use some level converters for your design going forward.

[electrotrains]

Hi Batari,

Agreed - the pico is a really nice dev platform. I hadn't heard of the picollo - do you have link to your announcement?

 

Regarding the 5v tolerance, I'd read this article and concluded it was worth a go without level shifters - though I should probably have one on the data bus.

 

But the main aim was to make something fun and cheap that people could build themselves even without much soldering experience. Extra components get in the way of that goal. And if they don't last forever, it doesn't matter so much when the parts cost less than five pounds.

 

Robin

 

[electrotrains]

8 hours ago, fdr4prez said:

What if you use a microUSB adapter to microSD?

The 2600PicoCart is acting as a USB mass storage device, not a USB host - so that wouldn't work.

 

Edit - having said that, there is a USB host library available for the pico, so you could rework the firmware to make something like that work. But I prefered no other components, and to make maximum use of the hardware on the pico board itself, hence the use of the on-board flash.

Edited May 24, 2023 by electrotrains

[mimo]

Looking forward to having a play with these carts.
Regarding the 2600 cart, can it be PAL/NTSC switchable? Would be useful for me as I have both flavours 

[+SvOlli]

Nice project. It's also awesome to learn about the "limited 5V tolerance".

 

Would like to help testing, both 2600 and 8bit versions.

For better connectivity: how about using a Pico W and run Wifi with FTP on the second core?

[+batari]

3 hours ago, electrotrains said:

Hi Batari,

Agreed - the pico is a really nice dev platform. I hadn't heard of the picollo - do you have link to your announcement?

 

Regarding the 5v tolerance, I'd read this article and concluded it was worth a go without level shifters - though I should probably have one on the data bus.

 

But the main aim was to make something fun and cheap that people could build themselves even without much soldering experience. Extra components get in the way of that goal. And if they don't last forever, it doesn't matter so much when the parts cost less than five pounds.

 

Robin

 

It was announced and shown on a live streaming video. I can probably find the link with some effort.

 

Basically it's a Melody-like board based on the RP2040 and was designed for cartridge games, but this can also be had with a slot that can act as a module that works with a Harmony cart so its library of games can be expanded, for when people use the power of the RP2040 chip for new games.

 

It's a new board, actually, and uses the RP2040 chip from the Pi Pico rather than an actual Pi Pico board, but the Piccolo can still run microPython and do all of the things a Pi Pico can do.

 

I am sure that any games made for the Piccolo can be ported to this with minor changes (one reason for creating a new board was to be able to use a larger flash chip and an I/O layout with 1-to-1 symmetry with the 2600's address bus.

 

As for level conversion, I am not sure it's a great idea to go without it. Level converters are cheap and abundant and can be found with through hole parts. If someone can solder a Pi Pico, they can solder a few DIP chips as well. I recently bought a reel of level converters for 10 cents each, so at these prices there isn't much reason not to use them.

 

Basically, a typical 3.3v part will have an absolute maximum of around 4.6v. Though it will probably survive for a time at 5v, it may not last. I have done experiments with 3.3v parts in a 5v environment and yes, they don't die right away, but found they lasted about 72 hours of constant use. I haven't done such testing with a Pico, but I do have some examples without level converters I have been meaning to test.

 

[electrotrains]

Batari,

 

It might be worth agreeing to use a certain set of IOs for the address bus and data bus for future compatibility?

I'm using GPIO0 (A0) to GPIO12 (A12) for the address bus, then GPIO13 (D0) to GPIO20 (D7) for the databus.

Does that match what you've used?

 

GPIO21/22 used for PAL60/PAL/NTSC selection for the menu.

ADC pins not used at all.

 

Regarding 5V tolerance, there was a comment from the CEO of Raspberry Pi foundation on Hackaday:

 

Quote

Eben Upton says:

September 25, 2022 at 4:16 pm

Note: the pads themselves are 5V tolerant for input, just not 5V5 tolerant, which is what we’d need them to be to put “5V tolerant” in the data sheet. (Hypothetical) future designs will fix this.

 

Assuming this was him (there has been no official statement to the contrary, despite publicity in the relevant forums) then it looks ok. I'll do more soak testing before sending any out though.

 

Robin

Edited May 24, 2023 by electrotrains
spelling

[+batari]

Mine is GPIO0-12 for the address bus, and GPIO16-23 for the data bus. The reason I did it this way is you can use a byte load/store directly to GPIO16-23. GPIO13-20 will work but this may require a shifting operation, possibly a masking operation as well to access.

Unfortunately, they did not run GPIO23 to a pin. There are points on the board to get GPIO23 on a Pi Pico, I am told, but I am not sure how convenient they are.

 

There are other Pico variants that give you GPIO23, but I don't know which ones offhand.

 

The data bus location may not be a huge deal, as the shifting and/or masking might only add a couple of cycles so I'm not sure it will make or break anything.

 

However, I just realized something important: the level converter on the Piccolo board's data bus uses A12 to automatically control the data bus. Therefore, you don't have to poll A12 and turn off the data bus in code, which can free up a lot of processor time. This is a good reason for using at least one level converter. The level converter is just a standard '245 bus transceiver.

 

GPIO 13, I think, allows you to override the data bus direction on the level converter, but I can't remember offhand. I'll take a look.

 

 

[electrotrains]

Sounds like a nice hardware design, but I guess the lack of GPIO23 on the pico board rules out a common pin scheme. It might be possible to pick it up somewhere, but the pico board itself is on a tiny scale so not very friendly to a normal soldering iron.

[The Mr. Video]

I'm certainly looking forward to this. I've been looking for a cheap multicart solution for a long time.

6 hours ago, electrotrains said:

But the main aim was to make something fun and cheap that people could build themselves even without much soldering experience. Extra components get in the way of that goal. And if they don't last forever, it doesn't matter so much when the parts cost less than five pounds.

Maybe you could make the voltage regulator an optional part for those who want to "bullet-proof" their PicoCart?

[+x=usr(1536)]

5 hours ago, SvOlli said:

For better connectivity: how about using a Pico W and run Wifi with FTP on the second core?

At that point, it may be worth running Samba (or similar).

 

In fact...  Regardless of the network filesystem or transfer protocol chosen, make it switchable.  One press of the button turns <insert network filesystem / transfer protocol here> on; a second press turns it off.  That would make it really easy to boot the machine, copy over whatever it was you wanted to copy, then regain full use of the CPU.

[+SvOlli]

On 5/24/2023 at 12:08 PM, SvOlli said:

For better connectivity: how about using a Pico W and run Wifi with FTP on the second core?

This is something that might have come across the wrong way. May suggestion about FTP was that I try to implement the additional FTP server. (At least if @electrotrains thinks that this should be possible, and would want to merge it, once I've established a stable fork.)

 

On 5/24/2023 at 5:54 PM, x=usr(1536) said:

At that point, it may be worth running Samba (or similar).

 

In fact...  Regardless of the network filesystem or transfer protocol chosen, make it switchable.  [...] then regain full use of the CPU.

About Samba: no. Just no. FTP is a rather simple protocol, easy to implement. Embedded FTP servers are already available as open source code. It took me 10 minutes to find a candidate that's worth trying to integrate. Samba is one hell of a beast that's hard to get right, and I couldn't dig up anything that might run on a Pico.

 

About making it switchable: why? Why do you need a dual core 133MHz CPU to run software to accommodate a game console designed in the 70s which runs at <1% of that clockspeed?

My idea is to let one CPU core handle the 2600 bus and the other one runs the internet connection. The only problem that might arise is that the FTP might slow down filesystem access of the simulation, or that FTP uses too much of the 264k RAM.

 

On 5/24/2023 at 1:07 PM, batari said:

Mine is GPIO0-12 for the address bus, and GPIO16-23 for the data bus. The reason I did it this way is you can use a byte load/store directly to GPIO16-23.

I thought that the PIO State Machine of the Pico was intended for compensating this kind of problems. (Well, one of the use cases.)

[+x=usr(1536)]

4 hours ago, SvOlli said:

About Samba: no. Just no. FTP is a rather simple protocol, easy to implement. Embedded FTP servers are already available as open source code. It took me 10 minutes to find a candidate that's worth trying to integrate. Samba is one hell of a beast that's hard to get right, and I couldn't dig up anything that might run on a Pico.

Why Samba?  Because these days the chances of someone under the age of 30 knowing what FTP is are slim.  But, if that's not what you want to do, it's not what you want to do.  No skin off my back either way.

4 hours ago, SvOlli said:

About making it switchable: why? Why do you need a dual core 133MHz CPU to run software to accommodate a game console designed in the 70s which runs at <1% of that clockspeed?

By that line of reasoning, why bother with ARM CPUs for offload processing on the same platform?  Nobody needs a Harmony or Harmony Encore, right?  No need for Galagon, Mappy, etc., either.

[+batari]

3 hours ago, SvOlli said:

I thought that the PIO State Machine of the Pico was intended for compensating this kind of problems. (Well, one of the use cases.)

Possibly, but a better hardware design from the beginning would eliminate having to use up one of them just for this purpose. Then they could be free for other uses, and certainly they will be used in other instances as there is already a lot of overhead fiddling with GPIO outputs.

[electrotrains]

The ROM emulation on the 2600PicoCart does not use PIO, it uses the same polling techinque used it the original UnoCart2600.

This article (not by me) is worth reading if you want to learn more:

https://github.com/rhulme/picoROM_pio/blob/master/doc/README.md

 

Edited May 26, 2023 by electrotrains