Jump to content
IGNORED

Legacy versus ARM-based 2600 Game Development


Thomas Jentzsch

Recommended Posts

3 hours ago, SpiceWare said:

The ARM could be used help a little bit by doing this:


        MAC READ_PADDLE_1
        ldx INPT0         ; 3
        stx DSWRITE       ; 4 
        ENDM


which would differ the bpl/sty paddle1 logic for the ARM to handle.  That would saves 2 cycles per scanline. I'm not aware of anybody having done this yet.

I was considering this for Circus AtariAge, but so far I have enough cycles to just process it with the 6502 while the screen is being drawn.

 

 

Where this idea becomes amazing though is processing for the trackball. It opens up possibilities for many games.

  • Like 2
Link to comment
Share on other sites

1 hour ago, batari said:

You could. It would have to be coded into the driver, but this could be done. No need for ldx, as you could do a NOP INPT0 and the ARM could still capture the value.

Yes, I was just trying to point out a simple access to the address would be sufficient and just dropped off the "stx DWRITE" to make the point. Essentially this would be 3x quicker than the original 6507 implementation - 3 cycles instead of 9.

 

  • Like 1
Link to comment
Share on other sites

4 minutes ago, Andrew Davie said:

Yes, I was just trying to point out a simple access to the address would be sufficient and just dropped off the "stx DWRITE" to make the point. Essentially this would be 3x quicker than the original 6507 implementation - 3 cycles instead of 9.

 

You could even take it a step further and do a NOP INPT0,x (with x preset to 1) and this will access both INPT0 and INPT1 in 4 cycles :)

  • Like 4
Link to comment
Share on other sites

7 hours ago, SpiceWare said:

For a regular one player game the 6507 code might look something like this:


        MAC READ_PADDLE_1
        lda INPT0         ; 3   - always 9
        bpl .save         ; 2 3
        .byte $2d         ; 4 0
.save   sty Paddle1       ; 0 3
        ENDM

 

You can do in one cycle less as described here. :) 

Edited by Thomas Jentzsch
  • Like 1
Link to comment
Share on other sites

3 hours ago, Andrew Davie said:

Ok, technically you don't need the ,x. .. right?  You could hardwire it so access to INPT0 did the job of reading both.

 

You mean modifying the paddle? Because INPT0 and INPT1 address decoding is burned into the TIA chip and I don't see a way to change that.

 

What I was getting at was a NOP INPT0,x will access INPT0 on the third cycle then INPT1 on the fourth cycle, effectively readying two paddles in four cycles with ARM assistance. As below:

  Zero page indexed addressing

     Read instructions (LDA, LDX, LDY, EOR, AND, ORA, ADC, SBC, CMP, BIT,
                        LAX, NOP)

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch address, increment PC
        3   address   R  read from address, add index register to it
        4  address+I* R  read from effective address

       Notes: I denotes either index register (X or Y).

              * The high byte of the effective address is always zero,
                i.e. page boundary crossings are not handled.
Link to comment
Share on other sites

47 minutes ago, batari said:

You mean modifying the paddle? Because INPT0 and INPT1 address decoding is burned into the TIA chip and I don't see a way to change that.

 

What I was getting at was a NOP INPT0,x will access INPT0 on the third cycle then INPT1 on the fourth cycle, effectively readying two paddles in four cycles with ARM assistance. As below:


  Zero page indexed addressing

     Read instructions (LDA, LDX, LDY, EOR, AND, ORA, ADC, SBC, CMP, BIT,
                        LAX, NOP)

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch address, increment PC
        3   address   R  read from address, add index register to it
        4  address+I* R  read from effective address

       Notes: I denotes either index register (X or Y).

              * The high byte of the effective address is always zero,
                i.e. page boundary crossings are not handled.

 

No, I didn't mean "modifying the paddle"

