Jump to content

Recommended Posts

23 minutes ago, johnnywc said:

Hi there!  The game does not roll on real hardware; I'm assuming the point in the game is when the hill appears or during a transition screen wipe to another screen?

 

Yes. About halfway through the hill stage.

 

Quote

The ARM cycle counting thing sounds very interesting; how is it done and is it something developers can use?  Probably the most frustrating part of developing for the ARM is trying to speed optimize code without any true benchmark telling you whether or not the changes you've done are helping or not. ?  

 

Cycle counting is part of my emulator. It differs to Stella in that Stella executes the ARM program instantly, relative to the 6507. I've tried a different approach whereby the 6507 is stalled with NOPs like in the real hardware. Cycle counting is tricky with the ARM however so it's not perfect but it is helpful to make sure the program isn't going bezerk. I hope to get the emulation to a state where it is accurate enough for optimisation work but it's not there yet.

 

This is the link to the README where I briefly discuss ARM emulation.

 

https://github.com/JetSetIlly/Gopher2600#arm7tdmi-emulation

 

(Current code supports CDFJ+ but I've not prepared a binary yet)

 

Quote

Yes, MAM is enabled in Turbo Arcade.  The screen will roll without it (mostly because we need to update the entire 40x184 view screen on every frame from compressed data).

MAM is enabled, but we never write to the MAM control address because Chris aka cd-w provided me with a CDFJ+ driver that has MAM enabled by support so I can save a few bytes of ROM not having to enable it in code (same for RobotWar and Gorf Arcade). :idea: :D 

 

 

Ah. Of course. I didn't think about it being enabled in the driver.

 

Quote

 

It is an upgraded CPU but I'm not sure what the specs are.  @batari Fred would have all the info about that. 

 

 

Edited by JetSetIlly
  • Like 1
7 hours ago, JetSetIlly said:

Cycle counting is part of my emulator. It differs to Stella in that Stella executes the ARM program instantly, relative to the 6507. I've tried a different approach whereby the 6507 is stalled with NOPs like in the real hardware. Cycle counting is tricky with the ARM however so it's not perfect but it is helpful to make sure the program isn't going bezerk. I hope to get the emulation to a state where it is accurate enough for optimisation work but it's not there yet.

Stella does some coarse counting too. It only counts memory accesses, which should be good enough to detect major overruns. The values are displayed in the debugger's 'States' tab of CDFJ.

 

Exact ARM cycle counting is very tricky, it will be very interesting to see how exact Gopher2600 can become.

19 minutes ago, Thomas Jentzsch said:

Stella does some coarse counting too. It only counts memory accesses, which should be good enough to detect major overruns. The values are displayed in the debugger's 'States' tab of CDFJ.

 

Exact ARM cycle counting is very tricky, it will be very interesting to see how exact Gopher2600 can become.

It's pretty good now. I'm doing quite a bit of legwork with the ARM during OS and VB, and I'm finding good correlation between Gopher2600 and hardware. It's my "go-to" when I want to see if I have time overruns and more particularly memory access errors. I've found quite a few issues in my code with Gopher that haven't shown up on Stella. 

16 hours ago, johnnywc said:

Probably the most frustrating part of developing for the ARM is trying to speed optimize code without any true benchmark telling you whether or not the changes you've done are helping or not.

 

Use Timer1 on the ARM:

 

#define T1TCR   *(unsigned int*)0xE0008004 // Timer Control Register
#define T1TC    *(unsigned int*)0xE0008008 // Timer Counter



    T1TC = 0;           // make sure timer starts at 0
    T1TCR = 1;          // turn on timer

    RoutineToTest();

    T1TCR = 0;          // turn off timer
    execution_time = T1TC;

 

There's also a Timer0, but it's used by the CDFJ driver.

  • Like 1
  • Thanks 2
1 minute ago, SpiceWare said:

 

Use Timer1 on the ARM:

 


#define T1TCR   *(unsigned int*)0xE0008004 // Timer Control Register
#define T1TC    *(unsigned int*)0xE0008008 // Timer Counter



    T1TC = 0;           // make sure timer starts at 0
    T1TCR = 1;          // turn on timer

    RoutineToTest();

    T1TCR = 0;          // turn off timer
    execution_time = T1TC;

 

There's also a Timer0, but it's used by the CDFJ driver.

Thanks Darrell, this is very helpful! :thumbsup:  

  • Like 1
23 minutes ago, SpiceWare said:

 

The audio routines.

 

I'm missing something potentially very useful here!  I just wrote my own audio system - 16 "channels" with envelopes, of sorts, priorities and mixing. Hmmm.

32 minutes ago, Andrew Davie said:

I'm missing something potentially very useful here!  I just wrote my own audio system - 16 "channels" with envelopes, of sorts, priorities and mixing. Hmmm.

 

The audio routines work in 2 modes:

  • 3 voice music
  • digital samples

For the 3 voice music you use some C functions to set the waveform and a frequency for each voice:

    setWaveform(0, SINE_WAVE);
    setWaveform(1, SINE_WAVE);
    setWaveform(2, SINE_WAVE);

    setNote(0, getPitch(note0));
    setNote(1, getPitch(note1));
    setNote(2, getPitch(note2));

 

 

The CDFJ (and DPC+) driver takes care of doing waveform addition to create a 4-bit digital audio value. The 6507 code needs to do this once per scanline:

 

        lda #AMPLITUDE
        sta AUDV0


Additionally you can run ARM code with an IRQ that will update AUDV0 once per scanline while the ARM code is running.

 

The music in Stay Frosty 2 is an example of this:

 

 

 

For digital sample mode you set a pointer to the packed sample data (two 4-bit samples per byte) and set the frequency. The CDFJ driver will unpack the data for you.

 

  setSamplePtr(SAMPLES[gCurrentSample-1]);
  setNote(0, SAMPLE_RATES[gCurrentSample-1] * 256);

The speech in Draconian is an example of this:

 

 

  • Like 2

It's funny to think that this port technically has better scaling than the arcade original.

 

Sound effects-wise the only change I'd recommend is switching to a plain square wave for the tire screeching noise instead of the buzzer distortion it's using currently.

  • Like 1
  • 1 month later...
On 5/23/2021 at 9:36 AM, sramirez2008 said:

And for anyone without a footpedal, there are now 3D printed joystick couplers available too. Btw, this game is already quite the achievement.?

Joystick Coupler.jpg

How can I get a hold of a CX40 joystick coupler, is there a place online where I can score one of these bad boys???

 

Thanks,

 

Ray Jackson

Edited by BIGHMW
spelling error
7 minutes ago, BIGHMW said:

How can I get a hold of a CX40 joystick coupler, is there a place online where I can score one of these bad boys???

 

Thanks,

 

Ray Jackson

PM @amiman99 He was making them before.

  • 6 months later...

Turbo Arcade has been nominated for the Atari Homebrew Award for Best Homebrew WIP (Port)!

 

766685561_Atari2600BestWIPHomebrew(Port).thumb.jpg.9f270484777b4dc799e3271feb98061a.jpg

 

Thanks to @Nathan Strum for the amazing graphics ? AND for the cool sounds! :music:  (Wait... Nathan does sound too?!? :o;) )

 

