> just wondering if the cp/m for the 8086 can run software for the 8080 and
> z80 computers ??
No. It is however much more trivial to code a CP/M-80 emulator for
CP/M-86 (and if you're running one of the 4.1 CP/Ms (PCP/M 2, DOSPLUS 1.x)
you can use Jim Lopushinsky's CP/M-80 emulator just fine - don't know if
it'll run on a 2.2-class CP/M like CP/M-86 1.x though)
-uso.
No the 8086 is not an 8080 differnt instruction set at the binary
level.
Yes with caveats, read on.
The CP/M-86 system must have a NEC V20/V30 series CPU as it has the
8080 mode of operation (YES 8080!) and then you need a small bit of
code to start a 8080 program and link it nack to the V20 in 8086/88
mode.
The alternate is have a secondary 8085/z80 like the Compro and other
systems did (dec rainbow too) to run CP/M 80 programs and interface to
the 8086/88.
Allison
Robert
Jim Lopushinsky's CP/M-80 emulator for CP/M-86 runs perfectly
under 'CP/M-86 For The IBM, Version 1.1.'
Get it here:
Robert Flossmann wrote:
>There was one flavour of CP/M that could run CP/M-80
>files directly. The DEC Rainbow 100's CP/M-86/80
>CP/M was also sold as Lifeboat's SB-80
That's because the DEC Rainbow had a Z80 and an 8088, and would
boot into CP/M, CP/M-86 MS-DOS, or as a VT100 terminal.
The Commodore 128 used the same scheme with a Z-80 and a 6502,
and the Apple2 had an optional Z-80 card that was fairly popular.
However, for some machines (Compupro, Zenith, DEC and others), versions
of CP/M-86 that supported this capability came into existence. These
versions were created by 3rd parties, but this capability was not
natively present in the DR version of CP/M-86. In addition to custom
software, some means of executing 8080 or Z-80 code was required. This
could be accomplished in either hardware (separate CPU) or in some cases
it could be software emulated (somewhat slow, but it did work). Also,
in systems with an 8088, the 8088 could be replaced with an NEC V-20
chip, an 8088 clone chip which had internal hardware emulation for a
Z-80 as one of it's added features.
I think it was just an 8080, not a Z-80, that the V-20 emulated.
Wasn't it Toshiba that got to second-source the Z-80?
Correct. No idea why NEC didn't put a Z80 in the V20 (lack of
alternate register set is likely). NEC however did source the Z80
as the upD780 and was a fully pin and software compatable z80
right down to the undocumented instructions.
Toshiba also sourced the Z80 and HD64180 (later to be the Z180).
Allison
> CP/M-86 did not, as released by digital research, have any
> support for running CP/M-80 programs.
>
> However, for some machines (Compupro, Zenith, DEC and others),
> versions of CP/M-86 that supported this capability came into
> existence. These versions were created by 3rd parties, but this
> capability was not natively present in the DR version of CP/M-86.
> In addition to custom software, some means of executing 8080 or
> Z-80 code was required. This could be accomplished in either
> hardware (separate CPU) or in some cases it could be software
> emulated (somewhat slow, but it did work). Also, in systems
> with an 8088, the 8088 could be replaced with an NEC V-20 chip,
> an 8088 clone chip which had internal hardware emulation for a
> Z-80 as one of it's added features.
Correction, Barry: the NEC V-series chips natively support
the -8080- instruction set; not the Z-80.
If you feed a Z-80-specific instruction to a V20, it hangs.
HARD. Gotta reach for the Big Red Switch.
Barry Watzman wrote:
>
>CP/M-86 did not, as released by digital research, have any support for
>running CP/M-80 programs.
>
>However, for some machines (Compupro, Zenith, DEC and others), versions
>of CP/M-86 that supported this capability came into existence. These
>versions were created by 3rd parties, but this capability was not
>natively present in the DR version of CP/M-86. In addition to custom
>software, some means of executing 8080 or Z-80 code was required. This
>could be accomplished in either hardware (separate CPU) or in some cases
>it could be software emulated (somewhat slow, but it did work). Also,
>in systems with an 8088, the 8088 could be replaced with an NEC V-20
>chip, an 8088 clone chip which had internal hardware emulation for a
>[8080] as one of it's added features.
Wouldn't it be nice if Intel or AMD would tuck a Z-80 into a corner
of a modern chip? :)
I think that was Hitachi.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
>nos...@nouce.bellatlantic.net wrote:
>>
>... snip ...
>>
>> Toshiba also sourced the Z80 and HD64180 (later to be the Z180).
>
>I think that was Hitachi.
Yep brain fade. Toshiba was CMOS 8085.
Allison
Thats what Zilog does to exist. There are several ways for that to
happen. You can use the Ez80 parts or if your into custom silicon
you can use a library that gets you a z80 embedded in your design.
Allison
Almost true. Digital Research did include some programs with CP/M-86 to
ease compatibility between it an CP/M-80. 86XLT86. There were two x86
assemblers and linkers, one each for the 8080 (ASM86.COM and GENCMD.COM)
and for the x86 (ASM86.CMD and GENCMD.CMD). They also included XLT86
(both .COM and .CMD versions), which was a program that translated 8080
.ASM source code into x86 .A86 source code.
XLT86 was pretty crude; nevertheless, most of the early programs that
rapidly appeared on CP/M-86 were simply the CP/M-80 versions shoved thru
XLT86, with a little hand tweaking (MBASIC, Wordstar, etc.).
--
The two most common elements in the universe are hydrogen and stupidity.
-- Harlan Ellison
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net
The 8086 was incompatible with the 8080, but Intel designed the 8086 to
be "translate compatible" with the 8080. This meant that each register and
flag of the 8080 had a counterpart in the 8086, and all instructions and
modes had parallels in the two processors. The 8086 had parity calculation
and handling, as well as a "halt" instruction, both of which were less
than usefull on an advanced processor.
Intel (and others) released translators to take 8080 assembly programs to
the 8086. In addition, DOS was designed to be roughly compatible with CP/M.
As a result, for a while after the PC came about, programs were commonly
translated from CP/M 8080 programs to DOS 8086. The most famous of these
was Wordstar.
I suspect what rapidly killed off this mode was the fact that translated
8080 code could only make use of 64kb of memory, which the PC quickly
overran.
--
Samiam is Scott A. Moore
Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas
Good does not always win. But good is more patient.
No, it didn't. The 8086 was noticeably missing the equivalent of
the XTHL 8080 instruction, which meant it was impossible to
manipulate the stack in the 8086 without destroying some register
content. This was a very stupid omission.
push ax
push bx
pop ax
pop bx
Doesn't do it. That is effectively "xchg ax,bx". xthl exchanges
the top of stack with the hl register. So we could save hl and
access TOS with xthl. Or we could access the word below the return
address with "pop hl; xthl". With careful design of the calling
sequence the stack was clean when the routine was done. I used it
extensively to keep code re-entrant.
Sorry, I misread you.
So what did the 8080->8086 translator do for xthl ? My guess would
be to use a memory location.
That would be great. :)
--
Paul
- Mansfield Chavs: http://groups.yahoo.com/group/mansfieldchavs
- Mansfield Goths and Alternatives:
http://groups.yahoo.com/group/mansfieldgoths
- The Alternative Guide to Mansfield:
http://groups.yahoo.com/group/alternativemansfield
(snip)
> No, it didn't. The 8086 was noticeably missing the equivalent of
> the XTHL 8080 instruction, which meant it was impossible to
> manipulate the stack in the 8086 without destroying some register
> content. This was a very stupid omission.
Depending on which registers you use to replace the 8080 registers,
I think you can do it with two XCHG and probably a MOV. Maybe
MOV BP,SP
XCHG [BP],CL
XCHG [BP+1],CH
I am not sure that CX is the replacement for HL, though,
but others can be used.
I have the description of CONV86 and it doesn't mention that
it doesn't support XTHL, only some 8085 instructions like RIM.
-- glen
> So what did the 8080->8086 translator do for xthl ?
I tested this in linux with my cp/m emulator and a copy of XLT86.COM:
(results edited for clarity)
xlt86> cat XTHL.ASM
xthl
xlt86> aliados XLT86.COM XTHL.ASM
XLT86 Version 1.1
Copyright(c) 1981
Digital Research
Symbol Setup
Setup Blocks
Join Blocks
List Blocks
Translate-86
END OF FILE (7), File: SOURCE=XTHL.ASM
Traceback: 2767 7978 0C9C 00FF # 0AB4 0CB5 587B 0148
End of Execution
xlt86> cat XTHL.A86
M EQU Byte Ptr 0[BX]
MOV BP,SP
XCHG BX,[BP]
xlt86>
It does the same with some other instructions, expand to several
instructions using registers that does not have 8080 equivalents.
--
Salu2
Exactly my point on the original stupidity of not including the
instruction. The equivalent has to destroy some register content,
in this case bp.
Ah, I get it. Since the 8080 translated code does not know about bp,
use bp. Great until you try to extend the translated code :-)
:> MOV BP,SP
:> XCHG BX,[BP]
: Exactly my point on the original stupidity of not including the
: instruction. The equivalent has to destroy some register content,
: in this case bp.
You could expand it to
PUSH BP
MOV BP,SP
XCHG BX,2[BP]
POP BP
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)