Udo Munk wrote:
(snip)

> You can interface a 16 bit CPU to a 8 bit environment without much
> problems. Was done anyway, e.g. Seattle Inc had a 8086 card for S-100
> bus systems,

(snip)

I believe many used 16 bits on the S-100 bus.

The original S-100 has two 8 bit data buses, one for input
and one for output (or read/write if you like). It may have
made sense in the beginning, but most don't work that way, so it
wasn't hard to use both as a 16 bit bus.

At least I think that is what 16 bit S-100 cards did.

-- glen

>> There really isn't a requirement to "not destroy anything", because
>> the 8086 has more registers than the 8080 - so after you map 8080 to
>> 8086 registers, you are still left with a few scratchpad registers.
>
>Disagree. You may well want to preserve '86 registers. I
>certainly have.

Sure - it may be a requirement of yours... but it's not a necessary
requirement of an 8080->8080 translator. The job of an 8080 -> 8086
translator is to take 8080 code and generate 8086 code that does the
same function. Since the original 8080 program could not have stored
data in registers which did not exist on the 8080, it cannot rely on
data in 8086 registers not mapped to 8080 registers (Technically, one
could argue that there is no specific requirement to preserve any
8086 registers, since the 8080 registers could be represented in RAM,
however for efficiency's sake most translators map them directly into
8086 registers and they are therefore relied upon by the translated
program).

It may be a requirement in your implementation, or you may be doing
something beyond an 8080 -> 8086 translator which relies on data not
specific to the original 8080 program which is kept in non-mapped
8086 registers ... but that does not mean that preserving the non-mapped
registers is a requirement to the task of 8080 -> 8086 translation.

Given that any 8086 registers directly mapped to 8080 registers will
be "trashed" by the translated code, why would you stipulate a that
there is a requirement to not affect certain other specific registers.
If there is a requirement to preserve the 8086 registers around the
translated code, then it would seem best to preserve all potentially
affected 8086 registers on entry and exit from the translated code,
not on each individual translated instruction.

The 8086 has a fairly close mapping of instructions to 8080 instructions,
I've just pulled out my 8080 -> 8086 table, and I find that the only
8080 instructions requiring more than 1 8086 instruction are:

PUSH PSW -> LAHF / PUSH AX
POP PSW -> POP AX / SAHF
Cond. CALL -> !Cond. JMP around CALL
Cond. RET -> !Cond. JMP around RET
LDAX rp -> MOV SI,mrp / MOV AL,[SI]
STAX rp -> MOV SI,mrp / MOV [SI],AL
XTHL -> POP SI / XCHG BX,SI / PUSH SI

You will notice that the last three "trash" SI - Using a scratchpad
register is the most efficient way to accomplish these functions, and
I do NOT preserve it since it's content is not relied upon for any
other purpose or at any other time in the translated code.

So it happens in my implementation that the following 8086 registers
may be altered by the translated code:

AH = Scratchpad for flags
AL = 8080 Accumulator
BX = 8080 HL registers
CX = 8080 BC registers
DX = 8080 DE registers
SP = 8080 Stack pointer
SI = Scratchpad register used by some translated instructions.

Although not altered by the translated code, it is assumed that
CS and DS have been established to point to a suitable memory
region prior to launching the translated code.

The following 8086 registers happen NOT to be altered by the
translated code:

DI, BP, ES

These are details of my implementation, but not specific required
characteristics of an 8080 -> 8086 translator.

If the higher level 8086 system requires that registers be preserved
after executing the 8080 code, then this is no different than a similar
requirement to preserve registers after a block of 8086 code - the
person integrating the 8080 code into the system would be responsible
to preserve/restore the affected registers, just as he is responsible
to setup CS and DS - these are system specific functions that the
general purpose translator cannot forsee.

In practice, differences in OS, I/O devices, memory layout etc. mean
that the translated 8080 code will require some work before it can
be used anyway - providing suitable setup/exit code is part of that
process.

