Hacker News Reader

Comment by kken | Hacker News Reader

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.

View on HN

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/

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

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.

Is there a way to make a compatible 6502 variant that doesn't have this waste?

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

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.

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.

“The 100 MHz 6502” does a different clever thing - it copies all the dedicated RAM and ROM into its own FPGA copy. Then it can perform 7 to 25 instructions before the next external read/write cycle!

http://www.e-basteln.de/computing/65f02/65f02/

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.

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

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.

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

The Pac-Man cart was 4k, not 2k. But maybe it should have been 8k, like Ms. Pac-Man later was.

You are correct on both accounts :-) (I mis-remembered the ROM size).

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.

Reply on news.ycombinator.com