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.

In article <0e87e5a9de89ad86083a730d02ecbc44@localhost.talkaboutcomputing.com> "craigl" <craigl@removethis.mindwrap.com> writes:[color=blue]
>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.
>[/color]
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

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:
[color=blue]
> 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.
>[/color]

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

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" <craigl@removethis.mindwrap.com> wrote in message
news:0f0e44a3499939a0b6a9fbbe3fa58aad@localhost.talkaboutcomputing.com...[color=blue]
> 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
>[/color]

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.

[url]http://www.retrotechnology.com/herbs_stuff/s100_pin20.html[/url]

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:


[url]http://www.retrotechnology.com/herbs_stuff/s100bus.html[/url]

Herb Johnson

Herbert R. Johnson, New Jersey USA
<a href="http://retrotechnology.com/herbs_stuff/"> web site</a>
<a href="http://retrotechnology.net/herbs_stuff/"> domain mirror</a>
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"