As to the statement that the 8086 cannot perform an XTHL function
without destroying some other register or non-stack data - as I
showed in my last posting, it can - but in my 8080 -> 8086 translator
I destroy SI because it produces smaller/faster code and SI is
available for destruction. If you happen to want to use SI for some
other global purpose on the system running code generated by my
translator, I consider it no different than if you wanted to use AX,
BX, CX, or DX - SI is one of the registers used by the translated
code... deal with it (ie: preserve/restore it around the translated
code block).

Dave

--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com Some stuff I have for sale: www.dunfield.com/sale

On Jul 27, 12:51*pm, glen herrmannsfeldt
wrote:
> s_dubrov...@yahoo.com wrote:
>
> (snip)
>
> > Intel apparently had a document around the time of the introduction of
> > the 8086 detailing how to do the 8080 conversion to 8086 code. *Has
> > anyone seen this document, or happen to have it, or know of an online
> > reference??
>
> It seems that one is in SIG/M 173
>
> http://www.retroarchive.org/cpm/cdro...00/VOL173/0CAT...
>
> -- glen

Well, that is a translating program written for REC, Regular
Expression Compiler, not the Intel Doc I'm after.

Steve

glen herrmannsfeldt schrieb:

> I think these sound right. If the official intel translator
> is found, we can verify them.

On the ISIS tools disk at http://www.unix4fun.org/z80pack/ you will find
Intels CONV86 ISIS program, that can be used under CP/M with the ISIS
emulator. Easy enough to have it convert some programs and figure what
it does.

Udo Munk
--
The real fun is building it and then using it...

Dave Dunfield wrote:
(snip)

> The 8086 has a fairly close mapping of instructions to 8080 instructions,
> I've just pulled out my 8080 -> 8086 table, and I find that the only
> 8080 instructions requiring more than 1 8086 instruction are:

> PUSH PSW -> LAHF / PUSH AX
> POP PSW -> POP AX / SAHF

I presume that LAHF and SAHF were specifically added
to the 8086 to do this. LAHF then turned out to be
very useful in getting flags out of the 8087.
(Store into memory, load into AH, LAHF, conditional
branch based on those flags.)

> Cond. CALL -> !Cond. JMP around CALL
> Cond. RET -> !Cond. JMP around RET
> LDAX rp -> MOV SI,mrp / MOV AL,[SI]
> STAX rp -> MOV SI,mrp / MOV [SI],AL
> XTHL -> POP SI / XCHG BX,SI / PUSH SI

I think these sound right. If the official intel translator
is found, we can verify them.

> You will notice that the last three "trash" SI - Using a scratchpad
> register is the most efficient way to accomplish these functions, and
> I do NOT preserve it since it's content is not relied upon for any
> other purpose or at any other time in the translated code.

> So it happens in my implementation that the following 8086 registers
> may be altered by the translated code:

> AH = Scratchpad for flags
> AL = 8080 Accumulator
> BX = 8080 HL registers
> CX = 8080 BC registers
> DX = 8080 DE registers
> SP = 8080 Stack pointer
> SI = Scratchpad register used by some translated instructions.

I think this sounds right, too. The BX and CX registers
have some special uses needed to make these work.

> Although not altered by the translated code, it is assumed that
> CS and DS have been established to point to a suitable memory
> region prior to launching the translated code.

Depending on the code, CS and DS may or may not have the
same value. As the code may be bigger than the 8080 code,
it might be useful to have CS and DS point to code space
and data space, respectively. That might require segment
override on some data references.

(snip)

-- glen

>> PUSH PSW -> LAHF / PUSH AX
>> POP PSW -> POP AX / SAHF

>I presume that LAHF and SAHF were specifically added
>to the 8086 to do this.

I believe so yes.


>> AH = Scratchpad for flags
>> AL = 8080 Accumulator
>> BX = 8080 HL registers
>> CX = 8080 BC registers
>> DX = 8080 DE registers
>> SP = 8080 Stack pointer
>> SI = Scratchpad register used by some translated instructions.

>I think this sounds right, too. The BX and CX registers
>have some special uses needed to make these work.

HL is special on the 8080 because of the 'M' pseudo-register
access to memory - this makes BX the obvious choice, since BX
can be dereferenced to memory and CX or DX cannot. The
other special HL operations (DAD, XCHG, XTHL) can be done on
any 8086 register.

