Jump to content
ZackAttack

Open-source C++ project template now available

Recommended Posts

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:

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.

 

  • Like 6

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Is there any coordination with SpiceWare and his SpiceC project?

 

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

Share this post


Link to post
Share on other sites

Is there any coordination with SpiceWare and his SpiceC project?

 

Not at this time. Good idea though.

  • Like 1

Share this post


Link to post
Share on other sites

 

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.

  • Like 1

Share this post


Link to post
Share on other sites

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:

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?

Share this post


Link to post
Share on other sites

 

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.

  • Like 1

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

 

Share this post


Link to post
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.

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