I meant that the ARM code that is watching addresses on the buss and returning whatever memory access is appropriate... can see INPT0 on the buss and at that stage decide to do a read of both INPT0 and INPT1 without need for the ",x" and do both in just 3 cycles. But maybe I'm misunderstanding how things work. It was just an idea :)

Link to comment
Share on other sites

10 hours ago, Andrew Davie said:

 

No, I didn't mean "modifying the paddle"

I meant that the ARM code that is watching addresses on the buss and returning whatever memory access is appropriate... can see INPT0 on the buss and at that stage decide to do a read of both INPT0 and INPT1 without need for the ",x" and do both in just 3 cycles. But maybe I'm misunderstanding how things work. It was just an idea :)

Oh, I see. No, the 6507 sets up all addresses on the address bus. The ARM can't (or, shouldn't) output an address to the address bus.

Link to comment
Share on other sites

Is there a technical reason the ARM couldn't feed a KIL opcode to the 6502, and then take over the address and data buses itself, interfacing with TIA and RIOT directly?

 

It would seem a lot more efficient to not have to babysit the 6502 at all, and you could hammer TIA registers even faster. (Once per main clock? Once per color clock?) The game would probably be lighter too, since it wouldn't need any ARM<->6502 interfacing code, nor any 6502 code at all, beyond feeding the KIL.

 

[edit - answering my own question, the lack of R/W line at the cart slot pinout is the monkey wrench in the above plan, so we need the 6502 alive for the writes. Pity.]

Link to comment
Share on other sites

On 2/14/2020 at 2:44 PM, batari said:

Oh, I see. No, the 6507 sets up all addresses on the address bus. The ARM can't (or, shouldn't) output an address to the address bus.

 

On 2/14/2020 at 5:30 PM, RevEng said:

Is there a technical reason the ARM couldn't feed a KIL opcode to the 6502, and then take over the address and data buses itself, interfacing with TIA and RIOT directly?

 

It would seem a lot more efficient to not have to babysit the 6502 at all, and you could hammer TIA registers even faster. (Once per main clock? Once per color clock?) The game would probably be lighter too, since it wouldn't need any ARM<->6502 interfacing code, nor any 6502 code at all, beyond feeding the KIL.

 

[edit - answering my own question, the lack of R/W line at the cart slot pinout is the monkey wrench in the above plan, so we need the 6502 alive for the writes. Pity.]

Yes it can; we just need to think outside the box a bit which we are already doing with the design.

 

The ARM can run an emulated TIA and RIOT if we include an HDMI video out on the cart like the Retron77 has - I'm part of the development team for this console and it would be interesting to see both combined into a streamlined dream machine or just heavy concept material, you know what I mean.

 

This will allow the best of both worlds on the console and even regular games would be "improved" with reduced flicker via 6 player sprites and missle sprites instead of 2 if we set the more powerful TIA to merge 3 frames. If the player wants to play a classic Atari game like ESB or one of the newer games that doesn't work well with merging TIA frames, they can just unplug the cart with the enhanced TIA and use the default TIA.

 

And programmers can use it for contest where the souped up TIA isn't allowed; the default TIA doesn't merge any frames but we can do some really cool tricks with it ;)

 

Link to comment
Share on other sites

  • 1 month later...
On 1/23/2020 at 3:17 PM, Cafeman said:

Compare Pac-Man 4K  and Ladybug ... its obvious to me which one has a little extra oomph in the cartridge ... but they are both 10/10 games. 

I haven't been following this thread since it was moved from it's original "Galaga 2600" thread... wow it certainly has taken on a life of it's own! :) 

 

I did want to clarify that Lady Bug does NOT use the ARM or any extra RAM (128 bytes total), although it does use 16K of ROM.  It could have been released exactly as it is "back in the day", I suspect around 1983 or 84 (pre-crash ;) ). :D 

 

EDIT: Oops, I was only on page 10 when I saw this quote and felt compelled to reply; I did realize it had been dormant for a couple months. :|  Disregard!

 

 