DX is special on the 8080 only because of XCHG - this can be
done on any suitable register on the 8086, so the choice for
mapping of BX and DE into CX and DX could be done either
way.


>Depending on the code, CS and DS may or may not have the
>same value. As the code may be bigger than the 8080 code,
>it might be useful to have CS and DS point to code space
>and data space, respectively. That might require segment
>override on some data references.

Although it's possible to implement the equivalent of small
model in translated 8080 code, the truth is that the original
code would have assumed a single address space - there
will be no way to discern an instruction referencing data in
code space (static tables etc.) from insturctions referencing
data space (at least not easily at translation time) - for example,
a subroutine which copies memory could use a static table
as source, or another dynamic block - the only difference is
the runtime address passed to it.

So virtually all 8080->8086 translations would be assuning a
single CD=DS=SS address space - anything else would require
significant manual labor. And yes, it was done - I've seen projects
which began as translated 8080 code and "grew and grew"...

Dave

--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com Some stuff I have for sale: www.dunfield.com/sale

>> So virtually all 8080->8086 translations would be assuning a
>> single CD=DS=SS address space - anything else would require
>> significant manual labor. And yes, it was done - I've seen projects
>> which began as translated 8080 code and "grew and grew"...

>If the person doing the translation knew the coding style,
>it might not be so bad.

If the translation was done by a person, then it was feasable.
I thought we were talking about automatic translators .... I don't
recall ever seeing one that would generate anything other than
tiny model 8086 code (all in one segment).

>Also, it shouldn't be so hard
>to find references to constant data in code space and
>separate them from other data references.

Difficult for an automatic translator - 8080 code used to
use all kinds of "tricks" to save space here and there,
so it was not uncommnon to reload the low byte of an
address and not the high - if there are possible entry
points within the segment, it can quickly become very
difficult to automatically figure out where things are in
advance (at translate time) - plus, even if you could,
you would need to generate multiple versions of
subroutines with addressing modes (segments) to
match the used argument times - not impossible, but
I never saw an automatic translator that could do it.

>It helps if the code was written to be reentrant.
>(Yes, that was done in the 8080 days.)

:-)

The Intel 8086 Family Users Manual says this about
CONV-86 (on page 2-92):

"Some programs cannot be completely converted
by CONV-86. Exceptions includes:

- self-modifying code
- software timing loops
- 8085 RIM and SIM instructions
- Interrupt code, and
- macros"

I especially like the reference to self-modifying...

The intel translator was IIRC very similar to my own, and
basically did a instruction by instruction translation - very
simple, but therefore not dependant on the program logic
and able to at least "mostly" convert just about anything.

Dave

--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com Some stuff I have for sale: www.dunfield.com/sale

Dave Dunfield wrote:
(snip)

> So virtually all 8080->8086 translations would be assuning a
> single CD=DS=SS address space - anything else would require
> significant manual labor. And yes, it was done - I've seen projects
> which began as translated 8080 code and "grew and grew"...

If the person doing the translation knew the coding style,
it might not be so bad. Also, it shouldn't be so hard
to find references to constant data in code space and
separate them from other data references.

It helps if the code was written to be reentrant.
(Yes, that was done in the 8080 days.)

-- glen

Dave Dunfield wrote:
(snip)

> If the translation was done by a person, then it was feasable.
> I thought we were talking about automatic translators .... I don't
> recall ever seeing one that would generate anything other than
> tiny model 8086 code (all in one segment).

I meant the person using the automated conversion
program. The problem is, if the code expands then there
might not be enough room for data. If one knows something
about the code, one might be able to fix it.

(snip)

> Difficult for an automatic translator - 8080 code used to
> use all kinds of "tricks" to save space here and there,
> so it was not uncommnon to reload the low byte of an
> address and not the high - if there are possible entry
> points within the segment, it can quickly become very
> difficult to automatically figure out where things are in
> advance (at translate time) - plus, even if you could,
> you would need to generate multiple versions of
> subroutines with addressing modes (segments) to
> match the used argument times - not impossible, but
> I never saw an automatic translator that could do it.