There are many amazing games nominated this year for the Atari 2600, Atari 5200/8 bit, Atari 7800 and Atari Lynx.  If you haven't already, visit the link, play some games and cast your vote for your favorites!

 

*We are planning on completing Turbo Arcade for a release in late 2022.  Stay tuned for more info! :D  

  • Like 7
  • Thanks 1
  • 4 weeks later...
  • 5 months later...

Turbo Arcade still has quite a lot of work remaining before it's ready for release. It's been on the back burner for awhile as Lady Bug Arcade and RobotWar:2684 were completed, and Qyx and Gorf Arcade are in the process of being finished up now. Turbo Arcade is expected to be released in 2023.

 

You can track projected release dates for Champ Games on their website: https://champ.games/development

  • Like 5
  • Thanks 1

My local arcade has this, I was there Saturday playing it, recently got a 2600 myself so will try out the demo! They also have a Gorf cabinet!

 

ah doesn't work on an Unocart which is what I've bought :( :(  

Edited by str0m
update
  • Like 1
9 minutes ago, str0m said:

My local arcade has this, I was there Saturday playing it, recently got a 2600 myself so will try out the demo! They also have a Gorf cabinet!

 

ah doesn't work on an Unocart which is what I've bought :( :(  

Unfortunately the Unocart doesn't support any ARM games AFAIK; hopefully they'll be able to add that support someday! ?

 

With that said, Turbo Arcade is a 64K CDFJ+ game that isn't supported on any multi-cart (Harmony/Harmony Ecore, Unocart, Pluscart) because of the larger ROM size and/or the ARM chip.  The only way to currently play the Turbo Arcade ROM is with the Stella emulator version 6.6 or better or the Gopher2600 emulator.  

 

Hope that helps!

John

 

  • Like 1
  • 10 months later...

ZeroPage Homebrew is playing an Exclusive Update to Champ Games' Turbo Arcade plus LIVE Video Interview with John Champeau on tomorrow's ZPH stream LIVE on Twitch, hope you can join us!

 

Games:

WATCH AT 1080P60 FOR FULL QUALITY

 

  • Like 4

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