AltairZ80 simulator updated - CP/M

This is a discussion on AltairZ80 simulator updated - CP/M ; The AltairZ80 simulator has been updated and is available for download at http://www.schorn.ch/cpm/intro.html New: - Various new devices (courtesy of Howard M. Harte) - New operating systems to play with (courtesy of Howard M. Harte) * 86-DOS by Seattle Computer ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 49

Thread: AltairZ80 simulator updated

  1. AltairZ80 simulator updated

    The AltairZ80 simulator has been updated and is available for download
    at http://www.schorn.ch/cpm/intro.html

    New:
    - Various new devices (courtesy of Howard M. Harte)
    - New operating systems to play with (courtesy of Howard M. Harte)
    * 86-DOS by Seattle Computer Products
    * CDOS (Cromemco Disk Operating System)
    * CompuPro Collection (CP/M 2.2Q, CP/M 2.2NZ, CP/M 86 1.1PB)
    * CP/M Pus (for SIMH and CompuPro, contributed by Tony Nicholson)
    * MS-DOS 1.25
    * N8VEM Single Board Computer (Monitor & CP/M 2.2C)
    - Updated documentation
    - Minor bug fixes

    Features of the simulator:
    - Pre-built versions for PC, Macintosh (OS X universal binary),
    LINUX (i386) and Zaurus (ARM LINUX)
    - Full ANSI C source code and documentation available for download
    - Choice of processor (8080 CPU, Z80 CPU, 8086 CPU)
    - Optional banked memory (16 banks with 64 Kbytes)
    - MMU with flexible ROM and memory mapped I/O support
    - Optional hard drive support for additional storage capacity with
    choice of disk geometry
    - Various devices for Northstar, CompuPro and Vector Graphic
    - Optional networking support via TCP/IP
    - Support for multiple consoles
    - Timer and keyboard generated interrupts
    - Memory access and instruction breakpoints
    - VT100 emulation via Telnet
    - Ability to set the clock speed for "real-time" simulation (useful for
    games)
    - Based on SIMH 3.8-0

    Ready to run disk images include:
    - Original Altair software such as the famous 4K Basic
    - 86-DOS (by Seattle Computer Products)
    - CDOS (Cromemco Disk Operating System)
    - CompuPro Collection (CP/M 2.2Q, CP/M 2.2NZ, CP/M 86 1.1PB)
    - CP/M 1.4 (for the historically inclined, with sources)
    - CP/M 2.2 (including all sources for CCP, BDOS and BIOS)
    - CP/M Pus (for SIMH and CompuPro)
    - CP/NET 1.2 and CPNOS 1.2 (including all customized sources)
    - Personal CP/M (including source for CCP, BDOS and BIOS)
    - CP/M 3 (including sources for BIOS)
    - MP/M II (supporting banked memory and up to 4 consoles via Telnet)
    - DOS+, NovaDOS, P2DOS, SuperDOS, Z80DOS, ZSDOS
    - NZ-COM (Z-System based on CP/M 2.2, sources, PDF user manual)
    - Z3PLUS (Z-System based on CP/M 3, sources, PDF user manual)
    - CP/M 86 (CP/M for 8086 with BIOS sources)
    - IMDOS (56K IMDOS V2.05)
    - MDOS (Micropolis MDOS V3.0)
    - MS-DOS 1.25
    - N8VEM (Single Board Computer (Monitor & CP/M 2.2C))
    - NDOS (Northstar DOS 5.0 and 2.1.1)
    - OASIS (OASIS multi-user version 5.5A for Vector Graphic)

    Ready to run disk images of CP/M application software:
    - Programming languages: Ada, Algol, APL, various Basic implementations,
    BDS C, COBOL, Forth, FORTRAN, Lisp, Modula 2, Mumps, muSIMP,
    Pascal, UCSD Pascal II.0, PL/I, PLM, SPL, MINOL, VTL-2
    - Basic collection includes MTBASIC, S-BASIC and TARBELL BASIC
    - Office applications: dBASE, Wordstar, VEDIT, Multiplan, SuperCalc
    - Games: Adventure (Colossal Cave), Catchum, Worm, Ladder, Rogue,
    Wanderer
    - Development: M80, L80, CREF80, DDTZ,
    transfer between host file system and simulated file system
    with wild card support

    Download at http://www.schorn.ch/cpm/intro.html

    --
    Peter Schorn
    peter.schorn at acm.org
    http://www.schorn.ch

  2. Re: AltairZ80 simulator updated

    Hello Peter,

    On Mon, 28 Jul 2008 19:40:20 +0200, Peter Schorn wrote:

    >The AltairZ80 simulator has been updated and is available for download
    >at http://www.schorn.ch/cpm/intro.html


    Thanks for your Info.

    Rolf


  3. Re: AltairZ80 simulator updated

    Peter Schorn ha scritto:
    > The AltairZ80 simulator has been updated and is available for download
    > at http://www.schorn.ch/cpm/intro.html
    >
    > New:
    > - Various new devices (courtesy of Howard M. Harte)
    > - New operating systems to play with (courtesy of Howard M. Harte)
    > * 86-DOS by Seattle Computer Products


    This 86-DOS is *really* interesting, esp. the chckdsk's last line of
    output, whose reveal that there wasn't technical limitations for the use
    of the full 8086/88 moby, gate$ and the IBM engineers has really huge
    blames.

    Best regards from Italy,
    Dott. Piergiorgio.

  4. Re: AltairZ80 simulator updated

    Blames? They thought that 640k was all that anyone would need (and, in
    1980 (when the design was done) they were probably right). So they put
    firmware and memory mapped I/O beginning just beyond 640K. I hardly
    think that it's right to attack them for that.


    dott.Piergiorgio wrote:
    > Peter Schorn ha scritto:
    >> The AltairZ80 simulator has been updated and is available for download
    >> at http://www.schorn.ch/cpm/intro.html
    >>
    >> New:
    >> - Various new devices (courtesy of Howard M. Harte)
    >> - New operating systems to play with (courtesy of Howard M. Harte)
    >> * 86-DOS by Seattle Computer Products

    >
    > This 86-DOS is *really* interesting, esp. the chckdsk's last line of
    > output, whose reveal that there wasn't technical limitations for the use
    > of the full 8086/88 moby, gate$ and the IBM engineers has really huge
    > blames.
    >
    > Best regards from Italy,
    > Dott. Piergiorgio.

    ** Posted from http://www.teranews.com **

  5. Re: AltairZ80 simulator updated

    On Jul 28, 2:10*pm, "dott.Piergiorgio"
    wrote:
    > Peter Schorn ha scritto:
    >
    > > The AltairZ80 simulator has been updated and is available for download
    > > athttp://www.schorn.ch/cpm/intro.html

    >
    > > New:
    > > - Various new devices (courtesy of Howard M. Harte)
    > > - New operating systems to play with (courtesy of Howard M. Harte)
    > > * * 86-DOS by Seattle Computer Products

    >
    > This 86-DOS is *really* interesting, esp. the chckdsk's last line of
    > output, whose reveal that there wasn't technical limitations for the use
    > of the full 8086/88 moby, gate$ and the IBM engineers has really huge
    > blames.
    >
    > Best regards from Italy,
    > Dott. Piergiorgio.


    Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    not a limitation of MS-DOS, but rather a limitation of the PC
    hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    and 10x CP/M-80 RAM probably seemed reasonable at the time.

    It also looks like there is a bug in chkdsk, but Tim Paterson probably
    didn't have a meg of RAM to test with.

    -Howard


  6. Re: AltairZ80 simulator updated

    Howard Harte ha scritto:
    > On Jul 28, 2:10 pm, "dott.Piergiorgio"
    > wrote:
    >> Peter Schorn ha scritto:
    >>
    >>> The AltairZ80 simulator has been updated and is available for download
    >>> athttp://www.schorn.ch/cpm/intro.html
    >>> New:
    >>> - Various new devices (courtesy of Howard M. Harte)
    >>> - New operating systems to play with (courtesy of Howard M. Harte)
    >>> * 86-DOS by Seattle Computer Products

    >> This 86-DOS is *really* interesting, esp. the chckdsk's last line of
    >> output, whose reveal that there wasn't technical limitations for the use
    >> of the full 8086/88 moby, gate$ and the IBM engineers has really huge
    >> blames.
    >>
    >> Best regards from Italy,
    >> Dott. Piergiorgio.

    >
    > Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    > not a limitation of MS-DOS, but rather a limitation of the PC
    > hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    > and 10x CP/M-80 RAM probably seemed reasonable at the time.


    I can agree on this, but... why starting with A bank and not, say, D or
    E bank ?

    Until MCGA video memory & graphic register can be inside an entire 64K
    bank, and AFAICT the three XT bios (system, HD controller and graphic
    card) can fit inside an entire 64K bank, if one known how to do things
    in 8086 asm.

    >
    > It also looks like there is a bug in chkdsk, but Tim Paterson probably
    > didn't have a meg of RAM to test with.


    hmmm... indeed the .pdf of Paterson's ad for his 8086 cards show a 16 Kb
    RAM card; and also a quick glance of the manuals seems to show no
    trace of memory models other than .COM/tiny; I think that the effective
    capability of handling large binary of 86-dos can be (theorically)
    tested with a code whose has a sequence nearby 64K of NOPs and a brief
    routine at the end of bank whose print the bank done. I guess can be
    easily done with a good macro assy.

    For now, I'll try to give SIMH SET CPU MEMORY=768k (if works, the
    documentation isn't clear on this command...) and look what chkdsk outputs.

    But I agree that this "0 bytes total system RAM" seems a clear evidence
    of some bug or nonimplemented routine.

    Thanks for your reply and informations !

    Best regards from Italy,
    Dott. Piergiorgio.

  7. Re: AltairZ80 simulator updated

    dott.Piergiorgio ha scritto:

    >>
    >> It also looks like there is a bug in chkdsk, but Tim Paterson probably
    >> didn't have a meg of RAM to test with.


    > For now, I'll try to give SIMH SET CPU MEMORY=768k (if works, the
    > documentation isn't clear on this command...) and look what chkdsk outputs.
    >
    > But I agree that this "0 bytes total system RAM" seems a clear evidence
    > of some bug or nonimplemented routine.


    UPDATE: actually here *IS* a bug (and the system ram routine is actually
    implemented) :

    with 768K of ram in the emu:

    A:chkdsk
    19 disk files
    245760 bytes total disk space
    146944 bytes remain available

    786432 bytes total system RAM
    774304 bytes free

    now "total system ram" correctly gets that there are 768K....

    Later I'll see the results with 64K increments of emu ram..

    Best regards from Italy,
    Dott. Piergiorgio.

  8. Re: AltairZ80 simulator updated

    > Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    > not a limitation of MS-DOS, but rather a limitation of the PC
    > hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    > and 10x CP/M-80 RAM probably seemed reasonable at the time.


    The 640 barrier was largely illusory anyway. Basic memory management
    support in DOS had most of what it needed to support 1 MB, as evidenced
    by the high memory support of later years.

    The real mind blower is the short-sightedness of a 1 MB limit. The cause
    of that one is the size of a paragraph, the basic unit of the segment
    register.

    De

  9. Re: AltairZ80 simulator updated

    Remember that the original IBM-PC had basic in ROM. Plus BIOS. Plus
    hardware memory mapped I/O (including devices that were then being
    designed but that would not come to market for another 2 years, like the
    EGA and PGA video cards).


    dott.Piergiorgio wrote:
    > Howard Harte ha scritto:
    >> On Jul 28, 2:10 pm, "dott.Piergiorgio"
    >> wrote:
    >>> Peter Schorn ha scritto:
    >>>
    >>>> The AltairZ80 simulator has been updated and is available for download
    >>>> athttp://www.schorn.ch/cpm/intro.html
    >>>> New:
    >>>> - Various new devices (courtesy of Howard M. Harte)
    >>>> - New operating systems to play with (courtesy of Howard M. Harte)
    >>>> * 86-DOS by Seattle Computer Products
    >>> This 86-DOS is *really* interesting, esp. the chckdsk's last line of
    >>> output, whose reveal that there wasn't technical limitations for the use
    >>> of the full 8086/88 moby, gate$ and the IBM engineers has really huge
    >>> blames.
    >>>
    >>> Best regards from Italy,
    >>> Dott. Piergiorgio.

    >>
    >> Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    >> not a limitation of MS-DOS, but rather a limitation of the PC
    >> hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    >> and 10x CP/M-80 RAM probably seemed reasonable at the time.

    >
    > I can agree on this, but... why starting with A bank and not, say, D or
    > E bank ?
    >
    > Until MCGA video memory & graphic register can be inside an entire 64K
    > bank, and AFAICT the three XT bios (system, HD controller and graphic
    > card) can fit inside an entire 64K bank, if one known how to do things
    > in 8086 asm.
    >
    >>
    >> It also looks like there is a bug in chkdsk, but Tim Paterson probably
    >> didn't have a meg of RAM to test with.

    >
    > hmmm... indeed the .pdf of Paterson's ad for his 8086 cards show a 16 Kb
    > RAM card; and also a quick glance of the manuals seems to show no trace
    > of memory models other than .COM/tiny; I think that the effective
    > capability of handling large binary of 86-dos can be (theorically)
    > tested with a code whose has a sequence nearby 64K of NOPs and a brief
    > routine at the end of bank whose print the bank done. I guess can be
    > easily done with a good macro assy.
    >
    > For now, I'll try to give SIMH SET CPU MEMORY=768k (if works, the
    > documentation isn't clear on this command...) and look what chkdsk outputs.
    >
    > But I agree that this "0 bytes total system RAM" seems a clear evidence
    > of some bug or nonimplemented routine.
    >
    > Thanks for your reply and informations !
    >
    > Best regards from Italy,
    > Dott. Piergiorgio.

    ** Posted from http://www.teranews.com **

  10. Re: AltairZ80 simulator updated

    The 640k limitation was ENTIRELY in the hardware. The Heath/Zenith
    Z-100 allowed 768k of user RAM (it's video and bios used the last 256k),
    and it was running the same OS as the PC.


    Dennis Boone wrote:
    > > Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    > > not a limitation of MS-DOS, but rather a limitation of the PC
    > > hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    > > and 10x CP/M-80 RAM probably seemed reasonable at the time.

    >
    > The 640 barrier was largely illusory anyway. Basic memory management
    > support in DOS had most of what it needed to support 1 MB, as evidenced
    > by the high memory support of later years.
    >
    > The real mind blower is the short-sightedness of a 1 MB limit. The cause
    > of that one is the size of a paragraph, the basic unit of the segment
    > register.
    >
    > De

    ** Posted from http://www.teranews.com **

  11. Re: AltairZ80 simulator updated

    Barry Watzman wrote:
    > The 640k limitation was ENTIRELY in the hardware. The Heath/Zenith
    > Z-100 allowed 768k of user RAM (it's video and bios used the last 256k),
    > and it was running the same OS as the PC.
    >
    >
    > Dennis Boone wrote:
    >
    >> > Try MS-DOS 1.25. You'll find more evidence that the 640k barrier is
    >> > not a limitation of MS-DOS, but rather a limitation of the PC
    >> > hardware. Of course, the IBM had to put memory-mapped I/O somewhere,
    >> > and 10x CP/M-80 RAM probably seemed reasonable at the time.

    >>
    >> The 640 barrier was largely illusory anyway. Basic memory management
    >> support in DOS had most of what it needed to support 1 MB, as evidenced
    >> by the high memory support of later years.
    >>
    >> The real mind blower is the short-sightedness of a 1 MB limit. The cause
    >> of that one is the size of a paragraph, the basic unit of the segment
    >> register.
    >>
    >> De

    >
    > ** Posted from http://www.teranews.com **





    The 8088 had a 20 bit address bus = 1 meg.

  12. Re: AltairZ80 simulator updated

    Barry Watzman wrote:

    > The 640k limitation was ENTIRELY in the hardware. The Heath/Zenith
    > Z-100 allowed 768k of user RAM (it's video and bios used the last 256k),
    > and it was running the same OS as the PC.


    Later versions of OS/2 would run DOS in something like 704K,
    not using the X'A0000' block normally reserved. In addition,
    there was almost 64K more available at X'100000' due to the
    way segment offsets were computed on later processors.

    -- glen


  13. Re: AltairZ80 simulator updated

    cavelamb himself wrote:
    (snip)

    > The 8088 had a 20 bit address bus = 1 meg.


    That is true, but you could do more.

    There were pins that would indicate which segment the
    address came from. One could have a separate address
    space for code, stack, and data. I believe the 8080
    could also do that based on the type of access.

    -- glen


  14. Re: AltairZ80 simulator updated

    *Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >memory mapped I/O


    Please correct me, but as far as I know neither the 8080 nor the 8086
    nor any of their derivatives use memory mapped I/O. In fact this is
    what made the IBM-AT emulator for the Atari using little more that a
    bare 80286 possible -- all I/O were redirected to native 68000
    subroutines and all memory accesses done directly.


  15. Re: AltairZ80 simulator updated

    On Jul 30, 5:25*am, Axel_Ber...@b.maus.de (Axel Berger) wrote:
    > *Barry Watzman* wrote on Tue,08-07-29 02:55:
    >
    > >memory mapped I/O

    >
    > Please correct me, but as far as I know neither the 8080 nor the 8086
    > nor any of their derivatives use memory mapped I/O. In fact this is
    > what made the IBM-AT emulator for the Atari using little more that a
    > bare 80286 possible -- all I/O were redirected to native 68000
    > subroutines and all memory accesses done directly.


    I was considering the video card as memory mapped I/O, and I'm sure
    there are other examples.

    Peter Schorn just added a MP/M-86 and Concurrent CP/M-86 software kit
    to his site.

    It's pretty amazing to be able to run MP/M-86 in simulation.
    Concurrent CP/M-86 includes support for the Compupro DISK3 controller,
    and runs all of the I/O in interrupt-driven mode, including the DISK1A
    FDC. MP/M-86 uses interrupts for everything except the FDC.

  16. Re: AltairZ80 simulator updated



    "Axel Berger" wrote in message
    news:200807301425.a54811@b.maus.de...
    > *Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >>memory mapped I/O

    >
    > Please correct me, but as far as I know neither the 8080 nor the 8086
    > nor any of their derivatives use memory mapped I/O.


    They both could use it as could the Z-80 (see TRS-80 Model I and III).
    The video on the IBM PC was memory mapped (and still is on IBM
    compatibles these days. Of course anything more than CGA also uses ports
    to map banks of video RAM into the CGA area.
    Memory mapping isn't a function of the CPU, it's a function of the support
    chips.

    Tom Lake


  17. Re: AltairZ80 simulator updated

    Tom Lake schrieb:
    >
    >
    > "Axel Berger" wrote in message
    > news:200807301425.a54811@b.maus.de...
    >> *Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >>> memory mapped I/O

    >>
    >> Please correct me, but as far as I know neither the 8080 nor the 8086
    >> nor any of their derivatives use memory mapped I/O.

    >
    > They both could use it as could the Z-80 (see TRS-80 Model I and III).
    > The video on the IBM PC was memory mapped (and still is on IBM
    > compatibles these days. Of course anything more than CGA also uses ports
    > to map banks of video RAM into the CGA area.
    > Memory mapping isn't a function of the CPU, it's a function of the
    > support chips.
    >
    > Tom Lake


    Mapped video memory is not memory mapped I/O, you still just read/write
    memory.

    Example for real memory mapped I/O are the 8080 and Z80 systems that
    switched their ROM off by a JMP instruction, usually to address 0. The
    read access to memory address 0 would trigger I/O that takes the ROM
    offline and places RAM into this address range, re-programming some sort
    of MMU that way.

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

  18. Re: AltairZ80 simulator updated

    On Wed, 30 Jul 2008 14:25:00 +0200, Axel_Berger@b.maus.de (Axel
    Berger) wrote:

    >*Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >>memory mapped I/O

    >
    >Please correct me, but as far as I know neither the 8080 nor the 8086
    >nor any of their derivatives use memory mapped I/O. In fact this is
    >what made the IBM-AT emulator for the Atari using little more that a
    >bare 80286 possible -- all I/O were redirected to native 68000
    >subroutines and all memory accesses done directly.


    Generally they do not. But, there is NOTHING to prevent you from
    doing so and I can state that one system the NS* Horizon uses memory
    mapped IO to do the FDC.

    There are a lot of good reasons to do memeory mapped IO on
    8080/8085/z80 (and others) in that you ahve greater address space
    and logical operations on ports are doable plus word (16bit) transfers
    in a single instruction even with 8080!

    Allison

  19. Re: AltairZ80 simulator updated

    On Wed, 30 Jul 2008 19:13:13 -0400, "Tom Lake"
    wrote:

    >
    >
    >"Axel Berger" wrote in message
    >news:200807301425.a54811@b.maus.de...
    >> *Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >>>memory mapped I/O

    >>
    >> Please correct me, but as far as I know neither the 8080 nor the 8086
    >> nor any of their derivatives use memory mapped I/O.

    >
    >They both could use it as could the Z-80 (see TRS-80 Model I and III).


    The TRS80 also memory mapped the keyboard!

    Allison



    >The video on the IBM PC was memory mapped (and still is on IBM
    >compatibles these days. Of course anything more than CGA also uses ports
    >to map banks of video RAM into the CGA area.
    >Memory mapping isn't a function of the CPU, it's a function of the support
    >chips.
    >
    >Tom Lake



  20. Re: AltairZ80 simulator updated

    Udo Munk wrote:
    >

    .... snip ...
    >
    > Example for real memory mapped I/O are the 8080 and Z80 systems
    > that switched their ROM off by a JMP instruction, usually to
    > address 0. The read access to memory address 0 would trigger I/O
    > that takes the ROM offline and places RAM into this address range,
    > re-programming some sort of MMU that way.


    I built my 8080 systems with a dual flipflop that was reset by the
    reset pulse, and then counted up to three (a shift register). It
    counted memory accesses. Until it hit three the high byte of the
    memory access was supplied by a dipswitch (or patch board plugging
    into a socket). This let me start execution on any of 256 possible
    pages. Never had any urge to change it. The basic reason for the
    construct was that, at time of conception, I had no idea what my
    eventual monitor was going to look like.

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



+ Reply to Thread
Page 1 of 3 1 2 3 LastLast