CPC I/O port decoding

[zhulien]

hi,


Within the CPC wiki I/O port docs, what is meant such as:


Decoded As?
http://www.cpcwiki.eu/index.php/I/O_Port_Summary


11110111 00000000 (#F700)
xxxx0x11 xxxxxxxx


With the CPC, most software uses out (c),c to send a value to the i/o ports.  Does that mean that the content of c is never put on the address bus of the expansion port?  But when we do a memory write such as ld (bc), a... the content of c is put on the bus of the expansion port?  Or is the full 16 bits of the address put on the expansion port regardless of whether it is a memory operation or an I/O operation?

[arnoldemu]

hi,


Within the CPC wiki I/O port docs, what is meant such as:


Decoded As?
http://www.cpcwiki.eu/index.php/I/O_Port_Summary


11110111 00000000 (#F700)
xxxx0x11 xxxxxxxx


With the CPC, most software uses out (c),c to send a value to the i/o ports.  Does that mean that the content of c is never put on the address bus of the expansion port?  But when we do a memory write such as ld (bc), a... the content of c is put on the bus of the expansion port?  Or is the full 16 bits of the address put on the expansion port regardless of whether it is a memory operation or an I/O operation?

This means that #f700 is the "recommended port". The I/O port to use to avoid problems with other hardware.

However, a lot of hardware implementations do not decode it exactly.

x means 'don't care'. i.e. it can be 0 or 1. The hardware probably doesn't decode this.
1 means 'it must be 1'. 0 means 'it must be 0'.
So this means the hardware is partially recognising the address and accepting any address that matches that pattern.

What happens is the A15-A0 have the port. For out (c),a this will be the value in BC. D7-d0 hold the data in this case in A.

If you do out (c),c, then BC is the address and C is the data. If the device doesn't decode a7-a0 (i.e. ignores it), then the data and port a7-a0 are the same.

The full 16-bits of the address are always put on the bus, and the full data bits are put on the bus. /RD and /IORQ means an I/O read. /WR and /IORQ means an I/O write.
/ before means the signals are 'low' or 0 when active.

[zhulien]

I'm wanting to use #2000 - #2003, looking at the I/O, it appears there is nothing that uses them.  Because I am going to ignore the upper 2 bits of the entire address bus (for now), effectively I am taking advantage of #8000 - #8003 also not being used.  Are there any issues with this approach?  Effectively it is decoded as xx10000000000000 right?

[arnoldemu]

I'm wanting to use #2000 - #2003, looking at the I/O, it appears there is nothing that uses them.  Because I am going to ignore the upper 2 bits of the entire address bus (for now), effectively I am taking advantage of #8000 - #8003 also not being used.  Are there any issues with this approach?  Effectively it is decoded as xx10000000000000 right?

A15 and a14 are used by gate-array and crtc.

If a15=0 and a14=1 then gate-array will be selected.
If a14=0 then crtc is selected.

So #2000 means your hardware AND the crtc is selected. #8000 means crtc is still selected. Both will take the data on the bus.

I/O address space and memory address space is separate. So you could decode memory read/writes and it would be ok.

EDIT: A lot of CPC hardware decode a single address bit and want that to be 0.
There is one address bit reserved for expansions so this often means addresses are F8xx or similar. The other bits set to 1 to avoid them be selected at the same time.

[zhulien]

thanks, actually what i need to do since i have not enough GPIOs, is honour the upper bits to avoid hardware clashes and sacrifice the lowest bit and i can mask or shift.  The downside of such, is it removes the block transfer instructions from being useful... i will think of something

[arnoldemu]

thanks, actually what i need to do since i have not enough GPIOs, is honour the upper bits to avoid hardware clashes and sacrifice the lowest bit and i can mask or shift.  The downside of such, is it removes the block transfer instructions from being useful... i will think of something

Yes the block i/o functions can't be used on cpc.

[arnoldemu]

thanks, actually what i need to do since i have not enough GPIOs, is honour the upper bits to avoid hardware clashes and sacrifice the lowest bit and i can mask or shift.  The downside of such, is it removes the block transfer instructions from being useful... i will think of something

use a partial decoding. Ideally full decoding *IS* best, but as you say your limited by GPIO pins.

So at a minimum:
A10 = 0 for expansion peripherals.
A7=1 (to avoid FDC).
You can decode A9,A8,A6-0 as you need. Look for a spare address on the page.

If you want to have some form of "fast" i/o access then you could ignore A8 and A9. You could in theory use 4 INI, IND, OUTI, OUTD in a row to read or write 4 bytes of data to your i/o port. You would decode it as the same i/o address, but the cpc sent it to base,base+0, base+1,base+2.  (base is your chosen address)

You couldn't use OTIR,OTDR etc because they would loop too much but you could get some more speed using INI and OUTI.

[rpalmer]

The only way to get some form of "block" transfer is to somehow use a memory mapped I/O scheme.
For example

Flag Read Ops as I/O to the memory mapped I/O hardware so that the /RD and /MREQ now act as I/O functions
setup BC/DE/HL for LDIR (where DE is the hardware address for I/O storage and HL = DE)
LDIR
reset Read Ops as normal memory to the memory mapped I/O hardware to ignore /MREQ and (/RD /WR) combinations

The hardware for this may be more complicated, but I think it get around the problem. The down side is which part of available memory you which to sacrifice

rpalmer

[zhulien]

that is correct and planned for day 1