[OT] Tri-state line drivers

[Rink]

Apologies for this being a little off topic - although it'd be easy enough to bring the discussion into the ZX realm. I really wanted to ask this on SinclairZXWorld because of the large number of super-smart people here.

I need to replicate the functionality of an expansion board for the Sharp X1 (also Zilog Z80 based). Unfortunately, I don't have too much info to go on about the board or its circuitry - but I know a few things. Basically, it's a line driver board to take the CPU signals and drive them through a long cable into an expansion box.

The lines which are inputs to the box (CPU -> Expansion) are easy enough to work out - they're buffered with SN74LS541 line drivers. Where I'm having difficulty, is understanding the inputs (Expansion -> CPU - NMI, EXWAIT, EXINT, EXIO, IEI) and the data bus.

The data lines (D0-D7) don't actually seem to be buffered at all! But I want them to be.

The others seem to be running through a SN74LS367 bus driver. But I can't work out how the card knows when to enable the *G pin on the 367 and when to tri-state. Or can these chips be configured to tri-state when not at logic 0?

Any pointers in the right direction would be much appreciated. I've not actually had to work with line driving circuitry before.

Many thanks.

[PokeMon]

The others seem to be running through a SN74LS367 bus driver. But I can't work out how the card knows when to enable the *G pin on the 367 and when to tri-state. Or can these chips be configured to tri-state when not at logic 0?

No these simple drivers can either drive or go in tristate mode. This is done with the enable /G only. If no other item is connected, this signal can be simply tied to GND to enable the drivers all-time. As there are no schematics to the SHARP calculator it is difficult to say. But you can maybe follow the /G inputs of the driver if connected to GND or somewhere else.

[Rink]

Argh, my head hurts. Unfortunately, the board i'm copying is super-rare. Can't even source one from Japan at the minute.

The expansion box lets you connect multiple I/O cards which have daisy-chained interrupt signals but everything else is just passed through to all cards. And that's the problem. If the CPU is writing, then obviously the direction is Base->Box. But if the CPU is reading and an internal device answers, then the direction is still Base->Box. I can't see how the interface card could know if a card in the box is asserting values on the data lines. Especially not with the few components that I know are on the original board. The schematic for the expansion box also shows that it is not buffering the data lines.

So... Either there's something clever that can be done, or the data lines aren't to be buffered. Which begs the question, if the cable length isn't so much of an issue as to affect D0-D7, then why buffer the others? Unless Sharp didn't want to try and sell an adapter board (for many, many yen) that only had a few PCB traces on.

[1024MAK]

Adding a bi-directional buffer/driver for the data bus is a bit more involved. The buffer will normally be in CPU to ext bus mode.
To enable devices on the ext. side to supply data to the CPU, the direction input must be gated by both the CPU /RD signal and the output of an address decoder. The address decoder will generate an active signal only when the CPU addresses the address space of the available ext. devices. If these also put data on the data bus during an interrupt, this must be taken in to account as well.

Mark

[Rink]

To enable devices on the ext. side to supply data to the CPU, the direction input must be gated by both the CPU /RD signal and the output of an address decoder. The address decoder will generate an active signal only when the CPU addresses the address space of the available ext. devices.

Thanks Mark, this was more or less my understanding of things as well. Reminds me of the old fun I used to have with ISA devices.

The expansion cards for the X1 are expected to obey Sharp's rules as to which addresses they can use. The English documentation I have, the bits I've translated, and the things I've figured out myself, all suggest that to be true. But there's no way for an expansion card to report back up the chain that it has decoded the address and is now going to drive the data lines. (Apart from the interrupt-based cards of course). So I can't understand how a line driver can sit in the middle and boost the signals, since the expansion card couldn't report its direction.

Either that, or the original man-in-the-middle board assumes that if the CPU is reading from a different device, then no expansion card is going to need to receive that data. If that was the case then maybe I could drive the lines correctly. Edit: actually... Not sure that would solve the problem at all. Better get the coffee on and have a think.

[PokeMon]

Why do you don't build up your own box ?
Bidirectional drivers are only an issue for the databus which doesn't have any as you said.

[RWAP]

Not sure whether this will help, but the Sinclair QL uses a form of double writing (I believe) in order to be able to provide bi-directional data on the normally read-only ROM port.

This enabled a hard disk, and a Flash EPROM card to be connected to the ROM port.

[Rink]

Why do you don't build up your own box ?

...

You know... That's actually a pretty sensible suggestion. It's not like I really have to worry about compatibility with existing X1 expansion cards - they're so damn rare (read: impossible to find outside of Japan and even then it's tough) that i'm basically going to be recreating all of them anyway. Cheers mate; good thinking.

@Rich - that sounds like a pretty interesting setup. I'll check it out, thanks. I don't know much about the QLs other than that they look swet, and have inside one of the coolest processor ever dreamt up.

[1024MAK]

To enable devices on the ext. side to supply data to the CPU, the direction input must be gated by both the CPU /RD signal and the output of an address decoder. The address decoder will generate an active signal only when the CPU addresses the address space of the available ext. devices.

Thanks Mark, this was more or less my understanding of things as well. Reminds me of the old fun I used to have with ISA devices.

The expansion cards for the X1 are expected to obey Sharp's rules as to which addresses they can use. The English documentation I have, the bits I've translated, and the things I've figured out myself, all suggest that to be true. But there's no way for an expansion card to report back up the chain that it has decoded the address and is now going to drive the data lines. (Apart from the interrupt-based cards of course). So I can't understand how a line driver can sit in the middle and boost the signals, since the expansion card couldn't report its direction.

Either that, or the original man-in-the-middle board assumes that if the CPU is reading from a different device, then no expansion card is going to need to receive that data. If that was the case then maybe I could drive the lines correctly. Edit: actually... Not sure that would solve the problem at all. Better get the coffee on and have a think.

First, a buffer/driver on the data bus may not be needed.
Second, the address decoder for the data bus buffer I referred to in my earlier post typically would decode a fixed address range.
So for example, in my fictional computer, I/O ports 0 to 63 are used internally by the system and I/O ports 128 to 255 are allocated to the expansion system. So the address decoder for the data bus buffer will have an active output whenever the CPU addresses a port in the range 128 to 255. It would be desirable for the data bus on the expansion side to have pull-up resisters, so that if there was no card fitted for some of the address range, the data bus would float to a defined high state.

The only other practical system is for each I/O card to communicate to the logic controlling the data bus buffer via a wired OR line. But this only works if the existing expansion cards were designed with this in mind.

Mark

[RWAP]

@Rich - that sounds like a pretty interesting setup. I'll check it out, thanks. I don't know much about the QLs other than that they look swet, and have inside one of the coolest processor ever dreamt up.

I have just found some information as to how the write to the ROM port was achieved.

Basically, the driver uses 256 memory mapped ports: from $FE00 to $FEFF. When it needs to write byte XX to the interface, it makes a read to the port $FEXX
and discards the result.

The interface uses a decoder that catches the address range and latches the low eight bits of the address bus.

- The latched byte becomes the byte to be written to the device.