Macrotech MP-Z80 Dual Processor CPU - CP/M

This is a discussion on Macrotech MP-Z80 Dual Processor CPU - CP/M ; Anyone have this board in a working system? I have two of them and they both exhibit the same problem in a Compupro 8-16 system. I believe there is a timing issue of some kind with the System Support or ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Macrotech MP-Z80 Dual Processor CPU

  1. Macrotech MP-Z80 Dual Processor CPU

    Anyone have this board in a working system? I have two of them and
    they both exhibit the same problem in a Compupro 8-16 system. I
    believe there is a timing issue of some kind with the System Support
    or the Disk-3 boards. One of these CPU's actually worked fine at one
    time for a few days. Anyway, they both start the boot sequence fine as
    the Z80 and then when switching processeors to the 286 for CP/M-86
    the system hangs up. I tried the documented jumper settings etc,
    (thanks to the manual from Herb Johnson) but still the same problem.
    If someone has more info, or has had the same probelm, I would
    appreciate hearing from you.

    Thanks!

  2. Re: Macrotech MP-Z80 Dual Processor CPU

    On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
    wrote:

    >Anyone have this board in a working system? I have two of them and
    >they both exhibit the same problem in a Compupro 8-16 system. I
    >believe there is a timing issue of some kind with the System Support
    >or the Disk-3 boards. One of these CPU's actually worked fine at one
    >time for a few days. Anyway, they both start the boot sequence fine as
    >the Z80 and then when switching processeors to the 286 for CP/M-86
    >the system hangs up. I tried the documented jumper settings etc,
    >(thanks to the manual from Herb Johnson) but still the same problem.
    >If someone has more info, or has had the same probelm, I would
    >appreciate hearing from you.
    >
    >Thanks!


    If I were to make a wild guess the, since it worked for a while then
    stopped the thought is the one (or more) files required for x86
    version of CP/M have become corrupt or gone missing.

    The two most likely timing issues for most S100 cards is not enough
    wait states for the CPU speed and general conformity to IEE696.
    The frist is slow memory (or IO) and fast cpu related. The latter is
    usually things like Temp-master/DMA items. I susepct the latter is
    lest likely as the system did work for a while and also the DISK3 and
    Macrotech are both late enough to conform to IEE696/S100.

    FYI: the most common way to kill files in a CPM system is power down
    with the floppy is the drive or the hard disk heads not parked (most
    MFM drives didn't always autotpark safely).


    Allison


  3. Re: Macrotech MP-Z80 Dual Processor CPU

    On Mar 25, 4:34*pm, no.s...@no.uce.bellatlantic.net wrote:
    > On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
    >
    > wrote:
    > >Anyone have this board in a working system? I have two of them and
    > >they both exhibit the same problem in a Compupro 8-16 system. I
    > >believe there is a timing issue of some kind with the System Support
    > >or the Disk-3 boards. One of these CPU's actually worked fine at one
    > >time for a few days. Anyway, they both start the boot sequence fine as
    > >the Z80 *and then when switching processeors to the 286 for CP/M-86
    > >the system hangs up. I tried the documented jumper settings etc,
    > >(thanks to the manual from Herb Johnson) but still the same problem.
    > >If someone has more info, or has had the same probelm, I would
    > >appreciate hearing from you.

    >
    > >Thanks!

    >
    > If I were to make a wild guess the, since it worked for a while then
    > stopped the thought is the one (or more) files required for x86
    > version of CP/M have become corrupt or gone missing.
    >
    > The two most likely timing issues for most S100 cards is not enough
    > wait states for the CPU speed and general conformity to IEE696.
    > The frist is slow memory (or IO) and fast cpu related. *The latter is
    > usually things like Temp-master/DMA *items. *I susepct the *latter is
    > lest likely as the system did work for a while and also the DISK3 and
    > Macrotech are both late enough to conform to IEE696/S100.
    >
    > FYI: the most common way to kill files in a CPM system is power down
    > with the floppy is the drive or the hard disk heads not parked (most
    > MFM drives didn't always autotpark safely).
    >
    > Allison


    Thanks for the reply Allison. Actually the system works fine with just
    changing out the CPU with the Compupro 8085/8088 board as well as the
    Compupro 80286 board. Also I have floppy based system disks which also
    work fine, except with the Macrotech board. The Macrotech board does
    work fine as just a Z80 with the 8 bit boot configurations for CPM80.
    I tried playing with different wait states etc, and I do know that
    there were some inherent issues with timing concerning this board and
    the System Support I board. I was just hoping someone had a similar
    experience and place to start looking. Looks like if I get the time I
    will have to debug the hardware further here.

    Take care!

  4. Re: Macrotech MP-Z80 Dual Processor CPU

    On Tue, 25 Mar 2008 23:05:58 -0700 (PDT), Rich Camarda
    wrote:

    >On Mar 25, 4:34*pm, no.s...@no.uce.bellatlantic.net wrote:
    >> On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
    >>
    >> wrote:
    >> >Anyone have this board in a working system? I have two of them and
    >> >they both exhibit the same problem in a Compupro 8-16 system. I
    >> >believe there is a timing issue of some kind with the System Support
    >> >or the Disk-3 boards. One of these CPU's actually worked fine at one
    >> >time for a few days. Anyway, they both start the boot sequence fine as
    >> >the Z80 *and then when switching processeors to the 286 for CP/M-86
    >> >the system hangs up. I tried the documented jumper settings etc,
    >> >(thanks to the manual from Herb Johnson) but still the same problem.
    >> >If someone has more info, or has had the same probelm, I would
    >> >appreciate hearing from you.

    >>
    >> >Thanks!

    >>
    >> If I were to make a wild guess the, since it worked for a while then
    >> stopped the thought is the one (or more) files required for x86
    >> version of CP/M have become corrupt or gone missing.
    >>
    >> The two most likely timing issues for most S100 cards is not enough
    >> wait states for the CPU speed and general conformity to IEE696.
    >> The frist is slow memory (or IO) and fast cpu related. *The latter is
    >> usually things like Temp-master/DMA *items. *I susepct the *latter is
    >> lest likely as the system did work for a while and also the DISK3 and
    >> Macrotech are both late enough to conform to IEE696/S100.
    >>
    >> FYI: the most common way to kill files in a CPM system is power down
    >> with the floppy is the drive or the hard disk heads not parked (most
    >> MFM drives didn't always autotpark safely).
    >>
    >> Allison

    >
    >Thanks for the reply Allison. Actually the system works fine with just
    >changing out the CPU with the Compupro 8085/8088 board as well as the
    >Compupro 80286 board. Also I have floppy based system disks which also
    >work fine, except with the Macrotech board. The Macrotech board does
    >work fine as just a Z80 with the 8 bit boot configurations for CPM80.
    >I tried playing with different wait states etc, and I do know that
    >there were some inherent issues with timing concerning this board and
    >the System Support I board. I was just hoping someone had a similar
    >experience and place to start looking. Looks like if I get the time I
    >will have to debug the hardware further here.
    >
    >Take care!


    Being familiar with the system support board the likely timing issue
    is memory and/or IO speed (access times). I'd max out he wait states
    as 286 is faster than 8086/8088 and normally wants faster memory and
    IO devices. Also you have two places to set waits, CPU and also the
    individual boards, max out the cpu board first. There isnt much on
    the system support other than the interrupt controller (make sure the
    8259 is the faster A part) that should be unduely sensitive to system
    bus timing.

    Also use a bus terminator... some cards are more sensitive to bus
    ringing than others and despite improved backplanes the S100 bus is
    never been super clean.

    Allison

  5. Re: Macrotech MP-Z80 Dual Processor CPU

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

    > There isnt much on
    > the system support other than the interrupt controller (make sure the
    > 8259 is the faster A part) that should be unduely sensitive to system
    > bus timing.


    I always thought that the 8259A was completely different but
    backwards compatible. In 8080 mode it outputs the appropriate
    8080 instructions, and in 8086 mode the data needed by the 8086
    interrupt logic. The 8259 only does 8080 mode. In addition,
    the 8259A might need to be faster. That is, unlike just about
    every other Intel part where the letter indicates only speed.

    > Also use a bus terminator... some cards are more sensitive to bus
    > ringing than others and despite improved backplanes the S100 bus is
    > never been super clean.


    I used to hear stories about DEC specifying a maximum speed for
    bus drivers to reduce crosstalk. I never heard that in regard to
    S100 systems.

    -- glen


  6. Re: Macrotech MP-Z80 Dual Processor CPU

    On Wed, 26 Mar 2008 11:21:34 -0800, glen herrmannsfeldt
    wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >(snip)
    >
    >> There isnt much on
    >> the system support other than the interrupt controller (make sure the
    >> 8259 is the faster A part) that should be unduely sensitive to system
    >> bus timing.

    >
    >I always thought that the 8259A was completely different but
    >backwards compatible. In 8080 mode it outputs the appropriate
    >8080 instructions, and in 8086 mode the data needed by the 8086
    >interrupt logic. The 8259 only does 8080 mode. In addition,
    >the 8259A might need to be faster. That is, unlike just about
    >every other Intel part where the letter indicates only speed.


    No, they are functionally identical. the 59A however has a different
    timing spec such that it better fits the 8085A and the 8088/6 which
    have the multiplexed bus and a different system timing than 8080.

    The 59A is generally a faster part. The 59A came around when the 8085
    hit 5mhz and there needed to be a part for the (8mhz) 8088/86 as well.

    In intel numbering the suffix letter can indicate anything not always
    speed or functionality. Usually it indicates some difference from an
    earlier part. In the 8200 family of peripherals the "A" parts are
    characterized for 8085/8088/8086 use as they have different bus
    timings and are generally much faster than the old 8080. I ,ay add
    there are 82xxAH (Hmos faster parts) and A-2 parts (usually a screen
    or scaling step for faster operation) to match faster CPU speeds
    without IOwaits.

    >> Also use a bus terminator... some cards are more sensitive to bus
    >> ringing than others and despite improved backplanes the S100 bus is
    >> never been super clean.

    >
    >I used to hear stories about DEC specifying a maximum speed for
    >bus drivers to reduce crosstalk. I never heard that in regard to
    >S100 systems.


    S100 is a fairly sloppy bus and it was not designed well. It suffers
    from both crosstalk and ringing though many of the later backplanes
    were multilayer and that helped. As to spec for speed I think IEE696
    covers that well with the timing and overlap requirements.

    As to DEC those were terminated busses and the driver tended to be
    characterized for the bus speed and faster drivers tended to exhibit
    bothersome faster edges and also lower drive impedances which do
    not match the characteristic impedance of the bus. That mismatch
    tend to give rise to ringing and overshoot (both positive and
    negative). There are other reasons as well but it's a bus that falls
    outside this group.

    Allison

    >-- glen



+ Reply to Thread