[N8VEM-S100:7280] IEEE 696 compliance/non-compliance

[norwestrzh via N8VEM-S100]

I wire-wrapped a simple EPROM circuit on a N8VEM buffered prototype card. (Very nice card, BTW! Easy to work with.) It is just a single 27C256 EPROM that can be phantomed out by doing I/O to port "FF". I have a couple of Digital Research (Computers) 64k static RAM cards with a half phantom feature. Lower 32k can be phantomed out. The wire wrap circuit works very well with a CompuPro CPU-Z. On power up, or reset, the EPROM is in the memory map, and it goes away when I write to port "FF". It's a toggle, actually, so it can come back again with additional I/O to "FF".

Unfortunately, it doesn't work at all with *any* of my Cromemco ZPU's (revs. C, E, and F). Very disappointing. That is where I *really* wanted it to work. It also won't work with a couple of NorthStar CPU cards I tried, and a CCS 2810A CPU card. I'm not terribly surprised about the NorthStar or CCS. They are *very* old, and I doubt that they are 696 compliant. The Cromemco CPUs did surprise me. The CompuPro card was advertised as 696 compliant, but I'm not sure about any of the others.

It is a very simple circuit. Besides the address and DI buses, it only uses sMEMR, sOUT, sINP, reset*, and pDBIN. Oh, and of course, phantom*.

The only cards in the backplane (CompuPro 20-slot) are the wire-wrap EPROM card, the 64k static memory card, the CPU, and a N8VEM serial card (for console).

So, my question is: is there any particular place to look for 696 non-compliance problems, or is that a total bucket of worms? I wonder if there are any "tweaks" I can make to the Cromemco ZPUs to get them to work with the EPROM card? Anybody know what might be the problem here?

Roger

[John Monahan]

Impossible to tell from the description below Roger.

Post the schematic

John





From: n8vem-***@googlegroups.com [mailto:n8vem-***@googlegroups.com]
Sent: Saturday, June 20, 2015 8:03 PM
To: n8vem-***@googlegroups.com
Subject: [N8VEM-S100:7280] IEEE 696 compliance/non-compliance



I wire-wrapped a simple EPROM circuit on a N8VEM buffered prototype card. (Very nice card, BTW! Easy to work with.) It is just a single 27C256 EPROM that can be phantomed out by doing I/O to port "FF". I have a couple of Digital Research (Computers) 64k static RAM cards with a half phantom feature. Lower 32k can be phantomed out. The wire wrap circuit works very well with a CompuPro CPU-Z. On power up, or reset, the EPROM is in the memory map, and it goes away when I write to port "FF". It's a toggle, actually, so it can come back again with additional I/O to "FF".

Unfortunately, it doesn't work at all with *any* of my Cromemco ZPU's (revs. C, E, and F). Very disappointing. That is where I *really* wanted it to work. It also won't work with a couple of NorthStar CPU cards I tried, and a CCS 2810A CPU card. I'm not terribly surprised about the NorthStar or CCS. They are *very* old, and I doubt that they are 696 compliant. The Cromemco CPUs did surprise me. The CompuPro card was advertised as 696 compliant, but I'm not sure about any of the others.

It is a very simple circuit. Besides the address and DI buses, it only uses sMEMR, sOUT, sINP, reset*, and pDBIN. Oh, and of course, phantom*.

The only cards in the backplane (CompuPro 20-slot) are the wire-wrap EPROM card, the 64k static memory card, the CPU, and a N8VEM serial card (for console).

So, my question is: is there any particular place to look for 696 non-compliance problems, or is that a total bucket of worms? I wonder if there are any "tweaks" I can make to the Cromemco ZPUs to get them to work with the EPROM card? Anybody know what might be the problem here?

Roger

[norwestrzh via N8VEM-S100]

Post by John Monahan
Impossible to tell from the description below Roger.
Post the schematic
John

Not really a schematic, more like a diagram. The address selection on the LS688 wasn't actually implemented on the card. The LS688 was hard wired to recognize "FF". And, the LS244's (U3, U4, U5) were not used. Instead, the LS245's provided on the buffered prototype card were used. Also, the control signals shown on one LS244 (in the diagram) are actually spread out over a number of LS245's as provided on the buffered prototype card. I think there are a total of 5 LS245's used. Oh, and there is a bicolor LED attached to pins 5 and 6 of the LS74 so that I can check the state of the flip-flop visually. I doubt that has anything to do with the problem?

Roger

['Rick' via N8VEM-S100]

Roger,
Phantom is active low, and open collector. That's why it is *phantom. Could use a germanium diode in series with d-flipflop to s-100 bus pin. This is how people with cromemco floppy fdc cards shadow for the on board eprom/roms.

Rick Bromagem

Post by norwestrzh via N8VEM-S100

Post by John Monahan
Impossible to tell from the description below Roger.
Post the schematic
John

Not really a schematic, more like a diagram. The address selection on the LS688 wasn't actually implemented on the card. The LS688 was hard wired to recognize "FF". And, the LS244's (U3, U4, U5) were not used. Instead, the LS245's provided on the buffered prototype card were used. Also, the control signals shown on one LS244 (in the diagram) are actually spread out over a number of LS245's as provided on the buffered prototype card. I think there are a total of 5 LS245's used. Oh, and there is a bicolor LED attached to pins 5 and 6 of the LS74 so that I can check the state of the flip-flop visually. I doubt that has anything to do with the problem?
Roger
--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
For more options, visit https://groups.google.com/d/optout.

