Post - Forum - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Forum Help

Post Your Message

Previous Messages

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

Posted By

Gaia
on 2010-05-31
13:44:39

Re: AustroSpeed Fully Decompiled!

This is quite a feat, actually! I wonder how it was accomplished?

I still think there would be some creative room to creating a BASIC cross-compiler

Posted By

Chicken
on 2010-05-31
10:52:49

Thanks, MikeZ!

This is great news (and finally, we can comment on it

).

Honestly, I would have loved this 20 years ago

But it's never too late and I hope some ppl take the opportunity and enhace the compiler.

Posted By

Csabo
on 2010-05-15
10:52:49

AustroSpeed Fully Decompiled!

MikeZ sent us word that AustroSpeed Compiler has been decompiled to a fully working pure BASIC version. The purpose is to provide a source file for anyone who wants to change how AustroSpeed works. He hopes that someone will take advantage of what he has done to make the Plus/4 AustroSpeed version much better than it currently is.

The new ZIP file can be found on the program's detail page, replacing the previous "extra" package. Also included is an Excel file containing MikeZ's P-code listing, and an important readme file (be sure to check it out). Kudos to MikeZ for his excellent work, enjoy!