Cromemco 64FDC and Front Panel Operation - CP/M

This is a discussion on Cromemco 64FDC and Front Panel Operation - CP/M ; Spent a few hours getting a Cromemco 64FDC to work in an IMSAI system with a fornt panel. It had been several years since I did my last IMSAI with a 64FDC and had forgotten about how it disables the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Cromemco 64FDC and Front Panel Operation

  1. Cromemco 64FDC and Front Panel Operation

    Spent a few hours getting a Cromemco 64FDC to work in an IMSAI system with
    a fornt panel. It had been several years since I did my last IMSAI with a
    64FDC and had forgotten about how it disables the bus, thus preventing the
    front panel (and booting) from worrking. For future reference, here's the
    fix - the 64FDC was built post iEEE-696 and has two grounds atttached to
    pins 20 and 70. These pins were labelled UNPROT and PROT pre 696, causing
    conflicts. To fix, simply cut these ground traces on the 64FDC board next
    to the pads (other grounds exist so no big problem), and things work
    again. You may also need to cut the trace on bus pin 98 on the board -
    this is a signal from Cromemco ZPU and other processor boards signalling
    cards in the bus of 4Mhz operation. On the 64FDC, when pin 98 is high, it
    causes the insertion of a wait state into the on-board EPROM logic.

    Also be aware that there were two (or more perhaps) revisions of the 64FDC
    boards. I have what I think is original version plus a Rev B board. It is
    the Rev B schematic that is detailed in all of the 64FDC manuals in my
    possession and available online. There are significant differences
    between the revs, especially with respect to the logic that drives the
    pRDY line. In addition, IC 47 is a spare socket on the Rev B board where
    it was previously used to gate *WE and *RE signals from an on-board PAL to
    feed the pRDY logic. In addition, bus pin 98 is not present on the
    original board. The effect is that things seem to work the same, its just
    the logic to implement pRDY changed.

    FYI, I have this board working fine in DD/DS with an FD-505 combo drive
    (both 3.5 and 5.35 combined). Also drives a pair of 8 inch in DD/SS.

    Craig Landrum, CTO
    Mindwrap, Inc.


  2. Re: Cromemco 64FDC and Front Panel Operation

    In article <0e87e5a9de89ad86083a730d02ecbc44@localhost.talkabo utcomputing.com> "craigl" writes:
    >Spent a few hours getting a Cromemco 64FDC to work in an IMSAI system with
    >a fornt panel. It had been several years since I did my last IMSAI with a
    >64FDC and had forgotten about how it disables the bus, thus preventing the
    >front panel (and booting) from worrking. For future reference, here's the
    >fix - the 64FDC was built post iEEE-696 and has two grounds atttached to
    >pins 20 and 70. These pins were labelled UNPROT and PROT pre 696, causing
    >conflicts. To fix, simply cut these ground traces on the 64FDC board next
    >to the pads (other grounds exist so no big problem), and things work
    >again. You may also need to cut the trace on bus pin 98 on the board -
    >this is a signal from Cromemco ZPU and other processor boards signalling
    >cards in the bus of 4Mhz operation. On the 64FDC, when pin 98 is high, it
    >causes the insertion of a wait state into the on-board EPROM logic.
    >
    >Also be aware that there were two (or more perhaps) revisions of the 64FDC
    >boards. I have what I think is original version plus a Rev B board. It is
    >the Rev B schematic that is detailed in all of the 64FDC manuals in my
    >possession and available online. There are significant differences
    >between the revs, especially with respect to the logic that drives the
    >pRDY line. In addition, IC 47 is a spare socket on the Rev B board where
    >it was previously used to gate *WE and *RE signals from an on-board PAL to
    >feed the pRDY logic. In addition, bus pin 98 is not present on the
    >original board. The effect is that things seem to work the same, its just
    >the logic to implement pRDY changed.
    >
    >FYI, I have this board working fine in DD/DS with an FD-505 combo drive
    >(both 3.5 and 5.35 combined). Also drives a pair of 8 inch in DD/SS.
    >
    >Craig Landrum, CTO
    >Mindwrap, Inc.
    >

    The 16FDC also grounds 20 and 70. Interestingly, the manual
    does not show this. The 16FDC also uses 98 which is clearly
    shown. As to the function of 20 and 70, I would say it has
    more to do with the memory board(s) that you are using rather
    than the fact that they are in an IMSAI chassis. The front
    panel (CPA) can be modified to drive 20 and 70 from the
    repurposed power switch but I have never seen one so modified.
    Even with that modification in place, I don't think it would
    interfere with other FP operations if the memory didn't honor
    protect/unprotect.

    Bill



  3. Re: Cromemco 64FDC and Front Panel Operation

    I've wondered .... and asked here .... why the 16FDC would not work in
    an IMSAI with a front panel, so I thank you for your explanation.
    However, at the same time, I have to question it.

    Yes, pins 20 and 70 were nominally designated as memory protect and
    unprotect (could be used to effectively make a RAM memory board into a
    ROM board, temporarily).

    However, the number of memory boards that actually implemented this was
    quite small, and I've been unable to get the 16FDC to work with an IMSAI
    front panel when the memory boards in the system didn't implement the
    protect / unprotect feature. So I'm questioning if that's the entire
    explanation. However, I have not gone and looked at any schematics to
    see if there is any use of those pins.


    craigl wrote:

    > Spent a few hours getting a Cromemco 64FDC to work in an IMSAI system with
    > a fornt panel. It had been several years since I did my last IMSAI with a
    > 64FDC and had forgotten about how it disables the bus, thus preventing the
    > front panel (and booting) from worrking. For future reference, here's the
    > fix - the 64FDC was built post iEEE-696 and has two grounds atttached to
    > pins 20 and 70. These pins were labelled UNPROT and PROT pre 696, causing
    > conflicts. To fix, simply cut these ground traces on the 64FDC board next
    > to the pads (other grounds exist so no big problem), and things work
    > again. You may also need to cut the trace on bus pin 98 on the board -
    > this is a signal from Cromemco ZPU and other processor boards signalling
    > cards in the bus of 4Mhz operation. On the 64FDC, when pin 98 is high, it
    > causes the insertion of a wait state into the on-board EPROM logic.
    >
    > Also be aware that there were two (or more perhaps) revisions of the 64FDC
    > boards. I have what I think is original version plus a Rev B board. It is
    > the Rev B schematic that is detailed in all of the 64FDC manuals in my
    > possession and available online. There are significant differences
    > between the revs, especially with respect to the logic that drives the
    > pRDY line. In addition, IC 47 is a spare socket on the Rev B board where
    > it was previously used to gate *WE and *RE signals from an on-board PAL to
    > feed the pRDY logic. In addition, bus pin 98 is not present on the
    > original board. The effect is that things seem to work the same, its just
    > the logic to implement pRDY changed.
    >
    > FYI, I have this board working fine in DD/DS with an FD-505 combo drive
    > (both 3.5 and 5.35 combined). Also drives a pair of 8 inch in DD/SS.
    >
    > Craig Landrum, CTO
    > Mindwrap, Inc.
    >


  4. Re: Cromemco 64FDC and Front Panel Operation

    From Todd Fischer's authoritative doc on the IMSAI CPA changes, p3:

    "Modification to eliminate hardware memory protect (S-100 bus pin 20) from
    bus. Note that this bus pin becomes “GROUND” in the IEEE 696
    specifications:

    On COMPONENT SIDE, CUT trace leading from bus pin 20 to via. Note that
    this modification requires removing the switch bracket to gain access to
    the bus pin. As an alternative, it may possible to insulate bus pin 20
    with a piece of tape or similar insulating means "

    I gather from this that the IMSAI front panel WAS connected to pin 20 and
    I suspect that any other board that pulled this pin directly to ground
    might cause a problem, depending on what pin 20 was actually connected to
    on the CPA. In my case, it absolutely prevented me from, doing an
    EXAMINE, but I could still do a RESET.

    No mention was made in Todd's doc about pin 70, but I would still cut it
    on the 64FDC. Its far easier to mod the 64FDC than it is to yank the CPA
    in an IMSAI system :-) ....and there are other grounds on the 64FDC as
    backup.

    FYI, the system that used this board will be going on eBay this week with
    dual 8inch, a combo 3.5/5.25 in an IMSAI 2 minicabinet, Cromemco ZPU,
    TUART, and a Tanner/DRI 64K RAM card, console and printer cables, plus a
    bunch of software. Its almnost an exact duplicate of another IMSAI system
    I will be keeping.

    Craig


  5. Re: Cromemco 64FDC and Front Panel Operation

    Thanks for pointing this out, Craig. IMSAI originally (pre-IEEE-696 S-100
    Bus Specs c. late 1977) intended for pin 20 to disable the one-shots (when
    pulled LOW) for the EXAMINE and DEPOSIT functions provided on the Front
    Panel as a feature (optional modification of the RUN/STOP switch to provide
    hardware WRITE PROTECT/UNPROTECT for the early static memory boards such as
    the RAM 3 and RAM IIIA. Original early IMSAI kits included a small piece of
    film mask that could be placed over the RUN/STOP region of the photo mask to
    display PROTECT/UNPROTECT (of memory) after requiring the RUN/STOP switch.
    Cromemco, Godbout, Parasitic Engineering, and other Left Coast manufacturers
    who were instrumental in establishing the IEEE spec felt that the "Roberts
    Bus/Altair" needed more ground lines, so tried to establish redundant
    grounds in locations that were deemed obsolete. Thus, Joe Killian's simple
    solution to killing MEM WRITES via hardware met its ignoble end!

    I saw a small number of systems come through IMSAI Customer Service in the
    early years that actually had this modification, but I believe such efforts
    were motivated more by the "Bells and Whistles" allure than by practical
    need for such a feature. The original IMSAI 8080 User Reference manual
    includes a full-size copy of the optional mask, but the poor quality of
    reproduction renders it more "for the curious" than the practical.

    Best regards to all,

    -Thomas "Todd" Fischer

    "craigl" wrote in message
    news:0f0e44a3499939a0b6a9fbbe3fa58aad@localhost.ta lkaboutcomputing.com...
    > From Todd Fischer's authoritative doc on the IMSAI CPA changes, p3:
    >
    > "Modification to eliminate hardware memory protect (S-100 bus pin 20) from
    > bus. Note that this bus pin becomes "GROUND" in the IEEE 696
    > specifications:
    >
    > On COMPONENT SIDE, CUT trace leading from bus pin 20 to via. Note that
    > this modification requires removing the switch bracket to gain access to
    > the bus pin. As an alternative, it may possible to insulate bus pin 20
    > with a piece of tape or similar insulating means "
    >
    > I gather from this that the IMSAI front panel WAS connected to pin 20 and
    > I suspect that any other board that pulled this pin directly to ground
    > might cause a problem, depending on what pin 20 was actually connected to
    > on the CPA. In my case, it absolutely prevented me from, doing an
    > EXAMINE, but I could still do a RESET.
    >
    > No mention was made in Todd's doc about pin 70, but I would still cut it
    > on the 64FDC. Its far easier to mod the 64FDC than it is to yank the CPA
    > in an IMSAI system :-) ....and there are other grounds on the 64FDC as
    > backup.
    >
    > FYI, the system that used this board will be going on eBay this week with
    > dual 8inch, a combo 3.5/5.25 in an IMSAI 2 minicabinet, Cromemco ZPU,
    > TUART, and a Tanner/DRI 64K RAM card, console and printer cables, plus a
    > bunch of software. Its almnost an exact duplicate of another IMSAI system
    > I will be keeping.
    >
    > Craig
    >




  6. Re: Cromemco 64FDC and Front Panel Operation

    Todd, thanks for your post! It explains something that I never sorted
    out, over my years of using IMSAI 8080 (front panel) systems and why
    they had trouble with a grounded pin 20. Thanks, and I'd like to use
    your post on my Web site if you don't mind. Here's some more notes
    about pins 20 and 70, which will also be part of my Web page on the
    subject. Comments from anyone else would be appreciated.

    http://www.retrotechnology.com/herbs...100_pin20.html

    Herb Johnson

    On the Altair 8800b, pin 20 and 70 are output from the FRONT PANEL
    board, for memory protect (70) and memory unprotect (20). These signals
    were active high when the address bus had the address of a memory board
    which was to be write protected or unprotected. The address was set up
    on the front panel, manually; then the front panel switch "PROT/UNPROT"
    was manually toggled. These are NOT signals from the CPU card or the
    processor.

    On the corresponding MEMORY BOARD of the same memory address, PROT or
    UNPROT would set or reset a flip flop to disable or enable
    (respectively) future writes to memory on that board. How much memory
    was write-protected was up to the board's design. For a few board
    schematics I looked at today, there was one, or two, flip-flops.
    Addressing any memory location on that board when PROT or UNPROT was
    active would set or clear the flip-flop selected by that address.
    Typically the block was up to 4K bytes; typical boards of that time had
    anywhere from 1K bytes of memory to 16K bytes.

    Memory boards with write protect also provided a bus signal, /PS (pin
    69), which was active low when the board (or block on the board) was
    addressed and write-protected. The 8800b FRONT PANEL would display this
    as the PROT STATUS LED. Again, this is a front panel signal and not a
    signal to the CPU board or processor.

    Applications and history

    Write-protected memory fell out of favor on microcomputers, as front
    panels became out of favor and as write-protected memory became
    disused. Some later memory cards provided write-protect switches on the
    board. The user would reach inside the S-100 card cage and toggle the
    on-board DIP switch for that memory bank, in use of course. (Many
    people ran their systems without covers for convenience and cooling.)

    On subsequent S-100 cards and on IEEE-696 cards, many manufacturers
    wired pins 20 and 70 to ground; and pin 69 was unused. However, the
    IMSAI CP-A front panel schematic shows pin 20 as a line labled "T5".
    The text circuit description does not
    mention this signal. The schematic shows this signal as a line, pulled
    up with a resistor to +5 volts, which goes to several flip-flops used
    with front-panel controls. The CP-A does not support MEM PROT or MEM
    UNPROT or /PS.

    I did not understand this CP-A feature until Thomas "Todd" Fischer
    explained it. Thanks, Todd!

    The solution I used to bypass this grounded pin 20 is dirt-simple,
    assisted by the fact that pin 70 (grounded on the CP-A) is immediately
    on the other side of the connector from pin 20. I simply put a very
    small piece of paper over BOTH pin 20 and 70 on the board, looping it
    over the edge of the edge connector; and I insert it carefully into its
    bus connector. Sometimes I'll put a bit of transparent tape over the
    paper JUST large enough to make contact on either side of the pin; but
    not so large as to cover the adjacent pins. The paper is not pulled off
    during insertion and it's held by the connector in place.

    References: schematics from manuals for IMSAI, Altair/MITS, Morrow
    products. Read the manuals! Also I have some S-100 bus signal lists at:


    http://www.retrotechnology.com/herbs_stuff/s100bus.html

    Herb Johnson

    Herbert R. Johnson, New Jersey USA
    web site
    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"


+ Reply to Thread