Where can I find a 8080 to x86 assembler conversion tool? [closed]

Question

EDIT, GOOD NEWS!

10 years later, I decided I finally had to sit down and make this happen. I wrote the necessary convert-8080-to-z80-or-x86 and convert-z80-to-x86 tools, converted the Sargon code to x86 code, increased the search depth as I discuss below, and basically met all my goals, see project website.

For a retro computing project, I need to translate a body of 1970s era 8080 assembly language into x86 form. There was a time when a tool to do just that was a key part of Intel's marketing for introduction of the 80x86 family. But my googling skills don't seem up to the job of finding that original tool or something similar. Does anyone know if such a tool is available anywhere ?

EDIT

I have decided to add some background information to make it clearer what I am trying to do. This is for general interest and also maybe to tease out some more feedback.

In a previous project, I took a look at the 1970s era chess program Microchess, and with the blessing of the author Peter Jennings got it running on contemporary machines. Peter recounted the story of Microchess on his website and provided 6502 assembly language source. My contribution has now been added to the story and can be found at;

http://benlo.com/microchess/microchess9.html

The way I tackled that project was to minimally transform the code by hand so it matched C language semantics, for example I transformed this;

        LDY #$0F            ; CALCULATE
        LDA SQUARE          ; POINTS
ELOOP   CMP BK,Y            ; CAPTURED
        BEQ FOUN            ; BY THIS
        DEY                 ; MOVE
        BPL ELOOP
FOUN    LDA POINTS,Y        ;

To this;

        LDYi    (0x0F);     // CALCULATE
        LDA     (SQUARE);   // POINTS
ELOOP:  CMPx    (BK,Y);     // CAPTURED
        BEQ     (FOUN);     // BY THIS
        DEY;                // MOVE
        BPL     (ELOOP);
FOUN:   LDAf    (POINTS,Y);

I created C preprocessor macros matching all the 6502 instructions needed, for example LDYi() loads emulated register Y with an (i)mmediate value.

Some time later I found a German guy, Andre Adrian, had taken my code and added an interface to enable the code to be driven from a modern chess GUI. Pretty cool, I wish I'd thought of that. This can be seen at his website;

http://www.andreadrian.de/schach/index.html

On the same page (I use google translate) he links to the original version of Sargon, another classic chess program, possibly the retro chess classic, and expresses a wish that someone would bring this code back to life in the same way I did with Microchess (I think that's what google translate is saying anyway). Well, okay, I'm here to serve! This time I won't neglect to add the GUI interface too, or maybe I will collaborate with Andre.

The Sargon assembly language is here;

http://web.archive.org/web/20040217034933/madscientistroom.org/chm/Sargon.html

Andre has removed everything extraneous and left just the assembly language code here;

http://www.andreadrian.de/schach/sargon.asm

Now, the plot thickens. Andre tried to get this stuff to work himself using an emulator. (Edit 3jan2012 - Andre has moved this forward a lot and you can now run the old Sargon code on a modern PC - See his Answer below and his website linked above). But there is a complication I don't think he understands. The Sargon code is actually targetted at the Z80. But the assembly language is not normal Z80 assembly, instead it is 8080 assembly, with weird Intel style mnemonics for the Z80 only intructions. Some background; The Zilog Z80 is a third party descendent of the Intel 8080. It uses a binary compatible superset of the 8080 instruction set. Zilog decided to provide a cleaner, more orthogonal, but totally different (at the source level) assembly language for the Z80. A third (fourth?) party clearly decided this was a bad decision and made an alternative Intel style Z80 assembler, with the Z80 extensions expressed in Intel like fashion. Or maybe they just added the Z80 extensions using the macro facility of an existing 8080 assembler. It doesn't matter; The complication is that the Sargon code uses this rather weird hybrid assembler.

There are a few reasons I want an 8080 to x86 translator rather than either an emulation of the Z80 or a repeat of the C Macro approach from my Microchess project;

1) There's much more code this time. If possible I'd like to avoid line by line editing, even if it's a minimal transformation.

2) I'd like the code to run at full speed this time. It looks to me as if I can increase the search depth, something I couldn't do with Microchess. Chess code eats CPU cycles, it takes as many as you can give it and then wants more.

