Raspberry Pi Pico Multicart - 2600PicoCart

[electrotrains]

Finished more cart emulation this afternoon (Pitfall II DPC), so that's it level with the original version of the UnoCart.

 

The ARM M0+ in the pico doesn't have a hardware divide (unlike the M4 in the UnoCart) so I had to revise things a little bit - it wasn't until I looked at the dissassembly that I realised why the 2600 kept crashing.

 

Anyway, with the revised code the music sounds just as good (or bad?) as it does on the UnoCart so that's a success 🙂

[electrotrains]

Hi all,

 

I was just pondering a possible future 2600 pico project...

 

There is already open-source code (Adafruit DVI/HDMI) for driving a HDMI display using 8 pins on the pico.

 

That leaves enough pins (just) on a RP2040 (i.e. custom PCB - not a standard pico) to monitor the 2600 address and data bus.

 

Could you make a cartridge that monitored the 6502 memory access (particularly writes to the various graphics registers) and essentially build a frame on the pico for output via HDMI?

 

I'm thinking of a pass-thru, or maybe mulitcart, that also has a DVI socket for a perfect picture output to modern TVs. Looks like audio could be done too:

https://github.com/mlorenzati/PicoDVI

 

This is the DVI breakout:

https://www.adafruit.com/product/4984

 

Thoughts?

 

Robin

[+x=usr(1536)]

3 hours ago, electrotrains said:

Hi all,

 

I was just pondering a possible future 2600 pico project...

 

There is already open-source code (Adafruit DVI/HDMI) for driving a HDMI display using 8 pins on the pico.

 

That leaves enough pins (just) on a RP2040 (i.e. custom PCB - not a standard pico) to monitor the 2600 address and data bus.

 

Could you make a cartridge that monitored the 6502 memory access (particularly writes to the various graphics registers) and essentially build a frame on the pico for output via HDMI?

 

I'm thinking of a pass-thru, or maybe mulitcart, that also has a DVI socket for a perfect picture output to modern TVs. Looks like audio could be done too:

https://github.com/mlorenzati/PicoDVI

 

This is the DVI breakout:

https://www.adafruit.com/product/4984

 

Thoughts?

 

Robin

If you haven't already, you may want to take a look at the 7800GD.  While not exactly the same as what you're proposing, there are enough similarities there that it might at least be interesting.

 

Other than that, I suppose that you could build a TIA in emulation, intercept activity to/from the one on 2600 itself, and have it direct its output to your output method for framebuffering and display.  If the cycles are there to do it on the Pico, can't see why it wouldn't be possible.  Not that I mean it would be easy, just possible 

[Windless]

Very cool project. I really like the idea of having a sub $10 dev cartridge.

 

I started gathering informations about the possibility to make one on a blue pill while working on my current project, and for almost the same reason than for this other project, I decided that for just a few more cents than a bluepill, this one would be a very nice match (plus the form factor is so nice ) https://fr.aliexpress.com/item/1005005303669884.html.

 

