Perl can do anything. That's kind of boring, in a certain way [Footnote 1].
Because Perl is so powerful, it's that much harder to impress people with any particular thing you do. There are multiple reasons to want to impress people; perhaps you're vain. Perhaps I'm vain. But I also just enjoy code as a highly formalized system of, basically, poetry [Footnote 2].
So maybe that's why I'm writing 6502 code for the Atari 2600 right now. Or maybe I just always wanted to. Or maybe I miss writing 6502 for the Atari 800/XL/XE computer, but I'm enjoying the better development tools (vi, dasm, cc65 on a fast host, generating tables from Perl). But that's not why I started this article.
I had a thought. It requires some background. It's not interesting outside the scope of Atari 2600 programming, but if I pulled it off, which I'm not even going to try to do, I'd impress. The 2600 has no frame buffer. To display an image on the screen, the processor has to spend all of its time basically copying data to the screen by way of hardware registers. For the most part, the code looks like LDA #$xx, STA $reg, with some table lookups off of the X and Y registers too. If you have a RAM based cartridge, like the Starpath, you can write self-modifying code that generates code to do nothing but LDA #$xx, STA $reg, over and over. That's as close to optimal as you can currently get. There isn't enough time each scan line to update all of the registers. You can position a sprite or two, update the sprite colors, but then you don't have the cycles to update the 40 bit wide background, or vise versa.
But a cartridge could be even *better* than RAM based. What if the code did nothing but LDA #$00, then STA to registers over and over while another chip actually drove the data bus? The 6502 would be sending low signal on all pins, but if there were some Xilinix style programmable logic on there too that knew how to just blitter data from a buffer straight to the data bus, every third cycle (with the other cycles being STA instructions read from ROM and then the one byte page zero address to write to)? You could *double* data throughput to the screen. Rather than screens being little programs, with lots of index registers and lookup tables, screens would be pure data -- what to write to the player and missile position registers, the background data registers (which must be updated *twice* a scan line if you don't want the right side of the screen to mirror or copy the left side), player color registers, background color registers, etc, etc.
The 2600 doesn't export many pins to the cartridge, so the ROM can't bus master. But with this scheme, it could be faked badly. Some register could be written to to tell it to wait to start asserting the data lines every time it sees a page zero STA. Then the register could be banged again to make it stop copying data. It would need its own little ROM or RAM or something. STA zero page takes three cycles. There are 76 cycles per scan line. One STA should be done to the CPU sync register, and to keep the size of this routine from being completely unrolled, a branch should be done, which leaves enough cycles for 22 register bangs -- unheard of.
Oh, even better, if the code does one LDA #$00 then STA $00 over and over, then the PLA could assert both the data and the address, and then each line would be even more free form for things like updating player position to make players appear in multiple locations on the same line on some lines while changing colors on others, etc.
Footnote 1:
You do something hard or clever, and people say, thanks, you saved me the work (even if they're half serious, or if they really wanted it). Marc did Coro, which is mind blowing, and no one really... well, no one's mind was really blown.
Screw you all. You're spoiled rotten with all of this great CPAN stuff.
Footnote 2:
Sometimes people write Perl where the source code is literally poetry, but more often, it's beautiful for other reasons. Poetry makes clever use of words. Code makes clever use of interfaces, glue, algorithms, etc. Good poetry, like code, inspires awe and makes us feel like the world is a little less desolate of stupidity and coldness.
Someone wrote how about they considered code to be a specific kind of art -- a performance art. I don't remember their original argument, but I remember it jiving with me. It's more of a skill than a specific accomplishment, each work has very limited scope, it doesn't age well (except as archaeological relics).
-scott
