When we looked at this for the all-16-bit 65Org16, we realised there's no harm in doing 16-bit wide accesses to 8-bit peripherals - you just ignore the upper byte.

That usually works, but sometimes you'll have to be careful in the design. For example, on the 65c51, with normal addressing where register numbers are at consecutive addresses, if you write to the transmit register with a 16-bit write, you'll also write to the status register which causes a software reset.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Good point, but not so for the 65Org16 - writes and reads are word-wide. For the '816, indeed, it might be necessary to hook up such a peripheral only to even addresses, with a simple change of address decode. Does that work? I think it does...

Ah yes, you're refreshing my memory.


The I/O IC's register-select bits could be shifted up the address bus by one, and A0 would have to go into the chip-select logic so the IC is only selected if A0 is 0. This exposes another disadvantage to locking out a trait of the 816 though. If you want to read or write a 65c22 VIA's timer counter or latches, it's nice to be able to address both bytes at once, which the '816 can do, in a pair of consecutive clocks, all in one instruction.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You could make a 6522 derivative with 16 bit data, and access the entire register in one cycle.

Best not to boil any vegetable. When I prepare any fresh vegetable I bring the water to a rolling boil, add a pinch of salt, let it boil for another minute and then turn off the fire. As soon as the water has settled down I put in the vegetables and let them sit for no more than ten minutes. I drain the water and then dot the vegetables with some butter, and they're ready.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The fact that the '816 can do byte- or word-size accesses mirrors what other 16 and/or 32 bit MPUs can do. For example, the MC68000 MOVE instruction can handle a byte, a word or a double word. The MOVE opcode has a bit field (bits 12 and 13) that tells the MPU the data size to be handled. So the 68000 is doing in the instruction itself what the '816 would do with two instructions (REP or SEP followed by LDA or STA).

The ability to read or write byte-sized data is essential to achieving trouble-free I/O. For example, if I wish to output a character to POC's console I would do it by writing a byte to the DUART's channel A transmitter FIFO, which is at offset $03 in the device (absolute address $00D103). If I were to write a word to that offset I would also touch the register at offset $04, which happens to be the auxiliary control register (ACR). Among other things, the ACR is where the baud rate table is selected and the counter/timer is configured. You'd best believe that an errant write on the ACR could cause a major malfunction.

Kludges like excluding odd addresses to avoid writing the MSB are treating the symptom, not the problem, and merely add to the amount of decoding hardware needed to make the system work.


Plus it's an atomic read, so you are guaranteed to grab all 16 bits before an impending interrupt hits.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That seems to be a lot of work just to make up for a deficiency in the microprocessor.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Perhaps, but probably still easier than adding processor support for mixed-width data.

Yes, it doesn't seem too bad to me - some peripherals just work, some need spaced-out mapping, some will be fine but not optimal.