Open-source C++ project template now available

[ZackAttack]

*** UPDATE 08/18/2023 ***

This project has been superseded by the newer elf format and should not be used for any new projects. 

 

I'm currently working on some comprehensive libraries for parsing assets, fixed point math, collision detection and more. C++ Libraries and examples will be posted once ready.

 

For now, you may reference the elf tests embedded in the UCA repository here: United-Carts-of-Atari/source/ElfTests at main · Al-Nafuur/United-Carts-of-Atari · GitHub.

 

 

Spoiler

For those of you who would like to write 2600 games in C++ there is now a project template you can use to get started.

 

The following are required to build and run:

• UnoCart-2600 with latest firmware that supports ACE file format
• Atollic TrueSTUDIO for STM32
• Source code

The template produces a simple bin which draws some skulls and lets you move around P0 with the joystick. You can create games up to 448KB in size and use as much of the 192KB of RAM as you'd like.

 

Currently there is no support for this file format in any emulators. You must test on actual hardware with the UnoCart-2600.

 

Edited August 18, 2023 by ZackAttack

[Mr SQL]

Is it possible to create a version for the Harmony Encore that can compile the same source code?

[ZackAttack]

Is it possible to create a version for the Harmony Encore that can compile the same source code?

 

Possible, yes. Practical, no.

 

The two carts use completely different microcontrollers with completely different capabilities.

[+Gemintronic]

Is there any coordination with SpiceWare and his SpiceC project?

 

I think learning 2 different C implementations might explode my head. <- My failing, obviously

[ZackAttack]

Is there any coordination with SpiceWare and his SpiceC project?

 

Not at this time. Good idea though.

[Mr SQL]

 

Possible, yes. Practical, no.

 

The two carts use completely different microcontrollers with completely different capabilities.

 

High difficulty for you as the dev, but it would be very practical from a standpoint of expanding the userbase so that more people could play the C++ games.

 

I followed a similar approach with Flashback BASIC in order to enable SuperCharger games to run on the Portable console. You do end up coding to the LCD so you would lose some of the power from whichever processor is the strongest, but you could have special modes that trick out the stronger platform at the expense of compatibility in case the programmer needs all the capabilities.

[+stephena]

For those of you who would like to write 2600 games in C++ there is now a project template you can use to get started.

 

The following are required to build and run:

• UnoCart-2600 with latest firmware that supports ACE file format
• Atollic TrueSTUDIO for STM32
• Source code

The template produces a simple bin which draws some skulls and lets you move around P0 with the joystick. You can create games up to 448KB in size and use as much of the 192KB of RAM as you'd like.

 

Currently there is no support for this file format in any emulators. You must test on actual hardware with the UnoCart-2600.

 

 

Just seeing this now. Is there any possibility (or desire for that matter) to get this running in Stella?

[ZackAttack]

 

Just seeing this now. Is there any possibility (or desire for that matter) to get this running in Stella?

 

There is certainly desire to have it running in Stella.

 

For development purposes I hacked together a modified version of stella which builds the game as part of stella.exe and runs it that way. This is actually great for development purposes because you get all the visual studio tools like conditional breakpoints and the ability to modify variables during runtime. Obviously that's not going to work for a general solution since there would be massive security implications with shipping Atari games as windows/Linux executables.

 

The Uno cart uses a STM32f4 MCU. If there's an open source emulator for the Cortex-M4 it would certainly be possible to add support to stella.

[+stephena]

Added an issue for this on Stella Github: https://github.com/stella-emu/stella/issues/364

 

Don't know how feasible it is, but at least it is now included in the list and on our radar.

[DirtyHairy]

 

The Uno cart uses a STM32f4 MCU. If there's an open source emulator for the Cortex-M4 it would certainly be possible to add support to stella.

 

 

I guess you are compiling to Thumb, so this should be covered by the Thumbulator. However, as you are emitting a 6502 instruction stream, there may be synchronization requirements that cannot be covered by the current code.

[ZackAttack]

 

 

I guess you are compiling to Thumb, so this should be covered by the Thumbulator. However, as you are emitting a 6502 instruction stream, there may be synchronization requirements that cannot be covered by the current code.

 

