Query on formatting capabilities
phillipeaton opened this issue · 18 comments
Hello,
-
Is it possible to make this
LDA #$01 ;0C1B: 86 01
display like this
LDA #PAWN ;0C1B: 86 01
in specific parts of the code only? -
Is it possible to make this
MLIST RMB %0000011111111000 ;0400: 2040 bytes
display like this?
MLIST RMB 2040 ;0400: 2040 bytes
For some reason, my RMBs always display in binary.
Thanks for any feedback!
Additionally, is there any way to suppress the conversion of printable characters to ascii, e.g.
POSK FCB 24 ;024E: 18 '.' 24, 95
FCC "_" ;024F: 5F '_'
POSQ FCB 25 ;0250: 19 '.' 14, 94
FCC "^" ;0251: 5E '^'
FCB $FF ;0252: FF '.' -1
to be displayed as
FCB 95 ;024F: 5F '_'
POSQ FCB 25 ;0250: 19 '.' 14, 94
FCB 94 ;0251: 5E '^'
FCB $FF ;0252: FF '.' -1
The best I'm able to do here is to use word i.e.
POSK FDB $185F ;024E: 18 5F '._' 24, 95
POSQ FDB $195E ;0250: 19 5E '.^' 14, 94
FCB $FF ;0252: FF '.' -1
Thanks for any thoughts!
Hello,
1. Is it possible to make this ` LDA #$01 ;0C1B: 86 01` display like this ` LDA #PAWN ;0C1B: 86 01` in specific parts of the code only?
I don't think f9dasm can do it. dasmfw might be able to do it with a deflabel.
2. Is it possible to make this `MLIST RMB %0000011111111000 ;0400: 2040 bytes` display like this? `MLIST RMB 2040 ;0400: 2040 bytes` For some reason, my RMBs always display in binary.
Since that should have been fixed in Issue #16 - what f9dasm version exactly are you using?
Additionally, is there any way to suppress the conversion of printable characters to ascii, e.g.
POSK FCB 24 ;024E: 18 '.' 24, 95 FCC "_" ;024F: 5F '_' POSQ FCB 25 ;0250: 19 '.' 14, 94 FCC "^" ;0251: 5E '^' FCB $FF ;0252: FF '.' -1to be displayed as
FCB 95 ;024F: 5F '_' POSQ FCB 25 ;0250: 19 '.' 14, 94 FCB 94 ;0251: 5E '^' FCB $FF ;0252: FF '.' -1
Yeah. const 024e-0252 followed by +dec 024f and +dec 0251
... not very intuitive, I know ...
V1.78, according to the program itself (on Windows 10 64-bit)
X:\SkyDrive\_PJE\Programming\Forth\>f9dasm
f9dasm: M6800/1/2/3/8/9 / H6309 Binary/OS9/FLEX9 Disassembler V1.78
Loaded binary file CHESS.CMD_flex-vfs_expand_$1696.bin
Press any key to continue . . .
CONST character string fix works perfectly, this is actually what I wanted:
const 024E-0252
+dec 024E-0251
hex 0252
---
POSK FCB 24,95 *024E: 18 5F '._' 24, 95
POSQ FCB 25,94 *0250: 19 5E '.^' 14, 94
FCB $FF *0252: FF '.' -1
Thanks!
Right, so dasmfw is an f9dasm rewrite. Well, if it's largely compatible with f9dasm, I'd be happy to give it a go. Any reason why you haven't promoted it on your own website - documentation missing?
Unfortunately, I'd need a Windows binary, the last (and only) time I used a C compiler was to write a simple communication terminal in Borland Turbo C in the early 90s. Now if you'd have written dasmfw in Forth...
V1.78, according to the program itself (on Windows 10 64-bit)
Ah. I'd suggest switching to the latest V1.80; the RMB binary stuff should be fixed there. You can either build it from the sources here or get them with a pre-built executable from https://www.hermannseib.com/programs/beta/f9dasm.zip
Right, so dasmfw is an f9dasm rewrite. Well, if it's largely compatible with f9dasm, I'd be happy to give it a go. Any reason why you haven't promoted it on your own website - documentation missing?
Precisely. I'm currently writing one, but that's quite some work.
Unfortunately, I'd need a Windows binary, the last (and only) time I used a C compiler was to write a simple communication terminal in Borland Turbo C in the early 90s.
OK, I'll upload one later today.
Now if you'd have written dasmfw in Forth...
Hehe ... no. I kind of remember Forth from playing with it in 1982, but it wasn't exactly clicking with me.
I'm using f9dasm 1.80 now and the RMB binary problem is also resolved.
Looking forward to the dasmfw binary!
In case I wanted to compile from source (exciting!), could I use MinGW? I don't really want an 800MB install of Visual C++ on my machine, if I can avoid it.
I think mingw should do it; I test it with gcc on Linux from time to time, it should work. There's very few Windows-specific stuff in it. Anyway, here you are ...
dasmfw.zip
Contains the start of a documentation, too (dasmfw.htm).
Thank for the file.
I read the dasmfw.htm initial documentation file (and the "dsamfw -dasm=6809 -?" output) and immediately it looked quite different to f9dasm.
So I decided to run it with my binary and the info file I'm using with f9dasm and see what comes out the other side and, to my surprise, the resultant asm file is pretty much the same! (And a09 still assembles it to an identical source binary.)
I'm guessing then that the dasmfw.htm initial documentation file is describing all the new features, but the existing formatting commands that are in f9dasm are mostly still in place.
It'll take a few working days to look into that new functionality, e.g. adding named EQUs, but it already looks like a really promising framework. (Option -showzero still doesn't work, though 😀.)
Here's a screenshot from Beyond Compare that illustrates the compatibility:
The $10/16 difference is now fixed, it was a typo in the info file.
The missing two labels in the dasmfw version I don't understand, I'll have a look into that. They come from the following info file:
comment 1696 - ARGUMENTS : None
comment 1696 -
comment 1696 ----------------------------------------------------------
comment 1696
label 1696 DRIVER
label 16A6 DRIV01
label 16B6 NTDONE
label 16BE BLACK1
label 16C1 WHITE1
label 16C9 DR1
label 16CC DR2
The $0200/512 and character changes are simple formatting/character wrap issues, which can be fixed if needed in the info file by me.
If DRIVER and BLACK1 are not referenced anywhere in the code, dasmfw won't list them. To force the inclusion of unused labels, you'd have to write
usedlabel 1696 DRIVER
usedlabel 16be BLACK1
instead (f9dasm-compatible, so no problem in a mixed setup). If, however, they ARE used somewhere in the code, this would be an error in dasmfw; in that case, it would be helpful if you could send me binary and info file (treated as confidential, of course) so that I can recreate and fix the problem.
And yes, dasmfw should be able to handle f9dasm info files without big changes; some things can be done differently, and there are additional constructs that f9dasm can't handle, but it's possible to create info files that lead to an identical output from f9dasm and dasmfw.
I checked it the code, both labels are unused. DRIVER is the main entry point to the program and BLACK1 is simply showing where a branch was not taken to WHITE1.
Further dasmfw queries, I'll post on that repo.
Thanks for the feedback!
This should reach you by email, I guess - here comes another dasmfw which has slightly expanded capabilities, a better documentation including the info file statements ... and a fixed deflabel handling which didn't work correctly in the previous incarnation. Have fun!
dasmfw.zip
I'll check it out, thanks for the update 👍
Additionally, is there any way to suppress the conversion of printable characters to ascii, e.g.
POSK FCB 24 ;024E: 18 '.' 24, 95 FCC "_" ;024F: 5F '_' POSQ FCB 25 ;0250: 19 '.' 14, 94 FCC "^" ;0251: 5E '^' FCB $FF ;0252: FF '.' -1to be displayed as
FCB 95 ;024F: 5F '_' POSQ FCB 25 ;0250: 19 '.' 14, 94 FCB 94 ;0251: 5E '^' FCB $FF ;0252: FF '.' -1Yeah.
const 024e-0252followed by+dec 024fand+dec 0251
... not very intuitive, I know ...
Hello,
Please can you tell me the significance of the '+' in front of the 'dec' shown above?
Why is it needed? I've used 'hex' previously without the '+' and that seems to work as expected.
You're right, I should finally document it ...
If you think about it, there are various kinds of mutually exclusive options for a memory cell. These are:
- type (unused / code / data / rmb)
- size (default char / word; dasmfw also has dword for processors that support 4-byte entities)
- formatting (bin / char / dec / hex)
- semantics (const)
Each of these can be set with an info file instruction. In f9dasm, the '+' is necessary for historical reasons. Originally, f9dasm could only apply one instruction to any given address. In the first incarnations, that was code or data. Later on, I added a bunch of "wouldn't it be nice" options, like the const and char/dec/hex stuff ... and discovered that applying two or more options to a cell was a problem, as f9dasm simply replaced the complete previous option set. For simplicity's sake, I then added the '+' notation, which simply means "Don't replace the complete option set for a cell, but only the specific set of mutually exclusive ones".
In dasmfw, I redesigned that logic completely; it doesn't need the '+' notation any more. For compatibility reasons, it simply ignores '+' before an info file instruction.
Those four bullets make a lot of sense, now I've been working with f9dasm/dasmfw for a while, but perhaps not so obvious for a newbie!
Thanks for the detailed explanation regarding the '+', I can safely ignore them going forward :-)