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) > Well, if you can manipulate statistics at your will, of course I can do > too. So I will write programs that always will do MOV AH,x, MOV AL,y > instead of MOV AX,zz. If ...

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 118

Thread: How many SIG/M disks where there?

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

    Udo Munk wrote:
    (snip)

    > Well, if you can manipulate statistics at your will, of course I can do
    > too. So I will write programs that always will do MOV AH,x, MOV AL,y
    > instead of MOV AX,zz. If you count instruction usage on the rubbish it
    > will be all 8 bit instructions only and that is the prove then ;-)
    > Could even make sense if the data can't be properly aligned for some
    > reason and the 16 bit instruction would get a hefty execution time penalty.


    The penalty likely isn't worse than the two MOV instructions.
    Also, the 8088 doesn't have that penalty, or always has it,
    whichever way you count. The penalty is that the 8086 has to
    do two single byte operations on unaligned data, the 8088
    always has to do that.

    -- glen


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

    Udo Munk wrote:
    (snip, I wrote)

    >> Yes, it means that 8 bit peripheral hardware could be
    >> used, and people were more used to designing with that.
    >> Things like floppy controllers with an 8 bit data bus,
    >> and 8 bit wide memory.


    > I have serious doubts about that one. IBM build 32bit and 64bit
    > equipment in the late 60th already and in the 70th I have used TONS of
    > that stuff. They knew very well how to design a 16 or 32 bit floppy disk
    > controller e.g. I don't think they suddenly forgot about how to do that
    > in 1981, and they still sold tons of better equipment.


    They knew how to design such, but not at prices that anyone
    would pay for a personal computer. Though most of the S/360
    and S/370 I/O devices use an eight bit data bus. Memory had
    a much wider bus, but not I/O devices.

    -- glen


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

    glen herrmannsfeldt wrote:
    >

    .... snip ...
    > for 8080 source compatibility. It is supposed to work out that,
    > with the right assembler, you can assemble 8080 code to run on
    > the 8086. ...


    Nope, not possible. The 8086/88 lacks the equivalent of the XTHL
    instruction of the 8080/Z80, and that makes it impossible to
    manipulate the registers without destroying something, or using
    dedicated (i.e. non-stack) storage.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



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

    On Jul 26, 3:27*pm, Udo Munk wrote:
    > glen herrmannsfeldt schrieb:
    >
    > > Udo Munk wrote:
    > > (snip on AX vs AL)

    >

    [snipped]
    >
    > > vs AX. * Though much of that was added to the 8086 to allow
    > > for 8080 source compatibility. *It is supposed to work out
    > > that, with the right assembler, you can assemble 8080 code
    > > to run on the 8086. * Also, that is why I include ALU
    > > width in my geometric mean calculation.

    >
    > Not that easy probably, because 8080 to 8086 converters were used.
    > Is there such an assembler? Just wondering, because even Intel used an
    > 8080 to 8086 converter under Isis.
    >

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

    TIA
    Steve

    > > Even better, it should be weighted on actual instruction usage.

    >
    > > -- glen

    >
    > Well, if you can manipulate statistics at your will, of course I can do
    > too. So I will write programs that always will do MOV AH,x, MOV AL,y
    > instead of MOV AX,zz. If you count instruction usage on the rubbish it
    > will be all 8 bit instructions only and that is the prove then ;-)
    > Could even make sense if the data can't be properly aligned for some
    > reason and the 16 bit instruction would get a hefty execution time penalty.
    >
    > Udo Munk
    > --
    > The real fun is building it and then using it...



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


    http://www.alldatasheet.com/datashee...NTEL/8088.html

    To e-mail me, add the character zero to "dowcom". i.e.:
    dowcom(zero)(at)webtv(dot)net.

    --
    http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE

    MSWindows is television,… Linux is radar.


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

    On Sat, 26 Jul 2008 19:05:54 -0700 (PDT), s_dubrovich@yahoo.com wrote:

    >On Jul 26, 3:27*pm, Udo Munk wrote:
    >> glen herrmannsfeldt schrieb:
    >>
    >> > Udo Munk wrote:
    >> > (snip on AX vs AL)

    >>

    >[snipped]
    >>
    >> > vs AX. * Though much of that was added to the 8086 to allow
    >> > for 8080 source compatibility. *It is supposed to work out
    >> > that, with the right assembler, you can assemble 8080 code
    >> > to run on the 8086. * Also, that is why I include ALU
    >> > width in my geometric mean calculation.

    >>
    >> Not that easy probably, because 8080 to 8086 converters were used.
    >> Is there such an assembler? Just wondering, because even Intel used an
    >> 8080 to 8086 converter under Isis.
    >>

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


    I dont have it but remember it from back when and it was a nasty
    process due to instructions and also naming convetions.

    Somewhere on the net is a program that actually does the 8080->8086
    conversion. Caveats abound! I'd tried it once but I tend to avoid
    programming 8086 and later cpus close to the iron as they are 8080
    with a crufty bag on the side. I always thought the 8080 was clever
    with its use of resources and instructions but the 8086 was plain
    dumb.

    Allison

    >
    >TIA
    >Steve
    >
    >> > Even better, it should be weighted on actual instruction usage.

    >>
    >> > -- glen

    >>
    >> Well, if you can manipulate statistics at your will, of course I can do
    >> too. So I will write programs that always will do MOV AH,x, MOV AL,y
    >> instead of MOV AX,zz. If you count instruction usage on the rubbish it
    >> will be all 8 bit instructions only and that is the prove then ;-)
    >> Could even make sense if the data can't be properly aligned for some
    >> reason and the 16 bit instruction would get a hefty execution time penalty.
    >>
    >> Udo Munk
    >> --
    >> The real fun is building it and then using it...



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

    no.spam@no.uce.bellatlantic.net wrote:
    (snip)

    > Somewhere on the net is a program that actually does the 8080->8086
    > conversion. Caveats abound! I'd tried it once but I tend to avoid
    > programming 8086 and later cpus close to the iron as they are 8080
    > with a crufty bag on the side. I always thought the 8080 was clever
    > with its use of resources and instructions but the 8086 was plain
    > dumb.


    I always thought that given the 8080 compatibility requirement
    and the number of transistors, that the 8086 design was pretty good.

    As with many intel processors, it uses dynamic logic which I
    never really liked. That is, there is a minimum clock
    frequency that is fairly high. I think 2.5MHz for 8086.

    The 68000 was more like what one should have expected,
    more like minicomputers of the time, but it was somewhat
    later and more expensive than the 8086.

    -- glen


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

    s_dubrovich@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...3/0CATALOG.173

    -- glen


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

    On Jul 27, 7:55*am, no.s...@no.uce.bellatlantic.net wrote:
    > On Sat, 26 Jul 2008 19:05:54 -0700 (PDT), s_dubrov...@yahoo.com wrote:
    > >On Jul 26, 3:27*pm, Udo Munk wrote:
    > >> glen herrmannsfeldt schrieb:

    >
    > >> > Udo Munk wrote:
    > >> > (snip on AX vs AL)

    >
    > >[snipped]

    >
    > >> > vs AX. * Though much of that was added to the 8086 to allow
    > >> > for 8080 source compatibility. *It is supposed to work out
    > >> > that, with the right assembler, you can assemble 8080 code
    > >> > to run on the 8086. * Also, that is why I include ALU
    > >> > width in my geometric mean calculation.

    >
    > >> Not that easy probably, because 8080 to 8086 converters were used.
    > >> Is there such an assembler? Just wondering, because even Intel used an
    > >> 8080 to 8086 converter under Isis.

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

    >
    > I dont have it but remember it from back when and it was a nasty
    > process due to instructions and also naming convetions.
    >
    > Somewhere on the net is a program that actually does the 8080->8086
    > conversion. *Caveats abound! *I'd tried it once but I tend to avoid
    > programming 8086 and later cpus close to the iron as they are 8080
    > with a crufty bag on the side. *I always thought the 8080 was clever
    > with its use of resources and instructions but the 8086 was plain
    > dumb.
    >
    > Allison
    >

    Yes, there is XLT-86 on Gaby's site, which does a pretty good job of
    translating. It is interesting to run cp/m-80 v.2.2 thru it to see
    how close it comes to cp/m-86 disassembly, same overall structure
    mostly.

    However, for historical reasons I'm on the lookout for that particular
    intel document. Also, I'm on the lookout for the intel document which
    covers their 8086 relocation format/scheme. Also, I'm looking for
    DRI's application note regarding FIDD driver format, just in case any
    of these ring a bell.

    Steve

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

    On Sun, 27 Jul 2008 09:38:06 -0800, glen herrmannsfeldt
    wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >(snip)
    >
    >> Somewhere on the net is a program that actually does the 8080->8086
    >> conversion. Caveats abound! I'd tried it once but I tend to avoid
    >> programming 8086 and later cpus close to the iron as they are 8080
    >> with a crufty bag on the side. I always thought the 8080 was clever
    >> with its use of resources and instructions but the 8086 was plain
    >> dumb.

    >
    >I always thought that given the 8080 compatibility requirement
    >and the number of transistors, that the 8086 design was pretty good.


    The compatability was only in passing. NEC with the V20 took it to
    the level of real compatability.

    >
    >As with many intel processors, it uses dynamic logic which I
    >never really liked. That is, there is a minimum clock
    >frequency that is fairly high. I think 2.5MHz for 8086.


    Thats the stated minimum but I run them as slow as 500khz
    in debug sessions.

    >The 68000 was more like what one should have expected,
    >more like minicomputers of the time, but it was somewhat
    >later and more expensive than the 8086.


    Unfortunately also very late arrival. It was superior.

    Allison

    >
    >-- glen



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

    s_dubrovich@yahoo.com wrote:
    (snip)

    > Yes, there is XLT-86 on Gaby's site, which does a pretty good job of
    > translating. It is interesting to run cp/m-80 v.2.2 thru it to see
    > how close it comes to cp/m-86 disassembly, same overall structure
    > mostly.


    From web searching, the 80T86.CNV that I indicated in a previous
    post looked older (that is, more historical) than XLT86, but I
    don't actually know the history of either of them.

    -- glen


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

    glen herrmannsfeldt wrote:
    > s_dubrovich@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...3/0CATALOG.173
    >
    >
    > -- glen
    >


    Hi all,

    let's come back to the original question:

    How many SIG/M disks where there?

    Up to now I learned: 310, and they are all
    on ten WC cdrom. Are there any more and where
    can I download them?

    I learned a lot about TCP/IP for CP/M and the
    difficulties to decide between 8/16/32 bit
    cpus. Interesting, but.....

    Greetings,

    Uwe.

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


    >
    > 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??
    >
    > TIA
    > Steve


    I suppose we could always ask early employees from Microsoft or
    Digital Research

    Nudge Nudge wink wink

    Regards marcus

    (Apologies in advance for this cheap and troll centric inaccurate
    comment, but it was somehow irresistible )

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

    "Uwe Nass" wrote:

    > Hi all,
    >
    > let's come back to the original question:
    >
    > How many SIG/M disks where there?
    >
    > Up to now I learned: 310, and they are all
    > on ten WC cdrom. Are there any more and where
    > can I download them?


    Found on the Internet:

    In 1976 we created one of the first on-line Bulletin Board Systems with free
    access that anyone could log into. The system remained in operation until
    1996....over 20 years of continuous operation. We created the first on-line
    software library from which users could download software. The system also
    had chat rooms, and a crude e-mail facility. In 1990 the system was linked
    to the Internet.

    In 1977 we founded the SIG/M Software Library. It operated until 1983. In
    the six years of operation it created and distributed over 2,000 public
    domain and shareware CP/M programs on close to a hundred different floppy
    disks to over 50 computer clubs around the world. This was the first
    Software Library ever created for Personal Computers.

    In 1983 we created the PC/Blue Software Library and distributed over 200
    different public domain IBM-PC compatible software disks and shipped
    thousands of disks to hundreds of clubs around the world. Hank Kee served as
    the Librarian for both libraries creating the disks; Bob Todd, Steve Leon,
    and several other volunteers handled the distribution. The Library operated
    until the early 1990's when the Internet became a more popular way of
    distributing public-domain and shareware software.

    ROCHE> I also found an interesting text, saying that the "shareware" concept
    of the IBM Clown killed the SIG/M software library, but could not copy it.
    (It is the 4th links when you search for "SIG/M Software Library".)

    Apparently, there are a few companies selling copies of SIMTEL20 CD-ROM, but
    only those dealing with MS-DOS...

    Yours Sincerely,
    Mr. Emmanuel Roche, France




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

    Thierry B. schrieb:
    > --{ Udo Munk a plopé ceci: }--
    >
    >> No? Other have. Here the 8088 - 8-BIT HMOS MICROPROCESSOR - Intel
    >> Corporation datasheet:
    >> http://www.alldatasheet.com/datashee...NTEL/8088.html
    >>
    >> Intel describes it as a 8 bit processor with internal 16 bit
    >> capabilities, which it is, like others too.
    >>

    > At this time, beeing compliant with the 8bit world was a
    > marketing attitude, no ?
    >
    >


    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, and also IBM later offered 16 bit 8086 systems with some 16
    bit and some 8 bit slots. Why Intel build that 8088 thing ca. one year
    after they had the 8086 is a myth to me, and probably I don't want to
    know that.

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

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

    CBFalconer wrote:
    (snip regarding 8080 to 8086 compatibility)

    > Nope, not possible. The 8086/88 lacks the equivalent of the XTHL
    > instruction of the 8080/Z80, and that makes it impossible to
    > manipulate the registers without destroying something, or using
    > dedicated (i.e. non-stack) storage.


    I don't remember the specific answer to this one. It might be
    that it takes more than one instruction. You also have to use
    the right 8086 register for each 8080 register. The 8086 code
    might be larger. Also, I don't know that there is a rule
    against dedicated storage.

    -- glen


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

    glen herrmannsfeldt wrote:
    > CBFalconer wrote:
    > (snip regarding 8080 to 8086 compatibility)
    >
    >> Nope, not possible. The 8086/88 lacks the equivalent of the
    >> XTHL instruction of the 8080/Z80, and that makes it impossible
    >> to manipulate the registers without destroying something, or
    >> using dedicated (i.e. non-stack) storage.

    >
    > I don't remember the specific answer to this one. It might be
    > that it takes more than one instruction. You also have to use
    > the right 8086 register for each 8080 register. The 8086 code
    > might be larger. Also, I don't know that there is a rule
    > against dedicated storage.


    The point is that, with that instruction omitted, it is impossible
    to manipulate registers, stack, etc. without destroying something.
    This is a barrier the 8080, z80, 64180, z180 do not have.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



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

    On Tue, 29 Jul 2008 20:42:33 +0200, Udo Munk
    wrote:

    >Thierry B. schrieb:
    >> --{ Udo Munk a plopé ceci: }--
    >>
    >>> No? Other have. Here the 8088 - 8-BIT HMOS MICROPROCESSOR - Intel
    >>> Corporation datasheet:
    >>> http://www.alldatasheet.com/datashee...NTEL/8088.html
    >>>
    >>> Intel describes it as a 8 bit processor with internal 16 bit
    >>> capabilities, which it is, like others too.
    >>>

    >> At this time, beeing compliant with the 8bit world was a
    >> marketing attitude, no ?
    >>
    >>

    >
    >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, and also IBM later offered 16 bit 8086 systems with some 16
    >bit and some 8 bit slots. Why Intel build that 8088 thing ca. one year
    >after they had the 8086 is a myth to me, and probably I don't want to
    >know that.


    the 8086 has a signal to distinguish between a byte access and a word
    access, BHE/. Many other 16 and 32 bit cpus address IO and often
    memory as well on a byte basis based on instruction mode.

    The 8088 was designed to fit in the middle class where cost senstivity
    is high but 16 bits makes programming easier. Due to the cost of
    buffers and latches and savings on bus lines an 8088 system can be
    cheaper with less than 2:1 performance hit. It's also easier to debug
    hardware using 8088.


    Allison


    >Udo Munk



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

    >(snip regarding 8080 to 8086 compatibility)

    >> Nope, not possible. The 8086/88 lacks the equivalent of the XTHL
    >> instruction of the 8080/Z80, and that makes it impossible to
    >> manipulate the registers without destroying something, or using
    >> dedicated (i.e. non-stack) storage.


    >I don't remember the specific answer to this one. It might be
    >that it takes more than one instruction. You also have to use
    >the right 8086 register for each 8080 register. The 8086 code
    >might be larger. Also, I don't know that there is a rule
    >against dedicated storage.


    One of my long ago projects was "AT" (Assembly Translator) which
    is an attempt at a universal table driven translator from one assembly
    language to another - Worked very well for some architecture combos,
    and not so well for others. One of the first tables I did was 8080 -> 8086,
    and it is ndeed possible - Intel designed it that way (the tables are quite
    simple).

    Some 8080 instructions do require more than one 8086 instruction,
    for example:

    PUSH PSW

    Becomes

    LAHF
    PUSH AX

    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.

    For example, to maintain byte addressable high and low as well
    as 'M' access to memory, most translators mapped HL into BX.
    BC and DE typically went into CX and DX in order to maintain byte
    access to high and low. IIRC my translator maps the registers
    into:

    A = AL
    HL = BX
    BC = CX
    DE = DX

    This leaves SI, DI and BP as scratchpad registers with no 8080
    equivalent. One example of such use is LDAX/STAX - CX/DX
    don't provide a memory addressing function, so the translator
    would translate LDAX B into something like:

    MOV SI,CX
    MOV AL,[SI]

    XTHL could become:

    POP SI
    XCHG BX,SI
    PUSH SI

    -or-

    MOV SI,SP
    XCHG BX,[SI]

    [Since the 8080 has only one address space, we assume that
    DS and SS reference the same segment in the translated code
    If you really want to maintain stack segment acces, you could
    use BP instead of SI, although that would cost you an extra
    byte - The first example, although three 8086 instuctions instead
    of two, accomplishes this in the same space as the SI version
    of the second example]

    If you really really want to swap a register with the top of the stack
    and not destroy any registers or dedicated memory on the 8086,
    you could do it with something like:

    PUSH BP
    MOV BP,SP
    XCHG BX,2[BP]
    POP BP

    But for an 8080->8086 translator it makes more sense to use a
    scratchpad register and avoid having to preserve it..

    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


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

    Dave Dunfield wrote:
    >

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

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.


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