flash cart DIY 2600+ flash cart with a Raspberry Pico

[tihmstar]

Oh sorry, didn't realize they were in the repo!

 

Sounds like i should try the *2 parts.
The file `Otaku Flash Top2.stl` looks the same as `Otaku Flash Cart Cover.stl` is that intended?

[N0mi]

On 1/10/2024 at 7:24 PM, wongojack said:

Cool thread.  This is what makes AtariAge awesome

I absolutely agree! I read through all the pages and absolutely enjoyed it. 😃

Unfortunately, I completely lack the required technical knowledge and skill to build something like that myself, so I wonder how people like me will be able to get one of those brillant builds? 

[tihmstar]

7 hours ago, N0mi said:

Unfortunately, I completely lack the required technical knowledge and skill to build something like that myself, so I wonder how people like me will be able to get one of those brillant builds? 

I was planning to rewrite the software for otaku-flash to make it a real multicart with rom selection. 

Assuming that goes well, i can consider making it a fully assembled build (which would be software compatible with the DIY thing). Is that something people would be interested in?

 

Speaking of rom selection menu. If my ideas of the software go well, would there be anyone here that could code a rom selection menu for atari?

I took a look at how the "racing the beam" works, but don't really feel like going down the rabbit hole tbh. 

[N0mi]

Having a Multicart with a rom selection feature would be awesome!

I hope you will be able to alter the code accordingly.

[+karri]

I am not so sure about it. If you want to use it on a 2600+ then the menu won't work.

 

The RAM on a Pico is also too small to even hold one modern 7800 game. The limit is around 128k that I have been able to run.

[tihmstar]

47 minutes ago, karri said:

I am not so sure about it. If you want to use it on a 2600+ then the menu won't work.

 

The RAM on a Pico is also too small to even hold one modern 7800 game. The limit is around 128k that I have been able to run.

 

Worry not, i'm sure it's possible

 

Though, what is your concern about the 2600+? I don't really know my Atari stuff, nor do i know the 2600+, but if normal games work there, why wouldn't a homebrew that displays text?

 

