RX11 emulator update - VMS

This is a discussion on RX11 emulator update - VMS ; Project update: Brief recap of what I'm doing: I'm building a Unibus card that behaves like an RX11, but uses a PC to do the actual storage, via a cable to the parallel port. It is based heavily on the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: RX11 emulator update

  1. RX11 emulator update

    Project update:

    Brief recap of what I'm doing:
    I'm building a Unibus card that behaves like an RX11, but uses a PC to
    do the actual storage, via a cable to the parallel port. It is based
    heavily on the RXV11 emulator I made last year. The HW will consist of a
    dual-height custom card (I'm wiring the prototype now), plus an M105
    address selector and an M7821 interrupt control. These 3 cards form an
    SPC on the Unibus. The custom card has a ribbon cable that goes to the
    PC's parallel port. A C++ program on the PC performs the protocol and
    storage functions. A bit of the protocol is done in HW on the custom
    card.

    Status:
    My 'development system', a PDP-11/05, is up and running, with an
    external DD11 backplane out in the open for easy access.
    Working on the custom card prototype. The design/schematic is done, and
    I'm wire-wrapping it. It consists of about 13 or 14 chips -- 3 are
    8641's, the rest are LSTTL and one 555 timer. Note that a 4th 8641 is
    not needed (I think) because the RX11 only uses 10 of the 16 bits. My
    assumption is that allowing the unused bits to 'float' will be OK. If
    need be, I've left space for the 4th 8641.

    I think I have an elegant solution to a problem in the RXV11 emulator.
    The problem was:
    PC parallel ports run relatively fast. In the PC code for the RXV11, I
    had to put 'delay loops' in certain places, so that I could reliably
    talk to the HW over the cable, etc. But the delay loops are not based on
    actual time intervals, because C++ doesn't offer anything less than 1
    ms, which is way too long. So, I had used a for-loop which provided the
    right delay. BUT, the problem was that the delay is related to the speed
    of the CPU, and is also affected by other threads running in the same
    program.
    Solution:
    In the RX11 emulator HW, I've added a 555 timer which will provide a
    fixed clock signal, which will appear on one of the input pins on the
    parallel port. So, the PC code can use this clock to determine minimum
    delay times in the code. It will be independent of CPU speed, etc.

    Pete

    ----------
    To unsubscribe (or subscribe) from (to) this list, send a message to
    info-pdp11-request@village.org, with the first line of the message
    body being "unsubscribe" or "subscribe", respectively (without the quotes).

  2. Re: RX11 emulator update

    Thanks for the update, Peter.
    I guess I start looking for the DZ11 boards I recovered from a dumpster
    to see if the board has 8641's on it !

    cheers,
    - Henk, PA8PDP.


    "McCollum, Peter" wrote:

    > Project update:
    >
    > Brief recap of what I'm doing:
    > I'm building a Unibus card that behaves like an RX11, but uses a PC to
    > do the actual storage, via a cable to the parallel port. It is based
    > heavily on the RXV11 emulator I made last year. The HW will consist of a
    > dual-height custom card (I'm wiring the prototype now), plus an M105
    > address selector and an M7821 interrupt control. These 3 cards form an
    > SPC on the Unibus. The custom card has a ribbon cable that goes to the
    > PC's parallel port. A C++ program on the PC performs the protocol and
    > storage functions. A bit of the protocol is done in HW on the custom
    > card.
    >
    > Status:
    > My 'development system', a PDP-11/05, is up and running, with an
    > external DD11 backplane out in the open for easy access.
    > Working on the custom card prototype. The design/schematic is done, and
    > I'm wire-wrapping it. It consists of about 13 or 14 chips -- 3 are
    > 8641's, the rest are LSTTL and one 555 timer. Note that a 4th 8641 is
    > not needed (I think) because the RX11 only uses 10 of the 16 bits. My
    > assumption is that allowing the unused bits to 'float' will be OK. If
    > need be, I've left space for the 4th 8641.
    >
    > I think I have an elegant solution to a problem in the RXV11 emulator.
    > The problem was:
    > PC parallel ports run relatively fast. In the PC code for the RXV11, I
    > had to put 'delay loops' in certain places, so that I could reliably
    > talk to the HW over the cable, etc. But the delay loops are not based on
    > actual time intervals, because C++ doesn't offer anything less than 1
    > ms, which is way too long. So, I had used a for-loop which provided the
    > right delay. BUT, the problem was that the delay is related to the speed
    > of the CPU, and is also affected by other threads running in the same
    > program.
    > Solution:
    > In the RX11 emulator HW, I've added a 555 timer which will provide a
    > fixed clock signal, which will appear on one of the input pins on the
    > parallel port. So, the PC code can use this clock to determine minimum
    > delay times in the code. It will be independent of CPU speed, etc.
    >
    > Pete
    >
    > ----------
    > To unsubscribe (or subscribe) from (to) this list, send a message to
    > info-pdp11-request@village.org, with the first line of the message
    > body being "unsubscribe" or "subscribe", respectively (without the quotes).



+ Reply to Thread