5 ms·

This doesn't even cover all the neat assembly tricks with self-modifying code that you would actually use on a 6502 to speed up memory transfer.

by kken 4y ago

MatthiasWandel 4y ago
For games that scrolled the screen, those had to happen essentially between scans, so a lot of tricks were employed. Fixed addresses in the code, unrolled loops, and self modifying code to avoid the expensive zero page indicrect indexed addressing mode (the slowest instruction on the CPU). The other trick was to start moving the first line of screen just after it got displayed, which would give you nearly two jiffies to do it before the scan caught up to you on the next frame.
- natly 4y ago
  It's crazy how much work went into those old games. I have a feeling those programmers weren't even paid that well considering how few people owned computers back then (so the market can't have been large).
  - wkearney99 4y ago
    If you ever play(ed) the Atari 2600 version of River Raid, you got to witness some SERIOUS tweaking to work around the limits of that console. Every scanline processed on the fly during the vertical blanking interval. No screen buffer. The animation was soooo smooth.
  - kabdib 4y ago
    My first job out of college at Atari in 1982, writing game cartridges for the 400/800 computers, paid $25K a year. My first raise after a year was to $30K. There were programmers in other divisions making royalties off of their games. Tod Frye famously got $700K or so for his terrible version of 2600 Pac-Man (it was terrible not because he was a bad programmer, but because marketing decided that 2K of ROM had to be enough, and he was smart enough to pull off a miracle . . . of sorts). Also, the OP apparently doesn't know how to unroll loops, which is the first thing you do to your game's hot spots. (Never had to resort to self-modifying code).
    - DerekL 4y ago
      The Pac-Man cart was 4k, not 2k. But maybe it should have been 8k, like Ms. Pac-Man later was.
      - kabdib 4y ago
        You are correct on both accounts :-) (I mis-remembered the ROM size).
- vardump 4y ago
  No need, it can easily happen during the scan. As long as the scan and update memory location never meet, there's absolutely no problem.
rasz 4y ago
Afaik its <120KB/s with all the tricks. 6502 was hand designed and brain optimized for clever use of available silicon real-estate, roughly 20% of CPU bus cycles are dead/bogus/useless. RTS wastes 3 of its 6 cycles, RTI 2 of 6 wasted, JSR 1 of 6 wasted , all increments at least 1 cycle wasted etc. Sad to think state machine handling DMA transfers in REU is probably less than 50 macrocells, and Commodore ran its own fab, they could have build-in REU DMA in C128 and it would cost cents.
- mywittyname 4y ago
  Is there a way to make a compatible 6502 variant that doesn't have this waste?
  - rasz 4y ago
    https://en.wikipedia.org/wiki/CSG_65CE02#Pipeline_improvements https://en.wikipedia.org/wiki/CSG_65CE02#Pipeline_improvemen... fixed most painful ones, but afaik not all dead cycles. But it was 1988 and commodore didnt bother putting it into anything other than some IO card for the AMIGA, not to mention it still did nothing to cover slowness of moving data around. Japanese decided to do something about it for TurboGrafx-16 in 1987 Hu6502 http://shu.emuunlim.com/download/pcedocs/pce_cpu.html http://shu.emuunlim.com/download/pcedocs/pce_cpu.html Transfer Alternate Increment (TAI), Transfer Increment Alternate (TIA), Transfer Decrement Decrement (TDD), Transfer Increment Increment (TII) - pretty much x86 'rep movsb', except not great at 6 cycles per byte (~160KB/s). For contrast 5 years older 80286 already did 'rep movsw' at 2 cycles per byte. 6 years later Pentium did 'rep movsd' at 4 bytes per cycle. Nowadays Cannonlake can do 'rep movsb' full cachelines at a time at full cache/memory controller speed.
    - JPLeRouzic 4y ago
      I think there are tricks to rewrite the microcode on Pentium, does similar tricks exist for 80286, 386 or 68K? It would be fun to reconfigure one as a high speed 6502.
  - krallja 4y ago
vikingerik 4y ago
I did this in a homebrew Atari 2600 game. For a Space Invaders grid of sprites. Each is triggered by writing to a register, as the electron beam scans through to display each sprite. The interval between sprites on the same scanline is 3 cpu cycles. That's a single 6502 instruction, the write to that register. How do you do any kind of load or compare instruction along with that to decide whether to display that sprite? The answer was to copy that stream of instructions to RAM ahead of time, and replace each write to a missing invader with a no-op. The code is here if anyone wants to see (the "inv3" demo): http://dos486.com/atari/ http://dos486.com/atari/
- krallja 4y ago
  > copy that stream of instructions to RAM ahead of time Even this is easier said than done: there are only 128 bytes of RAM in the entire machine, and that has to suffice for global variables and stack memory in addition to storing modified code like this!