3) Even if I had a convenient emulation solution, I would need to get this stuff to assemble which is a problem given the weird assembler convention. But if I can translate all the 8080 mnemonics to x86, then I can work comfortably in x86 land, and simply hand translate the <10% or so lines of Z80 extensions into equivalent x86 code.

Sorry for this rambling post. Hopefully at least one person will find it interesting. One other request; I'd love to get the blessing of Dan and Kathe Spracklen, the legendary Sargon programmers. But they don't seem to have a web presence at all. Dan Spracklen is on LinkedIn but it seems to be a dead, unresponsive account. If anyone knows these people or how to reach them, please let me know.

Answer 1

http://www.arrakis.es/~ninsesabe/pasmo/ "Starting with version 0.5.0, can also generate 8086 code from Z80 sources, in binary format for Ms-dos COM files or in CP/M 86 CMD format." Pasmo 0.6: "Now can assemble 8080 code instead, or mixed with, Z80."

Answer 2

The Sargon source code runs now on a CP/M emulator. Here is the source ported from Wavemate Jupiter III to CP/M

A CPM emulator is available here

To assemble the source you need the TDL ZASM and TDL Linker. They are available here.

The commands to create Sargon in a MS-Windows console window are:

cpm ZASM_TDL sargon

cpm tdl-link sargon

cpm sargon

Answer 3

Must you actually translate the code, or would an emulator suffice? There's even one written in Javascript!

Answer 4

You might want to consider a few alternatives. One would be a static binary translation into C, this is probably easier if you assemble the 8080 code into a binary. Not seeing your code you are likely to have issues as it is not a one to one thing. The resources in the 8080 or the board it was running on wont match the 8086 you plan to run your code under. If you translate to C then you can target anything now or in the present and not be limited to x86 in a simulation environment to cover the prior problem. This is not as scary or painful as it may seem...Quite fun actually.

Something I have been thinking about doing is instead of translating to C translate to llvm's bytecode.

EDIT:

The problem with assembler to assembler, beyond having to do it again some day, is not the functionality of the instructions (register A = register A + 1), but the flags and the conditional branches (register A = register A + 1, if A == 0 Z = 1 else Z = 0, ...). Based on your understanding of 8080 vs Z80 you know that you are going to have to find or create a tool that can parse that assembler. My theory is that you are more likely to find an assembler to binary than a conversion tool. From binary then you can emulate (at far greater than full speed) or do a static binary translation, ideally to C. With the C you can be sloppy you can have every instruction have code to update the flags and then the optimizer in the C compiler can remove the dead code. Something an assembler is not going to do, leaving you with tons of unused instructions by going straight to x86. I didnt read the manual or too much of the code so it may be easy to handle, but in addition to the individual instructions there is the matter of stack and memory and registers and user interface. If this were to use a graphics/video interface you would have to replace that code wholesale, if the stacks vary between the 8080 and x86 then you are going to have to handle that, and there is likely to be hardcoded memory addresses that you are going to have to deal with. The hardcoded ones are easy the computed ones are much harder, jump tables and the like. How the stack is used for parameter passing and calls may vary between processors and the author may do stack clean up in a way that doesnt translate instruction for instruction. These are all things I hit when I did an assembler to assembler translation, granted it wasnt from a grandparent processor to its grandchild, like the 8080 to x86. I went kicking and screaming but eventually saw that, at least in my opinion, the translation to C covering so many of these problems. I am willing to bet, based on what you said about the 8080 variations from the z80, you may have to write your own assembly parser anyway. Here again the task seems impossibly huge, assembler or static translator when you start to think about how many instructions there are, how many variations. But once you get into it the grinding through instructions is not that bad.

I understand my answer is not directly tied to the question, the question is where can I find this tool. My answer has to do with: if you dont find the tool then. If you find the tool then good, done. If you find a tool that gets you close then you can hand or programattically adjust from there. Because I have done this before a few times I know that a full translation can be a fun project, particularly if the retro program is one that you care about enough to migrate to the present.

Answer 5

Trivia: The 8086 instruction set was designed specifically to make it easy to translate from 8080. That is where the instructions SAHF/LAHF originate, for example.

Answer 6

There seems to be a commercial 8080 to 8086 translator available as part of a package here.