MSX3: I/O
=========
Status: unfinished
The I/O is a bit tricky. This is what I understood from the Z380 specs, but
I'll need verification. The problem is not that the MSX I/O can't be used.
The problem is if the extended I/O range can be used. As far as I get it
now, if you output for example a value to #00123499, the VDP will recognize
it as an I/O to port #99.
Note: for the ones who didn't know what a Decoder Directive (DDIR) is, it
extends the address range of instructions.
There are 4 G of I/O adresses. I'll devide the I/O into four bytes, called
B0...B3, where B3 is the MSB.
I/O type 1:
IN A,(n) - OUT (n),a --- Normal Z80 direct I/O
B0 equals the I/O port n, B1 equals A. B2B3 are 0.
I/O type 2:
INA rr,(nn) - OUTA rr,(nn) --- 16-bit direct I/O
B0B1 equal nn, and B2B3 are 0.
These I/O instructions can be enhanced to 32-bits using Decoder Directives
(DDIR's).
I/O type 3:
IN A,(C) - OUT (C),A - all Block I/O (OTIR etc.) --- indirect I/O
B0B1B2B3 equal the 32-bit BC (BCz)
Now I have a few questions:
- On the Z80, does the 8-bit direct I/O (type 1) work the same way???
(putting the data also on the address bus?)
It is strange, because when using the 8-bit I/O instructions while having a
32-bit I/O range causes it to quite randomly write to alot of addresses in
the 0-FFFF range. For example, when you write #89 to port #99, then the
value #89 will be written to I/O port #8999... Does that mean that if you
use a 32-bit I/O range, you can't use the 8-bit I/O instructions??? Damn,
why didn't they implement this better.
The extended I/O range would be very useful in case of for example the
extended memory mapper (like described before). However, now it seems
another solution has to be found, a more complex controller, or just a
linear address range.
I see only one option to extend the I/O address range. B1 shouldn't be
connected, because its value is quite random (equals B with OUT (C),A and
equals A with OUT (n),A). By default, BCz equals zero. So, in all cases
(with legacy programs), B2 and B3 are set to 0. Therefor, it would be
possible to use #0000xx00-#FFFFxxFF, as long as the LSB (B0, the part after
xx) is not the value of an already existing 8-bit register.
---
I propose to define, say, 16 registers as 'extended I/O' registers. When I
look at my data, it seems the I/O ports 50-5F are still unused. Great. Then
this is how the 32-bits OUT-port is constructed:
#YYYYxxZZ
YYYY is the so-called "device ID". If a certain device uses the value 1234,
then it ignores all I/O except the ones of which the YYYY part of the
address equals 1234. Device ID 0000 may not be used.
xx is an undefined value. It can be anything.
ZZ is a value between #50 and #5F. These are the device YYYY its available
I/O ports. If it doesn't fit in 16 ports, it should use an additional Device
ID. The device only needs to read bits 0-3 of ZZ. The upper 4 bits are -for
the device- of no importance. However, the program MUST write within the I/O
range of #50-#5F. Other addresses will still address the same I/O device,
but will highly likely also affect another 8-bits device. For example when
you write to #1234xx99, I/O port nr. 9 of device 1234 is accessed. However,
at the same time also the VDP's I/O port is affected. It is also not very
wise to choose another address outside of 50-5F which is not used, because
maybe there is no device there now, but there might be in the future...
Using this system while programming is not as difficult as it seems.
Just store the 'ID' of the device you are currently using in BCz. Then,
simply modify the C register within 50-5F to access the different I/O ports
of the device, and use one of the instructions of I/O type 3 to write the
value. Or use the I/O type 2 instructions with a Decoder Directive (DDIR) in
front of it.
Do you understand what I mean, or does it need more clarification???
I hope I was clear enough.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