['Rick' via N8VEM-S100]

Roger,

I just noticed all eight high address bits are not included in your address decoding.
Is that what you wanted? Eprom will show up at just one byte address in each 256 bytes, all the way through addressed memory, right?

Rick

Post by norwestrzh via N8VEM-S100

Post by John Monahan
Impossible to tell from the description below Roger.
Post the schematic
John

Not really a schematic, more like a diagram. The address selection on the LS688 wasn't actually implemented on the card. The LS688 was hard wired to recognize "FF". And, the LS244's (U3, U4, U5) were not used. Instead, the LS245's provided on the buffered prototype card were used. Also, the control signals shown on one LS244 (in the diagram) are actually spread out over a number of LS245's as provided on the buffered prototype card. I think there are a total of 5 LS245's used. Oh, and there is a bicolor LED attached to pins 5 and 6 of the LS74 so that I can check the state of the flip-flop visually. I doubt that has anything to do with the problem?
Roger
--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
For more options, visit https://groups.google.com/d/optout.

['Rick' via N8VEM-S100]

Roger,

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).

CPU boards with no on-board memory do not need *Phantom. The ZPU board is
an example of this.

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.

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.

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.

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).

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.

Regards,
Rick

From: norwestrzh via N8VEM-S100
Sent: Saturday, June 20, 2015 8:02 PM
To: n8vem-***@googlegroups.com
Subject: [N8VEM-S100:7280] IEEE 696 compliance/non-compliance

I wire-wrapped a simple EPROM circuit on a N8VEM buffered prototype card. (Very nice card, BTW! Easy to work with.) It is just a single 27C256 EPROM that can be phantomed out by doing I/O to port "FF". I have a couple of Digital Research (Computers) 64k static RAM cards with a half phantom feature. Lower 32k can be phantomed out. The wire wrap circuit works very well with a CompuPro CPU-Z. On power up, or reset, the EPROM is in the memory map, and it goes away when I write to port "FF". It's a toggle, actually, so it can come back again with additional I/O to "FF".

Unfortunately, it doesn't work at all with *any* of my Cromemco ZPU's (revs. C, E, and F). Very disappointing. That is where I *really* wanted it to work. It also won't work with a couple of NorthStar CPU cards I tried, and a CCS 2810A CPU card. I'm not terribly surprised about the NorthStar or CCS. They are *very* old, and I doubt that they are 696 compliant. The Cromemco CPUs did surprise me. The CompuPro card was advertised as 696 compliant, but I'm not sure about any of the others.

It is a very simple circuit. Besides the address and DI buses, it only uses sMEMR, sOUT, sINP, reset*, and pDBIN. Oh, and of course, phantom*.

The only cards in the backplane (CompuPro 20-slot) are the wire-wrap EPROM card, the 64k static memory card, the CPU, and a N8VEM serial card (for console).

So, my question is: is there any particular place to look for 696 non-compliance problems, or is that a total bucket of worms? I wonder if there are any "tweaks" I can make to the Cromemco ZPUs to get them to work with the EPROM card? Anybody know what might be the problem here?

Roger

[norwestrzh via N8VEM-S100]

Hi Rick,

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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)

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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

[Bob Bell]

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,

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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)

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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.

Post by 'Rick' via N8VEM-S100
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

[norwestrzh via N8VEM-S100]

Thanks for the input, Bob.

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.

OK, I see what you're saying. Perhaps I need to re-wire this so that *Phantom is generated from A15 ORed with board select? I'll try that (with an O.C.) gate.

BUT again, I don't think *Phantom is the problem here. My 64k static RAM card has a "half phantom" option. By asserting phantom with that option enabled on the SRAM card, the lower 32k of SRAM is disabled. SO, with the CPU-Z (CompuPro) CPU card in place, when I power up the box, I can see the contents of the wire-wrap EPROM (27C32) at address 0-7FFF, the two 2716 EPROMs on the CPU card at 8000-87FF and 8800-8FFF (I hope I got that right!), and the SRAM card from 9000-FFFF. It all works perfectly. I can run a memory test on 9000-FFB0 (can't touch the monitor's stack area in high memory), and it passes. If I write anything to port "FF", the memory map is 0-7FFF is SRAM, 8000-8FFF is the EPROM on the CPU card, and 9000-FFFF is more SRAM. Memory tests on the two SRAM segments passes as well.

When I swap a ZPU card in (no other changes), the box is dead. The same monitor that runs from the two 2716s on the CompuPro CPU is in the 27C256 (relocated to ORG at 0h), and the ZPU is configured to power-on-jump to 0h. And, just to be sure, with the CompuPro CPU in the box, I can execute the monitor that resides at 0h in the 27C256, so I'm pretty sure that the monitor code in the 27C256 is OK.

Roger

[norwestrzh via N8VEM-S100]

I re-wired the circuit to comply with the suggestions about *Phantom, including an O.C. gate. The new configuration works (as expected) well with the CompuPro CPU card, but not at all with the Cromemco ZPU. There are a few more things to try w.r.t. the ZPU, but then I've got to move on to try to get V3 of the IDE card built and tested.

Strangely enough, by jiggling around the jumpers on the CCS 2810A CPU cards, I was able to get both of them working with the wire wrapped EPROM card!

Roger