FujiNet for Atari 2600

[tschak909]

It seems enough time  has passed to revisit this, as some new hardware has come to light.

 

For the hardware hackers in this group, what about mating an ESP32 with an RP2040 (RPi Pico) to provide the necessary bus interface/cartridge emulation for a device that would provide two main functions:

* Loading of games via internet

* Playing of multi-player games via internet.

 

Thoughts?

-Thom 

[jeffpiep]

I’m game. Happy to work with anyone else interested. I learned how to use the PIOs and DMA on the PICO as a lookup table much like a ROM. Should be totally doable. Add the ESP32 with the FujiNet interface with external power and this thing becomes usable

on the 2600+ too.

[Thomas Jentzsch]

11 hours ago, tschak909 said:

It seems enough time  has passed to revisit this, as some new hardware has come to light.

 

For the hardware hackers in this group, what about mating an ESP32 with an RP2040 (RPi Pico) to provide the necessary bus interface/cartridge emulation for a device that would provide two main functions:

* Loading of games via internet

* Playing of multi-player games via internet.

Probably I am missing something here, but the PlusCart already covers the first point. And AFAIK for multi-player games, one would need a server. 

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Probably I am missing something here, but the PlusCart already covers the first point.

Second point is covered by PlusROM functions, which are already supported by various emulators and the PlusCart.

 

[tschak909]

The first point is that with FujiNet, games can either be loaded via local SD card storage, or via the Internet, like with the rest of the FujiNet platforms.

 

The second point is that we have an extensive stack of network operations with protocol offloading that can connect to modern Internet end-points, with JSON and XML parsing to boot.

 

And we have a WIN/POSIX port of the emulator to work with emulators.

 

I dunno, seems like a no-brainer to me for FujiNet to come here, but if you guys think you have all this covered, then...

 

-Thom

 

[tschak909]

Oh, and there's this, the Lobby system we've working on, and a game of 5 card stud poker which uses it:

 

 

 

[+Al_Nafuur]

1 hour ago, tschak909 said:

The first point is that with FujiNet, games can either be loaded via local SD card storage, or via the Internet, like with the rest of the FujiNet platforms.

With the PlusCart, games can either be loaded via local flash storage, or via the Internet. Also with the PlusCart Duo games can be loaded via a local SD card (even though I never understood the need for fumbling around with SD cards when we have a webDav based system).

 

1 hour ago, tschak909 said:

The second point is that we have an extensive stack of network operations with protocol offloading that can connect to modern Internet end-points, with JSON and XML parsing to boot.

 

And we have a WIN/POSIX port of the emulator to work with emulators.

 

I dunno, seems like a no-brainer to me for FujiNet to come here, but if you guys think you have all this covered, then...

 

-Thom

 

The idea of the PlusROM functions is to offload the extensive work to the internet back end. So the PlusROM backends can (and should) be used as proxy to the services used.

 

38 minutes ago, tschak909 said:

Oh, and there's this, the Lobby system we've working on, and a game of 5 card stud poker which uses it:

 

 

 

It shouldn't be too difficult to connect a PlusROM and its dedicated backend to your service. However, how to display the information with the TIA is another problem...

 

[tschak909]

5 minutes ago, Al_Nafuur said:

With the PlusCart, games can either be loaded via local flash storage, or via the Internet. Also with the PlusCart Duo games can be loaded via a local SD card (even though I never understood the need for fumbling around with SD cards when we have a webDav based system).

 

The idea of the PlusROM functions is to offload the extensive work to the internet back end. So the PlusROM backends can (and should) be used as proxy to the services used.

 

It shouldn't be too difficult to connect a PlusROM and its dedicated backend to your service. However, how to display the information with the TIA is another problem...

 

Well, if you'd like to join forces, we have a discord, and a lot of battle tested code across multiple platforms :

https://discord.gg/2Ce9guX

 

And our firmware source code is here:

https://github.com/fujiNetWIFI/fujinet-platformio/

 

-Thom

[+ZeroPage Homebrew]

ZeroPage Homebrew has the Exclusive World Premiere of 5 Card Stud PlusROM/FujiNet Client on tomorrow's ZPH stream LIVE on Twitch! Hope you can join us!

 

Fri Apr 5, 2024 | LIVE @ 12PM PT | 3PM ET | 7PM GMT

WATCH LIVE: https://twitch.tv/zeropagehomebrew/

WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• 5 Card Stud PlusROM/FujiNet Client (2024 Exclusive World Premiere | 2600) by Wolfgang Stubig @Al_Nafuur
• ZΔRKSTΔRS V: Stellar (2024 Exclusive World Premiere | 2600) by Leandro Camara @HSW3ET
• Frogger (2024 WIP | 2600) by Philip Blackman @splendidnut

 

