LeChuck

Awesome! I re-ordered this and the 6502 book to get the coils and latest updates. Gives me an excuse to keep the old set at work for reading while compiling

Hurrah on the updates, my procrastination paid off! Just ordered this and the 6502 book. How well do these stay open on the table? I usually print things like this out with spiral binding so they lay flat .. but decided to get the books since they look nice and are so inexpensive. LeChuck

Hope everyone is doing well! Any disassembling going on lately? I said I wouldn't let the pandemic stop me from finishing Space Invaders, but I admit it has been hard to focus on projects like this while the world is on fire around me. Anyway, I picked my latest code back up and started going through it again this week. The only thing it really lacks are meaningful labels/defines and a few small TBD code/data areas I marked before .. so luckily is still practically done! Just to throw another bone out in the meantime .. - The code uses bitmaps to store the remaining invaders in each row. These bitmaps gets shifted over to the right as needed so that bit 0 corresponds to the leftmost column that still has invaders remaining. - The code also has a variable that tracks the bottom-most row that still has invaders remaining. Among other reasons, it uses this to know how many rows of invaders to draw. - Both of these get updated immediately when you shoot an invader. This creates a graphic glitch when you kill the last remaining invader in the leftmost column or in the bottom row - since the code is no longer processing those rows/columns, the invader goes to black immediately and never gets a death animation. I've seen that glitch my whole life, it was interesting to find out why. There are a million little gems like that in here. Hopefully I can actually finish this soon and make a thread to describe the findings .. LeChuck

Cool - it's kind of sad how long I've had it to being almost ready to post. The house flood of 2017 really screwed things up momentum-wise, it took a couple years to fully recover from that. Luckily I took a lot of notes of the higher-level algorithms, register usage, etc so it's pretty easy to pick back up.

I would probably do a single repository too, with all the games in their own folders under there. If these were larger, more involved projects separate repositories would make more sense. Nice to be able to clone once and get everything in one swipe!

Every time I start to get back into polishing off Space Invaders for posting online, something happens. It's done and just needs labels / comments / cleanup - I'm not letting this damn pandemic get in my way! Anyone working on any disassemblies lately?

Good question, I've been wondering the same. I plan to make a GitHub repository for mine, like DEBRO is doing with his. It would be nice to have a master list or collection somewhere.

Oh boy, I am horrible at time estimations. We had a medical issue in the family, so yet another year has flown by. Time to polish off Space Invaders and get it posted before something else happens (the gods must not want it to get out) Anyone else working on disassemblies lately?

It was wishful thinking to have this done by end of January - I'm still finishing insurance haggling for this flood and unpacking boxes! Anyway, this is still on my todo list once things get back to normal. Hopefully in the next couple months .. it is on the cusp of being complete!

Regarding Space Invaders - it does indeed update GRPx on the fly for each individual invader in a row (it must do this, since any one could be shot or showing a death animation frame). It also interweaves P0 and P1 to give more time for the updates - i.e. P0 P1 P0 P1 P0 P1, hitting GRP0/GRP1 alternately. I haven't seen the Coke Win! demo, but given enough code/data/time between rows you could certainly have individual bitmaps.

Indeed. The missing initialization would normally happen when it processes being in the game select state .. so it wasn't designed to go straight into starting a new game without running that atleast once. We had a broken toilet line flood the house, so I'm behind on finishing this labeling/cleanup. Hopefully by end of January or so .. uggh

I'll post the gory details when I start a new thread. But the short answer is that if you power up with the reset switch held, it leaves a byte of game selection flags uninitialized .. so it thinks you're in the variation with two players firing simultaneously. And due to the state of two other flags, it allows player 0 to take both of the potential shots. Cool TODO list, hope you don't have any other plans

At the risk of being horrified, my first commented disassembly had to be Space Invaders. I know there is the SI Deluxe hack with some comments, and a few other hacks with comments, but I wanted to go 100% on the original binary (every RAM bit, every instruction, every table accounted for). I've searched for this periodically out of paranoia, but I haven't seen it done yet .. which is very surprising considering the popularity. Anyway, being on vacation this week I finally finished it - hurrah! Now I'm in the stage of polishing off the file, renaming labels, and other cleanup before posting. As part of this I wanted to explain a few things I've always wondered about too (besides the overall logic flow and object usage) - the double shot trick, why some invaders don't display a death animation, how it randomly breaks up the shield bits on collisions, etc. I'll start a new thread when it's ready so I can systematically brain dump everything I've learned going through the code. Not sure which game will be next. Some of my other favorites have already been done (Combat, E.T., Pitfall, Asteroids, Superman) .. maybe Pac-Man, Journey:Escape, Spider-Man, Missile Command, or .. Dennis - Out of curiosity, what is on your TODO list?

I learned x86 assembly in high school using a Peter Norton book from the library. Like most good tutorials, it started out assuming you know nothing and built onto a project piece by piece. It also got you familiar with using a debugger, which is just as important as being able to write and build code. I learned Motorola 6800 assembly from college classes, and various other instruction sets from work and side projects. The suggestions above are spot-on - find a good book or online tutorial, get a simple program building, and start experimenting and stepping through your code with a debugger.

Yep, I suspect we all go about this in mostly similar methods. Reminds me of following electromechanical pinball schematics - start with the lights (or other obvious landmarks) and work backwards. Are there any commented disassembly conventions around here? For now I'm doing everything in my personal style, but I could adjust it before posting if it would make it easier to follow for others here. I read DEBRO's disassembly of Basketball recently, that looked nice. As far as my disassembly - I'd probably call it 85% now (I'm afraid to mention which game it is - I'm pretty sure it hasn't been done, but I'd be horrified if I found out it was before I finished). Some logic and RAM usage tackled every session, can't wait to finish .. hopefully by the new year, or shortly after.