I have one of these pinkish-purple cheap pico clones (actually an exact clone of WeAct Studio's pico nearly-clone) . I can test the pcb on three different SECAM VCS (an older one with NTSC TIA, two with the PAL one). I'd be happy to share the cost.
 

Edited May 29, 2023 by Windless

[Windless]

I also have a question about the warning about not plugin the USB cable when the cartridge is in the console : if you power the rapsberry pico via Vsys an not Vusb, wouldn't you just need a diode on the pcb to prev the USB port from trying to power the VCS when it is switched off ? (anyway, the port should be able to power it ^^)

[electrotrains]

7 hours ago, Windless said:

I also have a question about the warning about not plugin the USB cable when the cartridge is in the console : if you power the rapsberry pico via Vsys an not Vusb, wouldn't you just need a diode on the pcb to prev the USB port from trying to power the VCS when it is switched off ? (anyway, the port should be able to power it ^^)

 

Yes - the use of a schottky diode for this is described in the Pico datasheet, and allows the pico to be powered by both USB or VSYS, and prevents back powering. I left it out to make the project simple to build and opted for a warning on the PCB instead.

 

At the moment, when the pico boots, it looks to see whether it is being powered by VBUS or VSYS, and that determines whether it goes into mass storage mode or 2600 cartridge mode, so there would be no benefit to allowing it to be plugged into USB when acting as a cartridge.

 

Robin

Edited May 30, 2023 by electrotrains

[Windless]

2 minutes ago, electrotrains said:

At the moment, when the pico boots, it looks to see whether it is being powered by VBUS or VSYS, and that determines whether it goes into mass storage mode or 2600 cartridge mode, so there would be no benefit to allowing it to be plugged into USB when acting as a cartridge.

Ok, that definitively explains why.

 

I was thinking of my bluepill based version more as a development cartridge that would be permanently connected to the computer and would only store the data in SRAM, hence having a diode ^^

[waynel]

On 5/25/2023 at 2:15 PM, x=usr(1536) said:

these days the chances of someone under the age of 30 knowing what FTP is are slim

I don't think they're that slim.  My new Brother scanner, and the Epson printer I recently threw out both support FTP.  Both of those companies see value in maintaining FTP as a feature for a reason.

 

Anyone using this device is likely a technology enthusiast, so they're probably heard of or used FTP, and if they haven't this can be a good learning opportunity for them.  No need for ageism.  I certainly don't think the world is overflowing with under-30's who clamor for Samba instead of FTP.

Edited May 31, 2023 by waynel

[+x=usr(1536)]

3 hours ago, waynel said:

I don't think they're that slim.  My new Brother scanner, and the Epson printer I recently threw out both support FTP.  Both of those companies see value in maintaining FTP as a feature for a reason.

Whether or not a device supports a feature has nothing to do with whether or not people even know of its existence, let alone understand it.  But, since we're now here: the main reason that printer companies continue to support FTP comes down to legacy systems and software that still, for utterly incomprehensible reasons, continue to use it with no viable alternatives in place.  This is something that (and I'm speaking from experience here) IT Departments care about, and end users in general just don't.  I've written the no-FTP-because-it's-insecure part of security policies several times over the course of many years in that field, and no end user has ever asked to have it enabled.  Not one, and not even once.

 

It is the sort of thing that will get you a big, fat, sweaty red mark on a third-party security audit, however, unless you can negotiate a specific carve-out for it on a per-case basis by showing need.  Boards of Directors and shareholders don't like seeing red marks on audits.  It makes the company appear to have a lax security posture, and then I, as the <insert title here> of Security, would get to hear about it.  I never liked hearing about big, fat, sweaty red marks on security audits: that was usually an indicator that we'd missed something fundamental, and missing fundamental things is generally bad from a security standpoint, especially when words like, "lawyers," and, "liability," start cropping up in relation to said missed fundamental things.

 

That's largely in the enterprise world, though.  How many Mom & Pop users actually care?  You tell me.  I don't have insight into their home lives as relates to their printers, and, frankly, don't have the slightest bit of interest in the subject.  However, I'll hazard a guess that at least 99.44% of them let Bonjour handle the work of setting up the printer and subsequently transferring data to and from it.  For the other 0.56%, they either a) know what they're doing and can go be happy, successful corner cases living lives of great spiritual fulfillment and satisfaction with their printed materials, or b) don't know what they're doing and hopefully it all somehow works for them so that the one family member who 'knows something about computers' doesn't get another 3-hour call from Aunt Gladys as she struggles to print out nice pictures of kitties.  Either way, not my circus and not my monkeys.

3 hours ago, waynel said:

Anyone using this device is likely a technology enthusiast, so they're probably heard of or used FTP, and if they haven't this can be a good learning opportunity for them.

Fine.  What you're overlooking here is that this part of the discussion was effectively over and done with.  My give-a-damn about FTP vs. Samba has long since left the building and went drinking with Elvis in the back of his limo.

3 hours ago, waynel said:

No need for ageism.

No need for slinging around baseless accusations, either, and I'll save you the trouble of reminding me of my comment regarding people under 30 and FTP: it's based on observation, not some prejudice you have assumed that I harbour.

