2600 Flash Cart / Multi-Cart Comparison Matrix

[+splendidnut]

11 minutes ago, Al_Nafuur said:

@JetSetIlly is making a very very huge effort to emulate the custom code of DPC+ and CDFJ ROMs (but not the drivers) in gopher2600.

Yikes, he's attempting to emulate the custom code itself... and NOT running things via ARM emulation.... that seems a bit ridiculous.  Is that even true?

 

 

[JetSetIlly]

10 minutes ago, splendidnut said:

Yikes, he's attempting to emulate the custom code itself... and NOT running things via ARM emulation.... that seems a bit ridiculous.  Is that even true?

 

Yes. It's the only way for the recent ROMs by @MarcoJ and @ZackAttack to run without hardware. I agree, it does seem ridiculous 🙂 but I'm having fun and it's not far from working.

 

Edit: On reflection, we might be talking at cross purposes. It is ARM emulation (Thumb-2 instruction too if necessary). But those recent ROMs I mentioned are completely custom ARM programs and use the ARMs GPIO to communicate with the 2600 half of the system. There's very little room for optimisation by implementing the driver in native code, like we do now with CDFJ+ etc.

 

Edited January 25, 2023 by JetSetIlly

[+splendidnut]

The following is my understanding of the compatibility problem between the PlusCart/UnoCart and the Harmony Cart.

The issue with the hardware itself is that the microcontrollers have different memory maps and run at different speeds.... but they have relatively compatible ARM chips (same gen?).

 

Unless someone makes a memory address patching program, the easiest way to solve the hardware issue is to have developers recompile their code and target the two different microcontrollers indiviudally.  Seems logical to me.  I'm going to go out on a limb and say that developers would be willing to do this.  Speaking for myself, I would be fine with doing that as long as it's relatively painless.

 

So that just leaves solving the main pieces missing in the DPC+ driver.  I believe the following is missing from the DPC+ support in the PlusCart/Unocart:

  - 3 channel music

  - ability to call custom ARM code, and return from it.

 

Solving those would breakdown the barriers with DPC+, and also open up the door to creating CDF/CDFJ/CDFJ+ drivers that can run on the Pluscart/Unocart.

 

Is my understanding correct?  Or is there something I'm missing?

[Thomas Jentzsch]

2 minutes ago, splendidnut said:

So that just leaves solving the main pieces missing in the DPC+ driver.  I believe the following is missing from the DPC+ support in the PlusCart/Unocart:

  - 3 channel music

  - ability to call custom ARM code, and return from it.

Maybe I am missing something here. But AFAIK Stella is emulating all these, so it should be possible to implement Stella's code for the PlusCart too. Same for CDF(J)(+).

[+johnnywc]

4 minutes ago, splendidnut said:

Unless someone makes a memory address patching program, the easiest way to solve the hardware issue is to have developers recompile their code and target the two different microcontrollers indiviudally.  Seems logical to me.  I'm going to go out on a limb and say that developers would be willing to do this.

+1 I would be more than willing to compile my Champ Games to target the Plus/Uno carts!   

[+splendidnut]

2 minutes ago, Thomas Jentzsch said:

Maybe I am missing something here. But AFAIK Stella is emulating all these, so it should be possible to implement Stella's code for the PlusCart too. Same for CDF(J)(+).

Yes.  If my understanding is correct, I believe the "call custom ARM code" is the key barrier.  The audio generation routine is also a tricky bit... but the PlusCart/Unocart's run faster, so probably alleviate the time constraint issues here. 

 

---

 

The PlusCart/Unocart essentially need versions of the DPC+/CDF(J)(+) drivers.  Once those are created, they can be made available to @johnnywc and others to use when recompiling their code.

 

 

As I said before... @Al_Nafuur can try to reach out to @batari.  I believe there are quite a few other people around with knowledge to make this happen.  But it's probably best to touch base with @batari first.

[Thomas Jentzsch]

44 minutes ago, splendidnut said:

Yes.  If my understanding is correct, I believe the "call custom ARM code" is the key barrier. 

