Eckhard Stolberg wrote:
I don't really like how the output is formated. I think most of us
put the labels at collumn 1, the instructions at collumn 17 and the
operands at collumn 25. Maybe your disassembler could format it's
output like this too? This would also allow you to put in the
I'll offer it as an option in a subsequent release. The current format
is my personal preference.
addressing mode overrides for the instructions. If you do:
NUSIZ0 equ $0004
sta NUSIZ0
then DASM will generate a zeropage access, because of the leading zeroes.
But sometimes you might want to generate an absolute access, because of
the different timing. In DASM you can enforce this by doing
sta.w NUSIZ0
I think your disassembler should generate those overrides automatically,
because otherwise some games wouldn't assmeble to the correct binary
with DASM.
That one's on my to-do list. I'm also planning on offering an option to
generate .byte and .word directives for assemblers that don't support
the DASM syntax.
Also it would be good if one could define different labels for read
and write accesses. On the VCS for example writing to address $04
will set the NUSIZ register for player 0, but reading from that same
address will get you the status of one of the collision registers.
Maybe your disassembler could differentiate between the two access
modes and use different labels accordingly?
Believe it or not, I didn't think of that. It currently just uses the
first address regardless of the instruction. I'll have to extend the
instruction tables, though, to indicate whether each instruction is a
read or write.
Distella only includes those equates for TIA registers that get
actually used. I think this helps the readability a bit. Maybe
your disassembler could do the same?
That's one where I've flip-flopped a bit. An earlier version filtered
labels, but I took it out since I didn't want code labels to be dropped
when they were specifically requested in a config file. I'll have to
give it some more thought. I could make filtering unused labels a config
option or maybe special-case code vs. external labels. Maybe I should do
both and offer --filter-code and --filter-external options.
And it would be good if your disassembler could handle atleast the
simple bankswitching formats that use accesses to fixed addresses
to switch to a certain bank. I think there are at least two games
for the 7800 that also use such a scheme, so this feature might be
helpfull for your own purposes too. ;-) Maybe you could allow the
user to define an area in the binary and set the origin for it.
Then one could assign a hotspot address to that area and the
automatic tracing routine would know when to switch banks.
User-defined file formats are on my list, but I hadn't really even
looked at tracing through banks yet.
And since you have to redirect the output into a file yourself,
which affects all output of the program, maybe there is a way to
get at least some sort progress indicator still displayed on the
screen?
Actually, I think I'm going to replace the writes to standard output
with writes to a file specified on the command-line. With any luck, the
default buffering policy will make things faster. The iostreams code is
amazingly slow compared to the stdio version I started out with. Roughly
a factor of 5 on my machine.
--
http://www.classic-games.com/ http://www.indie-games.com/
"If you torture a ballot long enough, eventually it'll confess."
--Alan Simpson
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
