Hi folks - you've found your way to my 6809 static binary translator (otherwise
known as a Compiled Instruction Set Simulator).  It's sort of like a decompiler
but doesn't make any effort to build the generated C back up into more high-level
statements.


I've been working on this project for some time as a low priortity background
task, but I think it's now getting close to being ready for testing by others.  It has
*not* been tested and we haven't run any translated programs with it yet, so I'm looking
for alpha testers who can try it out and feedback errors or suggestions for improvement.

The code is a development of an earlier disassembler, so to use it as a
static binary translator (from here on, "sbt") you need to add the parameter --sbt

6809dasm --sbt rom.bin

The disassembler part of the code will try to do a tree-walk of the code
to determine what is code and what isn't.  Non-code is not output at all.

Because this sort of code exploration often fails to find code that is
executed via a jump table, you may have to give the disassembler some hints
as to what is code, which you do by creating a .dat file with entries such
as:

   code 3FE8

You can find code address by adding tracing to an existing emulator, or
by examining a hand disassembly of your rom if one exists.

There are some other directives available too - "org", "label", "comment" etc.
They'll be documented elsewhere eventually.

If you have a .dat file, you would invoke the sbt like this:

6809dasm --sbt rom.bin rom.dat

By default the translator assumes a raw binary which starts with code.
There is an option specifically for vectrex roms, eg

6809dasm --sbt --vectrex polar_rescue.bin polar_rescue.dat

I may add an option soon for stand-alone roms, which will recognise
the restart/nmi/irq/swi vectors as code entry points.  It's not there yet.

The translator normally tries to work with 'basic blocks' of straight-line
code, and doing so allows it to remove a lot of redundant calculations -
usually the setting of flags which aren't ever used in the code before
being overwritten by new values.

However a mode is available that overrides this optimisation, which is
useful when verifying a new translation by running in a 'dual cpu'
environment alongside a regular emulator.  Single Step mode also forces
the PC to be updated on every instruction.  Invoke it as follows:

6809dasm --sbt --single-step rom.bin rom.dat

(--single-step can be abbreviated to --ss for quicker typing.  Use the
long form in scripts for clarity though!)

Finally, there's some provisional support for cycle counting, available
by invoking --timing:

6809dasm --sbt --single-step --timing rom.bin rom.dat

Note that at the moment, timing calculations have not been optimised.  There
is a huge scope for conflating the timing calculations, as has been done in
previous sbt's by this author.


So... if that all sounds like something you want to try,

fetch 6809sbt.tar, unpack it, "make clean" (just in case), then "make".

It will build "6809dasm" (and a 6809 assembler which is used in testing).

If you find problems and need to modify and recompile the translator,
just type 'make'.  The make script automatically runs the updated sbt
on a couple of validation suites, which ought to catch most errors that
you might accidentally introduce when modifying the sbt code.

The main workhorse is "6809.c".  The code in 6809.c is invoked from
the disassembler whose code is in 6809dasm.c.  6809dasm.c is a hack,
it started out as Sean Riddle's disassembler but by the time I had
finished with it, it was pretty much unmaintainable code.  If major
changes are ever needed in that part of the system, it'll be better
to rewrite the module completely than to keep hacking the existing code.

The code in 6809.c isn't as bad, but it too is still under development
so there are some old pieces of code in there that have not yet been
removed, and maybe some out of date comments.  There are several
assumptions made in the code that it is important to be aware of
when working on it, and not all of them have been well documented!
(For example, the convention for storing flag information is
important and not obvious).

Keep me updated with successes or problems or contributed code fixes.

thanks

Graham <gtoal@gtoal.com>
PS I am now in the process of adding a fallback interpreter to the SBT.
At the moment, there are two separate sets of programs - the original sbt
code, and any files ending in -fallback which for now are pure emulator only -
I have not yet merged the emulator into the sbt, so for the moment
you can ignore the -fallback files.  They do however seem to work
correctly and pass the same verification tests as the SBT versions.
The emulator is the same one as the sbt is based on so it should be a
seamless switch-over.  If you look in 6809-fallback for "ifdef BROKEN"
you'll see the bugfixes I had to apply to the original author's code (which
was quite an old version) - the bugs were identified by the validation tests.
PPS Rewrite of tree-walking is underway: http://gtoal.com/SBTPROJECT/generic/