3 hours ago, waynel said:

I certainly don't think the world is overflowing with under-30's who clamor for Samba instead of FTP.

You have an opinion and that's good!

 

Pro-tip: if you'd like to receive kinder, gentler, packed-with-fuzzy-bunnies-and-rainbows replies to your future replies, don't go around slinging out terms like 'ageism' willy-nilly.  People may not take kindly to it.  Crazy, huh?

[Windless]

Do you plan to release the schematic / pcb / code on github soon ? I think I'll try to order a pcb, adding a diod and maybe test a thinig or two.

[+Yurkie]

On 5/29/2023 at 12:50 PM, electrotrains said:

Hi all,

 

I was just pondering a possible future 2600 pico project...

 

There is already open-source code (Adafruit DVI/HDMI) for driving a HDMI display using 8 pins on the pico.

 

That leaves enough pins (just) on a RP2040 (i.e. custom PCB - not a standard pico) to monitor the 2600 address and data bus.

 

Could you make a cartridge that monitored the 6502 memory access (particularly writes to the various graphics registers) and essentially build a frame on the pico for output via HDMI?

 

I'm thinking of a pass-thru, or maybe mulitcart, that also has a DVI socket for a perfect picture output to modern TVs. Looks like audio could be done too:

https://github.com/mlorenzati/PicoDVI

 

This is the DVI breakout:

https://www.adafruit.com/product/4984

 

Thoughts?

 

Robin

I would love to hear others with skills weigh in on this. And cartridge that is also a RF to HDMI converter!!! I mean HOLY Fu*king shit, think of all the original hardware that won't need modded!

 

 

[Windless]

On 6/3/2023 at 2:54 PM, Yurkie said:

And cartridge that is also a RF to HDMI converter!!! I mean HOLY Fu*king shit, think of all the original hardware that won't need modded!

 

 

You can't do an RF to HDMI converter on the cartridge because the RF signal is not routed to the cartridge. What was suggested is that you could monitor the bus for data sent to the TIA (graphic chip of the 2600) and then emulate the chip to recreate the picture in the cartridge and generate an HDMI signal from that.
Since the TIA is the hardest part to emulate*, I'd rather just completely emulate the 2600, eventually putting an emulator in an original case. But emulating the TIA on a cartridge is still a fun project and if anybody does it - i'll be happy to read the project's log

 

* : the 6502 and RIOT are almost completely known, the TIA is the part that behaves diffferently from version to version and might even change a few out-of-spec behaviour depending on supply voltage or temperture - the other will also but those can't be triggered from 2600 code AFAIK

[KevKelley]

4 hours ago, Windless said:

You can't do an RF to HDMI converter on the cartridge because the RF signal is not routed to the cartridge.

Oh. I know. What I intended on doing was try to power it by the cart so one could plug RF out from the console into the cart and then from the cart to the audio source. Just to reduce cables and make things all-in-one. 
 

Best analogy can think of is the Compumate cart plugging into the cartridge ports. 

[Himeno]

Anything New about it or  where to geht the boards? 

 

Can the 2600 Board be used of the 4mb and 16mb picos or only the 800 Version? 

Edited August 4, 2023 by Himeno

[Zonie]

Not 2600 or even Atari related, but does anyone know of an adapter that you can plug into an SD slot on a device and write to / read from a USB stick? Basically the opposite of what is usually out there. We are looking at making one with an RPi, but if one exists already...

 

Have a device with SD slot only, but want to use USB drive instead. Device does NOT have a USB port.

Edited August 4, 2023 by Zonie

[Windless]

8 hours ago, Zonie said:

Have a device with SD slot only, but want to use USB drive instead. Device does NOT have a USB port.

