How many SIG/M disks where there? - CP/M

This is a discussion on How many SIG/M disks where there? - CP/M ; 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 ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 118 of 118

Thread: How many SIG/M disks where there?

  1. Re: How many SIG/M disks where there?

    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


  2. Re: How many SIG/M disks where there?

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


  3. Re: How many SIG/M disks where there?

    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

  4. Re: How many SIG/M disks where there?

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

  5. Re: How many SIG/M disks where there?

    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


  6. Re: How many SIG/M disks where there?

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


  7. Re: How many SIG/M disks where there?

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


  8. Re: How many SIG/M disks where there?

    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


  9. Re: How many SIG/M disks where there?

    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


  10. Re: Sockets, tcp/ip

    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

  11. Re: Sockets, tcp/ip

    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




  12. Re: Sockets, tcp/ip

    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

  13. Re: How many SIG/M disks where there?

    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



  14. Re: Sockets, tcp/ip

    > 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




  15. Re: Sockets, tcp/ip

    "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

  16. Re: Sockets, tcp/ip

    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

  17. Re: Sockets, tcp/ip

    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


  18. Re: Sockets, tcp/ip

    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.


+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6