Jump to content
IGNORED

FujiNet for Atari 2600


Recommended Posts

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 

  • Like 4
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

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

 

  • Like 1
Link to comment
Share on other sites

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:

New Era of Gaming: FujiNet Game Server - FujiNet

 

New Era of Gaming: FujiNet Game Server – AtariOrbit and 6502 Fun

 

:)

 

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...

 

  • Like 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

  • 2 months later...

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!

 

Games:

 

  • Like 3
Link to comment
Share on other sites

  • 2 months later...

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

2600_pcb_rear.png

2600_schem.jpg

2600_pcb_front.png

  • Like 2
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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....

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

 

DS1Z_QuickPrint1.thumb.png.a2bb6b44da2070fca5742439b294c69b.png

 

(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...

 

DS1Z_QuickPrint2.thumb.png.b33e5f624846ce6e45b86d709e4586f7.png

 

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.

 

DS1Z_QuickPrint5.thumb.png.a6fb65c14ff4ba119f1cd9a8663a5619.png

 

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 by gtortone
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

The A Team 80S GIF

 

-Thom

Link to comment
Share on other sites

Yes, but take into account that current PlusCart-Pico uses Arduino-Pico libraries due to some Arduino library dependencies for ESP8266 (WiFi) and FAT filesystem, but

for future Atari-2600 FujiNet code I'm considering the idea to use plain Pico-SDK to make the project minimal.

Link to comment
Share on other sites

  • 2 weeks later...

@mozzwald just got back the first prototype PCBs for the #Atari2600 version of #FujiNet. This PCB has sockets for both an #ESP32 dev-board, and an #RP2040, along with an indentation for the internal antenna, SD card socket, and buttons. #retrocomputing #retrogaming

2600fuji_rear.thumb.jpg.967fe23dd0c317a3d9373ed25224a1e8.jpg

2600fuji_front.thumb.jpg.775f84b5a01a244bbf1d7b2b56f8517f.jpg

-Thom

  • Like 1
Link to comment
Share on other sites

Great news!

 

I think I will open-source the HEM project to be able to use some of the same sources as this project. No reason to reinvent the wheel here.

 

A question - is it necessary to use the full ESP32 dev board, or could the simpler ESP8266 work?

Link to comment
Share on other sites

36 minutes ago, batari said:

Great news!

 

I think I will open-source the HEM project to be able to use some of the same sources as this project. No reason to reinvent the wheel here.

 

A question - is it necessary to use the full ESP32 dev board, or could the simpler ESP8266 work?

No. Our firmware needs the extra muscle afforded in the ESP32.

 

-Thom

Link to comment
Share on other sites

On 7/13/2024 at 3:40 PM, tschak909 said:

No. Our firmware needs the extra muscle afforded in the ESP32.

 

-Thom

First, glad to see the board is working.

 

So, from the schematic above it looks like the extra muscle is to drive the SD card? So if the SD card was not used, could a version with the 8-pin ESP8266 work (in theory?)

Link to comment
Share on other sites

Posted (edited)

No. We use the extra CPU muscle and RAM to drive a very well abstracted network devices, with lots of protocol adapters and channel modes like a JSON and XML parser. A complete PDF rasterizer is also present for printer emulation.

 

I would suggest looking at our codebase. 

https://github.com/FujiNetWIFI/fujinet-firmware

Edited by tschak909
Link to comment
Share on other sites

  • 3 weeks later...

#FujiNet for #Atari2600 Status. Gennaro Tortone ported the #PlusCart Firmware to the RP2040.

Now we change the PlusCart code to do SIO calls to the ESP32 Firmware stack, instead of the ESP AT firmware. This exposes our network stack to the #RP2040.

 

#retrocomputing #retrogaming

 

pluscart_fujinet_hybrid.jpg

pluscart-fujinet.png

  • Like 2
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   0 members

    • No registered users viewing this page.
×
×
  • Create New...