I'd be happy to discuss this subject if you open another thread, but basically from the read command to the answer, the slowest mode of the physical layer specification lets you 18 cycles at 12.5MHz (1.44µs). The usb Mass Storage Class ("usb key") have not been design for this. Even USB has not been (IIRC, usb 2 is polled every 125µs, usb 3 is a bit better but usb has lot of things to do before starting to get the data you want). With todays cheap and slow 128Go usb key, caching would be very expensive *and* take 20 minutes.
So unless there is a possibility to declare the SD card busy after the command is received and before you answer, the timing will be an issue. And I don't think there is (SD Cards are not meant to be shared between hosts, so the host probably checks for business before sending commands.)

 

Edit : could this sub-discussion be moved to another thread by our ❤️ admins ?)

Edited August 5, 2023 by Windless

[+SvOlli]

On 8/4/2023 at 3:32 AM, Himeno said:

Can the 2600 Board be used of the 4mb and 16mb picos or only the 800 Version?

It's not as much about the size of the flash, but rather the pinout of the board. Educated guess, from what I know about tinkering with different Pico Clones: what's sold as 4MB should typically work, as the differences I encountered so far were about the pins 3V3_EN and VSYS. So those should work.

 

The 16MB boards I bought so far, were using all 30 GPIOs of the RP2040, so those won't work, as adapting the software to the new layout would slow down the handling of the I/O to a point where I just won't work. Nevertheless, if the PCB design is released adapting the "adapter board" to the new pinout should be rather straight forward.

 

On 8/4/2023 at 3:32 AM, Himeno said:

Anything New about it or  where to geht the boards?

As stated in the thread about the Atari 8-bit version of this cart, @electrotrains has some health issues slowing him down at the time. So "gute Besserung" from Germany.

[Windless]

On 8/5/2023 at 1:30 PM, SvOlli said:

adapting the software to the new layout would slow down the handling of the I/O to a point where I just won't work

I *think* (still all buggy) I managed to read the address spread in 3 bits blocks and write the output in 2 blocks on another ports just fast enough on an stm32f401. The rpi pico is 133MHz and, thought I think M0 cores don't have the handy BFI instruction, it seems the "Programmable IO" thing is dedicaded to this kind of translations, it might be able to treat the fifo in a few cycles while the cores can do other things. (the "datasheet" is something inbetween a tutorial and a medium post, I still have a hard time understanding it ^^)

[Himeno]

mmh more news on the 800 version then the 2600 version ;D

[electrotrains]

Hi all, sorry no news on the 2600 version of this cart.

 

Although it works fine on my 2600 Jr, the test devices I sent didn't work on other peoples 2600's, which was unexpected and took the wind out my sails.

 

I suspect it may be because these other 2600's boot more quickly than mine, and the pico hasn't had a chance to fully initialise before the atari starts reading from the cartridge. But that's speculation until I can do more testing with a scope.

 

So, I'll come back to this version when I've finished with the Atari 8-bit version.

 

Robin

 

[Windless]

I still need to reinstall my lab (probably this week-end), but I have some spare rpy picos, a ds1054Z with three probes and two 50hz (secam) 2600 here is you need a few recordings.

[gtortone]

Hi,

I'm available to test or develop code if needed. I also have a Pico and an oscilloscope if this can help !

[gtortone]

On 8/31/2023 at 5:08 PM, electrotrains said:

 

I suspect it may be because these other 2600's boot more quickly than mine, and the pico hasn't had a chance to fully initialise before the atari starts reading from the cartridge. But that's speculation until I can do more testing with a scope.

 

Hi,

I suspect I have this "fast boot" Atari Jr. release... I wrote some code to emulate a simple 2K cartridge on Pico without success,

now I'm waiting for a STM32-Discovery board from a friend to test UltimateCart-2600...

[Dionoid]

On 8/31/2023 at 5:08 PM, electrotrains said:

I suspect it may be because these other 2600's boot more quickly than mine, and the pico hasn't had a chance to fully initialise before the atari starts reading from the cartridge. But that's speculation until I can do more testing with a scope.

Hi, I found this discussion on asserting the Pico's GPIO pins very early on startup. Maybe the proposed solution can help you?

https://github.com/raspberrypi/pico-sdk/issues/959#issue-1327789697

[+rbairos]

From what I recall,  modded Flashback 2 starts polling data around 2 msec, and a heavy sixer 25 msec.