[+x=usr(1536)]

FYI: tnfs.online has a huge 2600 library online, built from the Atarimania set.  Just mentioning it in case anyone wants to test TNFS over the Internet.

[tschak909]

Now that the STM32 based PlusCart firmware has been ported to work on the RP2040. Work begins on the Atari2600 #FujiNet board.

The 2040 talks to the ESP32 via the UART. The 2040 acts as the bus interface.

 

-Thom

[+batari]

Thought I would chime in here. First let me say I think it's great that the RP2040 is seeing more love.

 

That being said, I am wondering if you have worked around the reported slow boot times on the RP2040. The time from power on to running the first line of C code is more than 100ms with the default Pico bootloader/SDK. Just curious, does the project include bootloader changes to work around this problem?

 

If so, I want to see them as it will save me some time. If not, it is my plan to figure out a solid workaround for my RP2040-based HEM and other RP2040 cart boards, and I am looking at sending the Atari into a RAM loop with assembly in the first stage bootloader, so then the Pico SDK can take as long as it wants after that setting things up. I can share of course once I get it figured out, if it would help some of these other Pi Pico projects out there.

[gtortone]

Hi @batari, you will find GIT repo of PlusCart-Pico here: 

https://github.com/gtortone/PlusCart-Pico

 

Regarding RP2040 boot time let's take into account two things:

 

1) we are overclocking RP2040 @250MHz at startup with set_sys_clock_khz(250000, true) in main.c

2) flash read/write performances are optimized due usage of "proper" second stage bootlader for W25Q080 flash available on Pico "purple", if you take a look to platformio.ini
    you will find this line:

 

board_build.arduino.earlephilhower.boot2_source = boot2_w25q080_2_padded_checksum.S

 

In practice, during my developments I never had any issues with RP2040 boot time; I tested RP2040 with Atari 2600 Jr (PAL) and Atari 2600 Darth Vader (PAL).

The customization of second stage bootloader was required to read ROMs that cannot be loaded in RAM due to huge size (e.g. 128 KB ROM), but I don't

write the bootloader from scratch because there are a bunch of bootloader available in Pico-SDK to optimize read/write performances for different flash chips...

 

Let me know if you need further details....

 

[+batari]

The race condition between the ARM and console boot has been a long standing challenge with ARM-based carts. I would test on a sixer and a 7800, as these seem to be the most problematic with boot time. These are the consoles where I have seen the worst boot time issues.

 

I don't know what overclocking and optimization of the second stage bootloader will get you over a stock Pi Pico (which takes 130ms), but my estimates put the typical boot time of some consoles at around 25ms, and I'd think you want to beat that by a good margin, which might be hard to do that way.

 

I do still plan to write a custom first stage bootloader, then nobody needs to worry about overclocking or using a special flash chip to try to beat the console to boot.

[gtortone]

Hi @batari I have done some tests with an oscilloscope with a C code that setup a pin (GP5) and make an endless loop moving this pin up and down...

I have used two probes: one on the +5V of RP2040 and the second one on the GP5 - so I put the trigger in single mode on the +5V channel and

disconnect/reconnect the USB power in order to trigger the acquisition.

 

This is the first test with Arduino-Pico library and C/C++ compiler -O3 optimization:

 

 

(we have to measure the time between rise of CH1 and start of toggling of CH2) in this case we have 200ms of boot time

 

As second test I have added to platformio.ini the bootloader optimized for my RP2040 board flash chip...

 

 

boot time now is 100ms... very good but quite far to your requirements....

 

As third test I have removed Arduino-Pico library (that have some Arduino-like initialization for setup() and loop() functions and other stuff...)

and I have used plain Pico-SDK to move GP5 pin. In this test I did not use overclocking or custom bootloader.

 

 

boot time is now 17ms.

 

It is clear that Arduino-Pico is very nice and suitable for C/C++ development, but as usual these frameworks add some overhead

on hardware performances...

 

 

Edited Friday at 09:27 PM by gtortone

[+batari]

Great to hear that, I think you should be good!

 

I will probably still have a custom first stage bootloader for my RP2040-based cartridge boards, but for my HEM project, I think i'll fork from your sources because 17ms sounds like it should work just fine.

[tschak909]

1 minute ago, batari said:

Great to hear that, I think you should be good!

 

I will probably still have a custom first stage bootloader for my RP2040-based cartridge boards, but for my HEM project, I think i'll fork from your sources because 17ms sounds like it should work just fine.

 

-Thom