But why? Stella doesn't know that code too. Everything is in the source code.

44 minutes ago, splendidnut said:

The PlusCart/Unocart essentially need versions of the DPC+/CDF(J)(+) drivers. 

Again, why?

[+splendidnut]

Just now, Thomas Jentzsch said:

But why? Stella doesn't know that code too. Everything is in the source code.

The hardware needs the 6507 fed with NOPs (0xEA latched on the data bus) while custom ARM code is running, and then a JMP abs needs to be injected to return control to the 6507 when the custom ARM code is done running.  The ARM drivers for DPC+/CDFJ handle this. So....

 

2 minutes ago, Thomas Jentzsch said:

Again, why?

Incompatible memory maps due to using different microcontrollers.  The audio driver may or may not require more intricate changes due to differences between the microcontrollers.

 

Those items would require the DPC+/CDF(J)(+) drivers to be patched and any custom ARM code to be recompiled.

 

Or someone could write an ARM code address relocater that would fix all the address issues (both in the drivers and all the games).  I believe this has all have been discussed before but I'm not sure where that all ended up.

[Thomas Jentzsch]

37 minutes ago, splendidnut said:

The hardware needs the 6507 fed with NOPs (0xEA latched on the data bus) while custom ARM code is running, and then a JMP abs needs to be injected to return control to the 6507 when the custom ARM code is done running.  The ARM drivers for DPC+/CDFJ handle this. So....

I see. Thanks!

37 minutes ago, splendidnut said:

Incompatible memory maps due to using different microcontrollers.  The audio driver may or may not require more intricate changes due to differences between the microcontrollers.

 

Those items would require the DPC+/CDF(J)(+) drivers to be patched and any custom ARM code to be recompiled.

 

Or someone could write an ARM code address relocater that would fix all the address issues (both in the drivers and all the games).  I believe this has all have been discussed before but I'm not sure where that all ended up.

Early 2018 @DirtyHairy successfully patched SF2, Space Rocks and Space Cactus Canyon to work with a PlusCart. All DPC+ games.

 

The STM RAM is at 0x20000000 and LPC at 0x40000000. This means every 4 bytes sequence aligned to 4 bytes which ends with 00 40 is most likely a RAM address which must be patched. So at least DPC+ is pretty feasible (or close).

[+splendidnut]

Ah, finally found the link to that:

 

 

[+johnnywc]

2 minutes ago, splendidnut said:

Ah, finally found the link to that:

 

 

Wow, posted on my birthday too!   Must be a good sign...   

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Early 2018 @DirtyHairy successfully patched SF2, Space Rocks and Space Cactus Canyon to work with a PlusCart. All DPC+ games.

2018 PlusCart 🤔

 

Must have been the UnoCart, but I have never seen a DPC+ driver in the UnoCart code. Did he also patched the Harmony driver?

[+splendidnut]

Just now, Al_Nafuur said:

Must have been the UnoCart, but I have never seen a DPC+ driver in the UnoCart code.

Yeah, it's in the UnoCart thread where he talks about it.  It appears he didn't release anything publicly.

 

I might play around with this in the near future...

[+batari]

I could probably write DPC+ and CDFJ drivers for the PlusCart in a few days.

 

However, I am not convinced about the UNOCart. I never was, really. When we came up with Harmony, we came up with Melody first, and took a very careful look at chip selection to ensure that Melody boards could be affordably made for AtariAge. When we made Harmony, we could have just slapped a bigger, faster ARM on it and called it a day, with no consideration about the economics of a cartridge board. But that wasn't the point - an advanced cartridge board, available inexpensively for AtariAge to publish games, was the primary goal. Melody came first, and Harmony arose from Melody. Not the other way around.

 

I invested my own money in Melody, upwards of $20k for the first big run. I continue to invest in it at no profit or a loss, but it's OK as Harmony carts make up for that. Runs of Melody require huge cash outlays. So... what would happen if I support the UNOCart? Would this threaten or destroy my ability to offer cartridge boards at cost, or a loss, to AtariAge? While I have freely given my time in the past and can continue to do so, freely giving away my money is not really sustainable. I'm not wealthy and have to be careful with money these days, in this economy. And I am not getting any younger, have kids in college and have to think of retirement someday.

 

