Hi everyone,
This is my first post, so please forgive if this is a really dumb question!

I am trying to reverse engineer the code for a Commodore CBM2022/2023/3022 printer. I have the ROM image and I have used various disassemblers.
In the most part, the output makes sense but I am having trouble understanding some of the branch addresses as they seem to be in the middle of instructions, which from my understanding, is not correct.

Here are some examples:

From http://www.white-flame.com/wfdis/:

Example 1. This appears to not have disassembled the BIT instructions correct to force the branch address to a valid location: (2c and 24 appear to be the starting byte of BIT operations)



Example 2: This time the address is marked differently from the usual format (I assume 'Lf9f8 = * + 1' means 1 byte offset into where it should be)



I tried a different disassemler, https://www.masswerk.at/6502/disassembler.html
and got a different output:



This time is disassembled the code correct, but there are branches to address 06D3 which is in the 'middle' of the BIT operation.

I then tried, BeeDis and got a similar result:




So, I'm stumped. I thought that branches should always jump to the start of an instruction, not into the middle of one.
Does anyone know what's going on here?
Thank you

The rom is available from here: https://www.commodore.ca/manuals/funet/ ... dex-t.html

Jumping into the middle of an instruction is a trick often used to reduce the number of branches in code.

In your first code example, jumping to Lf3d5 sets the carry flag and returns.

Jumping to Lf3d3 clears the carry flag and returns.

Jumping to Lf3d0 clears the accumulator and returns, leaving the carry flag alone.

Ah ha! Thanks BillG, That makes sense now.

So if I wanted to create source code that I could then compile, from my disassembled code, what would I do in this case? (I assume I would need to expand it out to more than one branch. And that this code is the result of a compiler optimisation trick?)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That is most likely hand-written assembly language code. Compilers tend not to jump into the middle of instructions like that.

I would comment your code something like this:



I previously missed the fact that the first bit instruction is absolute mode; jumping to LF6D0 also sets the carry flag

System calls in Apple ProDOS are like that:


Another common technique is putting a text string inline:

Turbo Pascal for CP/M does this extensively.