Ram on pico is not an issue, you can have it load from flash directly if you really need it. Checkout this project doing exactly that for a gameboy flashcart (https://github.com/shilga/rp2040-gameboy-cartridge-firmware).

 

Though to be fair, i'm personally not really interested in the 7800 and was planning to server the games from ram for convenience, as i also wanted to support cartridges with external ram.

 

Maybe if you *really* want 7800 support, i could try coding the flashcart such that roms are loaded from flash. But even if i do that someone would need to pick up the project and adjust it for the 7800 as i have no intention to do so (because i don't have the hardware and also don't really care personally).

 

First i will work on serving the data from ram though and try fixing the "slow boot" problem. Once that's done we'll see what's up next.

 

For the slow boot i have 2 ideas.

The first ist to race the atari, by writing some pico assembly code which sets up GPIO super early in the boot to hold the atari CPU in a busyloop (something similar to `b .`) by emiiting one magic opcode.
Then when the pico fully booted, release that busyloop and run the software.

My other idea is to catch the atari from an undefined state assuming the CPU doesn't halt itself meanwhile.

The assumption is that the CPU keeps executing random garbadge, so at some point it will fetch an instruction from ROM. If that happens i just server a $00 (BRK) opcode, which causes the CPU to read a ptr fom 0xFFFE and jump there.

From there the menu (which needs to be coded at some point anyways) needs to clean up whatever mess the undefined execution of the CPU did until then, bring the system in a clean state and show the list of roms.

 

Basically keep writing $00 (BRK) on the bus untill you detect that this was an instruction fetch which the CPU executed (because the next addr on the bus if 0x1FE and 0x1FF). Then once we confirmed we actually caught the CPU, emit another $00 (BRK), but now serve the real entrypoint of the rom that we load (later this should be the rom selection menu software).

 

What are your thoughts on these approaches? Anything i need to know as a non-Atari guy?

 

Worst case if i can't fix this in software maybe we can add a capacitor to the cart so that we boot the atari, charge the capacitor, then power cycle the atari with the pico still booted.

[N0mi]

@astroguy suggested using a Pico W, would this (or an comparable better device) provide a solution?

I understand enabling WiFi causes him problems, could the use of dip switches be an alternative in order to achieve rom selection on the 2600+? 

[+karri]

1 hour ago, tihmstar said:

what is your concern about the 2600+

The 2600+ dumps the cart and transfers the code to the internal CPU for execution. There is no way for the CPU to access the cart after that. So if there is a menu you will be able to run it. But if the menu tries to load in the game from the cart it does not have the means to do it.

 

Another thing is that the 2600 can run most of the code from the flash. But there is some bankswitching schemes where the flas is too slow and you have to run it from Pico's RAM. There is also at least one scheme where even running at 400MHz from RAM is too slow.

 

So the Pico is a fun experiment. But it is not as good as a dedicated multicart.

[tihmstar]

36 minutes ago, karri said:

The 2600+ dumps the cart and transfers the code to the internal CPU for execution. There is no way for the CPU to access the cart after that. So if there is a menu you will be able to run it. But if the menu tries to load in the game from the cart it does not have the means to do it.

I see, so that will be out of scope then.
Though maybe some clever hacks are still possible. I.e. you could select the rom, then reset the 2600+ with the pico still remembering the selected rom (i.e. either capacitor, or ".noinit" ram variable).

 

36 minutes ago, karri said:

Another thing is that the 2600 can run most of the code from the flash. But there is some bankswitching schemes where the flas is too slow and you have to run it from Pico's RAM. There is also at least one scheme where even running at 400MHz from RAM is too slow.

I'll try it anyways. For reference, do you have a few examples of such "fun" roms, so i can test once i get there?

[N0mi]

1 hour ago, tihmstar said:

I see, so that will be out of scope then.
Though maybe some clever hacks are still possible. I.e. you could select the rom, then reset the 2600+ with the pico still remembering the selected rom (i.e. either capacitor, or ".noinit" ram variable).

I guess any method of pre-selecting the rom would do the trick, whatever the appoach might be. 

[tihmstar]

So i've starting writing my own Atari 2600 flashcart software, which is compatible with Otaku-flash hardware.

I want it to work on original Atari 2600 hardware, but don't really care about the 2600+ emulator.
I assume it could run on 7800 in future, but i don't really plan on working on that.

 

I managed to solve the powerbank bootup issue by performing what i call a "boot dance", where i catch the CPU from undefined state and then redirect it to the reset vector of the target rom.
Successrate isn't exactly 100% but very close to that. If it doesn't work first try (which it usually does), just power off and on the console and it usually works second try.

One side-effect of this bootdance is that the system is still in an undefined state once the dance is done. The only thing the dance provides is code execution redirection to the reset vector, but other than that there are no guarantees.

Things like CPU flags need to be cleaned up and any hardware "configuration" possibly caused by random writes need to be reset into a good state. Ideally the first piece of code that runs should bring the system into a well-defined state (not sure how much is defined anyways).

 

So now that the initial PoC works, is here anyone who wants to write a rom selection menu? I provide functions to the pico to see the address bus and potential writes to it, so whatever interface works best for the rom selection menu can be used.

Ideally the rom selection menu should bring the system into a defined state, not use banking and be able to later redirect execution to the target rom. Also, reading the rom titles should ideally not be done by a "serial" on a single address, but preferably on a range of addresses as that is more resistent to timing issue.

 

If you want to experiment yourself you can find the current WIP code here: https://github.com/tihmstar/Otakutachi

Just generate the rom.c with karri's python script, then paste `rom_contents` into `include/rom.h`.

I tested the following 3 games and all of them booted at least.

 

(shasum)

ce7580059e8b41cb4a1e734c9b35ce3774bf777a  Combat ~ Tank-Plus (USA).a26 (no bank switching)

1ffe89d79d55adabc0916b95cc37e18619ef7830  Video Olympics - Pong Sports (USA).a26 (no bank switching)

d68937e57a367e61eaa4b44550ae8b9d69456661  Asteroids.A26 (F8 bankswitching)

 

Combat seems to work fine with Otaku-flash as well as Otakutachi.

Pong didn't seem to work correctly with either. I could load and run the game, but player 2 bar was missing and i couldn't control player 1 bar myself. Maybe i'm misunderstanding something, but i couldn't figure it out 😕

Asteroids works correctly on Otaku-flash, but has some issue on Otakutachi. The asteroids randomly jump across the screen and when starting a game the player starts at the very top of the screen. Trying to move around often causes the game to crash.

I'm wondering whether my bankswitching isn't quite right. Maybe it's switching too late? I don't think it is too early, or is it? Either way, i assume something about the bankswitching is off, since Combat seem to run fine. But then again, Pong didn't work on either 😕

 

Maybe a custom rom can help debug (bank switching) timing issues?

 

Contributions are welcome.

Cheers!

 

[CPUWIZ]

On 5/10/2024 at 4:28 AM, karri said:

The 2600+ dumps the cart and transfers the code to the internal CPU for execution. There is no way for the CPU to access the cart after that. So if there is a menu you will be able to run it. But if the menu tries to load in the game from the cart it does not have the means to do it.

 

Another thing is that the 2600 can run most of the code from the flash. But there is some bankswitching schemes where the flas is too slow and you have to run it from Pico's RAM. There is also at least one scheme where even running at 400MHz from RAM is too slow.

 

So the Pico is a fun experiment. But it is not as good as a dedicated multicart.

 

It's not that hard to make a multicart with a menu, think about it some more. . I am not giving it away.  

[tihmstar]

Update: i fixed the bankswitching issue. it turned out to be a bank switching synchronisation issue with a simple fix.

 

Next up rom selection menu. Please someone write this for me 🥲