Cromemco 16FDC and IMSAI front panel

see below, plz. Dick ----- Original Message ----- From: "Doug Coward" <mranalog(a)home.comTo: <classiccmp(a)classiccmp.orgSent: Thursday, September 20, 2001 10:53 AM Subject: Re: Cromemco 16FDC and 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 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. 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. 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 > @ home in Poulsbo, WA > Analog Computer Online Museum and History Center > http://www.best.com/~dcoward/analog > =========================================