6 ms·
Large-scale analysis of code re-use in Atari 2600 games (2022)
- readthenotes1 3y ago"the dividing line between optimized and obfuscated code at that level can be very difficult to discern. " There's an old aphorism "it is easier to make working code fast than it is to make fast code work"
- kabdib 3y agoIn a game, it's sometimes difficult to tell if code is worknig or not. I've seen bugs in games that turned out to be interesting features (e.g., arithmetic overflow in Robotron caused an enemy to zoom to the opposite side of the screen from the player, pummeling the player from "over there". The designers kept that bug in the game, it made it better).
- truculentest 3y agoIs this wise use of taxpayer money? ACKNOWLEDGMENTS This work is supported in part by the Government of Canada's New Frontiers in Research Fund
- nsxwolf 3y agoCheaper and better than wars.
- heywhatupboys 3y agoif this is a jab at Ukraine, they were literally invaded, endured torture and forced relocations, abductions of their children, etc. And they deserve our financial support
- iscream26 3y ago[flagged]
- giantbanana 3y ago[dead]
- cplusplusfellow 3y ago[flagged]
- kstrauser 3y agoYes. This is how I want my taxpayer money spend: funding basic research. I couldn't care less about Atari 2600 software in itself, but I bet they learned some pretty handy things about being able to analyze other kinds of software that I care more about.
- JohnFen 3y ago> Is this wise use of taxpayer money? I think so, yes. Cultural history is important.
- bagels 3y agoThis is the first time I have seen the use of the word Archaeology in relation to understanding software.
- kstrauser 3y agoVernor Vinge's "A Fire Upon the Deep" expounds on the idea quite a bit. Imagine in the far future where pretty much all software you'd ever care to write has already been written, and the real challenge is in finding it again when you need it.
- heywhatupboys 3y agoyou don't need scifi books for that. Read up on the Java-class mentality in the 90's with people writing generic classes, and "puzzle architects" combining classes from a marketplace.
- ahefner 3y agoWas that really a thing? I ask because it feels like what I see people doing today around cloud and related technologies (kuber-this, kafka-that, etcd.), choosing solutions even before defining their problem.
- j45 3y agoSounds similar to Ruby/gem, node/npm, Python/pip and many more
- heywhatupboys 3y agono, nothing like that
- talideon 3y agoWhat Vinge didn't anticipate is everybody just rewriting everything in Rust. :-)
- 3y ago
- WaitWaitWha 3y agoMy biggest problem with the 2600? The tape drive. I could write the code but if the tape drive crashed during write out, the entire code had to be re-written. Solution was to write small chunks of code to multiple tapes. Yes, I had to swap the tapes, but if it crashed it was just that portion. And then, floppies showed up!
- WaitWaitWha 3y agoThanks for the corrections. Sadly, my memory seems to fade. I remember it was an Atari. It had a tape drive that I struggled with. I leave it at that.
- tenebrisalietum 3y agoYou had a tape drive for the Atari 2600 video game system that has no video RAM, 128 bytes of system RAM, a video chip not driven by the ANTIC that requires the CPU to program it for each line, and a crippled 6502 that addresses 4Kbytes of ROM max?
- vardump 3y agoWell... https://en.wikipedia.org/wiki/Starpath_Supercharger https://en.wikipedia.org/wiki/Starpath_Supercharger "The Starpath Supercharger (originally called the Arcadia Supercharger) is an expansion peripheral cartridge created by Starpath, for playing cassette-based proprietary games on the Atari 2600 video game console.[2][3][4][5] The device consists of a long cartridge with a handle on the end, and an audio cassette cable. It adds 6 KB to the Atari 2600's 128 bytes of RAM (increasing it 49-fold to 6,272 bytes of RAM)..."
- CyberDildonics 3y agoHow does this relate to the current story of finding code reuse?
- Mountain_Skies 3y agoAre you thinking of the Atari 400 or 800 instead of the 2600? While there were a few cassette systems for the 2600, they're somewhat rare and the only one that allowed for writing out programs appears to have been a homebrew hack.
- SomeRndName11 3y agoApple-I WozMon a good example of very extreme optimization. Check the latest Ben Eater's video.
- MegaDeKay 3y ago> Only documented 6507 instructions were disassembled, since we reasoned that use of undocumented instructions would have been rare, and this avoided having a number of data values being erroneously interpreted as instructions. This assumption jumped out at me. The 2600 programmers were pulling every trick in the book to crunch code size down and squeeze every cycle they could out of that 6507. How well those illegal opcodes [0] might have been understood back at this time is another question. They were apparently used in NES games [1] but that console obviously came later. [0] https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes [1] https://www.nesdev.org/wiki/CPU_unofficial_opcodes https://www.nesdev.org/wiki/CPU_unofficial_opcodes
- JohnFen 3y agoGood catch. > How well those illegal opcodes [0] might have been understood back at this time is another question. I'd be willing to bet they were understood very well. Lots of people back at that time spent a lot of effort looking for and characterizing undocumented opcodes for pretty much every processor that was in use. I was one of them! Is the 6507 identical with the 6502 from an opcode perspective? It's also possible that there weren't any really useful undocumented opcodes on that particular processor. Most of them weren't, they were just side-effects of how the processor parsed the instructions.
- MegaDeKay 3y ago> Is the 6507 identical with the 6502 from an opcode perspective? Yes, I believe so. The differences were in the packaging - simplified to lower costs. "The main differences between 6502 and 6507 is that the 6507 has less address lines so it can only address 8K instead of 64K and it also lacks the IRQ# and NMI# interrupt lines." https://forums.atariage.com/topic/199454-programming-asm-for-6502-vs-6507-questions/ https://forums.atariage.com/topic/199454-programming-asm-for... But I found this bit from the NESDev wiki I linked above very interesting: "Most NMOS 6502 cores interpret them the same way, although there are slight differences with the less stable instructions. CMOS variants of the 6502 handle them completely differently, and later CPUs in the same family (e.g. 65C02, HuC6280, 65C816) were free to implement new instructions in the place of the unused ones."
- a1o 3y agoI kinda wanted to see the reused code in categories. I guess input handling gets lots of reuse. Maybe making the score boards (the GUIs of the time)... It would be interesting to know what would be them!