My biggest concern was with thumb 2 and FPU. Not sure if Thumbulator handles those. I wasn't planning on limiting things to just thumb, but I suppose we could if it's the difference between stella support or not.

[DirtyHairy]

 

My biggest concern was with thumb 2 and FPU. Not sure if Thumbulator handles those. I wasn't planning on limiting things to just thumb, but I suppose we could if it's the difference between stella support or not.

 

 

Nope, Thumbulator doesn't handle either. I did a short search for a suitable open source ARM core for 6502.ts a year ago, but didn't come up with anything better than Thumbulator.

[orange808]

Finally decided to get an unocart and play with the ACE format a little.  I see there isn't any "released" software using this and there still discussion about getting Stella support.

 

That leads to my question:

 

Is the ACE file format something that can be used for development or is this a fluid "work in progress" until Stella gets worked out?

 

I don't want to put anyone on the spot, but I also don't want to spend any time working on software that might get broken on future firmware.

 

I think my first order of business will be to move the 6507 VCSlib stuff over into CCM.  Hoping to get as much time as possible between the 6507 clocks to do other things.

 

[ZackAttack]

16 hours ago, orange808 said:

Is the ACE file format something that can be used for development or is this a fluid "work in progress" until Stella gets worked out?

The ACE file format is used to update the unocart firmware. ACE compatibility is part of the required testing for unocart firmware releases. It's safe to assume that ACE will continue to be supported on unocart. The c/c++ framework itself is pretty self contained and could even be used with other hardware solutions as long as the microcontroller has enough resources. 

 

Stella is the main thing you need to take into consideration. For development purposes I have a fork of the stella source that can run ACE/Strong-ARM games. The way this is done is only suitible for development purposes though. I wouldn't expect stella to support this new format until there were enough games released to make it worth while.

 

TLDR; if you use this framework you should expect your game to only be playable on unocart.

 

16 hours ago, orange808 said:

I don't want to put anyone on the spot, but I also don't want to spend any time working on software that might get broken on future firmware.

The entire tech stack is open source. That should minimize the risk of developing for a platform that gets abandoned.

 

If you provide more details about exactly what you're planning on building. I'd be happy to provide more details about how well suited this framework would be.

[orange808]

On 2/18/2020 at 9:21 AM, ZackAttack said:

 I'd be happy to provide more details about how well suited this framework would be.

 

Could you share a little information on the vcsWrite3 method?

 

What's the catch?

[ZackAttack]

vcsWrite3() is a WIP implementation of bus stuffing. I plan to implement error detection and correction to account for some systems that have been problematic in the past.

 

When it's done there will be a routine provided that does the error detection and provides the masks and values needed for A, X, and Y. Then vcsSetMasks() would be called during initialization and vcsLd*() would be called for A, X, and Y prior to using vcsWrite3(). Write3() will select STA, STX, STY, or SAX depending on the value being stuffed so that only 6 of the 8 bits need to be overridden by the ARM chip. Which 2 bits aren't stuffed will depend on the results of the error detection.

[orange808]

6 minutes ago, ZackAttack said:

vcsWrite3() is a WIP implementation of bus stuffing. I plan to implement error detection and correction to account for some systems that have been problematic in the past.

 

When it's done there will be a routine provided that does the error detection and provides the masks and values needed for A, X, and Y. Then vcsSetMasks() would be called during initialization and vcsLd*() would be called for A, X, and Y prior to using vcsWrite3(). Write3() will select STA, STX, STY, or SAX depending on the value being stuffed so that only 6 of the 8 bits need to be overridden by the ARM chip. Which 2 bits aren't stuffed will depend on the results of the error detection.

 

An automatic Unocart implementation similar to the error check startup routine from your ray casting demo, correct?

 

That's exciting news.  I can't even imagine what I could do with that.  :)

 

In the meantime, I think I'm going to add some overloaded methods to pass a cycle counter by reference.  Makes sense to handle assembler instructions first in vblank and overscan, compute the needed NOP cycles from a running count, give the 6507 some busywork, and run my pure C++ code afterwards.

[orange808]

I'm looking to finish up some work with .ACE.  Pause would be a nice feature to have.

 

I'm having some issues detecting the difference between a VCS and 7800 using .ACE.

 

Should I be able to read at $0xD0 and $0xD1?

[ZackAttack]

7 hours ago, orange808 said:

