[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [N8VEM-S100:7286] IEEE 696 compliance/non-compliance



Hi Rick,
 
>> The *Phantom signal is only needed as an input on a RAM (or Eprom) card.
>> *Phantom is used to disable output to the S-100 data bus when another card says
>> it needs access to send data to the bus (asserts *Phantom low).

Right.  I didn't know that it had to be O.C.  Easy enough to add an O.C. gate to my wire wrap.

BUT, I don't think *Phantom is the problem here.  Maybe I'm not understanding, but pin 67
(in this case) is just an exchange between my wire wrap and the 64k SRAM board.  It works
flawlessly when the CompuPro CPU card is in the backplane.  I can "see" the wire wrap
EPROM, AND the on-board EPROM (two 2716s) on the CPU-Z card.  Only the wire wrap
EPROM goes away when I output to port "FF".  That's all as it should be.
 
>> CPU boards with no on-board memory do not need *Phantom. The ZPU board is
>> an example of this.

Yep.  I need to go back and look at the schematic again, but I *think* that pin 67 of the bus
doesn't even figure into the ZPU at all.
 
>> The CCS 2810 CPU has an Eprom socket on it, so it does input *Phantom.
>> There is a *Phantom Enable jumper on the CCS 2810 board.

Right, and I disabled *Phantom with that jumper before I tried the board out.
 
>> The CPU-Z board disables the S-100 Data In buffers when it’s Eprom is addressed, and
>> the Eprom is enabled. So it won’t have a conflict with off-board data when reading
>> it’s Eproms.

Yep, it works flawlessly (see above)
 
>> Don’t know about Northstar, some boards had an Eprom, many did not, and then did
>> not have the Eprom decoding/enable circuit installed on the board.

Yes, I know.  It was just a stab in the dark.  Both of my N* CPU cards have provision for
on-board "PROM" (from reading the silk screen), but it isn't installed on either card.  I
don't think I have a schematic for them.
 
>> The N8VEM buffered prototype card address decoder seems to have been designed
>> to decode 8-bit I/O port addresses, so only the low 8-bits of address were needed.
>> To use it for memory decoding, you probably need to cut the 8 low address traces to
>> the 74LS688 chip, and wire by hand the upper 8 address lines (in order: A8 thru A15).

I don't understand this.  I used the low order 8 bits from the BPB (buffered prototype board)
to set up the I/O port to enable/disable the EPROM.  That works fine (with the CompuPro
CPU)  AND, I used the same low order address bits plus the 8 high order address bits (on
the BPB) to address into the EPROM (well, A15 isn't needed there -- it's a 32k EPROM).
That works fine too (with the CompuPro CPU).  It won't work at all with the Cromemco ZPU,
and that's where I *really* wanted it to work so that I could get away from the need to use
their FDC (16FDC in this case).  I don't want to use floppies (too slow), and their serial
console port is severely limited IMO.

BTW, the 27C256 is a 55 ns. part, and all CPU's that I've tried are 4 MHz, so I assumed
(perhaps wrongly?) that no wait state manipulation was necessary.  I've used these EPROMs
on 10 MHz SBCs with no problems.
 
>> Then correctly hook up the *Phantom signal. Attached is part of a conversation I saved
>> that explains how to assert *Phantom from an Eprom *CE signal to the S-100 bus.

OK, I'll have a look at that, but as I said, I don't think *Phantom is the problem in this case.
I think it has something to do with non-compliant signal timings on the S-100 bus, and I
was wondering if anybody knew of a likely place to look.
 
Roger