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 listReceived on 2012-03-07 10:00:04
Archive generated by hypermail 2.2.0.