Should I be able to read at $0xD0 and $0xD1?

Assuming you are referring to the values that are at those locations after power on reset. The firmware would need to be enhanced to restore the original RAM values before handing execution over to the ace file. The current firmware overwrites all the TIA RAM on startup and discards the original values. Might be worth posting something in the official firmware thread.

[orange808]

55 minutes ago, ZackAttack said:

Assuming you are referring to the values that are at those locations after power on reset. The firmware would need to be enhanced to restore the original RAM values before handing execution over to the ace file. The current firmware overwrites all the TIA RAM on startup and discards the original values. Might be worth posting something in the official firmware thread.

Thanks for the reply.

 

I'll post something there or open an issue on github.

 

 

[orange808]

Can you share some details about the open source licensing terms for using ACE and Unocart?

[ZackAttack]

I just added a permissive license to the strong arm repo. I think that's necessary since most will want to modify something and include it with their games.

 

Unocart firmware has a license on github as well: https://github.com/robinhedwards/UnoCart-2600/blob/master/LICENSE

 

It's worth noting that although the unocart is the only hardware that currently supports this framework, the plan has always been to have a stripped down cheaper cart for publishing games. In that scenario the unocart licensing wouldn't apply since strong arm can bootstrapped directly without going through the uno firmware.

[orange808]

49 minutes ago, ZackAttack said:

I just added a permissive license to the strong arm repo. I think that's necessary since most will want to modify something and include it with their games.

 

Unocart firmware has a license on github as well: https://github.com/robinhedwards/UnoCart-2600/blob/master/LICENSE

 

It's worth noting that although the unocart is the only hardware that currently supports this framework, the plan has always been to have a stripped down cheaper cart for publishing games. In that scenario the unocart licensing wouldn't apply since strong arm can bootstrapped directly without going through the uno firmware.

Thank you.  I was going to drop my project if my code was copyleft.

 

I inquired about the Pluscart design as a possiblity for manufacturing carts as well.  A board with RTC battery backup would allow me to drop the password game restore feature.  I know I could also use one of the "lower" sectors (currently occupied with firmware), but I have no desire to flash the cart while making test builds.  It's impractical. 

 

I understand the Pluscart board gerbers are available under GPL and I haven't sorted out rather or not that's a deal breaker.  The board only carries signals to and from the VCS and the STM32, so it might be okay.

 

Although, I'm immediately concerned that GPL licencing is fundamentally incompatible with using an STM32 board, because I don't believe the entire hardware design (STM32 gerbers etc) are available to open source the entire hardware project and meet the terms of GPL.

[orange808]

Since there aren't any .ACE files in the wild, here's the first thing I did tinkering with the template.  I had forgotten about the music on this one until today.  That's about as good as I can do without DPC music.

 

 

Strong-ARM.ace

[Dionoid]

On 2/21/2020 at 10:21 PM, ZackAttack said:

vcsWrite3() is a WIP implementation of bus stuffing. I plan to implement error detection and correction to account for some systems that have been problematic in the past.

 

When it's done there will be a routine provided that does the error detection and provides the masks and values needed for A, X, and Y. Then vcsSetMasks() would be called during initialization and vcsLd*() would be called for A, X, and Y prior to using vcsWrite3(). Write3() will select STA, STX, STY, or SAX depending on the value being stuffed so that only 6 of the 8 bits need to be overridden by the ARM chip. Which 2 bits aren't stuffed will depend on the results of the error detection.

I'm trying to wrap by head around how this bus-stuffing error correction is implemented. It sounds like first you do some error detection to figure out which bits have an issue with being stuffed. Then you provide values for A, X and Y which cover the bits which won't be overridden by the ARM. The SAX instruction will put A & X on the bus, so that covers the case where you want to send 0's for the non-stuffed bits, right? And then Y will probably contain 1's for these non-stuffed bits. Now depending on the value you want the ARM to put on the bus, you will feed the 6502 either the STA, STX, STY or SAX instruction, right?

And will the bus-stuffing error detection and correction make the 6502 load the correct values into A, X and Y automatically at the start? And does it mean that you can't use these registers in 6502 code logic anymore and everything should be bus-stuffed? Or is bus-stuffing only active during the display kernel?

Edited January 7, 2023 by Dionoid