Ram Card Design Help - CP/M

This is a discussion on Ram Card Design Help - CP/M ; I am completing a final design for the SuperAltair card. I really only need 56-60k to make Altair 8800 people happy, but stepping up to 128k is actually cheaper. I don't know enough about CP/M to know if this could ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: Ram Card Design Help

  1. Ram Card Design Help

    I am completing a final design for the SuperAltair card. I really
    only need 56-60k to make Altair 8800 people happy, but stepping up to
    128k is actually cheaper.

    I don't know enough about CP/M to know if this could be useful. I'm
    not even sure if the 8080 ever did bank swaping in CP/M. I imagine I
    would need a special CBIOS to handle the swapping? How much would be
    swapped? 0-32k stay the same all the time and 32-56 would get swapped
    out?

    Seriously, I could step up to 512k of SRAM for only another $2.30.
    The 4k SRAM card I made a kit out of has around $15 just in
    sockets. ; )

    The card will be an open source design. It will offer 128k-512k of
    bank swapped FLASH memory for a monitor, the memory described above,
    and a few more hot items of interest to everyone in the S-100
    community.

    Grant


  2. Re: Ram Card Design Help

    On Sat, 20 Oct 2007 21:53:22 -0700, Grant Stockly
    wrote:

    >I am completing a final design for the SuperAltair card. I really
    >only need 56-60k to make Altair 8800 people happy, but stepping up to
    >128k is actually cheaper.
    >
    >I don't know enough about CP/M to know if this could be useful. I'm
    >not even sure if the 8080 ever did bank swaping in CP/M. I imagine I


    Yes it did CPM+ aka cpmV3. By it's release 8080s were scarce it
    was written at the 8080 code level.

    >would need a special CBIOS to handle the swapping? How much would be


    CP/M+ had a expanded BIOS to handle that.

    >swapped? 0-32k stay the same all the time and 32-56 would get swapped
    >out?


    There were many schemes. The easiest is to have the lower 32k
    swapable.

    Generally speaking there are few applications that took advantage of
    extende memory. CP/M+ and MPM used it but user applications didn't.

    >Seriously, I could step up to 512k of SRAM for only another $2.30.
    >The 4k SRAM card I made a kit out of has around $15 just in
    >sockets. ; )


    Why not! It will work with z80s too and other may desire it.

    >
    >The card will be an open source design. It will offer 128k-512k of
    >bank swapped FLASH memory for a monitor, the memory described above,
    >and a few more hot items of interest to everyone in the S-100
    >community.


    Things Altair needed.

    Turnkey boot rom saves fingers on the front pannel. I actually
    had switches wear out from use several times.

    Enough ram usually 64K was enough.

    For most uses CP/M1.4 or V2.x with 48K ram was adaquate,
    56K nice and 64K allowed even the biggest aps enough room.

    Consistant IO Altair used multiple different IO cards... plus
    aftermarket. (Sio-A, SIO-B and 2SIO, parallel and there was a 4SIO)
    NS* [and a few others] really did the IO right in that all Horizons
    were two serial, parallel in, parallel out, Periodic interrupt Tick,
    and some interrupt management all on the backplane. Pick an
    IO and make sure all the software can play with it.

    PC compatable parallel printer board most of the centronics
    boards would do but were often third party. There are still plenty
    of printers both dot matrix impact and some lasers like the hp-4L
    that work fine of a standard parallel port for text.

    Softsector DD FDC, there were many so it was possible to upgrade
    but the standard Altair was hardsector single density. the problem
    is all the Altair disk software played with that one and only that
    one. A board that emulated the two board altair controller and
    had enough Flash to store the few programs that were unique
    to that controller would be interesting to some. [or patch the
    programs as needed to work with a generic style flash board.]

    Allison
    >Grant



  3. Re: Ram Card Design Help

    On Sun, 21 Oct 2007 13:29:44 +0000, no.spam wrote:

    > On Sat, 20 Oct 2007 21:53:22 -0700, Grant Stockly
    > wrote:
    >
    >>I am completing a final design for the SuperAltair card. I really
    >>only need 56-60k to make Altair 8800 people happy, but stepping up to
    >>128k is actually cheaper.
    >>
    >>I don't know enough about CP/M to know if this could be useful. I'm
    >>not even sure if the 8080 ever did bank swaping in CP/M. I imagine I

    >
    > Yes it did CPM+ aka cpmV3. By it's release 8080s were scarce it
    > was written at the 8080 code level.
    >
    >>would need a special CBIOS to handle the swapping? How much would be

    >
    > CP/M+ had a expanded BIOS to handle that.
    >
    >>swapped? 0-32k stay the same all the time and 32-56 would get swapped
    >>out?

    >
    > There were many schemes. The easiest is to have the lower 32k
    > swapable.


    Why would that be the easiest? 32k banks actually are pretty bad.
    A good compromise was upper 16k common and lower 48k swappable.
    For CP/M 3 it doesn't matter, because when the user bank is in context,
    the TPA can reach up into the common memory, so any bank size could be
    used. Not so with MP/M, the size of the swappable banks is the size of
    the TPA. 16/48 will work OK for MP/M, but if one wants to implement CP/NET
    that won't work. The CP/NET processes were not written as banked
    extensions and need to be completely in common memory. So the best
    compromise would be 20k common and 44k swappable, much better than a 32k
    TPA.

    In the current version of my virtual Z80 system the size of the common
    memory can be programmed in steps of 256byte pages, so one can experiment
    with this.

    At later times MMU's with page tables were used, the whole memory
    is split into pages with 4k or 8k so that any memory configuration can be
    programmed. There was a TTL MMU from TI that would do this, 743xx
    something, I don't know anymore, sorry.

    Something I still have to do for my virtual Z80 system.

    > Generally speaking there are few applications that took advantage of
    > extende memory. CP/M+ and MPM used it but user applications didn't.


    No CP/M 3 program can use it, because the memory management is transparent
    to the application and only the OS knows where GENCPM put the buffers,
    hash tables and so on. The ccp can be loaded from one bank to avoid disk
    access for a warm boot, or one can create a memory disk to be used by
    compilers as faster temp workspace. There is a lot one can do in the BIOS
    to speed up disk access significantly, but programs can't use it.

    Also MP/M programs can't directly use another bank, but one can write
    large programs split in smaller ones, running in separate banks and use
    OS services like message queues for communication.

    >>Seriously, I could step up to 512k of SRAM for only another $2.30. The
    >>4k SRAM card I made a kit out of has around $15 just in sockets. ; )

    >
    > Why not! It will work with z80s too and other may desire it.


    MP/M supports ~400kb, CP/M 3 supports 1mb, so go for it I think.

    ....
    > Allison
    >>Grant


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


  4. Re: Ram Card Design Help

    On Sun, 21 Oct 2007 18:33:12 +0200, Udo Munk
    wrote:

    >On Sun, 21 Oct 2007 13:29:44 +0000, no.spam wrote:
    >
    >> On Sat, 20 Oct 2007 21:53:22 -0700, Grant Stockly
    >> wrote:
    >>
    >>>I am completing a final design for the SuperAltair card. I really
    >>>only need 56-60k to make Altair 8800 people happy, but stepping up to
    >>>128k is actually cheaper.
    >>>
    >>>I don't know enough about CP/M to know if this could be useful. I'm
    >>>not even sure if the 8080 ever did bank swaping in CP/M. I imagine I

    >>
    >> Yes it did CPM+ aka cpmV3. By it's release 8080s were scarce it
    >> was written at the 8080 code level.
    >>
    >>>would need a special CBIOS to handle the swapping? How much would be

    >>
    >> CP/M+ had a expanded BIOS to handle that.
    >>
    >>>swapped? 0-32k stay the same all the time and 32-56 would get swapped
    >>>out?

    >>
    >> There were many schemes. The easiest is to have the lower 32k
    >> swapable.

    >
    >Why would that be the easiest? 32k banks actually are pretty bad.


    You only need one bit to select a bank then. There are plenty of
    other schemes. My preference is 4k scatter/gather paging.

    >A good compromise was upper 16k common and lower 48k swappable.
    >For CP/M 3 it doesn't matter, because when the user bank is in context,
    >the TPA can reach up into the common memory, so any bank size could be
    >used. Not so with MP/M, the size of the swappable banks is the size of
    >the TPA. 16/48 will work OK for MP/M, but if one wants to implement CP/NET
    >that won't work. The CP/NET processes were not written as banked
    >extensions and need to be completely in common memory. So the best
    >compromise would be 20k common and 44k swappable, much better than a 32k
    >TPA.


    Exactly, most any scheme works. I only suggested one possible way.

    >In the current version of my virtual Z80 system the size of the common
    >memory can be programmed in steps of 256byte pages, so one can experiment
    >with this.


    I have the granularity is nice but the overhead is high. 4K strikes
    a good balance.

    >At later times MMU's with page tables were used, the whole memory
    >is split into pages with 4k or 8k so that any memory configuration can be
    >programmed. There was a TTL MMU from TI that would do this, 743xx
    >something, I don't know anymore, sorry.


    74612 was one, it can also be done with a pair of 74ls189s or similar
    8 words by 8bits of ram or register.

    >Something I still have to do for my virtual Z80 system.


    I've done it and it's fun to play with. The most useful application
    is buffers, ramdisk and other bios bulk placed in them to allow a
    larger say 62-63K TPA.

    >> Generally speaking there are few applications that took advantage of
    >> extende memory. CP/M+ and MPM used it but user applications didn't.

    >
    >No CP/M 3 program can use it, because the memory management is transparent
    >to the application and only the OS knows where GENCPM put the buffers,
    >hash tables and so on. The ccp can be loaded from one bank to avoid disk
    >access for a warm boot, or one can create a memory disk to be used by
    >compilers as faster temp workspace. There is a lot one can do in the BIOS
    >to speed up disk access significantly, but programs can't use it.


    I didn't say they could not use it I said there were very limited
    number of applications that were written for that and utilized it.
    The larger volume of programs are for the CP/M2.2 programming
    model.

    Also CP/M 2.2 did not prevent or disallow expanded memory.

    >Also MP/M programs can't directly use another bank, but one can write
    >large programs split in smaller ones, running in separate banks and use
    >OS services like message queues for communication.


    If there is only one machine and ... The point being the user may be
    using V1.4 or even V2.2 and all of that means little there save for
    you can hide a large bios in banked/paged ram or use the excess ram
    as a ram disk.

    >>>Seriously, I could step up to 512k of SRAM for only another $2.30. The
    >>>4k SRAM card I made a kit out of has around $15 just in sockets. ; )

    >>
    >> Why not! It will work with z80s too and other may desire it.

    >
    >MP/M supports ~400kb, CP/M 3 supports 1mb, so go for it I think.


    MPM supports as much as CP/M 3 which is at least 1MB
    I know of no reason why larger is not possible.

    Basically how you page or bank memory it is up to you as it
    will be complatable with at least one of the many schemes
    out there all of which were mostly incompatable with each
    other.

    As to how much, 512k is a start more if you care to. MY
    suggestion is at least 512 and a meg is better. Reason,
    even on V2.2 the excess ram beyobd 64k can at a minimum
    be a ramdisk and I've found for that application the more
    is better and I have two systems with 1MB and one with 8MB
    as a baseline of experience. The speed and spae of ram disk
    can make even slow 8080s look impressive compared to a
    floppy.

    Allison





  5. Re: Ram Card Design Help

    On Sun, 21 Oct 2007 20:28:11 +0000, no.spam wrote:

    ....
    >>> There were many schemes. The easiest is to have the lower 32k
    >>> swapable.

    >>
    >>Why would that be the easiest? 32k banks actually are pretty bad.

    >
    > You only need one bit to select a bank then. There are plenty of
    > other schemes. My preference is 4k scatter/gather paging.


    Ah, for the circuit design that would be the easiest, true.
    4kb page tables would be the best option, agreed.

    >>A good compromise was upper 16k common and lower 48k swappable.
    >>For CP/M 3 it doesn't matter, because when the user bank is in context,
    >>the TPA can reach up into the common memory, so any bank size could be
    >>used. Not so with MP/M, the size of the swappable banks is the size of
    >>the TPA. 16/48 will work OK for MP/M, but if one wants to implement CP/NET
    >>that won't work. The CP/NET processes were not written as banked
    >>extensions and need to be completely in common memory. So the best
    >>compromise would be 20k common and 44k swappable, much better than a 32k
    >>TPA.

    >
    > Exactly, most any scheme works. I only suggested one possible way.


    For CP/M 3 any scheme works and it doesn't matter. I just wanted to point
    out that the 32/32 scheme might not be a real good idea, if one wants to
    use MP/M on the system.

    >>In the current version of my virtual Z80 system the size of the common
    >>memory can be programmed in steps of 256byte pages, so one can
    >>experiment with this.

    >
    > I have the granularity is nice but the overhead is high. 4K strikes a
    > good balance.


    What you can program at a very early stage in OS initialization is the
    size of the common memory, leaving the rest as swappable banks. That is to
    experiment with 16/48 settings and others, because I couldn't get CP/NET
    stuffed into that. There is no overhead involved because the segmentation
    can be programmed once only and any change afterwards just would make a
    mess, so it is verboten ;-)

    >>At later times MMU's with page tables were used, the whole memory is
    >>split into pages with 4k or 8k so that any memory configuration can be
    >>programmed. There was a TTL MMU from TI that would do this, 743xx
    >>something, I don't know anymore, sorry.

    >
    > 74612 was one, it can also be done with a pair of 74ls189s or similar 8
    > words by 8bits of ram or register.


    Ah yes, the 74612 was the one I meant, if I remember right that one was
    used in some machines I worked with.

    >>Something I still have to do for my virtual Z80 system.

    >
    > I've done it and it's fun to play with. The most useful application is
    > buffers, ramdisk and other bios bulk placed in them to allow a larger
    > say 62-63K TPA.


    I was using that for real work, not to play with, and that machine wasn't
    running any DRI product at all. We needed 4mb memory for real huge
    programs and lots of data needed right in memory, because of real time
    requirements.

    >>> Generally speaking there are few applications that took advantage of
    >>> extende memory. CP/M+ and MPM used it but user applications didn't.

    >>
    >>No CP/M 3 program can use it, because the memory management is
    >>transparent to the application and only the OS knows where GENCPM put
    >>the buffers, hash tables and so on. The ccp can be loaded from one bank
    >>to avoid disk access for a warm boot, or one can create a memory disk to
    >>be used by compilers as faster temp workspace. There is a lot one can do
    >>in the BIOS to speed up disk access significantly, but programs can't
    >>use it.

    >
    > I didn't say they could not use it I said there were very limited number
    > of applications that were written for that and utilized it. The larger
    > volume of programs are for the CP/M2.2 programming model.


    I would be interested to see such applications, I've never seen one before
    for CP/M 3 which utilizes this.

    > Also CP/M 2.2 did not prevent or disallow expanded memory.


    No, CP/M 2.2 and before wouldn't know about banked memory and if there is
    some, it could all be used by applications in some way. Not so easy to do
    with CP/M 3 because the OS itself uses banking frequently and in an
    application you won't know which banks are free to use, there is no OS
    support function to figure this. Of course you could gencpm to use lets
    say 3 segments and have the rest used by applications. But if someone
    gencpm with different segment configuration, your application is going to
    destroy OS data structures.

    ....
    >>MP/M supports ~400kb, CP/M 3 supports 1mb, so go for it I think.

    >
    > MPM supports as much as CP/M 3 which is at least 1MB I know of no reason
    > why larger is not possible.


    Sorry but I cannot agree with this. MP/M, as distributed, supports 8
    memory segments, one reserved for the OS, 7 for user banks. In the
    commonly used setup that are 7 banks with 48kb plus one full 64kb segment
    for the OS, alltogether 400kb. That's why the DRI MP/M documentation says
    400kb. I have looked already at the sources to expand this, requires some
    changes in the kernel and in the MP/M gensys program.
    If more memory is available that could be used as ram disk, but certainly
    not from applications, because MP/M doesn't know about and would
    completely screw up it's memory management. The OS is in control of the
    banking and the application is not supposed to switch to other banks.

    > Basically how you page or bank memory it is up to you as it will be
    > complatable with at least one of the many schemes out there all of which
    > were mostly incompatable with each other.


    There have been schemes that were almost/totally unusable for MP/M. And
    yes, it won't be compatible to anything, but that doesn't matter because
    the BIOS has to support the banking. Essential is a usable documentation
    for the banking hardware, so that BIOS's can be written.

    > As to how much, 512k is a start more if you care to. MY
    > suggestion is at least 512 and a meg is better. Reason, even on V2.2
    > the excess ram beyobd 64k can at a minimum
    > be a ramdisk and I've found for that application the more
    > is better and I have two systems with 1MB and one with 8MB as a baseline
    > of experience. The speed and spae of ram disk can make even slow 8080s
    > look impressive compared to a floppy.


    Absolutely.

    > Allison


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


  6. Re: Ram Card Design Help

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

    >>At later times MMU's with page tables were used, the whole memory
    >>is split into pages with 4k or 8k so that any memory configuration can be
    >>programmed. There was a TTL MMU from TI that would do this, 743xx
    >>something, I don't know anymore, sorry.


    > 74612 was one, it can also be done with a pair of 74ls189s or similar
    > 8 words by 8bits of ram or register.


    My choice might be one of the cache RAMs used in 486 systems.
    They might be cheap to buy if you can't rescue one off a
    used 486 system.

    -- glen


  7. Re: Ram Card Design Help

    > Softsector DD FDC, there were many so it was possible to upgrade
    > but the standard Altair was hardsector single density. the problem
    > is all the Altair disk software played with that one and only that
    > one. A board that emulated the two board altair controller and
    > had enough Flash to store the few programs that were unique
    > to that controller would be interesting to some. [or patch the
    > programs as needed to work with a generic style flash board.]
    > Softsector DD FDC, there were many so it was possible to upgrade
    > but the standard Altair was hardsector single density. the problem
    > is all the Altair disk software played with that one and only that
    > one. A board that emulated the two board altair controller and
    > had enough Flash to store the few programs that were unique
    > to that controller would be interesting to some. [or patch the
    > programs as needed to work with a generic style flash board.]


    That feature is the biggest push for the project. I will be emulating
    the Altair 8" hard sector controller on the card. Storage will be on
    USB mass storage devices, like a floppy disk, memory stick, hard
    drive, etc formatted with FAT or other file system. Actual Altair32
    compatible disk images will be used.

    For CP/M HD support I will probably make it compatible with the images
    from Altair Z80 (I think that's what its called)

    Other functions on the card include serial<->telnet bridge, VGA
    terminal emulation, etc...

    Grant


  8. Re: Ram Card Design Help

    Udo Munk wrote:
    >

    .... snip ...
    >
    > In the current version of my virtual Z80 system the size of the
    > common memory can be programmed in steps of 256byte pages, so one
    > can experiment with this.


    My hardware, which ran all the embedded systems at Yale-New-Haven
    Hospital from the early '70s to the late '80s, used roughly 8 x 8
    inch (about 20 x 20 cm) cards. With 16k bit memory chips, either
    ram or rom, just two cards allowed any mixture of RAM/ROM to be
    incorporated into a system. The buss received from memory chips on
    8 lines, buffered that on the CPU board, and echoed them out
    again. Thus there were no buffers on the memory boards. If a chip
    wasn't energized, it didn't energize the buss. The memory was 64k
    byte maximum, and was all static memory.

    These were later cards. Early cards used 4k chips, and 8k bit (2k
    byte) roms, and were nowhere near as convenient. The system used
    the 8080, not the Z80, because I never had time to redesign a Z80
    CPU card. The buss signals were compatible, since I had avoided
    using the somewhat peculiar 8080 signal set.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.




    --
    Posted via a free Usenet account from http://www.teranews.com


  9. Re: Ram Card Design Help

    On Mon, 22 Oct 2007 23:02:44 -0400, CBFalconer
    wrote:

    >Udo Munk wrote:
    >>

    >... snip ...
    >>
    >> In the current version of my virtual Z80 system the size of the
    >> common memory can be programmed in steps of 256byte pages, so one
    >> can experiment with this.

    >
    >My hardware, which ran all the embedded systems at Yale-New-Haven
    >Hospital from the early '70s to the late '80s, used roughly 8 x 8

    ^^^^
    no earlier than 1975.

    Allison

    >inch (about 20 x 20 cm) cards. With 16k bit memory chips, either
    >ram or rom, just two cards allowed any mixture of RAM/ROM to be
    >incorporated into a system. The buss received from memory chips on
    >8 lines, buffered that on the CPU board, and echoed them out
    >again. Thus there were no buffers on the memory boards. If a chip
    >wasn't energized, it didn't energize the buss. The memory was 64k
    >byte maximum, and was all static memory.
    >
    >These were later cards. Early cards used 4k chips, and 8k bit (2k
    >byte) roms, and were nowhere near as convenient. The system used
    >the 8080, not the Z80, because I never had time to redesign a Z80
    >CPU card. The buss signals were compatible, since I had avoided
    >using the somewhat peculiar 8080 signal set.
    >
    >--
    > Chuck F (cbfalconer at maineline dot net)
    > Available for consulting/temporary embedded and systems.
    >



  10. Re: Ram Card Design Help

    On Tue, 23 Oct 2007 10:52:27 +0000, no.spam wrote:

    > On Mon, 22 Oct 2007 23:02:44 -0400, CBFalconer
    > wrote:
    >
    >>Udo Munk wrote:
    >>>

    >>... snip ...
    >>>
    >>> In the current version of my virtual Z80 system the size of the
    >>> common memory can be programmed in steps of 256byte pages, so one
    >>> can experiment with this.

    >>
    >>My hardware, which ran all the embedded systems at Yale-New-Haven
    >>Hospital from the early '70s to the late '80s, used roughly 8 x 8

    > ^^^^
    > no earlier than 1975.
    >
    > Allison


    No? The 8008 and the MCS-8 development system were available 1972, you
    even could program in Fortran IV, PL/M was not done yet. I still have a
    single 8008 somewhere.

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


  11. Re: Ram Card Design Help

    On Tue, 23 Oct 2007 13:37:11 +0200, Udo Munk
    wrote:

    >On Tue, 23 Oct 2007 10:52:27 +0000, no.spam wrote:
    >
    >> On Mon, 22 Oct 2007 23:02:44 -0400, CBFalconer
    >> wrote:
    >>
    >>>Udo Munk wrote:
    >>>>
    >>>... snip ...
    >>>>
    >>>> In the current version of my virtual Z80 system the size of the
    >>>> common memory can be programmed in steps of 256byte pages, so one
    >>>> can experiment with this.
    >>>
    >>>My hardware, which ran all the embedded systems at Yale-New-Haven
    >>>Hospital from the early '70s to the late '80s, used roughly 8 x 8

    >> ^^^^
    >> no earlier than 1975.
    >>
    >> Allison

    >
    >No? The 8008 and the MCS-8 development system were available 1972, you
    >even could program in Fortran IV, PL/M was not done yet. I still have a
    >single 8008 somewhere.


    The way it's written it implied z80, there was nothing about 8008,
    Z80 was way later.

    However, even I did 8008 early on though at the time it was prefered
    to use assmbler as connect time (cross compiler was Fortran as was a
    simulator) was hard to get. I never saw a 8008 or MCS-8 actually run
    a PL/M or Fortran compiler maybe because 16k was maxram and
    most I'd seen had less than 1K. I still ahve the manual for the MCS-8
    I used back then and a few of the blue lines for the project. I
    still have an 8008 from back when also 1101s and early 2102s. None
    of this is new to me now, but it was in '72.


    Allison

    >
    >Udo Munk



  12. Re: Ram Card Design Help

    On Oct 21, 10:31 pm, Grant Stockly wrote:

    I think Allison wrote:
    > >standard Altair was hardsector single density. the problem
    > > is all the Altair disk software played with that one and only that
    > > one. A board that emulated the two board altair controller and
    > > had enough Flash to store the few programs that were unique
    > > to that controller would be interesting to some. [or patch the
    > > programs as needed to work with a generic style flash board.]

    >
    > That feature is the biggest push for the project. I will be emulating
    > the Altair 8" hard sector controller on the card. Storage will be on
    > USB mass storage devices, like a floppy disk, memory stick, hard
    > drive, etc formatted with FAT or other file system. Actual Altair32
    > compatible disk images will be used.
    >
    > For CP/M HD support I will probably make it compatible with the images
    > from Altair Z80 (I think that's what its called)
    >
    > Other functions on the card include serial<->telnet bridge, VGA
    > terminal emulation, etc...
    >
    > Grant


    Grant, your original request was something like: "I can put 128Kb, or
    even 512Kb, on this supercard. How should I bank-switch that extra
    memory?"

    the problem as I see it, is that bank switching in the S-100 world
    occurred before CP/M and programs made much use of it. And there were
    no standards, or there were a number of standards. I don't recall
    myself, which programs acutally USED banked memory. Ask around, check
    some old source code if you are ambitious.

    It was common in early S-100 boards to designate an I/O port - 40H if
    I recall without looking at the manuals - to select banks of RAM and
    swap them in upper memory somewhere. 8K and 4K banks come to mind.

    Later on, the scheme was to use RAM DISKS, with the RAM addressable
    through some I/O ports and readable either by I/O port or by a common
    segment of memory. Compupro had some MDRIVE boards like this.

    But READ THE MANUALS to see what various companies did. Enough S-100
    manuals are on line that you can find some memory board manuals and
    look them over. But also pay attention to Udo et al, who want to run
    MP/M and other OS's. You might ask Chuck Falconer and others who
    supported CP/M compatible OS's to see what banking they supported.

    But our colleagues suggest 4K sized pages, located whereever but
    generally above 32K and MAYBE up to the 64K limit. For simplicity, how
    about eight 4K segments between 8000H and F000H, each which can be
    selected from your remaining 64K or 450K in some fashion? Eight I/O
    bytes, each with one of eight bits set to select some 4K memory bank
    for its respective 4K memory window? (eight times 32K is 256K in that
    scheme, probably plenty!) If I'm write and you start with I/O address
    40H, you may be able to support some old programs!

    A simple management scheme would be the same I/O byte pattern for each
    4K segment of your "swap space". So you'd have eight total "pages"
    plus the zero page - anywhere in your upper 32K memory space, any size
    and location modulo 4K.. That's pretty flexible, uses 256K total. If
    you want to use a total of 512KB, then devote the other 256K to a RAM
    disk at some other I/O address set (for address bytes plus read/write
    byte).

    I have no idea what your hardware specifics are, some schemes will be
    easier than others.

    But, If I were you, I'd make it USER DEFINABLE. So, whatever you
    choose, the user can change it to suit them.

    Herbert R. Johnson, New Jersey USA
    http://www.retrotechnology.com/herbs_stuff/ web site
    http://www.retrotechnology.net/herbs_stuff/ domain mirror
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


  13. Re: Ram Card Design Help

    On Wed, 24 Oct 2007 02:17:06 +0000, no.spam wrote:

    > On Tue, 23 Oct 2007 13:37:11 +0200, Udo Munk
    > wrote:
    >
    >>On Tue, 23 Oct 2007 10:52:27 +0000, no.spam wrote:
    >>
    >>> On Mon, 22 Oct 2007 23:02:44 -0400, CBFalconer
    >>> wrote:
    >>>>My hardware, which ran all the embedded systems at Yale-New-Haven
    >>>>Hospital from the early '70s to the late '80s, used roughly 8 x 8
    >>> ^^^^
    >>> no earlier than 1975.
    >>>
    >>> Allison

    >>
    >>No? The 8008 and the MCS-8 development system were available 1972, you
    >>even could program in Fortran IV, PL/M was not done yet. I still have a
    >>single 8008 somewhere.

    >
    > The way it's written it implied z80, there was nothing about 8008,
    > Z80 was way later.


    Oh, I misunderstood it then, thanks.

    > However, even I did 8008 early on though at the time it was prefered
    > to use assmbler as connect time (cross compiler was Fortran as was a
    > simulator) was hard to get. I never saw a 8008 or MCS-8 actually run
    > a PL/M or Fortran compiler maybe because 16k was maxram and
    > most I'd seen had less than 1K. I still ahve the manual for the MCS-8
    > I used back then and a few of the blue lines for the project. I
    > still have an 8008 from back when also 1101s and early 2102s. None
    > of this is new to me now, but it was in '72.
    >
    > Allison


    Both, Fortran IV and PL/M were available as cross compilers only I think,
    I never saw a native compiler running on a MCS-8. So you needed a larger
    mini or mainframe with a Fortran compiler or access to GE timesharing
    network.

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


  14. Re: Ram Card Design Help

    no.spam@no.uce.bellatlantic.net wrote:
    > Udo Munk wrote:
    >> no.spam wrote:
    >>> CBFalconer wrote:
    >>>> Udo Munk wrote:
    >>>>
    >>>>... snip ...
    >>>>
    >>>>> In the current version of my virtual Z80 system the size of
    >>>>> the common memory can be programmed in steps of 256byte pages,
    >>>>> so one can experiment with this.
    >>>>
    >>>> My hardware, which ran all the embedded systems at Yale-New-Haven
    >>>> Hospital from the early '70s to the late '80s, used roughly 8 x 8
    >>> ^^^^
    >>> no earlier than 1975.

    >>
    >> No? The 8008 and the MCS-8 development system were available
    >> 1972, you even could program in Fortran IV, PL/M was not done
    >> yet. I still have a single 8008 somewhere.

    >
    > The way it's written it implied z80, there was nothing about 8008,
    > Z80 was way later.


    My message said nothing about 8080s, 8008s, or Z80s. It DID
    mention rough dates.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.




    --
    Posted via a free Usenet account from http://www.teranews.com


  15. Re: Ram Card Design Help

    On Wed, 24 Oct 2007 01:03:07 -0400, CBFalconer
    wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >> Udo Munk wrote:
    >>> no.spam wrote:
    >>>> CBFalconer wrote:
    >>>>> Udo Munk wrote:
    >>>>>
    >>>>>... snip ...
    >>>>>
    >>>>>> In the current version of my virtual Z80 system the size of
    >>>>>> the common memory can be programmed in steps of 256byte pages,
    >>>>>> so one can experiment with this.
    >>>>>
    >>>>> My hardware, which ran all the embedded systems at Yale-New-Haven
    >>>>> Hospital from the early '70s to the late '80s, used roughly 8 x 8
    >>>> ^^^^
    >>>> no earlier than 1975.
    >>>
    >>> No? The 8008 and the MCS-8 development system were available
    >>> 1972, you even could program in Fortran IV, PL/M was not done
    >>> yet. I still have a single 8008 somewhere.

    >>
    >> The way it's written it implied z80, there was nothing about 8008,
    >> Z80 was way later.

    >
    >My message said nothing about 8080s, 8008s, or Z80s. It DID
    >mention rough dates.
    >
    >--
    > Chuck F (cbfalconer at maineline dot net)
    > Available for consulting/temporary embedded and systems.
    >


    > These were later cards. Early cards used 4k chips, and 8k bit (2k
    > byte) roms, and were nowhere near as convenient. The system used
    > the 8080, not the Z80, because I never had time to redesign a Z80
    > CPU card. The buss signals were compatible, since I had avoided
    > using the somewhat peculiar 8080 signal set.


    They were mentioned.

    Early 70s to me is pre 8080 maybe even pre 8008. I did hardware then
    and in '72 the 1101 three voltage 256 bit device was a big deal and
    cost about an hours pay. By time the 2102 hit the street at $16 each
    in small volumes the 8008 was reality at $180 for the slow part.
    Still compared to around 100 to 200 peices of TTL it was better.

    Allison


  16. Re: Ram Card Design Help

    On Tue, 23 Oct 2007 20:18:44 -0700, Herb Johnson
    wrote:

    >On Oct 21, 10:31 pm, Grant Stockly wrote:
    >
    >I think Allison wrote:
    >> >standard Altair was hardsector single density. the problem
    >> > is all the Altair disk software played with that one and only that
    >> > one. A board that emulated the two board altair controller and
    >> > had enough Flash to store the few programs that were unique
    >> > to that controller would be interesting to some. [or patch the
    >> > programs as needed to work with a generic style flash board.]

    >>
    >> That feature is the biggest push for the project. I will be emulating
    >> the Altair 8" hard sector controller on the card. Storage will be on
    >> USB mass storage devices, like a floppy disk, memory stick, hard
    >> drive, etc formatted with FAT or other file system. Actual Altair32
    >> compatible disk images will be used.
    >>
    >> For CP/M HD support I will probably make it compatible with the images
    >> from Altair Z80 (I think that's what its called)
    >>
    >> Other functions on the card include serial<->telnet bridge, VGA
    >> terminal emulation, etc...
    >>
    >> Grant

    >
    >Grant, your original request was something like: "I can put 128Kb, or
    >even 512Kb, on this supercard. How should I bank-switch that extra
    >memory?"
    >
    >the problem as I see it, is that bank switching in the S-100 world
    >occurred before CP/M and programs made much use of it. And there were
    >no standards, or there were a number of standards. I don't recall
    >myself, which programs acutally USED banked memory. Ask around, check
    >some old source code if you are ambitious.


    Total lack of standards was the general problem.

    >It was common in early S-100 boards to designate an I/O port - 40H if
    >I recall without looking at the manuals - to select banks of RAM and
    >swap them in upper memory somewhere. 8K and 4K banks come to mind.


    Compupro mapped the ram as linear address and the CPU had a page
    mapping register that added the high bits.

    CCS was the one that ued 40H and any memory had a register at that
    address that mor or less determined if it was mapped and where.

    >Later on, the scheme was to use RAM DISKS, with the RAM addressable
    >through some I/O ports and readable either by I/O port or by a common
    >segment of memory. Compupro had some MDRIVE boards like this.


    I ahve an use a 512K Mdrive but that memory is IO mapped (only a few
    ports) and not accessable as "memory".

    >But READ THE MANUALS to see what various companies did. Enough S-100
    >manuals are on line that you can find some memory board manuals and
    >look them over. But also pay attention to Udo et al, who want to run
    >MP/M and other OS's. You might ask Chuck Falconer and others who
    >supported CP/M compatible OS's to see what banking they supported.


    Uzi Unix wasnted (needed!) banked memory and 4K pages would be about
    right.

    >But our colleagues suggest 4K sized pages, located whereever but
    >generally above 32K and MAYBE up to the 64K limit. For simplicity, how
    >about eight 4K segments between 8000H and F000H, each which can be
    >selected from your remaining 64K or 450K in some fashion? Eight I/O
    >bytes, each with one of eight bits set to select some 4K memory bank
    >for its respective 4K memory window? (eight times 32K is 256K in that
    >scheme, probably plenty!) If I'm write and you start with I/O address
    >40H, you may be able to support some old programs!


    I've done several system where The upper 32k was hard (always ram)
    and the lower 32k could be mapped as multiple paragraphs of 32K.
    It allows rom at 0 for boot, replace it with ram, page in different
    ram for Bios tables and buffers and page in additional 32K chunks
    as needed for user programs that would it in that space. Not ram
    efficient but when ram is cheap who cares.

    With 4K scatter/gather efficientcy is higher. Also applications can
    ask for thram they need and the manager can set that space
    aside and put the program there for it's time slice. The management
    cost is modest and hardware easy being basically a pair of 74189 or
    similar plus glue. This is closest to the mapper used in Z280 and
    also the PDP11.

    >A simple management scheme would be the same I/O byte pattern for each
    >4K segment of your "swap space". So you'd have eight total "pages"
    >plus the zero page - anywhere in your upper 32K memory space, any size
    >and location modulo 4K.. That's pretty flexible, uses 256K total. If
    >you want to use a total of 512KB, then devote the other 256K to a RAM
    >disk at some other I/O address set (for address bytes plus read/write
    >byte).


    This hits on the next step that CP/M (any) never achieved which is
    virtualization or memory and application space. To do this with CP/M
    you need a fine grained mapper of say 4K balancing code space and
    overhead and code to allocate, deallocate and keep a catalog of whos
    where. The implication is multitasking on either cooperative or
    preemptive basis and possibly both. Even simple cooperative
    with something like ESC-TAB to switch from task A to B to C and so on
    is a useful addition. The closest to this that most would know is
    Handyman in rom as on Kaypros. There are issues doing this
    under CP/M but are solvable.

    >
    >I have no idea what your hardware specifics are, some schemes will be
    >easier than others.
    >
    >But, If I were you, I'd make it USER DEFINABLE. So, whatever you
    >choose, the user can change it to suit them.


    To be user defineable install a FPGA and be prepared to tell everyone
    how to code it for brand A scheme or brand N . From a standpoint of
    supportability pick one and use that. No matter what you do there
    will be someone thats unhappy that you did it that way or that you did
    it all. ;-)

    Allison

    >Herbert R. Johnson, New Jersey USA
    >http://www.retrotechnology.com/herbs_stuff/ web site
    >http://www.retrotechnology.net/herbs_stuff/ domain mirror
    >my email address: hjohnson AAT retrotechnology DOTT com
    >if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    >"Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    >S-100 IMSAI Altair computers, docs, by "Dr. S-100"



  17. Re: Ram Card Design Help

    On Oct 26, 12:00 am, no.s...@no.uce.bellatlantic.net wrote:


    CCS was the one that used 40H and any memory had a register at that
    address that more or less determined if it was mapped and where.

    --
    As a matter of fact Cromemco also used 40H to switch banks, although
    aside from that I think they used a somewhat different system;
    effectively you wound up with almost the entire 64K in each bank (6
    max) with one additional bank shared by all and used by the system.

    Although they ran Z80 programs this was not CP/M; nevertheless another
    way of switching banks.

    A couple of years ago Randy had a good writeup of Cromemco's way of
    doing things; I probably have a copy somewhere if anyone's interested
    and can't find it elsewhere.

    mike


  18. Re: Ram Card Design Help

    no.spam@no.uce.bellatlantic.net wrote:
    >

    .... snip ...
    >
    > This hits on the next step that CP/M (any) never achieved which is
    > virtualization or memory and application space. To do this with
    > CP/M you need a fine grained mapper of say 4K balancing code space
    > and overhead and code to allocate, deallocate and keep a catalog of
    > whos where. The implication is multitasking on either cooperative
    > or preemptive basis and possibly both. Even simple cooperative
    > with something like ESC-TAB to switch from task A to B to C and so
    > on is a useful addition. The closest to this that most would know
    > is Handyman in rom as on Kaypros. There are issues doing this
    > under CP/M but are solvable.


    I supplied virtual code-space under CP/M. This was possible
    because the code-space was read-only, and didn't require hardware
    to virtualize. See the PascalP system.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.




    --
    Posted via a free Usenet account from http://www.teranews.com


  19. Re: Ram Card Design Help

    On Fri, 26 Oct 2007 03:00:22 +0000, no.spam wrote:

    > On Tue, 23 Oct 2007 20:18:44 -0700, Herb Johnson
    > wrote:
    >
    >>On Oct 21, 10:31 pm, Grant Stockly wrote:

    ....
    >>But READ THE MANUALS to see what various companies did. Enough S-100
    >>manuals are on line that you can find some memory board manuals and
    >>look them over. But also pay attention to Udo et al, who want to run
    >>MP/M and other OS's. You might ask Chuck Falconer and others who
    >>supported CP/M compatible OS's to see what banking they supported.

    >
    > Uzi Unix wasnted (needed!) banked memory and 4K pages would be about
    > right.


    When it comes to Unix and the like, just paged memory is not good enough,
    stuff is not that easy. You also need a MMU that is capable of generating
    page faults, whenever a JMP is made to a page not mapped and whenever a
    memory read/write is made to a page not mapped. Such a MMU must be coupled
    pretty close with the CPU, because it needs to know what address the CPU
    is going to use, and then trap that based on some tables. I don't
    know it anyone ever build such a MMU for the Z80, probably not worth the
    afford because of other CPU/MMU combinations available, that can do this.
    This is why DRI used another process model for MP/M, with a common
    segment for the OS entry, and one bank for every running process. They
    made a design failure with that 16kb common segment, don't know why. A 4kb
    common is enough for the OS entry, as CP/M 3 shows. Then you would have
    lots of 60kb banks to run processes and all that very efficient.
    Also the Z80 can't use virtual addresses, it's limited to a 16bit address
    space.

    > With 4K scatter/gather efficientcy is higher. Also applications can ask
    > for thram they need and the manager can set that space aside and put the
    > program there for it's time slice. The management cost is modest and
    > hardware easy being basically a pair of 74189 or similar plus glue. This
    > is closest to the mapper used in Z280 and also the PDP11.


    If you write in assembler and think a lot about segmenting your programs,
    that can be done, yes. On systems like Unix you just want to write real
    huge programs and don't be bothered with the memory management, kernel
    does it all for you. If you want to do page faults just with software, you
    need to inspect every JMP and every MOV, if it would address memory
    outside the current active page. Writing a C compiler that does this is
    quite a challenge, and it's a lot of overhead.

    I could build a descent MMU for a virtual Z80, because there I get at it
    innermost parts. No point in doing it tho, because probably no one will
    build it in silicon then. Could be done with PGA's of course, but why?
    There are much better CPU/MMU combinations readily available. Even the Z80
    got improved ages ago and has been replaced with better CPU/MMU.

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


  20. Re: Ram Card Design Help

    Hello Grant,

    Grant Stockly schrieb:

    >I am completing a final design for the SuperAltair card. I really
    >only need 56-60k to make Altair 8800 people happy, but stepping up to
    >128k is actually cheaper.


    You have Interest to Documents of S-100-BUS Maps.

    SALOTA-MFC-512-Systemen
    SALOTA Z80-CPU-Karte Z80A Microprocessor for S-100-BUS Maps.

    Only in German with Text and Pictures in File Format JPG.

    JPEG Image

    I can uploaden the Files and You can the Files then downloaden.

    The Files are very large.

    If I mean Maps find can into these times again in scanning with
    my Scanner Canon LIDE 500F.

    E-Mail is Reply-To: "rolf-news-harrmannATt-online.de"

    Rolf


+ Reply to Thread
Page 1 of 2 1 2 LastLast