development tools • NARD: Not A Real Disassembler

While I was trying to write a(nother) Perl script to work with BBC disc images that would ultimately analyse the contents of a disc image and determine what each file in it might be, I spent too long -- or maybe not enough time -- thinking about how to tell what might be a 6502 machine code program. I eventually settled on the idea of looking for continuous runs of valid instructions ending with a break in the flow of execution, such as RTS, JMP or a conditional branch.

And it somehow turned into this: This is a zip archive with a copy of the script and some demonstration files to explain it:

• hello_world.6502 -- the original BeebASM source code
• HELLO -- the 6502 program generated from it
• hello_1.ssd -- a disc image with HELLO
• nard -- itself

nard is not a real disassembler, insofar as it takes some detective work to track down where code really begins and ends, and lots of manual work renaming labels. It doesn't do any kind of stateful analysis of the code it's looking at. All it is doing is looking for a block of valid instructions, that ends with RTS, RTI, JMP or Bxx (i.e., a conditional branch). But not JSR, because the next RTS encountered will cause execution to resume at the next location. Only when a block of code ends cleanly with a change in the flow of execution is it considered legitimate.

What it can do is, take a file extracted from a disc image; search for chunks of 6502 machine code; and produce a file of BeebAsm-compatible 6502 assembly language code, which will assemble to produce a binary file which is byte-for-byte identical to the original input file. You can rename any of the temporary labels it assigns.

Once you have unzipped the above, open a shell, cd to the folder and typeThe -i parameter is the input file, and -l is the load address. 0x indicates a hex constant (because & and $ have special menings to the shell). You can optionally specify an execution address with -e, but in this case, it's the same as the load address.

You should see the following output:Note it's all been considered "not code", because the code does not end cleanly on a change of flow before the first invalid instruction. But we can see an RTS at &090D; so we can set a gap here. This time, run-g specifies a gap. The first address is the start of the gap, there is a comma as a delimiter, and the second address is the first after the gap. Just like *SAVE . If you want to specify multiple gaps, you will have to separate them with spaces; which can either be individually escaped with backslashes, or else put the whole lot in speech marks; -g "start1,end1 start2,end2"

This will give the following output:This is looking good, but we can do better.

Notice that labels have been assigned at the start of the code, and to every address in an instruction operand. These are of the form tl and a series of hex digits. We can use the parameter -o filename to generate a JSON file with the labels (which will also contain the gap definitions, so we can omit the -g parameter when we come to reload it); edit the JSON to give the labels more meaningful names; and then use the parameter -j filename to load this JSON file back in. We can also use -a filename to create a BeebAsm source file.The JSON will look something like this:though the order may be different, as the JSON object is implemented as a Perl hash, and the ordering of hash elements is subject to change. Addresses are given in decimal, but it is actually possible to specify hex constants with & or 0x.

And here's what the assembler output hello_again.6502 might look like with some renaming of labels:[/code]This will assemble to create a file hello.rec which will be a faithful recreation of HELLO.

There's still more work to do, changing runs of EQUBs of printable characters to single EQUS statements and allowing dot-labels in not-code sections. I was just desperate enough to be delighted when it worked at all.

Statistics: Posted by julie_m — Wed Oct 01, 2025 11:38 pm

---