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