6502.org

There might be an element of that; wrestling with a problem can be fun. That said, I find it deeply satisfying when something just works first time.

For many situations, I find my programs are more likely to work right the first time and less likely to show up bugs later if I take the time to optimize first and make it as short and clear as reasonably possible. When I've taken the attitude of "Just get it working," often those are the times I've ended up having to re-write it.

An hour-long video about the Oberon language has a couple of quotes I really liked (at around 36 minutes into in, give or take):

• Programs must not be regarded as code for computers, but as literature for humans.
• Reducing size and complexity is the triumph.

I've used this in the past, taken from someone else who mentioned it.

In this context, not so much that writing was like composing music, but more that music doesn't sound like anything when written on a page, you have to hear it. Similarly, especially for end users, getting them involved early in the development process lets them see and feel what the system is doing, vs just getting a spec (however detailed), crunching on it, and delivering in 6 months a system that does exactly what they asked for, but not what they wanted.

Similarly, it reminds me of this quote from Amadeus:

Thanks, I got my hands on a copy.

How is a tracing disassembler different from an ordinary disassembler? Is there a good open source Linux friendly tracing disassassembler that is ideal for my use case with the C64?

This topic might be helpful: Looking for a disassembler and suitable assembler

Thanks!

I'm developing mine with the C64 in mind. Check my sig, and the thread for it. (description of tracing here, nice screenshots here)

In essence, a tracing disassembler uses known entry points to the code to search out which parts of the binary contain actual instructions, and which are just embedded data, following branches and jumps and subroutine calls. An ordinary disassembler just starts at the beginning and tries to guess, byte by byte, whether it's looking at a real instruction or not.

Neither type is perfect, but I think tracing disassemblers are potentially much more useful when used correctly. I've had good results with White Flame's interactive one, though it's annoying that it only supports displaying PETSCII text, rather than also supporting the far more common ASCII.

I've found two major sticking points with tracing disassemblers. One is indirect jumps through dynamically determined addresses, which the tracer can't follow; in that case you have to manually determine which addresses can be jumped to, and make sure a trace begins from each one. The other is subroutines and BRK handlers which alter the return address before the corresponding RTS or RTI, for example to use inline data placed immediately after the call. BBC BASIC uses BRK in this way as an exception mechanism to report errors, and encourages machine-code routines for the BBC Micro to do the same. I've seen JSR used similarly, possibly inspired by that, but the trace continues past the JSR and has to be manually corrected to skip over the inline data.

The reason for these limitations is that the tracer doesn't actually execute the code; it just determines the length of each instruction, identifies which ones are branches, and uses those to decide where to begin new traces and halt existing ones. This is enough to correctly trace "conventionally written" code without any indirect jumps in it, but can't use any information about the dynamic contents of RAM.

This is sitting on my desk as I write, frayed and dog eared, but still in serviceable condition. Not a bad text. I also have Rodnay Zaks "6502 applications book" by Sybex Press ISBN 0-89588-015-6 which is handy for interfacing and goes through many of the 65XX peripheral chips and how to program them.

Both books have been with me since 1981. That seems like a very long time ago.

I see dead people ...

It's not a virus - it's a worm!

On a slightly more serious note than my last post here..

I learned about the 6502 from "The Red Book" - aka the 1978 Apple II Reference Manual. I still have that - it's worn, torn and held together with tape... I also have the Synertek Programming manual. Those and nothing more than a CALL -151 and I was off... (I even used the Apple Mini-Assembler too; F666G)

I latterly bought the Wozpac II - hard to get in the UK in those days and I really don't recall how I managed to pay for it in US$ from the UK either - I suspect my bank charged me an arm and a leg for it, as they do today (so nothing changes there) I also had at about the same time The Rockwell R6500 Hardware Manual (although the binding glue is brittle in that one - interesting to open it at the breaks - the 6522 is prominent!

These books aren't really programming manuals though, although I did learn a lot from the assembly listing the the Red book and my early experiments were all to do with making some sound effects on the Apple II speaker from assembly code.

For the OP - I'd dive in and write some code. Just do it, play with it, see what happens and have some fun, then you can go back to the disassembly and see how you might do that in your code or style - everyone is different

-Gordon

At least you guys had reference manuals to work with. When I started with the 6502, manuals had yet to be written. I worked off typewritten notes gotten from MOS Technology.

I think learning by doing is the best way for most people, it's a question of how much support you get, how much confidence you have, and how much effort it then takes.