Edited by johnnywc
Link to comment
Share on other sites

35 minutes ago, johnnywc said:

I did want to clarify that Lady Bug does NOT use the ARM or any extra RAM (128 bytes total), although it does use 16K of ROM.  It could have been released exactly as it is "back in the day", I suspect around 1983 or 84 (pre-crash ;) ).

Oh, I thought it was a melody board game.  I don't even remember posting that. 

  • Like 1
Link to comment
Share on other sites

17 hours ago, Cafeman said:

Oh, I thought it was a melody board game.  I don't even remember posting that. 

Using a Melody board doesn’t imply using all the resources available; you could put Combat on a Melody board and it wouldn’t magically become an enhanced game.

 

18 hours ago, johnnywc said:

Lady Bug does NOT use the ARM or any extra RAM (128 bytes total), although it does use 16K of ROM.  It could have been released exactly as it is "back in the day", I suspect around 1983 or 84 (pre-crash ;) ). :D 

That’s why despite Galagon being a VCS dream come true, I still consider Ladybug to be the pinnacle of homebrew for the system.  As far as I’m concerned, the limited edition in the Coleco case should be retconned into 2600 history :)

Edited by Jstick
Link to comment
Share on other sites

1 hour ago, Jstick said:

Using a Melody board doesn’t imply using all the resources available; you could put Combat on a Melody board and it wouldn’t magically become an enhanced game.

I think Cafeman was saying that Lady Bug is soooo good he just assumed I must have used the ARM/unicorn/Kray computer/etc. :lol:;)   

1 hour ago, Jstick said:

That’s why despite Galagon being a VCS dream come true, I still consider Ladybug to be the pinnacle of homebrew for the system.  As far as I’m concerned, the limited edition in the Coleco case should be retconned into 2600 history :)

Thanks for the kind words!  Galaga(on) takes full advantage of the ARM and is a lot of fun to play, but Lady Bug will always be my favorite and game that I'm most proud of.  :D  I'm glad I was able to fulfill my dream of making a game (and sentimental favorite) for the 2600 that could have existed 'back in the day' (along with Conquest(Caverns) of Mars, Lunar Lander, Avalanche and eventually Rip Off!), and I'm equally excited and motivated to use the new tools and technologies to make games that wouldn't have been possible back in the day.  To me it's the best of both worlds! :thumbsup: 

  • Like 7
Link to comment
Share on other sites

6 minutes ago, Cafeman said:

So what is the reason of using a melody board if it doesn't have an arm on it?

 

What is a Melody Board?

 

Quote
  • Melody boards can be reprogrammed without having to open the cartridge.  Thus, you can "recycle" your Melody-based game and get a significant 50% credit towards a new game, or, if an upgrade for the game becomes available you can get the latest version by sending the cartridge to us and paying return shipping.
     
  • The Melody has on-board RAM and supports every known Atari 2600 bankswitching method up to 32K in size.  This includes SARA-based (Superchip) games and all the unique bankswitching schemes developed by third-party 2600 game developers.  This gives homebrew authors more flexibility in developing new games down the road.

 

  • Like 1
Link to comment
Share on other sites

12 minutes ago, Cafeman said:

I feel like I may have known this years ago, but I have forgotten. So what is the reason of using a melody board if it doesn't have an arm on it?  More ROM memory?   Regardless, Ladybug really impressed me and it is fun!

At this point in time I am using Melody boards ONLY for DPC+ and CDF(J) games.  We have another ARM-based board, called the Aria, that we use for bankswitching schemes that legacy (EPROM-based) boards do not or cannot support.  Such as various SARA RAM schemes (F8SC, F6SC, F4SC). 

 

 ..Al

  • Like 2
Link to comment
Share on other sites

  • 2 months later...
On 1/7/2020 at 3:51 PM, RevEng said:

An $18 million dollar Cray supercomputer from 1984 can compute 0.8 Gigaflops. The ARM CPU in the harmony/melody does 0.84 Gigaflops.

 