As said, no such consideration for the hobby was done for UNOCart with its costly STM32F4 chip when it was created. And now years later, there is still no STM32F4 cartridge board available to AtariAge at all, whether at cost or even for profit. Nobody seems to believe enough in investing their own hard-earned money into cartridge boards for the benefit of the hobby.

 

Partly, it could be because it's open source. If it is closed source, at least you have some reassurance that someone else won't undercut you right after you outlay 5 figures of your own money. With open source, sometimes it isn't enough to give a design away with the hope that "someone else" will realize it for you. Particularly, if the piece you want "someone else" to do requires a huge capital investment and you know ahead of time that no profit will be made.

 

Flashcarts are profitable. Cartridge boards are not profitable, and producing cartridge boards is NOT cheap, even with economical parts. If you want it done you have to do it yourself.

 

And so another major factor is because STM32F4 boards would be so expensive. The STM32F4 is far from a cheap part. Nobody gave the part cost any thought ahead of time as we so carefully did for Melody/Harmony. You can get them cheaper from sketchy Chinese sellers than from reputable suppliers, but that carries a big risk for many reasons.

 

So, there's more.

 

When I released Harmony in 2009, I got some PMs from others who were worried about what it might do to the hobby.

 

Why? The 2600 homebrew community is, in its essence, a collective. That is why I love it so much. Most of us generally do things here for the greater good, the benefit of the whole. I don't think the hobby is really about individuals seeking a payday. It shouldn't be purely about the capital.

 

I mean, nobody's perfect and the situation isn't ideal, and some capital is necessary to sustain it as this hobby is not free, particularly the hardware side. But money should never be the primary motivator.

 

So when Harmony was released, these PMs showed concern about its effect on the homebrew community. Their concerns brought the tragedy of the commons to mind. This refers to a situation in which individual players act independently according to their own self-interest and not necessarily toward the common good of the collective.

 

I think that net/net, flashcarts do not appreciably add to the homebrew scene. At best they are neutral but they can be a net negative. I always knew this. This is why I do so many other things besides selling flashcarts. Aside from Melody boards, there's a lot of things I do that are silent. I haven't worked on bB for a while, but regardless, now basically all of the cartridge boards currently in use for 2600 and 7800 AtariAge games are from me. And a lot of the Jaguar boards too, and a Colecovision board, a 5200 board, and so on. I charge AtariAge exactly zero dollars for my design work, and I don't take any profit or royalties for the boards themselves.

 

The profits I do get from Harmony carts - which I will add isn't much anymore as Harmony carts are now $39 - well, it funds all of these other things I do here, such as the things that lose money or require massive cash outlays. In all, I don't make jack-squat doing this. I would be a lot better off financially if I quit the scene and spent an equivalent amount of time flipping burgers. But of course the work here is more satisfying than flipping burgers. Many of us work for little more than the satisfaction of a job well done.

 

So I explained this all to those who had concerns about Harmony, and it seemed to satisfy the concerns. Hopefully it makes sense to you all as well.

 

OK, back to the PlusCart. I am impressed by Al-Nafuur’s accomplishments both in his commitment to its development and in making affordable PlusCarts available when he can. PlusCart is one the best things you can get for the Atari 2600. If only the PlusCart existed, I would totally support that and add DPC+ and CDFJ to it, and it would have been done years ago. PlusCart does offer something new and different and is not just another flashcart. It absolutely adds to the scene. I am behind that sort of thing for sure.

 

But, the problem I have with the UNOCart, aside from the obvious fact that nobody really had any realistic thought about its suitability for supporting homebrews on a cartridge board when it was created? Well, nothing against the creator, but let's be honest, the creator had zero involvement in the 2600 scene before creating the UNOcart, and has had zero involvement in the 2600 homebrew community since then. The UNOcart’s main distributor has barely any footprint in the 2600 realm except for this cart. I think the only other thing 2600-related they do is license someone else's video mod for various Atari consoles that happens to also work on the 2600. Both the creator and distributor are active in the Atari 8-bit scene, not the 2600. Neither are out to improve the 2600 homebrew scene and now basically just exist to make money while only offering yet another vehicle to play the same games we can already play.

 