>>It helps if the code was written to be reentrant.
>>(Yes, that was done in the 8080 days.)

> The Intel 8086 Family Users Manual says this about
> CONV-86 (on page 2-92):

> "Some programs cannot be completely converted
> by CONV-86. Exceptions includes:

> - self-modifying code
> - software timing loops
> - 8085 RIM and SIM instructions
> - Interrupt code, and
> - macros"

> I especially like the reference to self-modifying...

> The intel translator was IIRC very similar to my own, and
> basically did a instruction by instruction translation - very
> simple, but therefore not dependant on the program logic
> and able to at least "mostly" convert just about anything.

One of my favorite tricks from those days was putting
instructions inside other instructions. A two byte
instruction could go in the address part of a load
instruction, for example. The 6809 has a
branch never instruction in both short and long
(8 and 16 bit offset) form. I used to do disassembly
of 8080 and 6809 code, so had to learn all the tricks.

-- glen

On Jul 23, 5:41*pm, "Mr. Emmanuel Roche, France"
wrote:
> Hello, Udo!
>
> Reading your message, I was laughing, since we are on such different
> wavelentghs!
>
> > This is not the OSI layer model, but nevermind, this model will do too.
>
> Anaway, as far as know the ISO OSI model is purely theorical, and has been
> overcomed by TCP/IP, by a "grass root effect" (as they say in
> English/American).
>
>
>
> > > claimed that TCP/IP could fit into 10 to 24KB. I have already
> disassembled a
> > > dozen programs bigger than this size.)
>
> > Such claims are pretty useless. There is no need to disassemble, the
> > TCP/IP stacks for Z80 systems are available as source code.
>
> Yes, but probably in "C"... and, years after years, we have heard stories
> here, in the comp.os.cpm Newsgroup, that C is not portable, or too big, or
> too slow. In my opinion, Unix and C are viable only on a 16-bits+ computer.
> For CP/M, I think that assembly language is the only solution (I searched
> the Internet for "TCP/IP in Forth", but found nothing, to my surprise).
>
> > or Windows, I'll tell you a top secret. The company Zilog, the guys who
> > invented the Z80 processor, still produce a Z80 CPU right now. The thing
> > is called eZ80. This little thingy is a Z80 CPU (with some extensions)
> > and a complete TCP/IP protocol stack put into the hardware. There is
>
> Yes, but this is not a Z-80 running at 4-MHz under CP/M, so it does not
> count.
>
> On the Web, there is a video of a German surfing the Net on a C=64 (if I
> have well understood). This proves that my goal is doable. I was VERY
> surprised that no Z-80 port of uIP (or Contiki) were made. Maybe Adam Dunkel
> learned to program on a 6502, and don't knows that the Z-80 exists?
>
> > Google... when I enter "Z80 TCP/IP" as search string I get hundreds of
> > hits, good matches on the first page already, describing ancient CP/M
>
> Hahaha! Me, I had entered "TCP/IP for CP/M"...
>
> Ok. I will now wait for the TCP/IP books. I think that everything that I
> will find will be in "C", since Internet (and, hence, TCP/IP) is based on
> some Unix standards. I already know how to write a library of macros
> emulating the printf function of C. For years, I have wanted a "C-to-BASIC"
> File Converter... Maybe it is time to write it? (I searched "TCP/IP in
> BASIC": no answer! It would be funny to be the first man to program a TCP/IP
> in BASIC! This way, the source would be portable, and readable.)
>
> Yours Sincerely,
> Mr. Emmanuel Roche, France

Here's some references for you:

Sockets:

http://www.opengroup.org/onlinepubs/009619199/index.htm


IBM docs about tcp/ip, TCP/IP Tutorial and Technical Overview:

http://www.redbooks.ibm.com/abstracts/gg243376.html

referer page:

http://publib.boulder.ibm.com/infoce...e/pdftable.htm

TCP/IP Wiki:
http://en.wikipedia.org/wiki/Tcp/ip

If you notice, the ka9q source uses sockets for the software 'bridge'
to the TCP/IP protocol.

