Re: userport: C64, Plus4, others?

On 3/7/2012 3:10 AM, Gábor Lénárt wrote:
> Hi Jim,
>
> On 6526, afaik: "PC will go low for one cycle following a read or write of
> PORT B".  So I guess, falling edge of PC can tell (or the low level ...) the
> uC that CPU put new value on CIA2 PORT B (if it's a writing session) or read
> a byte from (if it's a reading session).  If uC is fast enough (I am really
> not sure about this, fixme ...) an interrupt can be generated on the uC
> triggered by PC, and that interrupt handler would store/load the next value.
That would work for writing data from the 64 and reading it on the uC 
(Tie PC to INT on AVR).

Note, though that the 6526 PORTB is a IO port, not a data bus.  As such, 
it has no HiZ state.

An example:

We set the DDRB on 6526 to output data, and the uC has it's port set to 
INPUT.  All is well.  We output data on PORTB, PC goes low, triggering a 
uC INT, and the uC reads the data.

All is well.

Then, though, the uC needs to send data back to the 64.  If it just 
outputs data to PORTB, the two outputs (remember, DDRB is set to output 
on all pins) will fight one another, potentially damaging the 6526 (or a 
buffer that you put in the middle).

THere are a number of potential solutions.  I think the simplest is to 
dedicate two ports on the uC for data.  PORTI (input) and PORTO 
(output).  tie PORTB to IPORT and PORTB to the '245 and PORTO to the 
other side of the '245.  You can use PC as WRITE, which will trigger a 
read of PORTI.  Using a signal on the 64 for READ will allow the 245 to 
engage, dumping PORTO data to the PORTB pins.  Of course, the 64 needs to:

SET DDRB to input
BRING READ low
READ PORTB
BRING READ high

That's not too bad.  You can do this without the '245 (watch for low INT 
on READ, when found, set DDRO to output, put data on port, wait for READ 
to go hi, and then set DDRO to input).  However, this places more timing 
demand on the uC.
> So it seems pin PC can be used for handshaking quite well (both for reading
> and writing).
I guess I must have missed something, but I would not assume the uC 
*knows* when it is safe to place data on PORTB, for the double output 
concern listed above.



       Message was sent through the cbm-hackers mailing list