Re: userport: C64, Plus4, others?

Hi Jim,

On Tue, Mar 06, 2012 at 08:34:14PM -0600, Jim Brain wrote:
> On 3/6/2012 10:48 AM, Gábor Lénárt wrote:
> >Hi Ruud,
> >
> >On Tue, Mar 06, 2012 at 05:13:45PM +0100,Ruud@Baltissen.org  wrote:
> >And as far as I can understand the things, CIA can provide a (with
> >"PC") for the uC that new data put on (on C64 write), or data is
> >read (so next can be placed for read by the C64).
> Actually, the user port is good for this.
> 
> Handshaking will be the issue, in my opinion.  You can easily put
> the data on PortB and read it, but how do you tell the uC the data
> is there to be read, and how do you know when data is available to
> read?  On teh 6522, for example, the proper signals are CA1/CA2, but

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.

So it seems pin PC can be used for handshaking quite well (both for reading
and writing). The other stuff: maybe I would use another output pin
somewhere (PA2?) on userport: it's output only and C64 would be able to
signal that it wanna to start a new transfer (even with stopping the
previous - if was any). I set that bit while outputing a byte (or more),
this would be the "command code" which also indicates the data direction
after the "command" is specified; then I simply switch that signal off and
then only data is transferred (read/write, depending on the command itself).

One thing attracted my attention: if I understand well, CIA is "slow" that
there are one clock delay (sometimes?). So I am not sure if it does not
cause problems.


> they are not on the user port.  CB1/CB2 can provide the interrupts,
> but they're not as useful.
> 
> 
> 
> >The reason I'd like decent transfer rate between C64 (or DTV) and
> >the uC: I'd like to use an uC with ethernet capabilities later.
> >Though there are ethernet solutions (like TFE or RR-Net) for the
> >C64, I always felt that I want something like this for DTV too,
> >where there is no solution for the problem (and you don't have an
> >std C64 bus at all - but you have some kind of user port at least,
> >even if it's not the very same). As DTV has many memory, and I
> >already experimented with some kind of "advanced OS" (multitasking
> >etc) for the DTV, it would be really nice to have TCP/IP too (I've
> >already have a partly working stuff like that for RR-Net on C64,
> >as uIP seems to be complicated for me - and it's C - and I haven't
> >heard too much about IP65 when I started that project). But
> >currently I want to focus only a solution which provides good
> >transfer rate between C64 and a uC without thinking other topics.
> >- Gábor Message was sent through the cbm-hackers mailing list
> 
> I'm happy to help on both sides (64, and if you want to use AVR, the
> uC side).
> 
> You do need to ensure 2 more lines besides the 8 data lines (WRITE
> and READ, essentially). Everything else is details.

Yes, well, as I've described above, CIA's PC line - according to some random
dox I found with google ... - can be used to tell new data can be read/write
by the uC. So virtually, I need only _one_ line besides of 8 data lines.
Well, according to my original plans it's even enough: every transfer would
have a strict "syntax": for example, for writing, I write out a byte
(command code for the uC), the transferred data size (in bytes) then the
specified number of bytes can be read/write (the exact operation is
determined by the command code). However it's a bit sensitive stuff: If I
ever send more and less data than I specified as size (program bug, etc)
then I can't tell easily how to "catch" the attention of the uC, so that's
why I would involve another output-only pin which would signal a new command
code for the uC (if there is pending transfer, it is also stopped with
that). Note, that in my design, it's always the C64 which initiates any
transfer regardless of the data direction of the transfer: the PC line is
output only, also the "new command" line.

With DTV things go even more interesting. Afaik there is no handshaking line
as the PC pin with the CIA on a real C64. So maybe I should find a new
output line (or more, for "command" too?) for this purpose. As far as I can
remember, the PA line is available, also maybe two bits which were the
datasette stuff originally on a real C64. However DTV has an advantage too:
it's fast and it has DMA inside. With DMA I can do memory transfers much
faster than with LDA/STA combo, as DMA can read/write I/O registers too.
I've already done this with a digi player for a DTV, then I output series of
bytes to a SID register (not exists on a real SID with a real C64), so it
can work, but then a new problem: since there is no handshaking, I should do
that with very accurate timing maybe using some clock signal of the DTV
board itself: on DTV the "emulation of bad lines" can be turned off (in
contrast of a real VIC-II maybe) so if clock is accurate it can work, I
guess. Of course the "manual handshaking" theory is simplier but it's
really cool that DTV can do DMA, and it would be nice to use. I am not sure
about this, but I guess DTV's ASIC runs on 32MHz internally, with dividing
between the "tasks", eg doing DMA in every n.th cycle. Even if only every
32nd ASIC clock cycle is used for DMA, the transfer rate then should be
something like 1Mbyte/sec, which is not bad (well, maybe the half, since DMA
must read then write ...). Also without DMA, DTV is quite fast, as SDRAM
burst is used to read 4 bytes within a single clock and also execute them
(if no other memory reference is needed) if you turn on this feature from
software at least.

Anyway, as you can see, the weak point of "my" idea, that uC should be
always ready to accept read/write, no way to tell that it can't do it then.
Of course there can be some kind of "two-way handshaking" but I feel if I
can provide this without problems, it will create a more simple solution
also with faster data transfer rate.

For C64 as far as I can guess, an unrolled LDA/STA sequence can cause
something like 7 cycles (for LDA/STA), so on 1MHz it should be
around 140kbyte/sec. Maybe the double with C128 in 2MHz mode (can run CIAs
in C128 with 2MHz clock?).

- Gábor

       Message was sent through the cbm-hackers mailing list