see below, plz.
Dick
----- Original Message -----
From: "Doug Coward" <mranalog_at_home.com>
To: <classiccmp_at_classiccmp.org>
Sent: Thursday, September 20, 2001 10:53 AM
Subject: Re: Cromemco 16FDC and IMSAI front panel
>
> "Bill Sudbrink" <bills_at_adrenaline.com> said:
> > I brought this up some time ago, but never
> > got a satisfactory answer...
> >
> > When I use the above combination (regardless
> > of CPU board), while the system in general
> > works fine, the deposit/examine functionality
> > of the front panel stops working. Somebody
> > said they knew of a fix, but then never posted
> > anything else. I've looked at the schematics
> > (I have them for both items) and can't for the
> > life of me see anything that would conflict.
>
> > Any help greatly appreciated.
>
> Here is some of the IMSAI front panel gottas:
>
> MWRITE pin 68 - This signal needs to be generated
> by one source and one source only. It is generated
> by the IMSAI front panel (by a deposit) so make
> sure this signal is disabled on the CPU board when
> used with the IMSAI front panel.
>
isn't this an obsolete signal, derived on later boards by /(/sWO + sOUT)? I
don't have the doc's in front of me but it seems that this signal was dropped
from use in the standard. It seems to me that you have two choices: (1) make
everything adhere to the '696 standard, or (2) figure out exactly how it's all
supposed to work, and then resolve the incompatibilities. Most people prefer
(2) but (1)'s easier, because there's a published standard.
>
> PROT & UNPROT pins 20 & 70 - The IEEE 696 standard
> says that these pins will be at ground. Some
> motherboards ground these lines. But grounding
> these pins on the IMSAI front panel will disable
> the front panel. To fix this, cut the traces,
> on the front panel, right at edge connector
> pin 20 and 70.
>
I'm not so sure this signal is relevant at all. The IEEE 696 standard is
completely adhered to on absolutely no hardware I've ever seen. Check the
schematic to see whether this signal is even relevant to the memory boards in
your system. Odds are, unless the things were built after 1985, they don't
adhere to the standard at all.
>
> Data Out Bus - When the IMSAI front panel does
> a deposit operation, it expects the the data
> on the Data In Bus to be reflected on the
> Data Out Bus. Some later CPU boards disabled
> the Data Out Bus to cut down on bus noise
> especially above 2MHz.
>
The data Out bus is where you'd expect any data WRITTEN (during sOUT or sMEMW
cycles) by whoever is the bus master to appear. The data IN bus, following
similar logic, is where you'd expect data from outside the bus master to be
presented when it's doing an input (sINP or sMEMR) cycle.
>
The old 8080 boards mirrored the lower 8 addresses onto the upper 8 on the bus,
but that's not what this is about.
There is no need for data IN to appear on data OUT. IIRC, Data OUT should be
the
inputs to the I/O and Memory boards, and the outputs from a potential bus
master. Boards which function as a bus master or slave, e.g. disk controllers,
etc, with DMA capability, have to steer the data appropriately to reflect their
roles. They're slaves when being programmed by another master, but are the
master when they transfer data. Likewise, the FP has to be able to put the data
toggled into the switch register onto the DOUT[7..0] lines when doing a deposit,
and should reflect the content of DIN[7..0] when doing an examine. They're
separate busses and, for the benefit of poorly designed and underbuffered memory
and I/O boards that have devices with common I/O on board, should not be driven
at the same time.
Of course, it's possible to make some circuits work when both data busses are
driven, but I'd review the schematic before allowing both to be driven. Keep in
mind, BTW, that at the time the IMSAI FP was designed, memories with common I/O
were pretty uncommon. If both busses were driven, it was conceivably
permissible to drive both the DIN and DOUT busses on boards that (a) didn't
enable the receivers on the DIN bus during write cycles, (b) didn't assert the
nWE to the memory devices until the DIN bus was stabile, and (c) didn't enable
the output buffers from the memories during a write cycle. Violating any of
these conditions would probably cause problems, depending on the frontpanel
timing and the memory board's bus interface logic.
BTW, according to the '696 standard, there should be a set of status signals
(names in the standard start with lower case 's') which stabilize before a
falling edge of pSTVAL (phase1), during a true pSYNC. To avoid most risks, the
DBIN receivers should be enabled during the entire phase whenever pDBIN is true,
while /pWR should be used to enable the DBOUT drivers. Not being familiar with
the IMSAI front panel, I can't say what effects this sort of signalling protocol
will have on it. Those early devices, IMSAI, Altair, among others, didn't all
work right with the signalling as specified in IEEE 696 are followed. Some
older boards completely ignore the pWR* signal (AKA /pWR) and rely on sMEMW or
sOUT to control the bus and also the device write enable. This can cause
problems with other devices, particularly devices of later vintage, because they
allow for data to propagate to target devices with write enabled before the data
is valid. At a minimum, the nWE signal to SRAMs should not be activated before
data is valid. While many memory devices tolerate this condition, some don't.
Dick
=================================================
> Regards,
> --Doug
> =========================================
> Doug Coward
> _at_ home in Poulsbo, WA
>
> Analog Computer Online Museum and History Center
> http://www.best.com/~dcoward/analog
> =========================================
>
>
Received on Fri Sep 21 2001 - 08:44:12 BST