> 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.
> 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.
> 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."
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."
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).
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.
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.
Was 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.
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”.
I'm not entirely certain but I believe this trend represents a small but growing niche application of this word introduced by Foucault's Archeology of Knowledge.
Another, much less respectable off-label application of a term, but which is surprisingly useful nonetheless, is the generalized way the word "technology" is used in Scientology jargon and its offshoots, where it is not particularly associated with electronic or apparatus or mechanisms in a physical sense but, instead refers to any sort of construct that was devised as, and/or serves as a force and agency multiplier. In this usage, writing systems are principally regarded as a technology, as are mass marketing and propaganda, and a bunch of other things. I highly doubt scientologists/EST people were the first to use it this way, but don't know where they picked it up from.
I like the tangents, but I believe archeology is just used definitionally - when the context is lost, sifting through source code may as well be digging up ancient artifacts.
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!
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.
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.
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?
"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)..."
The Atari 2600 is a video game console, not a computer. See the other comments. You most certainly were not thinking about the 2600 when you wrote this as it is a cartridge based system similar to the NES.
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.
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
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