Perl FR Disassembler

Very nice! My Perl version doesn't yet print data in other than hex and ASCII.

Does your disassembler handle subroutine names?

I haven't implemented symbols yet; I'll probably get to that next week, along with cross-referencing. I intend to have an option like -s address=name to specify particular names, and generate internal labels for other addresses. kps 04:20, 7 November 2007 (UTC)
I have the option to specify a symbol name, but the subroutine naming is automatic unless another name is specified (only implemented when the CALL address is constant, as above). Also, I have an option to specify a comment for an address K10dfreak 14:53, 7 November 2007 (UTC)

I also took the liberty to change the appropriate ST/LD instruction names to PUSH/POP.

I did likewise (also for LDM/STM), along with changing the '2' shifts (e.g. LSL2 #5 -> LSL #21) and using AC, FP, and SP for R13-R15... all optional, of course. kps 04:20, 7 November 2007 (UTC)
Good idea about the '2' shifts -- I also renamed R13-15 K10dfreak 14:53, 7 November 2007 (UTC)

P.S. I also wondered how to upload a binary file, and had hoped there was a better way than pretending it was an image, but I couldn't find one.

DFR problems

I tried to run DFR v1.1 to check a jump address, but I couldn't get it to work. Could you tell me the branch address for the BNE:D instruction at 0x10545310? I've got it branching to 0x1054531e, which is the middle of an LDI:32 instruction, and can't be right.

I think you had the sign of the offset wrong there.
10545310  F3FA     BNE:D 0x10545306
Right, thanks. Fixed. K10dfreak 19:46, 9 November 2007 (UTC)

Re the DFR problems: It compiled OK, but crashed as soon as I ran it with no arguments. (First it complained about "too many input files" even when I had specified none. Then I hacked it past this and it crashed immediately in initialize() because char *s is used before it is initialized. Then I fixed this and it gave a bus error somewhere deep in a vfprintf() routine. Then I gave up.) I'm running on Intel Mac OS X with gcc 4.0.1. K10dfreak 18:29, 7 November 2007 (UTC)

Ah, yes. Last minute changes just before going to sleep. I'll fix that this evening. Thanks for the report. kps 20:20, 7 November 2007 (UTC)

Version 1.02 still does this, any ideas why?: K10dfreak 12:47, 9 November 2007 (UTC)

> make
cc -g   -c -o dfr.o dfr.c
cc   dfr.o   -o dfr
> ./dfr FRDC162B.BIN
dfr: too many input files
I've thought of a possibility -- perhaps you've edited one of the startup option files (.dfrrc or dfr.txt) and it has been saved with CR as the line terminator in the old Mac fashion, and the C library doesn't recognize that as a line ending.
Nope, that isn't it. I edited none of the files. Just un-zipped, copied the FW into the directory, compiled and ran. K10dfreak 14:38, 9 November 2007 (UTC)
Can you check the line endings in dfr.txt? Maybe the unzipper changed them due to the '.txt' extension.
The Mac doesn't mess with linefeeds, and most of the work I do is using Unix linefeeds anyway. But I double checked, and the linefeeds were Unix (0x0a). K10dfreak 19:21, 9 November 2007 (UTC)
I just did some debugging in gdb, and find that somehow the values that are used in op->argv aren't the ones that are passed from the options(3, argv) call at line 2116. Unfortunately I don't have time now to figure out the exact problem. (I know you don't like Perl, but I should point out that I just spent more time debugging platform-dependent bugs than I have in 3 years of maintaining a very large Perl package that runs under dozens of operating systems.) K10dfreak 19:40, 9 November 2007 (UTC)
I develop on a G4 10.3.9, and have run it on an x86 w/XP, but I'll try it on an Intel Mac on the weekend.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.