I have been using 6502Workbench to investigate code and I don’t understand
why it appears to be consistent.
Some parts of the code are cleanly disassembled, others are not (Eg after a
jmp) but later portions are cleanly disassembled again - why doesn’t it do
the lot?. I can get through this by manually ‘hint’ing at code for clean
disassembly.
But then sometimes after I ‘hint’ at code the opcodes have triangles (see
picture) and the lines on the left are bytes and the code is not clean.
What is going on? How do I fix this?

https://www.flickr.com/photos/10917598@N06/51425367908

Thanks
Andrew

Are you sure that it's code that you're manually forcing 6502bench to disassemble? Perhaps it's just data?

On Saturday, September 4, 2021 at 8:04:26 PM UTC-7, Andrew Roughan wrote:
> But then sometimes after I ‘hint’ at code the opcodes have triangles (see
> picture) and the lines on the left are bytes and the code is not clean.
> What is going on? How do I fix this?

Bear in mind that SourceGen is a code-tracing disassembler. It starts from "code start" points, and traces code as far as it can go. For simple programs this will cleanly separate code and data. For programs with indirect jumps and inline data elements, you will need to explicitly mark the places where execution starts or that hold inline data following a JSR. (There are features for formatting jump tables and common inline data formats that make those easy.)

Looking at the attributes column, you have put "code start point" tags on every byte. SourceGen did what you told it to and made EVERY BYTE a place where execution starts, including the bytes in the middle of earlier instructions.

Code often does this deliberately. For example, in Applesoft at https://6502disassembly.com/a2-rom/Applesoft.html#SymPOP :

d979: a2 16 ldx #ERR_NOGOSUB
d97b: 2c bit ▼ $5aa2 ;fake: BIT xxxx skips ahead to JMP ERROR
d97c: a2 5a UNDERR ldx #ERR_UNDEFSTAT

Code executing straight through will LDX #$16 and then BIT $5AA2, but code branching into the middle of the instruction will do LDX #$5A. SourceGen shows both paths, alerting you to the presence of an embedded instruction by showing a triangle next to the opcode. The above code doesn't use any attributes, because the code tracer identified both execution paths automatically. (The triangle bit is explained in the tutorial: https://6502bench.com/sgtutorial/odds-ends.html .)

What you need to do is select all of the code in that picture, Ctrl+H Ctrl+R to remove the tags, and then put a code start attribute ONLY on the place where the code starts.

Code start attributes are meant to be applied sparingly. Assuming you're using a recent version (currently v1.7.5), you should have received a warning when you applied the hint that what you were attempting (adding the tags to multiple bytes) was rarely a good idea.

fadden <thefadden@gmail.com> wrote:
> (The triangle bit is explained in the tutorial:
> https://6502bench.com/sgtutorial/odds-ends.html .)
>
> What you need to do is select all of the code in that picture, Ctrl+H
> Ctrl+R to remove the tags, and then put a code start attribute ONLY on
> the place where the code starts.
>
> Code start attributes are meant to be applied sparingly.

Thanks Andy for the comprehensive explanation.
I did seek in tutorial but it’s not there in my local version. I am using
1.6.0 - time to upgrade.
I assumed code hint needed to be used on a block. It was certainly quicker
to mark all code as code than to have to mark each start point as code. But
now I understand what’s going on better.

Thanks,
Andrew

On Monday, September 6, 2021 at 6:40:33 AM UTC-7, Andrew Roughan wrote:
> I assumed code hint needed to be used on a block.

A couple of versions back I stopped calling them "hints", because pretty much everybody who used the program made similar assumptions. "Code start point" more accurately describes their purpose. You don't need to identify the end of the code section or any bytes between because the computer can do that for you.

> It was certainly quicker
to mark all code as code than to have to mark each start point as code.

The SourceGen approach is to assume that everything it can't explicitly reach is data. I think a lot of people are used to simple disassemblers (e.g. the system monitor) that assume everything is code until you tell it otherwise, and expect to manually exclude data areas. It's a question of building up the code areas rather than stripping out the data.

My experience so far has been that SourceGen finds all the code without any help except when (1) JSRs are followed by inline data, or (2) there's a jump table of some sort (usually LDA/PHA/LDA/PHA/RTS, sometimes indirect JMP, but generally easy to spot). The former can be automated and the latter can be formatted with a single command that will apply the code start tags for you.