In other words, it brings about the same issues with the tragedy of the commons ... all without appreciably giving back to the community. Maybe this is a controversial opinion, but I would think not entirely.

 

As for cartridge boards - if someone put their own money down on a huge run of STM32F4 boards and offered them at cost to AtariAge, I would be behind it. But nobody has and I am sure nobody will. There's been talk but at the end of the day, the STM32F4 is still a rather expensive chip.

 

The main distributor of the UNOCart only offered STM32F4 cartridge boards if they get to publish the games themselves - and rake in the profits, obviously. Nothing wrong with publishing games, but I'd strongly prefer to support AtariAge or even support indie authors doing their own runs, and not a competing third party. Not to mention, I have serious doubts they would even care to match the quality and presentation of AtariAge - I mean, the UNOCart uses a rough 3D-printed shell with kind of a crappy label. It's acceptable for what it is, but don't we expect far better than that for homebrews? This isn't 2001 Hozer days anymore. I am always 100% behind AtariAge above any other publisher anyway, for reasons I don't even need to mention.

 

As I said, the PlusCart, pardon the pun, is definitely a positive contribution to the community. The cartridge board problem doesn't matter because Al Nafuur sells PlusCarts himself and it's easy to recognize his tireless efforts and of others involved. PlusCart offers something new and different that you can't find anywhere else. Most everyone involved with the PlusCart have the right kinds of intentions and motivations toward the 2600 homebrew community and that is what really matters here, I think.

 

Now, is there a way to write drivers that work on the PlusCart but not the UNOCart? I don't think so as the two seem inextricably linked, but if there was an obvious way I would have done it years ago.

 

So how could I go forward? Well, I have given thought to selling UNOCarts myself. There is no reason I couldn't. GPL allows that. I wouldn't be doing it to steal from anyone. My intent would be to give back to the community in the way the others who profit off of the cart don't seem to care to. I wonder how people would feel about that. People were up in arms about the Brazilian outfits making PlusCarts, but I think eventually they came to terms with the fact that the GPL literally allows this.

 

So why couldn't I? That way, if people would begin to buy them from me, I would be able to use the funds to finance the STM32F4 cartridge boards that nobody else wanted to, and I could then offer them to AtariAge at cost like I do with Melody boards. So then, finally, anyone creating a game for the platform could get it published at AtariAge if they wanted to. And of course - since it's open source, designs would be shared. That scenario would certainly help me battle my own conscience enough to write the DPC+ and CDFJ drivers for UNO - which I would do in Thumb2 assembly language, not C, to ensure they would actually work - because I understand that there have been timing issues with the C code in some cases, and I would want to get past that.

 

Certainly, the stuff they are doing with the STM32F4 is cool. I am glad they implemented the solution to bus stuffing that we have yet to add to the original BUS driver for Melody. Even if a cartridge board is going to be far from cheap and likely difficult to keep in production, it would be nice to see one regardless and nobody else is going to step up, put their money where their mouth is and offer it to AtariAge at cost, I am sure.

 

At the same time, though, I should mention something else. Before the UNOCart even existed, Chris Walton and I had a discussion about a better Melody board and we thought a dual-core ARM chip was the answer. One core handles the display and the other is free to be a coprocessor for 100% of the frame (not 20%.) Potentially this offers a 500% increase in performance. The STM32F4 is single core and therefore is still subject to the 20% limitation (which is another reason why some actual thought into chip selection would have been nice.)

 

