8 to 16 bit buffer interface

While the CPU, memory and most of the subsystems are connected with 8 bit width, there are two subsystems which use a 16 bit bus. These are the ATA/IDE interface and the Ethernet interface (CS8900a). To access 16 bit with an 8 bit CPU, one has to break accesses. One 16 bit access works out as two consecutive 8 bit accesses. This works as follows.



To read an 16 bit word, the device is accessed with the first access. While it provides its data, the lower half (D0-D7) is read by the CPU while the upper half (D8-D15) is latched (U44). The second access just enables the output buffer of this latch.
To write an 16 bit word, the device is accessed with the second access. The data provided in the first access is latched (U45). With the next access, the latched data is provided as low byte (D0-D7), while the CPU data is provided as high byte (D8-D15).

As the MC68008 always accesses low byte first, word addressing modes with 16 bit are possible. In this way, the address line A0 can be used to determine the current state of an access. A0 is low for the first and high for the second access.

The key point is this: a single instruction causes the CPU to generate two consecutive 8 bit accesses (either 2 consecutive reads or 2 consecutive writes). These are seen by the I/O device as one 16 bit read or write.

Sounds like a job tailor-made for the 65C816.

This looks entirely workable to me. In fact, it's the same approach as what I posted in your other thread back in May! Perhaps you overlooked that post. In any case, feel free to mention any outstanding questions you may have about how the scheme works.

The key point is this: a single instruction causes the CPU to generate two consecutive 8 bit accesses (either 2 consecutive reads or 2 consecutive writes). These are seen by the I/O device as one 16 bit read or write.

-- Jeff

In your code you'll need to stick to simple loads and stores such as LDA BIT STA STY etc. Instructions like that always deal with the lowbyte first. But R-M-W instructions (INC DEC etc) are a no-no -- a minor limitation to keep in mind. The write portion of a R-M-W instruction will deal with the high byte first (according to WDC's '816 datasheet) and thus won't work as expected with this circuit.

[...] The count is set in two contiguous registers that are in big-endian order.

My plan was to load the (16 bit) accumulator with the 16-bit byte count, do an XBA to reverse endianess and then write the result to the CF94. The MSB would be written to the MSB register and on the next Ø2 cycle, the LSB would be written to the LSB register. Seems foolproof, eh?

It should be possible to rig up something to accept writes in either byte order, using just a few more gates.

tokafondo, as Chromatix says, the coding limitation can be eliminated with only a small increase in circuit complexity. On the other hand, the difficulties resulting from the coding limitation are also small. That's because...

(a): in regard to an I/O device, it's pretty unlikely you'll want to use an INC DEC ROL ROR ASL or LSR (these are the Read-Modify-Write instructions) in the first place. And,

(b): it's easy to simulate the effect of these instructions anyway. For example, ...
Code:
INC DeviceRegister ; a Read-Modify-Write instruction
can be replaced by
Code:
LDA DeviceRegister
INC A
STA DeviceRegister

When register sizes are set to 16 bits, memory access will access two contiguous bytes of memory, at the cost of one extra clock cycle. Furthermore, a read-modify-write instruction, such as ROR <addr>, when used while the accumulator is set to 16 bits, will affect two contiguous bytes of memory, not one. Similarly, all arithmetic and logical operations will be 16-bit operations.

I understand your goal is to build a system around the S1D13513 graphics chip, which is a very fancy device indeed! I'm sure it'll present you with some challenges but this Read-Modify-Write limitation is a minor matter.

To implement the 16-bit bus interface, do you plan to use discrete logic (eg, 74_574 etc) or will you use some sort of PLD? In the latter case a small increase in complexity (to beat the small limitation) may come for free.

-- Jeff