6502.org

Hey folks!

I'm half way though Jim Butterfield's book on Machine Language for the Commodore 64 and Other Computers. Someone here recommended the book and I'm grateful they did. It's typically very easy to follow. I'm going back over the chapter on addressing modes for a 3rd time just to make sure I really get it. The book is about 50% instructional, the rest of it is an extensive series of apendicies.

Once I'm done with this book, what book should I pick up next? I'm just trying to plan ahead.

My goal is to be able to disassemble C64 programs and work backwards until I have a fully functional code base that I can use to reassemble the original binary byte-for-byte accurately. Maybe that's pie in the sky, but help me out here. Once I'm done with Butterfield's book, what should I be reading next to further that goal? I understand this is going to take time and effort and none of this is magic.

Are you doing any assembly language coding of your own? I'd say it's very important to put what you're learning into practice! There's a world of difference between being in the driver's seat and simply being an observer. If you aren't able to play with a real, flesh and blood 65xx you can use any of several simulators available.

My own learning experience was very "hands on" and for me that proved very successful. But one book I can heartily recommend is the mcs6500 family programming manual.

-- Jeff

Yes, albeit simple stuff like changing boarder colors to simulate a phosopor display. Right now I'm writing a faux BSoD program for the C64. It's just a gag: a two byte memory address generated at random and a fake processor error. This is requiring me to figure out how to get a random number. (I haven't figured that out, yet.) The errors will be humorous. "Zero page has been eaten by a grue," that sort of thing.

8 bit random number generators were discussed here.

Cheers,
Jim

I haven't gotten around to reading that one. I'll give it a look.
I learned with Programming the 6502 by Rodnay Zaks and the C64 Programmers Reference Guide.

This isn't necessarily hard with a decent start using a tracing disassembler.

But on complicated systems, using overlays and such, these can be much more difficult.

It's also potentially difficult to get the data organized in to anything remotely human, rather than as an opaque data blob that still assembles properly. Because, in the end, the assembler doesn't really care.

But even if you get that far doesn't mean that you understand the code, as there are several idioms that manifest in different ways within the program. Grasping these larger concepts can require more than what most of the assembly books will teach you, as they're more about data encoding, data structures, and other things not necessarily specific to assembly language programming.

Arguably, the best thing to look at next is any documented assembly code and try to suss that out -- which can be difficult even when it's documented -- so that you can try to apply what you see in those programs to the blob of bytes and pages of instructions that a disassembly will start you with.

I learned with Scanlon's "6502 Software Design" ISBN 0672216566 and the Apple ][+ built-in machine language monitor "CALL-151". My ][+ is gone (whereabouts unknown), but I still very much enjoy using the emulators. My book is still with me, but I no longer grab it first to look something up, because it's precariously held together by a vintage Apple black paper textbook cover, since the binding disintegrated many years ago from many hundreds of uses.

I completely agree with Jeff.

The best way to learn 6502 assembly language—any programming language, in fact—is by writing programs, running them and when they blow up (which they will do until you get the hang of it), figuring out where you went wrong. I fail to see how disassembling and reassembling the Commodore 64 firmware is going to teach you how to program. That's akin to attempting to learn how to play music by disassembling and reassembling a pipe organ.

Yep. This is definitely a contact sport.

I thought I got "the hang of it" many years ago, but my initial attempts still have a strong tendency to "blow up". I think I know why too ... premature optimization. Hugh Aguilar recently brought my attention to a quote that I hadn't seen before, but that seems to ring true, at least for me ... unfortunately, I haven't yet been able to rid myself of this ailment:

I hate when that happens.

Yeah, same with me. Do you think maybe we're subconsciously just thrill seekers ? After all, premature optimization is fun -- and it's kinda exciting when things blow up. The alternative is so boring. The stuff just works. Unless some darn grue comes along and eats zero page, I mean.

I tend to describe programming as a craft. It involves lots of creative solutions, and exploring what can be done with the tools; in addition to the engineering skills one needs in order to understand and effectively use the tools in the first place.

There's a lot to be learned form others' creative solutions, but as expressed above, you need to hone your own creative application of them as well. This is exercised even in simply figuring out how to reimplement or integrate others' solutions into your own code.

With the 65C816, those grues can really wreak havoc when you have pointed DP at the stack and your stack pointer arithmetic has "issues."
I see writing software, especially at the bare metal level, to be more like composing music.

All I see is blonde, brunette, red-head ...



-Gordon