And guess what, a dual-core Melody-like board is already a reality. I already have a cartridge board ready and a small run on hand that is based on the RP2040 (the chip from the Pi Pico). It's called the Piccolo board. The chip has 264k of RAM and nominally 2MB but up to 16 MB of flash for program code, and runs at 133 Mhz. The best part is that the RP2040 is actually very affordable and thus far more suitable for a cartridge board than the expensive STM32F4. These boards and thousands of RP2040 chips are already in my possession and ready to go as soon as anyone needs them.

 

I have two reels, each with 3400 RP2040 chips. Should be enough for a lifetime, maybe? Because, I believe you should make cartridge boards first, and not try to work backwards from something else. I believe in the economical, dual-core RP2040 much more strongly than I could in any expensive single-core ARM, and I would think the reasons should be obvious to anyone who has spent any time writing ARM-based bankswitch code.

 

Now... could these new STM32F4 schemes be ported to the Piccolo board? I don't know, but to be perfectly frank, if that were possible, I think it's worth doing rather than making an expensive cartridge board based on the STM32F4. Of course I still need to finance a larger run of these boards using these chips, so hopefully there is a way I can raise the funds...

 

[+Andrew Davie]

44 minutes ago, batari said:

So how could I go forward? Well, I have given thought to selling UNOCarts myself. There is no reason I couldn't. GPL allows that. I wouldn't be doing it to steal from anyone. My intent would be to give back to the community in the way the others who profit off of the cart don't seem to care to. I wonder how people would feel about that. People were up in arms about the Brazilian outfits making PlusCarts, but I think eventually they came to terms with the fact that the GPL literally allows this.

 

My own difficulty with the Brazillian outfit was not about them making/selling PlusCarts. It was about them not distributing their modified board which had the surface-mount ARM instead of the huge development board that PlusCart currently uses. I thought it a great move forward, and considering their work was entirely derived from the work that @Al_Nafuur, and to a lesser extent I myself, did on the PlusCart... I felt that under the GPL or whatever licensing or moral obligation they had, especially as they were relying on the online infrastructure for their own sales/carts to actually work... the very least I would have expected would be fore them to contribute to the community and release the design of their surface-mount board.  They were asked. They promised. They did not do it.

 

So it was not a matter for me of "coming to terms with the fact that GPL literally allows this".  It was somebody not meeting their obligations under the licensing (as I understand it) but even more importantly to the community which they are profiting off.

 

 

[Thomas Jentzsch]

8 hours ago, batari said:

And guess what, a dual-core Melody-like board is already a reality. I already have a cartridge board ready and a small run on hand that is based on the RP2040 (the chip from the Pi Pico). It's called the Piccolo board. The chip has 264k of RAM and nominally 2MB but up to 16 MB of flash for program code, and runs at 133 Mhz. The best part is that the RP2040 is actually very affordable and thus far more suitable for a cartridge board than the expensive STM32F4. These boards and thousands of RP2040 chips are already in my possession and ready to go as soon as anyone needs them.

That sounds really interesting. But is there an option to add WiFi and make it compatible with the PlusCart backend? Not for another flash cart, but for published games.

[+batari]

1 hour ago, Thomas Jentzsch said:

That sounds really interesting. But is there an option to add WiFi and make it compatible with the PlusCart backend? Not for another flash cart, but for published games.

Yes, there should be a free serial port to add a Wifi board like the Pluscart uses. I believe that is how it connects? There are also a few spare GPIOs, I believe. The board has a header on it - I will check to see if I added the appropriate signals.

 

[+MarcoJ]

15 hours ago, JetSetIlly said:

Yes. It's the only way for the recent ROMs by @MarcoJ and @ZackAttack to run without hardware. I agree, it does seem ridiculous 🙂 but I'm having fun and it's not far from working.

I've been able to use Gopher to run my ACE game in a kind of developer mode. It is running at a fraction of the speed of real hardware due to single threaded CPU speed limitation. In the future we may get to real time as processors get faster. It is useful to allow inspection and trapping of c code to understanding some conventional types of game bugs during development. The ability to abstract the ARM code into c code is amazing, something I would have never expected would work. In the past I had been solely testing my ACE games using a PlusCart and console, and debugging using silly things like changing the screen colour, playing sounds or crashing the system with a c goto loop. The development of Gopher for this kind of development debugging exercise is certainly useful in the short term for debugging and could lead to future real time emulation possibilities.

 

