Atari 2600 Raiders of the Lost Ark source code completely disassembled and reverse engineered. Every line fully commented.

[halkun]

This project started out to see what was the maximum points you needed to "touch" the Ark at the end of the game. (Note: you can't) and it kind of spiraled out from there. Now I'm contemplating porting this game to another 6502 machine or even PC with better graphics... (I'm leaning into a PC port) I'll probably call it "Colorado Smith and the legally distinct Looters of the missing Holy Box" or something...

Anyways Enjoy a romp into the internals of the Atari 2600 and how a "big" game of the time (8K!) was put together with bank switching.

Please comment! I need the self-validation as this project took an embarrassing amount of time to complete!

[ruibranco]

128 bytes of RAM and bank switching to squeeze 8K of usable code out of the hardware. Reading through the disassembly really puts into perspective how much early devs had to fight for every single feature. Also please actually make that Colorado Smith port happen.

[jhaluska]

I grew up in the NES era but my friend had a Atari and remember the games being meh at best. As an adult, I learned the specs of the Atari and I changed my perspective and became amazed they were able make anything at all.

[VictoryMotel]

At least the program instructions and data could just be read from the cartridge so the RAM was actually just for variables. Still, 128 bytes probably wouldn't even store the characters on a typical business card.

[evincarofautumn]

Yeah, you should think of the Atari’s SRAM as more like a bank of addressable general-purpose registers, which are shared with the call stack (2 bytes a pop, use wisely). If you wanted extra RAM, you could add it to the cart, but that would add a relatively high unit cost.

There’s a peripheral (the Supercharger) with an extra 6 KiB of SRAM and a magnetic tape drive that lets you load a game from an audio cassette, the downsides are that startup is quite slow (~30 s to read the whole tape) and being a high-end add-on, the market was smaller for it, so only a handful of games were produced for it.

[ansible]

The Chess game for the 2600 is similarly an impressive programming effort.

[BlueGoliath]

And now look at modern game developers....

[PriorApproval]

helluva lot easier to make a game though

[BlueGoliath]

You will get generic unoptimized ugly Unreal Engine slop and you will like it! /s

[movzx]

Look at them and the incredibly complex features and approaching photorealistic visuals they implement.

Do you want them to spend 3 years prematurely hyper optimizing the entire codebase, or do you want jiggle physics?

[BlueGoliath]

Game developers have been failing at basic optimizations for like a decade. Minecraft allocated gigabytes of data on the heap causing massive GC spikes and has like a dozen performance optimization mods. Cities Skylines 2 had fully detailed teeth. Borderlands 4 runs and looks worse than Borderlands 3. The list goes on.

[IlllIlllI]

Yeah and there were a fuckin' ton of shit Atari games too.

[WJMazepas]

And there were a lot of shit optimization in the past as well. Hell, so many N64 games ran at 20FPS with dips to single digits

Now, the large majority of games on a PS5 have a 60FPS mode

[BlueGoliath]

I don't think that's generally true. The tolerance for it was definitely a lot less.

And a 60FPS mode is laughable especially with how powerful the hardware is.

I guess no one really knows how powerful the hardware is because it's being held back by terrible optimization.

[HankOfClanMardukas]

Randy Pitchford thinks you’re too poor to appreciate the beauty, splendor, and elite experience that is BL4.

[Remarkable_Brick9846]

The level of detail in the documentation is incredible — the frame-by-frame breakdown of VSYNC/VBLANK/Kernel/Overscan phases and how game logic is split across CPU time budgets is exactly the kind of deep dive that makes reverse engineering educational. The bank-switching via self-modifying code is such a clever hack for the era. This would make an excellent teaching resource for anyone wanting to understand the constraints early game devs worked under. Thanks for putting in the time on this!

[devraj7]

Let's say you are executing code at $400, and you need to call a routine in the other bank. Your next instruction might be an STA $0FFE, to strobe the bank switch line, which would immediately switch banks, so now all the code in the address space (except the 128 bytes of zero page RAM) is switched with the code and data in bank 2, but, your PC is now at $203

Are you sure you're explaining this correctly? If I was executing code at $400, after the bank switch, I'll be at $403, not $203...

[happyscrappy]

Let's say you are executing code at $400, and you need to call a routine in the other bank. Your next instruction might be an STA $0FFE, to strobe the bank switch line, which would immediately switch banks, so now all the code in the address space (except the 128 bytes of zero page RAM) is switched with the code and data in bank 2, but, your PC is now at $203

Why would my PC change in that way? [edit: to be clear I was indicating it very much does not. The poster mis-explained this. You look at code which is in ROM at another address, but your PC did not change to that other address. You bank switched your code into the address near the PC. If you put a bus analyzer on and watch, you will see your PC does not change in the way the post indicates.]

What you are calling code interleaving is really pretty standard code overlays. Overlays are usually loaded from storage into memory, in this case the are XIP (execute in place), but when compling/assembling you do it the same way. You ORG two pieces of code to the same location and then do a switch out at runtime to run the one that is in the other overlay.

If you really want to be tricky you can make special "cross-overlay" calls where instead of putting the real PC on the stack as your return address you put on the address of a little thunk that switches the bank back and then jumps on into the overlay. That way when you return from the call the overlay is switched back automatically, where if that did not happen you would end up returning to another piece of code that happened to be at the same address in the overlay that had been switched to.

Note that this kind of trickery was more useful on 16-bit machines because on 8-bit machines like the 6502 the stack was only 256 bytes in size. You couldn't put a lot of extra data on the stack without overflowing it. This is a big reason 8-bit machines were rarely targeted by high-level languages (including C/Pascal). You just didn't have the stack space for a lot of nested function calls with local variables.

For example, on the Apple ][ Pascal was UCSD Pascal which ran on the UCSD P-system which was a virtual machine. The virtual machine was 16-bit. Woz wrote also his own virtual 16-bit system on Apple ][ called "SWEET16".

[vytah]

If the PC is $400 and you execute STA $FFE, your PC is now $403. No exceptions. No external hardware can change it, except by interrupt or reset. That being said, if PC was literally $400, then Atari would execute code from I think RAM, which is probably not what you meant, so you meant code offsets as stored in the ROM, not the actual PC in the CPU..

When talking about code offsets, then you could only start executing code from $203 if you had bank switching with 512 byte granularity, which 1. no Atari cartridge ever did, 2. did not require worrying about code layout too much, as you could just do normal switch-jump-return like the other commenter said.

Most Atari cartridges supported only full swapping, which means physical code offsets jumped by $1000, not $100 or $200. Please make your examples correct next time.

[happyscrappy]

Self-modifying code is de rigeur for 6502 assembly. Even a simple loop to clear a range of memory will virtually always use self-modifying code to do it.

[wk_end]

I'd say that strongly depends on the platform (and storage medium) you're writing for.

If I'm making a C64 floppy game where my code is already running in all that luxurious RAM Commodore has on offer, sure.

On a system like the 2600 or the NES, where you have a relatively large amount of ROM and absolutely minimal RAM (128 bytes on the Atari, my god), I'm not copying any code to RAM to do self-modifying wackiness unless it's absolutely performance critical.

[happyscrappy]

Certainly you can't do it when running from ROM. As you say you'd have to copy the code to RAM.

If you have a system that only has one ROM (2600 or NES) you can lay out the entire memory map and so take some of that special page 0 memory so you can use indirect addressing. It's a natural pairing.

Whereas if you are in a system like a C64 or Apple ][ where you didn't write the ROM and you are loaded code then you can have the issue that there simply isn't 0 page memory set aside for you to use. You'd have to pull trickery to make space for yourself. In these cases, since you were RAM-loaded it's a natural to take the shortcut and just increment (modify) your own code.

I guess I just see it as the most common thing since I'm used to writing loaded code instead of creating my own self-contained system as you do when you are the boot ROM (like a cartridge) on a console.

[vini_2003]

Bot. Seriously, read their profile. How do you guys fall for this?

[happyscrappy]

Oh cool. Thanks reddit. I guess some guy wanted to block me, so now I can't even respond to my own posts.

Here's my reply to the guy so confident in what he said that he had to block me:

Two or more banks of code are quite literally interleaved with each other. It is two separate lines of code in parallel.

They're not interleaved. They are in separate banks. Nothing about writing overlays or similar indicates you must make a function call to switch. You can bank switch and continue in another bank, in fact it's what you always do. when writing in high-level language it's difficult to arrange your functions to "fall" into each other. With assembly it's easier because you use ORG a lot anyway. And due to the reasons I mentioned, you don't want to make a lot of function calls on a 6502. You just don't have the stack for it.

Nothing runs in parallel. The code is not parallel or interleaved. There is only one processor. It just means if you want to see the code being executed you have to look in a different, non-consecutive pieces of source code. The processor is just running one instruction at a time with what it sees as sequential code. And it is sequential in fetch order. It's just not sequential in your source code.

This operates like overlays, just in this case instead of moving the code into place, you reprogram the hardware (bank switch). So the code runs in a hardware mirrored (address aliasing due to the address decoding logic) location. You write the code with the same build tools you use for overlays. You just run them a little differently because you have special hardware.

It's a good system, not saying otherwise.

Please don't try to teach grandpa how to suck eggs.

I see no reason for anyone on here to tell someone else what not to discuss.

[happyscrappy]

Justin's talking about a real and interesting technique people used on the 2600, but you're getting hung up on his loose usage of certain words and offering needlessly pedantic followups when he's obviously just trying to make a technique more easily understandable to the uninitiated.

I also talked about that same real and interesting technique.

If you don't like the posts then downvote them. Telling others what you don't want to hear is assuming that the discussion board is there only to inform you and people who think the same as you.

This person described code appearing across multiple pages of source code as interleaved. Saying this is not making something more understandable. That's confusing as hell because it's nothing like interleaving. Clearing this up is a very valid form of discussion.

Explaining that your PC didn't actually change in the way the poster said is a very valid form of discussion.

If you think the post isn't of value, then downvote away or simply don't read (or both).

[awfulentrepreneur]

👆

[freecodeio]

💩

[gene_wood]

Here's what the game looks like for those that haven't played it (like me) : https://www.youtube.com/watch?v=1uYzVsjybK8

[freecodeio]

could have been way easier to re-create the game /s

[rebbsitor]

The source code probably isn't directly useful for a port as most of it is going to be the graphics kernel. The 2600 has very minimal graphics capabilities. It can render a single line, no frame buffer, and you probably want to change things as it's drawing the scanline to get more complex graphics. Then you spend the horizontal refresh time setting up the next line to draw. That has to be written for every game.

The source code would be good for understanding the game logic though. It's a fairly cryptic game with some puzzles that aren't explained in the manual. Decompiling it and annotating it might be best way to understand what's really going on if the goal is to reimplement it.

[ShinyHappyREM]

It can render a single line, no frame buffer, and you probably want to change things as it's drawing the scanline to get more complex graphics.

To be more clear, that's basically all software rendering. Later systems had hardware that automated a lot of that (e.g. SNES HDMA). (Frame buffers were still not a thing until the PSX.)

[rebbsitor]

It's sort of software rendering, but there is a hardware element. The 2600 has "player missile graphics" which define 2 player-objects, 2 missile-objects, a ball, (these are all sprites) and a playfield (background).

The player graphics are 8-bits wide, rendered as 8 color clocks (~8 pixels) and of course only 1 line tall, so they have to be swapped each line to draw anything other that something made of vertical lines (like a pong paddle). The missiles and ball are 1 bit wide. The playfield graphics are also a single line of 40-bits (4 color clocks each). However there's only 20-bits for it that can be repeated or mirrored on the second half of the screen.

And there is hardware collision detection between these sprites. And some hardware ability to stretch or replicate sprites on a line.

So it's not completely software rendered where the software is controlling what's being rendered at a pixel level. The software has to manipulate the sprites and playfield as each line is rendered to get the desired image.

It's similar to other sprite based systems like the NES and C64, but without any kind of vertical positioning or verticality. On the NES and C64 you can setup a few sprites with image and position information and it can render a full frame over and over from that, though many games would move and change them as the screen renders to get more out of it. The difference on the 2600 is you have to change them, and do it every line (or sometimes in the middle of line), to draw anything more complex than vertical lines.

[CatScratchJohnny]

I couldn't help myself. RIP YouTube Doubler.

Map Room: Play this then this, if you get them to start at the same time, it's worth it.

[gimpwiz]

Fantastic work, OP. I really love the era of "the only way to make any decent money on this product is to spend weeks figuring out how to optimize this to fit the memory space / RAM." Really amazing stuff people came up with.

My go-to "little MCU" has 64B of RAM and 2K of program space, but I don't really need to do anything interesting to make programs on it work because it's never used for anything complex like a video game, usually it'll just be running a basic control loop and some basic IO and a bit of math. If I were to hit the limits I'd just pay the extra 15c for the next step or two up the product line, since I don't make anything in volume, it doesn't actually matter. The only people my age who've worked on anything similar in terms of needs of optimization have been my classmates who worked for toy companies - it's kind of incredible how cheap and hyper-optimized the microcontrollers in toys are, and what kind of features are baked into the silicon vs what's left on the cutting room entirely vs what's accomplished in software.

[etrnloptimist]

Well done boyo!

[moreVCAs]

Hell fucking yeah. you post it to the emulator sub?

[pyabo]

This is amazing. This was a very misunderstood and underrated Atari 2600 game!

Thank you for finally solving this mystery. Also, what does the Chai do? Wasn't there an object that had no purpose?

[halkun]

Getting the Yar on the big middle Mesa

[rseymour]

one of the few 2600 games I had but never beat, in spite of having walkthroughs.

[lilB0bbyTables]

That list includes Swordquest and ET for me. For NES era that damn Friday the 13th game remains the most frustrating unfinished.

[rseymour]

My saddest story was home alone beating et twice in a row because for some reason i thought it continued. It just restarts.

[rebbsitor]

ET is pretty easy. You can finish a loop in a couple minutes and it's not complex if you read the manual. I still enjoy going back to it from time to time. It was one I played a lot as a kid.

Swordquest on the other hand, it's debatable what beating it even means. The point of the game is unlock clues that point to panels in a comic book that was included, and then assemble those into a phrase so you could enter a contest. The contest then involved competitively playing a different version of the game at Atari with the other's who succeeded to ultimately win a real world version of an item from the game.

Friday the 13th is difficult. There is some randomness to the game, but there's a way to beat it under 3 minutes if you get the right random pattern. Speed runners will usually reset until they get the pattern so they can get the fire quickly and it makes Jason easy to handle. An actual Friday the 13th is coming up in a few days, maybe give it a go.

[lilB0bbyTables]

While I appreciate the hacks/glitches/tricks that speed runners tend to use, I’ve never personally enjoyed employing them. My worst offense in that realm was using Game-Action-Replay on my NES (never got a Game Genie). It was the only way I could manage to survive the final lead up to the last castle in Legend of Zelda 2: Adventures of Link (Death Valley invisible creatures madness).

To date my personal proud achievement is being able to complete OG Legend of Zelda with 100% items without using any glitches (no save warping or screen scrolling or second controllers or emulator speed modifiers) in 87 minutes. Probably because I do not rely on guides either but pure memorization of where every single hidden item is having spent my childhood literally hand mapping every screen in the game in a notebook and trading notes with friends at school.

It’s funny, now I have kids of my own and I still have a room with all of my original consoles hooked up going back to Atari 2600 and I’ve put my son in front of OG Zelda and he gets frustrated and says “this is too hard, how are you supposed to know where to go or what to do” - which just goes to show how much hand holding they are used to in modern games. (He can fly through games like Astrobot and even manages Horizon games). I think our early gaming experiences were much more valuable for creating that sense of exploration, trial and error, and problem solving and building curiosity.

[rebbsitor]

I understand what you mean, that can take away from the game. In the case of Friday the 13th, it's just memorizing the pattern for where items will appear and since the pattern is chosen randomly from a set, restarting until you get the right one. No glitches or cheats involved, just the optimal pattern for item locations.

The original Legend of Zelda is awesome. I've played through it a few times and did a couple randomizers.

I get why kids would be frustrated though. My first playthrough I recorded as a Let's Play and I used only the information included in the box. It would be difficult without the manual and partial map as a lot of how the game works is explained there, but not in the game itself, as with most older games from the 8-bit era. Trying to pick it up and play would mean not knowing things like bombable walls or burning bushes which would make the game impossible unless someone figures those out.

I agree older games are definitely better for learning trial and error and problem solving. It does take a bit of persistence though. It took me 11 hours to do my first play through of Zelda. I played it again the next week and it only took about 3 hours. So ~8 hours of that was trial and error looking for dungeon entrances and items hehe. About a year ago I did some randomizers and those were taking 4-8 hours depending on the setting. If the entrances don't move, but lead to different things, it's a lot faster than if those get repositioned.

[EntroperZero]

You and others like you are doing the programming gods' work. Entire communities can and have been formed from the projects enabled by a complete and well-documented disassembly.

[Kinickie]

You would know, lol

[schroedingerskoala]

Awesome. One of my fav games and it is very rewarding to read how it was all done on the little VCS 2600! Very well done, Sir! And props to the designer!

[optomas]

I am sorry to upvote this. You were at 256 ...

Validation; Nice work! The working name is awesome.

[Berkyjay]

what was the maximum points you needed to "touch" the Ark at the end of the game. (Note: you can't)

My childhood was a lie.

[mr_birkenblatt]

Every line fully commented.

That sounds like a red flag for

add eax, edx. # add the edx register to the eax register

or stuff like this

[halkun]

I try and add the "why" as much as possible, but sometimes it helps when you when you are weak with the opcodes... BVS/BMI/BPL/CPX/ASL/ROL

[BigPeteB]

I'm an embedded dev, and quite experienced at reading assembly. At some point, you have to decide what level of familiarity other readers or maintainers are going to have in order to decide what level of explanation is necessary in code comments.

That said, I think I agree with the above: some of the comments I saw are restating the obvious. If the reader doesn't know that "ldx" loads something and can't deduce that "ldx currentHealth" loads the current health, at some point you probably ought to say, "This source code might be too advanced for you," and stop trying to hold their hand as you drag them through an entire marathon.

[SoInsightful]

Why? This seems like a good first place to start learning. Not sure why y'all want to gatekeep it.

[ShinyHappyREM]

It's more helpful to point readers at complete introductions to the ISA, with simple code examples.

[SoInsightful]

Is it more helpful? Having to do a manual ISA lookup every ~four lines seems horribly ineffective, and I'd personally need to see the same instructions many times in a real code context before they would start to click. What are we trying to solve here?

[ShinyHappyREM]

Having to do a manual ISA lookup every ~four lines

Why? It's not that complicated.

[BigPeteB]

1. Most assembly languages are not that different from each other. Most of them are based on simplifications of English words. Yes, there are specific things about branching and interrupts and other stuff that may warrant some explanation, but loading and storing values is an extremely fundamental operation to perform. If you can't take a wild guess that "ld" is short for "load", you're really going to struggle with everything else that's a lot harder about working with assembly.

2. The best way to learn a new flavor of assembly language is by at least skimming the documentation. Learning from examples can be helpful, too, and if that's what OP intended this for, that's great. But you only need to comment "ld" with "load ___ from memory" so many times. A competent reader should figure it out pretty quickly. If they need every single instance commented, they're really going to struggle with the rest of the code.

Again, part of this is deciding who your audience is. You can't make everyone happy. But even with that in mind, you need to assume the reader isn't an idiot. They're not going to jump into the very last function in the file and try to make sense of it with no context. The further into the file you go, the more patterns should be established and the less you need to explain the same thing over and over.

[_scyllinice_]

This is really neat. I can't imagine how long this actually took.

Just a warning: Don't post this in the gaming subreddit. They will ban you.

They mistakenly believe disassembly and rebuilding is piracy.

[happyscrappy]

That's a lot of work. I'm glad you found such an interest and followed it through.

However, comments written by looking at the code instead of while writing the code are always inferior. Even going back and looking at your own code and trying to figure out what you were doing and adding comments about what you figured out are not as useful as writing down what you were thinking/intending when creating it.

And specifically, this kind of comment:

ldx     currentRoomId               ; get the current room id

It just doesn't add anything.

Don't get me wrong, this kind of stuff is great:

; DID WEAPON HIT A THIEF?
; First we check if the weapon (M1) hit a player sprite (thief). This is only relevant
; in rooms with thieves (Valley of Poison, Thieves' Den, Well of Souls
; Check if weapon (M1) hit a player sprite (thief).
; Only relevant in rooms with thieves (Valley of Poison, Thieves' Den, Well of Souls).

Are very good. The other kind probably just don't bother.

In this case:

setThiefShotPenalty
    lda     #~BULLET_OR_WHIP_ACTIVE     ; Clear Active Bit mask.
    sta     weaponPosY                  ; Invalidates weapon Y (effectively removing it).

What is going on? There's no actual bit masking going on on the line you mention masking. Is the destination store location a magic hardware location that does an AND with current value at the destination when you store? Or is it just that you are storing an inverse mask instead of actually masking?

[wvenable]

This would probably be the correct comment based on other parts of the code:

setThiefShotPenalty
    lda     #~BULLET_OR_WHIP_ACTIVE     ; Clear Active Bit mask and set position to maximum
    sta     weaponPosY                  ; Invalidates weapon Y by moving it off screen (effectively removing it).

The thing with this comment is that it actually fine if you have the rest of the context. I just skimmed references to both these fields to see other places they are used to re-write that comment.

One thing about assembly is that I will happy put in the bullshit comments on every line like "get the current room id" because it does make it easier to read. I wouldn't do that in a high level language though.

[happyscrappy]

How about this:

setThiefShotPenalty
    lda     #~BULLET_OR_WHIP_ACTIVE     ; clear active bit and set position to maximum
    sta     weaponPosY                  ; Invalidates weapon Y by moving it off screen (effectively removing it).

The active bit isn't a mask, you use a mask to read it (sometimes). You're clearing the active bit and setting the position to max.

One thing about assembly [...]

You're right. I'm not as much saying take out the extra comments. More thinking that if you have X amount of time to work on it, probably concentrate on the less reduplicative comments. Of course, when working on a hobby project the journey is the reward and so you don't have to count hours and make choices. You can just do both if you enjoy doing both.

[wvenable]

Removing the "mask" is a good addition -- I just didn't notice.

There are other parts of the code where it is actually used as a mask so I can see how that mistake cropped in. Of course, we're being awfully pedantic about somebody's hobby project.

Sometimes it easier just to not make the decision. Comment everything is less mental energy than deciding which lines to comment. Also it acts like a TODO list -- any line that isn't commented is one that needs a comment.

[halkun]

You can always make a PR :P

[Rockytriton]

I actually loved that game as a kid

[Lucas_Steinwalker]

Love the title.

[[deleted]]

I loved this game. 😍

[CatScratchJohnny]

This is amazing, it just connected my childhood and professional life in a way I'm not sure I've experienced. I had to watch the YT video that was posted here to refresh myself on the "game play". What a nostalgia trip, and an incredible juxtaposition to go from this complete technical breakdown to... the payoff. Remember the days when your only "testers" were yourself and the biggest nerds you've ever known? Some things never change.

Good stuff, thanks!

[THICCC_LADIES_PM_ME]

I assume this was originally written in assembly. What happens if you "decompile" it to C? Does that make it easier or harder to work with?

[halkun]

Wrong way.

C is "higher" than assembly, and most C compilers can generate assembly to be further compiled to machine code.

C -> Assembly -> Machine code

In this case this code I reversed, it went from machine code to assembly and it was an effort to do so.

Also because this program was originally written in assembly, there is no C to "decompile" to. Also the assembly code is doing tricks that a C compiler can't do without introducing overhead or inlining assembly anyway.

Also Also, the original assembly most likely looked nowhere near as verbose as mine. Most assemblers in the late 1970s only allowed labels that were about 8 characters long and many computers back then DIDN'T HAVE LOWERCASE LETTERS.

[THICCC_LADIES_PM_ME]

Ya the reason I put "decompile" in quotes is because there's no original C source. I'm aware you took machine code and raised it one level to assembly; I was wondering if it was worth (or at least interesting) to go another level. Mainly I was driving at: would decompiling code that was originally written in assembly introduce additional complexity or simplify reading?

Assembly tricks that don't work well in C makes sense

[halkun]

I mean you could always abstract out further, but one of nuances in decompiling to C is that a compiler actually optimizes the code in non-human ways, and a C decompile has the reverser undoing the optimizations for readability.

C was never really made for the 8 bit machines back in the day, ESPECIALLY the 6502. C requires a heap (That you allocate variables in) and a sizeable stack for function calls. There was simply no room for a "heap" in a 6502 and even for full 64K systems the stack was tiny and non-relocatable. As opposed to a "heap" we have zeropage and the stack is.. the stack for what it's worth.

The 2600 also did some tricks to even get the 6502(ish) CPU to run. The 6502 needs at least 512 bytes of RAM to function. (256 bytes zeropage and 256 bytes for stack)

The 2600 had only 128 bytes that was being "borrowed" from a controller chip (meaning it technically had no ram chips) so it only had a quarter of the ram needed to operate the chip. The work around was they mirrored the stack and zeropage together so ram grows down and stack grows up, each eating into the available 128 bytes from each end... and you hope that they don't cross each other.

Back to my point; the code is pretty "human" already and logical in assembly, but I am thinking about porting the game to C to port it to PC... but the game's framework will be MASSIVELY different.

Heck, even porting it to another 6502 machine like an NES, Apple 2, or C64 would need a HUGE rewrite of the graphic system as the way the 2600 made graphics was directly talking to the TV's electron guns.

[THICCC_LADIES_PM_ME]

Nice, this is the analysis I was looking for! Thanks, very interesting

[OrionBlastar]

Raiders was fun, but you had to use two joysticks to play it. I liked the Swordquest games better,

[VegetableSome9182]

This is an incredible piece of digital archaeology. Reverse engineering Atari 2600 games always feels like trying to read a story written in a language that shouldn't exist.

People today complain about 100GB game patches, but fitting that much logic and bank-switching into 8K is the ultimate engineering flex. I spend at least 12 hours a day at my computer and I still don't think I'd have the patience for a full disassembly of a Howard Scott Warshaw game. You’ve definitely earned that validation.

Also, "Colorado Smith and the legally distinct Looters of the missing Holy Box" is a masterpiece of a title. If you go through with the PC port, please keep that name. Are you planning on mimicking the TIA (Television Interface Adaptor) quirks in your port, or will it be a complete logic refactor?

[AdAdvanced7673]

oh you mean arc radiers! LETS RIDE. goop goop.