Posted By
MikeZ
on 2010-05-31
16:29:47
 |  Re: AustroSpeed Fully Decompiled!
I did it using a basic coded C64 decompiler on a C64 emulator, mainly because the decomp referenced some C64 Kermal routines that I was too lazy to track down in the Plus4 Kernal.
The C64 decompilers were set to recognize which compiler (austro or blitz) was used by checking the last byte of the compiled RTI. Each C64 compiler had a unique RTI length.
I simply added a choice for the end byte of the austro/plus4 RTI and then the C64 decomp would work on austro plus4.
I still got garbage because the compiled austro had the RTI stacked up after its pcode, so it could be replicated into any compiled file without an external source for the RTI. The decomp looks for the last "4f" in the compiled file as the end of pcode. Unfortunately the RTI. which is 6KB of ML, was full of "4f"s and the poor decomp tried to turn RTI ML into Basic. Needless to say, I just had to guess that when a whole stream of bogus Basic showed up in the decomp, that the beginning of that stream was the actual end of the compiler's own pcode, and the end of the decomp.
Then of course there was learning the structure of a compiled file: RTI from 1001 to 2ef2, then vectors pointing to the start and stop of pcode,variables,arrays,and data stmts.
All this followed by a bizarre system array Z*%(), whiose elements give the offset from start of array space to the location of each array itself.
Luckily, even though it's a plus4 austro, it was coded entirely in basic2.0. Otherwise, the D64 decomp would not have been able to do it.
Even after the decomp was complete, turning it into a run-able basic prg was a job, because austro allows stuff basic does not, such as integer(%) loop counters. The loops were horrible, with multiple exit points, so a double accounting system had to be used to keep track of the loop counts, because these numbers frequently became offsets for table lookups.
It has become a great analysis tool - stopping the prg and examining parameter values while tracking down problems. SVS has already ID'd one bug in austro regarding line numbers of errors, and now it could be fixed with a recompilation of AustroBASIC back into AUSTROSPEED.
There is alot more, but that should give everybody an idea of what was involved in this year long adventure. MikeZ
|
