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

7

19

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.

Mucilage answered 10/1, 2010 at 22:35 Comment(3)
How confident are you of translating Z80 into x86 code? There were a lot of neat tricks you could do with Z80 ops that you couldn't even approach with 8080, not to mention some rarely encountered incompatibilities with the condition bits. The Z80 was a weird CPU in many respects.Leeward
I'm pretty confident :-) I cut my teeth on Z80s, it was my CPU of choice for years (from 1983 until 1988 or so). I used to love the Z80 extensions, they made the CPU seem cool in a way that the 8080 or 8085 just wasn't. Looking over the Sargon code, I think that I could hand translate the Z80 specific lines, in a few hours of dedicated effort.Mucilage
Have you seen the asm translators floating around the 'old dos archives? nvm... looks like you already found the same one.Willianwillie
D
4

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

Devotional answered 11/12, 2010 at 17:15 Comment(1)
+1 Thanks, this is close to what I need.Mucilage
M
4

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
Madwort answered 11/12, 2011 at 20:58 Comment(4)
Hi Andre, Thanks for this and for providing all the retro chess computing material on your website. I was once quite keen to move this project forward once, I purchased a second hand copy of the Spracklen's book where the original code listing was found and I did some preparatory work as noted in this question. But then I got swamped by all my other projects and I put this one aside indefinitely. I still hope to get back to it, because as you know better than anyone, the really cool thing to do with this is to get Sargon working as a UCI or Winboard engine.Mucilage
!link Now we have a Jupiter III emulator to run SARGON with the same graphics as it had in 1978. The program is on link. The source code is on link. This is my present for myself and for everybody else.Madwort
Good work! A great present to retro chess computing fans. I will edit my question to give you credit for moving this forward.Mucilage
The link to cpmcons is now dead. :-(Gizela
D
3

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

Drainage answered 10/1, 2010 at 22:40 Comment(4)
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 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.Mucilage
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.Drainage
have done an emulator and a translator for the 6502. I would guess mame has an 8080 emulator if you cant find one elsewhere.Sedum
@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.Mucilage
S
3

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.

Sedum answered 11/1, 2010 at 1:38 Comment(4)
Thanks for your thoughts. I've added some background you might fond interesting. +1Mucilage
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...Mucilage
... 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,Mucilage
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.Sedum
B
3

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.

Bree answered 7/9, 2010 at 3:25 Comment(2)
Sorry, should have given you a +1 earlier when I saw your comment, for general interest. Back in the day I wrote an 8080 emulator for the 8086 that didn't use SAHF/LAHF. This was very rare (unique?) since all the other emulators I've seen needed SAHF/LAHF since their inner code interpreter modified the flags. Mine left the flags untouched so the 8086 flags could natively emulate the 8080 flags. A huge performance win. This remains a favourite hack of mine. In the unlikely event of someone stumbling on this and being interested in how I did that, contact me (eg use google) and I will share.Mucilage
Some more details about that history, and links to more, on retrocomputing.SE: The start of x86: Intel 8080 vs Intel 8086?Fordo
C
1

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

Chadwick answered 10/1, 2010 at 23:25 Comment(1)
Thanks +1. I may consider this if I run out of other ideas.Mucilage
M
1

Can you assemble the Z80 source to binary? If so, then run a disassembler on the binary back to "normal" Z80 assembler.

Mete answered 10/11, 2010 at 9:30 Comment(2)
Thanks for contributing at this late stage. No I don't have the weird Z80 assembler that uses Intel style mnemonics. And even if I did, and could get normal Z80 assembler using the mechanism you describe, I would be no better off (indeed worse off). The reason is that while Intel 8080 -> Intel 8086 assembly translator(s) definitely exist, but a Z80->8086 tool equivalent is even more obscure. Still +1 for trying! Incidentally, I should sheepishly add that I haven't progressed this project, it's been masked by other more urgent stuff.Mucilage
@Bill Forster, no shame in that. Anyway, there are a LoT of fast Z80 emulators, even JIT ones I think. But once you have real Z80 binary code, you could back-translate it to real Z80 and from there generate C code, which you will compile to native.Mete

© 2022 - 2024 — McMap. All rights reserved.