Re: userport: C64, Plus4, others?

From: Gábor Lénárt <>
Date: Thu, 8 Mar 2012 10:33:34 +0100
Message-ID: <>
On Wed, Mar 07, 2012 at 11:20:48AM -0600, Jim Brain wrote:
> 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.

What HiZ is? I guess it's high impedance, am I right? As being Hungarian I
am not sure about the English notion of things sometimes, sorry about it.

> 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).

Yes, but my idea that always the C64 is the one who must start a transfer
regardless of the data direction (read/write). uC won't respond by its own,
but C64 requires both of the read/write signaling with another line (maybe
PA2 on userport or something like that). So the C64 sets the direction up on
CIA, and uC is signaled about the data direction by the C64 so it will know
as well about the transfer direction. AFAIK even DTV has the PA line,
however I am a bit confused about DTV, as I've read it has not got fully
functional 8 bit I/O just for input, but it's possible that it was about the
Hummer game only and not the DTV (v2 or v3) actually, I must still
investigate about this.

However that's still true that there can be times for a short period (or
program bug?) when eg both of uC and C64 thinks they do output, and there
can be some problem then what you described. I am really not an expert about
digital circuits yet (that's also why I want to start a project like this to
learn some new things), I don't know who to make this safe and not to burn
something ... 

> 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

Maybe, however I would like to use an uC which has the minimal number of
pins as possible (using more ports on uC means more pins), I mean using a
DIP version is OK, but I think I have got no skills and tools to solder
chips which are not DIP.  Also making a board as a "DIY" style would be
quite hard then (for me at least).  I have some experience to build more
basic boards/soldering using discrete stuffs and DIP ICs.

Btw, for starting point I'd like to wire some kind of SD socket, with dual
purpose: uC would "boot" its "firmware" from it (there are boot loaders for
AVR like this afaik) and also it can be used to read/write data sent/read by
C64 too (yes, I know, SD2IEC and like are "better" because they are "ready"
and compatible with a stock machine too - since it uses std IEC bus, but
also because of this, it can't be as fast, and also note that having the SD
storage is only a part of the project, and not even the primary goal). It's
a bit like however as IDE64; it's also not compatible at hw level (it does
not using IEC) the compatibility is provided with KERNAL modification (on
DTV it's really easy, no need for additional hardware).

So I would need an uC which can interface with the C64 (and DTV later) and
which is also connected to an SD card for example. Besides this, my goal is
some kind of ethernet connectivity, I am not sure about this: uCs which has
it "built in" usually have just two many pins for an average hobby use. I am
thinking on using I2C or SPI bus with external ethernet chip designed for
this, it's still can be quite fast, at least as far as I can remember, the
transfer rate can be even 3-4 mbit/sec still on these serial buses. Also
other stuffs may be connected later on I2C/SPI, it remembered me a bit for
C2N-power btw :) Just I would like a solution which also works with DTV,
and using parallel data transfer from the view point of the computer.

> (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
> 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.

Hmm. As I've written above, uC won't answer on its own, just if C64 asks for
some answer. However still I need some kind of solution for preventing demage
when both of C64 and uC is configured (for any reason including a software
bug etc) as output. Normally it won't happen, but still. I am really not
experienced here though ...

> >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.

The key what I told that always the C64 tell it wants data to send or
receive (eg using that PA2 pin on user port). So the uC should know the data
direction. But still, as I've stated, some kind of protection would be
needed anyway.

Sorry if I missed something because of my "not so perfect" English, it can
happen ...

       Message was sent through the cbm-hackers mailing list
Received on 2012-03-08 10:00:05

Archive generated by hypermail 2.2.0.