Beginner's Guide to Disassembling 6502 Binaries
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- This video walks through the disassembly of the Commodore PET Space Invaders 6502 executable. It starts with an explanation of assembly language and how that is converted to machine language that can be executed by the CPU. It then walks through an example disassembly of the Space Invaders Commodore PRG file step by step, resulting in a final disassembly that can be modified and re-assembled to a working game.
You can download the disassembled Space Invaders code here:
www.commodore.i...
What a fantastic way of explaining this, Dave. Absolutely loved how you paced and connected everythign together in a very digestible format.
Awe man, this was a great comment to read. Thank you so much for watching and for taking the time to share positive feedback!
And that‘s why people wrote disassembler tools, kids, because ain‘t nobody has time to do this manually… 😜
Timely video from my perspective! Back into 6502 after decades and loving it. Great video editing skills, btw, very polished episode.
Thank you for regularly watching my stuff and always leaving kind comments. I really appreciate it!
Hi there. I'm not a PET guy or a 6502 guy but I am an 8-bit guy and a disassembler guy and a retrocomputing guy (-:
Are there any ways to tell if a .PRG file is for PET, VIC-20, or C64, or probably also C16 & Plus4? Do .PRG files always contain BASIC like this one or do they sometimes contain just machine code?
Commodore's prg file format really is as simple as "two bytes for the load address, then the binary data that gets loaded to that address". There's no metadata that would explicitly tell you which computer a prg file is for, but there are some clues. If the prg file contains BASIC tokens, you'd be able to tell which computer it's for by the load address, since the start of BASIC is known for the PET, VIC-20 and C64. The prg could certainly contain only machine language and no BASIC tokens. The tokenized BASIC you see in the Space Invaders code was there as a convenience to users so they wouldn't have to type a SYS command to launch the program.
I also would not be surprised if microdigital and the other companies still making 6502s [and yes you can buy a new 6502 today (well maybe not literally today today , but you know what I mean)] I have an instruction set appendix in them as well. I think Intel has their instruction reference on their website for free.
Now, that is impressive. Well done!
Thanks! I hope you enjoyed watching.
Does anyone know if KERNAL source code for the original Commodore PET is available? Original , not disassembly.
I've not run across it thus far.
I did something like this many years ago after graduating but before I started work to disassemble the Sinclair QL ROM. I used QLMON to do the dissasembly along with a lot of books to know what the system calls were. It was an interesting exercise but gave up eventually as I started a new job. I am curious what all those NOPs were at the beginning though, Scratch space, self modifying code or what?
Sounds like a fun project you were working on! I’m guessing the reason for the NOPs at the beginning was he wrote the machine language before the basic loader and didn’t know exactly how many bytes the basic loader would consume, so he started his assembly at $040F and padded from $0401-$040E with NOP. Then he added the BASIC loader at $0401 and left the intervening NOPs.
At #08:50 - Instead of LDX #$00 you could just write LDX #0. Same with the zero byte for the text string. A simple 0 would do.
You just typed 127 characters to tell me that I should have typed 1 fewer character.
@@commodorehistory - that, and to clarify to the viewers that there is no need to complicate things by indicating that "the next number is hexadecimal 0 so we write $00" when decimal 0 is the same and that a simple 0 would do.
22:52 Why should you need to recalculate the BNE address? It's only absolute in the assembly code, in machine code it's a relative jump which remains valid in relocated code (unless there is new code inserted between the branch and the target.)
But anyway, thanks for this very interesting video!
Totally right - I even mentioned that they’re relative earlier in the video. Good catch!
…except I guess since it was disassembled to an absolute address, when you reassemble the assembler would calculate the relative branch based on an incorrect absolute address.
@@commodorehistory That’s true.
Great video. Sub'd of course. Whenever I see 6502-related stuff on YT I have to immediately jmp straight to it like a nerd. Started my journey into assembly a few years ago but still have much to learn. Look forward to catching up with the rest of your videos. By the way, I wonder why they used so many NOP's at the beginning of their code?
Hey there piggy! Thanks for the kind feedback. I am guessing they just padded the beginning with NOPs because they didn't know exactly how big the basic loader would be, then they never went back and took them out, but that's a guess.
This guy sounds exactly like the American scientist from The Fast Show 😂
No way. That guy has been copying my act for years!
Awesome video, I really enjoyed it! I have had the mental thought process of disassembling before, and I am glad to see I was not terribly far off. I really am enjoying your channel, so you have my sub now!
Thanks for watching, and thanks for the sub! Let me know if there’s anything else you’d like to see.
'promosm' 😔
Fantastic explanation of the whole process.
One thing I was wondering about were the 9 NOP instructions at the beginning of the program. Do you know why they're there?
I was wondering whether that might be space for some self-modifying code?
Thanks for the kind words!! My best guess as to why the leading NOPs are there was just padding to allow the BASIC loader to be plugged in after the assembly code was done.
dude, i'm more impressed with your vi skills. my adhd brain wont allow me learn stuff like this unfortunately. i just cant help to quickly edit with whatever is most convenient. insert, delete and quit-save thats all i can do with vi.
You’ve got most of what you need to do with an editor covered then. I’ve been using vi my entire career, so a lot of it is muscle memory now.
Wow! New subscriber here, this is really usesful, thank you
Hey, thanks for subscribing! Hope you enjoy my content.
zamzam water
IIRC you can load label files into VICE so that the disassembler shows the actual labels
good to know. Thanks Andre!
I’ve disassembled 6502 for Gottleib System 80a pinball machines. I’ve disassembled (and written) tons of Z80 code but 6502, not much.
I’ve been trying for years to find assembly to load and save areas of memory from disk , do you know any examples of this in assembler?
Depending what you're looking for, any of the Commodore machine language monitors should be able to do what you have in mind. They all can save areas of memory to disk. Give it a try! If you have questions, ask.
@@commodorehistoryin a running assembler program not interactively, yes quite easy in a monitor just s name dev mem
Love that you use vi :-)
vi is a hard habit to break :)
Great that it does search and replace via regular expressions for this video though.
At #23:41 - I am a bit surprised that you were able to do a search and replace of $0428 without having to escape the $-sign.
Very cool Dave. Nice work! And thanks for showing the process.
Thanks NotaWizard! I appreciate you watching and taking the time to comment!
@@commodorehistory all good. btw I think that one of my comments was marked as spam as it had a github link in it. I wanted to edit it to change the word opcode to mnemonic in one place but it wouldn't let me. :)
At #31:00 - I think it is a mistake at this point to add a new instruction to initialize the Y register. The safe method is to keep the code identical to the original, and compare the newly assembled binary code with original and make sure they are identical.
That is certainly *not* the safe method. For the code to be relocatable, you cannot assume the low byte of the address will be zero. If you don’t explicitly set the Y register to 0 you’re risking the code not working. The only reason not to set it would be if your goal was not relocation but to be able to assemble an exact copy of the original binary. That’s explicitly not my goal.
@@commodorehistory - it is the safe method AT THIS POINT. At this point your goal is to prove that you assemble the symbolic code into a binary that exactly matches the original. Only then is it safe to make changes to the code to ensure that it is safe to relocate.
By the way, instead of messing with the setup code, I would look at the documentation for the assembler and see if there was a directive to force a data segment to start at a page boundary.
Guess what? I just had a look at the tass64 manual. The .alignind directive will do the trick.
Ah, got it. I thought you meant not to fix it at all. Fair point then.