This doesn't even cover all the neat assembly tricks with self-modifying code that you would actually use on a 6502 to speed up memory transfer.

by kken 4y ago

This doesn't even cover all the neat assembly tricks with self-modifying code that you would actually use on a 6502 to speed up memory transfer.

MatthiasWandel 4y ago

For games that scrolled the screen, those had to happen essentially between scans, so a lot of tricks were employed. Fixed addresses in the code, unrolled loops, and self modifying code to avoid the expensive zero page indicrect indexed addressing mode (the slowest instruction on the CPU). The other trick was to start moving the first line of screen just after it got displayed, which would give you nearly two jiffies to do it before the scan caught up to you on the next frame.

natly 4y ago
It's crazy how much work went into those old games. I have a feeling those programmers weren't even paid that well considering how few people owned computers back then (so the market can't have been large).
- wkearney99 4y ago
  If you ever play(ed) the Atari 2600 version of River Raid, you got to witness some SERIOUS tweaking to work around the limits of that console. Every scanline processed on the fly during the vertical blanking interval. No screen buffer. The animation was soooo smooth.
- kabdib 4y ago
  My first job out of college at Atari in 1982, writing game cartridges for the 400/800 computers, paid $25K a year. My first raise after a year was to $30K. There were programmers in other divisions making royalties off of their games. Tod Frye famously got $700K or so for his terrible version of 2600 Pac-Man (it was terrible not because he was a bad programmer, but because marketing decided that 2K of ROM had to be enough, and he was smart enough to pull off a miracle . . . of sorts). Also, the OP apparently doesn't know how to unroll loops, which is the first thing you do to your game's hot spots. (Never had to resort to self-modifying code).
  - DerekL 4y ago
    The Pac-Man cart was 4k, not 2k. But maybe it should have been 8k, like Ms. Pac-Man later was.
    - kabdib 4y ago
      You are correct on both accounts :-) (I mis-remembered the ROM size).
vardump 4y ago
No need, it can easily happen during the scan. As long as the scan and update memory location never meet, there's absolutely no problem.

rasz 4y ago

Afaik its <120KB/s with all the tricks. 6502 was hand designed and brain optimized for clever use of available silicon real-estate, roughly 20% of CPU bus cycles are dead/bogus/useless. RTS wastes 3 of its 6 cycles, RTI 2 of 6 wasted, JSR 1 of 6 wasted , all increments at least 1 cycle wasted etc. Sad to think state machine handling DMA transfers in REU is probably less than 50 macrocells, and Commodore ran its own fab, they could have build-in REU DMA in C128 and it would cost cents.

mywittyname 4y ago
Is there a way to make a compatible 6502 variant that doesn't have this waste?
- rasz 4y ago
  https://en.wikipedia.org/wiki/CSG_65CE02#Pipeline_improvements https://en.wikipedia.org/wiki/CSG_65CE02#Pipeline_improvemen... fixed most painful ones, but afaik not all dead cycles. But it was 1988 and commodore didnt bother putting it into anything other than some IO card for the AMIGA, not to mention it still did nothing to cover slowness of moving data around. Japanese decided to do something about it for TurboGrafx-16 in 1987 Hu6502 http://shu.emuunlim.com/download/pcedocs/pce_cpu.html http://shu.emuunlim.com/download/pcedocs/pce_cpu.html Transfer Alternate Increment (TAI), Transfer Increment Alternate (TIA), Transfer Decrement Decrement (TDD), Transfer Increment Increment (TII) - pretty much x86 'rep movsb', except not great at 6 cycles per byte (~160KB/s). For contrast 5 years older 80286 already did 'rep movsw' at 2 cycles per byte. 6 years later Pentium did 'rep movsd' at 4 bytes per cycle. Nowadays Cannonlake can do 'rep movsb' full cachelines at a time at full cache/memory controller speed.
  - JPLeRouzic 4y ago
    I think there are tricks to rewrite the microcode on Pentium, does similar tricks exist for 80286, 386 or 68K? It would be fun to reconfigure one as a high speed 6502.
- krallja 4y ago

vikingerik 4y ago

I did this in a homebrew Atari 2600 game. For a Space Invaders grid of sprites. Each is triggered by writing to a register, as the electron beam scans through to display each sprite. The interval between sprites on the same scanline is 3 cpu cycles. That's a single 6502 instruction, the write to that register. How do you do any kind of load or compare instruction along with that to decide whether to display that sprite? The answer was to copy that stream of instructions to RAM ahead of time, and replace each write to a missing invader with a no-op. The code is here if anyone wants to see (the "inv3" demo): http://dos486.com/atari/ http://dos486.com/atari/

krallja 4y ago
> copy that stream of instructions to RAM ahead of time Even this is easier said than done: there are only 128 bytes of RAM in the entire machine, and that has to suffice for global variables and stack memory in addition to storing modified code like this!