This is so asymmetric that the 6502+ARM pairing can't reasonably be compared to regular hardware assist found on other platforms.

 

[edit - corrected calculation]

Okay.  I've gotta say this, because you keep hammering this same talking point.

 

Given the amount of time that has passed, it makes absolutely perfect sense.  Moore's Law dictates that this would happen.  In fact, we could have calculated this amount of available power becoming available in 1982.  

 

You keep hammering this point like there's some kind of unnatural sorcery at work.  In reality, it's just the natural order of things playing out.  shrug

 

All I see is Moore's Law at work.  Too bad other consoles aren't on the same train, because there would be a bigger market for new NES or SNES carts.

 

Yeah.  The add ons on other consoles weren't more powerful and Moore's Law is the reason why.

 

Sorry.  You just keep posting it over and over.

  • Confused 2
Link to comment
Share on other sites

1 hour ago, orange808 said:

Okay.  I've gotta say this, because you keep hammering this same talking point.

 

Given the amount of time that has passed, it makes absolutely perfect sense.  Moore's Law dictates that this would happen.  In fact, we could have calculated this amount of available power becoming available in 1982.  

 

You keep hammering this point like there's some kind of unnatural sorcery at work.  In reality, it's just the natural order of things playing out.  shrug

 

All I see is Moore's Law at work.  Too bad other consoles aren't on the same train, because there would be a bigger market for new NES or SNES carts.

 

Yeah.  The add ons on other consoles weren't more powerful and Moore's Law is the reason why.

 

Sorry.  You just keep posting it over and over.

I do? ? Where am I posting it "over and over"?!? Please provide some links to support this accusation you've made.

 

My original post was in response to someone asking if ARM assist was any different than SNES in-cart acceleration, and it is different in terms of asymmetry, so I used a contemporary compute comparison for that. Indeed Moores law has allowed for ARM assist; you've said nothing shocking or illuminating there.

 

Whatever agenda you think I have is entirely in your own head - I've contributed significantly to the bB ARM functionality, so my code is probably in several ARM assist games at this point.

 

  • Like 6
Link to comment
Share on other sites

I distinctly remember reading about the supercomputer in other threads.  Anyhow, you're absolutely right that the VCS continues to impose limits.

 

Yep.  The jump between SNES and N64 was quite large.  Although, the cost of development also skyrocketed.  For most purposes, that's the day the two man dev team died out.  :(  It's ironic that moving to C was the same event that squeezed out the old guard for good.

Link to comment
Share on other sites

58 minutes ago, orange808 said:

I distinctly remember reading about the supercomputer in other threads.

You're distinctly wrong, and the non-weasel thing to do would be to just admit you made a mistake. Instead you've continued to imply that I've been repeating it, after which you try to move the conversation on. If you think you're saving face this way, you're not.

 

Apparently I've made this argument frequently enough that you felt compelled to reply to a six-month old post, just to make sure I'd stop. Sure sounds like it shouldn't be very hard to find one or two of these oh so many times I've "hammered at this same talking point", right?

 

Otherwise, go after some other imagined enemy, with your righteous indignation.

 

[/conversation]

  • Like 2
Link to comment
Share on other sites

21 minutes ago, RevEng said:

You're distinctly wrong, and the non-weasel thing to do would be to just admit to being wrong, rather than to continue to assert it without any evidence. 

 

Apparently I've done this frequently enough that you felt compelled to reply to a six-month old post, just to make sure I'd stop. Sure sounds like it shouldn't be very hard to find one or two of these oh so many times I've "hammered at this same talking point", right?

 

[/conversation]

Meh.  I'll gladly concede if you say it wasn't you or I'm mistaken.

 

Regardless, the $18 million dollar Cray thing is complete rubbish.  

 

Rather I'm mistaken or not, the Cray thing was a smear.  Nice touch with the dollar value as well.  :)

 

  • Confused 2
Link to comment
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.
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...