RE: [N8VEM-S100:7288] IEEE 696 compliance/non-compliance

To add to what has already been said, I believe the /Phantom signal is not being generated properly. As it is, and even with the OC driver as recommended, the /Phantom signal is always asserted when the port FF flip-flop is in its reset state, that is, Q is low. Sure, this gates the EPROM /CE pin low when ANDed with A15 low. But then, and until the state of the F/F changes with another port FF write, RAM is not accessible. Maybe this is the way it’s designed to work, but the original intent of /Phantom was to overlay RAM with ROM. When the ROM is addressed, /Phantom is asserted which disables RAM at that address. When RAM is addressed outside the range of the ROM, it works normally. No I/O port needed. This circuit keeps /Phantom asserted and does not permit RAM to be active at addresses outside the range of the ROM. Thus, the ROM can be read, but no RAM is available. If the intent was to have ROM at 0000H, up through 7FFFH, and RAM from 8000H to FFFFH, then I believe the /Phantom signal should be taken from the output of the 74LS32 OR gate.

My 3 cents.

Bob Bell

From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com]
Sent: Sunday, June 21, 2015 2:38 PM
To: n8vem...@googlegroups.com
Subject: Re: [N8VEM-S100:7288] 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

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.