13 hours ago, splendidnut said:

The hardware needs the 6507 fed with NOPs (0xEA latched on the data bus) while custom ARM code is running, and then a JMP abs needs to be injected to return control to the 6507 when the custom ARM code is done running.

Oh wow, is that how it works ,neat. I took a different approach with my ACE game engine; a small program running in RIOT ram suspends the 2600 into a loop while bulk ARM code is being run on the PlusCart. Then, once the bulk ARM code execution finishes, the RIOT programs waits for the signal from the PlusCart chip to return to conventional processor execution past 0x1000.

 

10 hours ago, batari said:

And guess what, a dual-core Melody-like board is already a reality.

This is going to be awesome.

 

 

 

[+Andrew Davie]

5 minutes ago, MarcoJ said:

Oh wow, is that how it works ,neat. I took a different approach with my ACE game engine; a small program running in RIOT ram suspends the 2600 into a loop while bulk ARM code is being run on the PlusCart. Then, once the bulk ARM code execution finishes, the RIOT programs waits for the signal from the PlusCart chip to return to conventional processor execution past 0x1000.

 

It is very clever, but also a limitation - because the PC is still incrementing - and you rely on not hitting a memory location which places something on the BUS which effectively crashes your program.  That is, you need to position the EA-wait trigger early in the codespace so that when it "virtually" steps through the address range with each "nop" and incrementing the PC... you don't run out of "time" so to speak. In other words, there's a very real limit on how long you can be "absent from duty" with regard to processing the address BUS requests.

[+MarcoJ]

6 minutes ago, Andrew Davie said:

In other words, there's a very real limit on how long you can be "absent from duty" with regard to processing the address BUS requests.

I imagine. Guessing the 6502 doesn't wrap around to 0x0000 when it hits 0xFFFF?

[+Andrew Davie]

Just now, MarcoJ said:

I imagine. Guessing the 6502 doesn't wrap around to 0x0000 when it hits 0xFFFF?

No idea for sure, but I would be very surprised if it didn't!

 

[JetSetIlly]

Just now, MarcoJ said:

I imagine. Guessing the 6502 doesn't wrap around to 0x0000 when it hits 0xFFFF?

It does, but once it starts reading 0x0000, the cartridge can no longer respond with the NOP byte, meaning the processor starts executing unwanted instructions. Which generally means carnage.

[Thomas Jentzsch]

I suppose putting a tiny loop onto the bus is too complex?

[+Andrew Davie]

1 minute ago, Thomas Jentzsch said:

I suppose putting a tiny loop onto the bus is too complex?

Here's how I understand it;  The ARM puts a nop on the data bus. And then it stops servicing the buS altogether. The nop remains on the bus. Every 2 cycles the 6507 puts an address (the PC) on the address BUS and expects the contents of that address. But the BUS isn't being serviced for most addresses, so it gets the EA (nop) byte that's on the bus already, and effectively sleeps for 2 cycles - BUT it also increments the PC.  So we're marching through memory. The ARM is not servicing the BUS, the EA remains on the BUS the whole time, and the 6507 is marching through its address space.

When the ARM code finally finishes, it recommences servicing the address BUS, cleverly restoring the 6507 to a known-good state so that the code can continue from the point where it triggered the EA-wait loop.  And the 6507 is blissfully unaware that anything happened.
So no, a tiny loop would require servicing the bus - which is the whole point of dumping EA on the bus and NOT servicing it.
That's my take on it

 

[Thomas Jentzsch]

5 minutes ago, Andrew Davie said:

When the ARM code finally finishes, it recommences servicing the address BUS, cleverly restoring the 6507 to a known-good state so that the code can continue from the point where it triggered the EA-wait loop.  And the 6507 is blissfully unaware that anything happened.
So no, a tiny loop would require servicing the bus - which is the whole point of dumping EA on the bus and NOT servicing it.

Got you.

 

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?