Steve

Hello, Steve!

> Here's some references for you:

Ho! My...

Many thanks, Steve. However, I will try to use only the 3 books recommended
by Phil Karn to understand TCP/IP (he should be knowledgeable, since,
according to him, his code was the base of Linux's TCP/IP). There are simply
too many references (this is typical of Unix stuff: they simply don't know
how to make things small, simple, and speedy). In addition, I must not mix
standard (that is to say: BSD) TCP/IP, LightWeight IP, and Ralf Kästner
version of doing things (I don't understand one single word of all his
comments in German). (I tried to re-assemble Ralf Kästner's CPMNET, but I am
missing a file named SYSLIB.REL.)

Meanwhile, I received the book of Douglas Comer: "Internetworking with
TCP/IP".

Am now waiting for the other 2 books recommended by Phil Karn.

Ho! By the way, I have seen, on the Retroarchive Web site, that Aztec C was
available for CP/M-86... So, if, finally, a lost copy of KA9Q for CP/M is
found, we could re-compile it to use it on IBM Clowns... Kirk Lawrence would
have liked that! A vintage 1985 version of TCP/IP, running under "CP/M-86
for the IBM PC", with floppies... (If the MS-DOS version was available, we
could compare it with later MS-DOS versions of KA9Q.)

Yours Sincerely,
Mr. Emmanuel Roche, France

On Jul 31, 6:00 pm, "Mr. Emmanuel Roche, France"
wrote:

>. So, if, finally, a lost copy of KA9Q for CP/M is
> found, we could re-compile it to use it on IBM Clowns... Kirk Lawrence would
> have liked that! A vintage 1985 version of TCP/IP, running under "CP/M-86
> for the IBM PC", with floppies... (If the MS-DOS version was available, we
> could compare it with later MS-DOS versions of KA9Q.)
>
> Yours Sincerely,
> Mr. Emmanuel Roche, France

I looked briefly at the referenced FTP site:

ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/

Examine the directories "above" this directory, and look for a "docs"
directory. There is a document in it which describes KAQ9 and
derivatives which provides some background. My impression is that the
C sources can in principle be assembled/compiled for CP/M or MS-DOS or
UNIX or Amiga. As in any compilation for a processor or an operating
system, one needs the correct libraries to support those items.

All this stuff is apparently part of the history of packet radio for
radio amateurs in the 1980's and early 90's. One might find more
information on Web pages and within discussion groups from the period
supporting that activity. I know nothing about that material or
activity, myself.

Again, my impression is that there is not much KA9Q "stuff" on the Web
- the above FTP site may be well over a decade old! Possibly, old CD-
ROMs of "amateur radio software" may have similar material. I also
recall old archives like DECUS carried some amount of MS-DOS material,
for the DEC Rainbow.

This is otherwise relevant to CP/M because all these resources also
archived CP/M material. And, as Roche suggests, the difference between
early MS-DOS and CP/M-86 was not so great. "Sauce for the goose is
sauce for the gander."

Herb Johnson
retrotechnology.com

theres software to do that i have a c64 online at present using serial cable
and bbs server on the pc It works with most machines except sadly my
osborne which for some unknown reason doesnt put the needed signals out of
its combined serial/parallel port starting to suspect a fault in the machine
as every machine apart from it trigger the dsr and cts lines once a terminal
app is loaded i have a vms shell and from there i use my 64 on irc,lynx or
gopher
Garth

> http://tcp.dr.ea.ms/
> full implementation for z80's

Apparently, "sponge" is:

Andrew J. Kroll
Software and Hardware Engineer and Consultant

He seems to have a problem with the English vocabulary (or maybe he is
dyslexic?) since even his very, very short lines contains many typos.

However, he seems competent about the C language, and recompiling old C
programs under various platforms (apparently, he has a Commodore C=128).

Finllay, he also has another Web page: http://cpm.dr.ea.ms/

That's all I have found, so far.

Let's hope that he will write more about his C=128 connected to a Linux box.
(His pictures are awful, barely readable.)

Yours Sincerely,
Mr. Emmanuel Roche, France

