views:

206

answers:

5

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. 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.

+2  A: 

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

Greg Hewgill
I am planning to get the 1978 vintage Sargon chess program running as a standard engine for use with modern GUIs. I did a similar thing before with some 6502 code where I made a kind of 6502 emulator with the C preprocessor, see http://benlo.com/microchess/microchess9.html and www.andreadrian.de/schach/index.html (in German). But the Sargon code should be a little stronger, and I'd like to get near native performance so I can wind up the search depth and get a kind of super Sargon. Going out now, no more comments for 8 hours or so sorry.
Bill Forster
I did almost exactly the same thing years ago with the Apple (6502) version of the Reversi program by the same authors. Even around 1990, the emulated 6502 (at 20 MHz x86 or so) exceeded the speed of the actual 6502 (1 MHz). Today the speed of CPUs will allow seriously fast emulation, and the 8080 is a pretty simple CPU architecture.
Greg Hewgill
have done an emulator and a translator for the 6502. I would guess mame has an 8080 emulator if you cant find one elsewhere.
dwelch
@Greg, it's cool that I was channelling you with my Microchess project. Kudos and +1. Hope you find the additional background I supplied today interesting.
Bill Forster
+1  A: 

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

Chinmay Kanchi
Thanks +1. I may consider this if I run out of other ideas.
Bill Forster
+2  A: 

Here is one:

GregS
Thanks for that. I tried it out on sargon.asm (see my additional background) and it generated just a few bytes of gobbledygook that wasn't even text. But there is source code, so there is hope and I might take another look. So +1
Bill Forster
+3  A: 

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.

dwelch
Thanks for your thoughts. I've added some background you might fond interesting. +1
Bill Forster
Thanks for your edit which I just noticed. I am not 100% committed to a particular approach yet. I have done this kind of thing before as well, and whatever approach I take I am very confident I can make it work. A key factor is that the amount of code is manageable, so hand tweaking is not the end of the world. Also, from a quick survey, it seems that although the Spracklens were definitely brilliant programmers, they didn't indulge in much trickery, the cleverness is in the algorithms. That makes translation (by any method) easier. All the graphics, hard addresses etc. I will dump. Damn...
Bill Forster
... this 600 character limit! Another poster talks about problems with 8080 flags vs Z80 flags, but really the incompatibilities are minor and restricted to the rarely used O and P flags. Most assembly language programs never test those flags, I will just inspect carefully, make sure I understand the algorithms I bring across, and step through the code carefully for verification,
Bill Forster
Sounds like a fun project, too bad I have a backlog of fun projects, some similar to this. Best of luck to you on it, sounds like you have a good handle on the problem in case you dont find an existing tool.
dwelch
A: 

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.

Yuhong Bao