Properly handle .sym files created by DASM

[sa666666]

There are some problems with the current implementation. This will be updated as we find them:

• labels with the same name but multiple addresses aren't handled correctly For example, it's not entirely clear how to handle the following case:

1.cardloop0              f269              (R )
2.cardloop0              f318              (R )
3.cardloop0              f3c7              (R )
4.cardloop0              f476              (R )
5.cardloop0              f525              (R )

For now we just remove the part of the label before the '.', and the label takes on the last address. This should be improved.

[g012]

I see two improvements possible :

1. Do a first pass, determine which local labels would resolve to the same name after stripping, and don't strip them during a second pass.
2. Dasm is old, this symbol file format does not have enough information. Just be done with it, also forget about the nightmare of parsing a .lst and extracting something useful, and instead design a file format containing everything you need to display a nice debugging experience. All new assemblers would generate that format easily, and I'm sure someone will one day patch dasm and ca65 too for it.

[sa666666]

I've long thought that when we have symbol/list files, we should use them completely. There's a lot of infrastructure in Stella to dis-assemble ROMs, detect graphics locations, differentiate between code and data sections, etc. And all this is necessary.

But for newly developed ROMs where we have this info directly from the accompanying files, we should ignore the built-in stuff completely and just use the direct information. This would lead to another oft-requested feature; source-level debugging.

[g012]

For symbol files, I don't see what can be done more than point 1. Any other idea ?

For list files, I really feel it's wasted resources. It's complex to extract useful information, and anyone who has a list file has the actual source as well so can derive any required data from it himself. Since there are many different assemblers, deciding a list file is a standard communication mean is like choosing the worst communication medium and asking everyone to support it. Even if many already do, I don't think it's a compelling enough reason to also support it. It's faster, easier, and far more useful to developers to create an easy and feature rich input file format for Stella.

Of course we'd all love to have source-level debugging ;) Assembler-agnostic. Since we're in this topic, I'd go as far as to wish for controlling Stella over sockets: imagine a demo, started from a visual demotool with a timeline, where clicking somewhere on the timeline would make Stella jump to that part, after setting some required state for that demo section. That'd be awesome.