"Mr. Emmanuel Roche, France" writes:

>> http://tcp.dr.ea.ms/
>> full implementation for z80's


>He seems to have a problem with the English vocabulary (or maybe he is
>dyslexic?) since even his very, very short lines contains many typos.


Please don't judge on someones ability to write error-free english prosa.
I myself would have difficulties to write like William Shakespeare nor
like Molière (aka Jean-Baptiste Poquelin).

The domain '.ms' is an indication of some island in the carribic sea.

amicalement, Holger

Herb Johnson wrote:
> On Jul 31, 6:00 pm, "Mr. Emmanuel Roche, France"
> wrote:
>
>> . So, if, finally, a lost copy of KA9Q for CP/M is
>> found, we could re-compile it to use it on IBM Clowns... Kirk Lawrence would
>> have liked that! A vintage 1985 version of TCP/IP, running under "CP/M-86
>> for the IBM PC", with floppies... (If the MS-DOS version was available, we
>> could compare it with later MS-DOS versions of KA9Q.)
>>
>> Yours Sincerely,
>> Mr. Emmanuel Roche, France
>
> I looked briefly at the referenced FTP site:
>
> ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/
>
> Examine the directories "above" this directory, and look for a "docs"
> directory. There is a document in it which describes KAQ9 and
> derivatives which provides some background. My impression is that the
> C sources can in principle be assembled/compiled for CP/M or MS-DOS or
> UNIX or Amiga. As in any compilation for a processor or an operating
> system, one needs the correct libraries to support those items.
>
> All this stuff is apparently part of the history of packet radio for
> radio amateurs in the 1980's and early 90's. One might find more
> information on Web pages and within discussion groups from the period
> supporting that activity. I know nothing about that material or
> activity, myself.
>
> Again, my impression is that there is not much KA9Q "stuff" on the Web
> - the above FTP site may be well over a decade old! Possibly, old CD-
> ROMs of "amateur radio software" may have similar material. I also
> recall old archives like DECUS carried some amount of MS-DOS material,
> for the DEC Rainbow.
>
> This is otherwise relevant to CP/M because all these resources also
> archived CP/M material. And, as Roche suggests, the difference between
> early MS-DOS and CP/M-86 was not so great. "Sauce for the goose is
> sauce for the gander."
>
> Herb Johnson
> retrotechnology.com

http://tcp.dr.ea.ms/
full implementation for z80's

On Sep 1, 5:21 am, "Mr. Emmanuel Roche, France" wrote:

> >http://tcp.dr.ea.ms/
> > full implementation for z80's
>
> Apparently, "sponge" is:
>
> Andrew J. Kroll
> Software and Hardware Engineer and Consultant
>
> [typical Roche complaints deleted]

> Finllay, he also has another Web page: http://cpm.dr.ea.ms/
>
> [typical Roche complaints deleted]

I found these pages to be an absolute *hoot*! "LOL" as the kids say
today. It's creative work using Commodore 128 technology of the era.
Looks - and sounds - fine to me. I did not review the source code but
Andrew does good and solid work.

If Roche wants more description and better English prose, how about
"the proof of the pudding is in the eating"? My impression is that the
C128 is hosting this content, under CP/M, hooked to the Internet
through a Linux box. Nothing beats looking at a working
impementation!

Herb Johnson
retrotechnology.com

Mr. Emmanuel Roche, France wrote:
>> http://tcp.dr.ea.ms/
>> full implementation for z80's
>
> Apparently, "sponge" is:
>
> Andrew J. Kroll
> Software and Hardware Engineer and Consultant

Nope, just passing on the url.

>
> He seems to have a problem with the English vocabulary (or maybe he is
> dyslexic?) since even his very, very short lines contains many typos.

He might be, who knows?

> However, he seems competent about the C language, and recompiling old C
> programs under various platforms (apparently, he has a Commodore C=128).
>
> Finllay, he also has another Web page: http://cpm.dr.ea.ms/
>
> That's all I have found, so far.
>
> Let's hope that he will write more about his C=128 connected to a Linux box.
> (His pictures are awful, barely readable.)

Did you try to email him?
He may have more information.