[HN Gopher] Large-scale analysis of code re-use in Atari 2600 ga...
       ___________________________________________________________________
        
       Large-scale analysis of code re-use in Atari 2600 games (2022)
        
       Author : corysama
       Score  : 60 points
       Date   : 2023-07-14 17:41 UTC (5 hours ago)
        
 (HTM) web link (dl.acm.org)
 (TXT) w3m dump (dl.acm.org)
        
       | truculentest wrote:
       | Is this wise use of taxpayer money?
       | 
       | ACKNOWLEDGMENTS
       | 
       | This work is supported in part by the Government of Canada's New
       | Frontiers in Research Fund
        
         | kstrauser wrote:
         | Yes. 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.
        
         | nsxwolf wrote:
         | Cheaper and better than wars.
        
           | heywhatupboys wrote:
           | if 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 wrote:
             | Palestinians also have, and still are, going through all of
             | those things. But in this case the US is funding the
             | perpetrators, so I guess that makes it OK.
        
             | giantbanana wrote:
             | [dead]
        
         | JohnFen wrote:
         | > Is this wise use of taxpayer money?
         | 
         | I think so, yes. Cultural history is important.
        
       | MegaDeKay wrote:
       | > 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
       | 
       | [1] https://www.nesdev.org/wiki/CPU_unofficial_opcodes
        
         | JohnFen wrote:
         | Good 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.
        
       | WaitWaitWha wrote:
       | My 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!
        
         | Mountain_Skies wrote:
         | Are 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.
        
         | tenebrisalietum wrote:
         | You 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?
        
         | CyberDildonics wrote:
         | How does this relate to the current story of finding code
         | reuse?
        
       | bagels wrote:
       | This is the first time I have seen the use of the word
       | Archaeology in relation to understanding software.
        
         | kstrauser wrote:
         | Vernor 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 wrote:
           | you 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.
        
           | talideon wrote:
           | What Vinge didn't anticipate is everybody just rewriting
           | everything in Rust. :-)
        
             | wslh wrote:
             | It is beyond Rust.
        
         | nickpeterson wrote:
         | I use the term software archaeology pretty regularly. I never
         | researched where I first heard it but I'm assuming it isn't my
         | invention. Lots of looking at legacy code requires a degree of
         | "knowing how the business used to work" or "how computers used
         | to work".
        
         | timschmidt wrote:
         | Similar to "forensic development".
        
       | SomeRndName11 wrote:
       | Apple-I WozMon a good example of very extreme optimization. Check
       | the latest Ben Eater's video.
        
       | readthenotes1 wrote:
       | "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 wrote:
         | In 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).
        
       | a1o wrote:
       | I 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!
        
       ___________________________________________________________________
       (page generated 2023-07-14 23:00 UTC)