MicroUSB. Whats a preferred alternative interface?
in [Commodore]
|
From: Tristan Mumford on 6 Dec 2006 04:08 On Wed, 06 Dec 2006 00:40:17 -0600, bud wrote: > Group: comp.sys.cbm Date: Wed, Dec 6, 2006, 5:11am (CST+6) From: > vmuikkul(a)ratol.fi (Ville Muikkula) > > script: > >>>I'm still having the problem of obtaining >>>an edge connector. >> >>http://www.8bitbaby.de/ > > Also: http://www.c64reloaded.com > > (If you're in US, or NA.) Australia. But thanks for the c64 reloaded url. I didn't know that one. > > salaam, > dowcom > > To e-mail me, add the character zero to "dowcom". i.e.: > dowcom(zero)(at)webtv(dot)net. > -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: Nick @ 64HDD on 7 Dec 2006 16:55 Hello Tristan, Tristan Mumford wrote: > Hello! > > Yes. More on MicroUSB. > At any rate because of my silly problem I took an alternate route. I > decided to use a uC for now to handle the low level stuff. This leaves me > free to conenct it to other things. > I'm knocking together the first hardware prototype tonight hopefully. > Should be fun. > > So anyway, what would be the best thing to do? I built my interface all those years ago to use I/O1 (because I wanted I/O2 available for the REU). I used a 74139 to do the decoding of the R/W lines. Unfortunately the hardware is back in Perth, whilst I'm currently in Japan. I also have some generic C64 expansion port PCBs. I won't be back though until after Christmas - so probably no help to you. Best to contact me through the 64HDD website (www.64hdd.com) - Nick
From: agila61 on 7 Dec 2006 19:20 Tristan Mumford wrote: > At any rate because of my silly problem I took an alternate route. I > decided to use a uC for now to handle the low level stuff. This leaves me > free to conenct it to other things. > As it is my options seem to be either User port, or Tape port. > In the case of the user port I have no idea how to establish an effective > communication method. Parallel would be nice, but how would I do it? http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chapter_6/page_360.html QUOTE The Commodore 64 gives you control over PORT B on CIA chip #1. Eight lines for input or output are available, as well as 2 lines for handshaking with an outside device. The I/O lines for PORT B are controlled by two locations. One is the PORT itself, and is located at 56577 ($DD01 HEX). Naturally you PEEK it to read an INPUT, or POKE it to set an OUTPUT. Each of the eight I/O lines can be set up as either an INPUT or an OUTPUT by by setting the DATA DIRECTION REGISTER properly. ENDQUOTE For the User port, use PC2 as the handshake line, Flag as the alert signal from the uC, PA2 as your data/control toggle, and PB0-PB7 as your data bus. You'll notice they are all on the same side of the port, with 2 grounds, except the PC2 handshake line. PA2 will always be set to OUT. When it is pulled high, the next byte on the data bus is a write of the control token. You need to indicate data mode I/O, but this can be as simple as a register address and PB7 as setting data R/W. Then pulling the PA2 low, you either read to or write from the PB port address. You can of course emulate a register based approach with a uC, if it is enough faster than the C64, so that when the control byte selects a "address byte" register, the uC stores the data in an appropriate place, and when the control byte selects a "data port" register in read mode, the uC fetches the first byte of data and places it in a latch to be read, waiting until the FLAG2 shows that it has been read to go fetch the next one. A second advantage of emulating a register based approach with the uC is that you can set aside one pseudo-register address as a device select register, so that you can use the uC for things in addition to the main function. The thing to note is that this is not a bi-directional port as such but a software-controlled directional port. That's why the PC2 handshake is important, to make sure that changes in the lines due to changed in the settings of the IO Data Direction Register will not result in the PC2 line being pulled low for one cycle ... only reading or writing the data port itself will drive the handshake line to toggle low then high. So the uC should put data for C64 input onto the bus until PC2 goes from low to high (or else Control/Data is pulled to Control), and should accept data output from the C64 when the PC2 line goes from high to low. A draft (that is, untested) routine to put out a control token and put it back into data mode is: Initializing: Be sure to set the DDR for PA2 to output. LDA $DD02 ORA %00000100 STA $DD02 before starting. I would suggest setting up the uC so it ignores whats going on until it receives a specific token. DON'T TOUCH THE OTHERS ... that's the serial bus and VIC memory map select. Be sure that the device space is in the memory map! 1. Switch the Control/Data line to control. I'll suppose that is PA2=1. This will be a single bit in PA ... Checking the memory map, that's $DD00. LDA $DD00 ORA #%00000100 STA $DD00 2. THEN set the DDR port for output LDA #$FF STA $DD03 3. Then store the prepared control token ... I will assume you passed it in register X STX $DD01 4. Go to Data mode to latch the control token LDA $DD00 AND %11111011 ; Set up Data mode STA $D000 5. And set the DDR register TXA ; read top bit of token BMI DATAWRITE ; Top bit 0 => set the User port for input LDA #0 STA $DD03 ; PB DDR for Data mode RTS DATAWRITE: ; Top bit 1 => set the User port for output LDA #FF STA $DD03 RTS That puts all of the protocol overhead into the control routine, and reading or writing a block of data from a sequential access dataport would be something like BUF1OUT: LDY #0 ; 2 B1OUTLP: LDA BUF1,Y ; 5 STA $DD01 ; 4 INY ; 2 BNE B1OUTLP ; 3/2 ; 256*14 +1 = 3585 cycles? assuming that there is a hardware buffer on that register, or that the uC can collect or feed that fast.
From: Tristan Mumford on 7 Dec 2006 19:41 On Thu, 07 Dec 2006 13:55:10 -0800, Nick @ 64HDD wrote: > Hello Tristan, > Tristan Mumford wrote: >> Hello! >> >> Yes. More on MicroUSB. >> At any rate because of my silly problem I took an alternate route. I >> decided to use a uC for now to handle the low level stuff. This leaves me >> free to conenct it to other things. >> I'm knocking together the first hardware prototype tonight hopefully. >> Should be fun. >> >> So anyway, what would be the best thing to do? > > I built my interface all those years ago to use I/O1 (because I wanted > I/O2 available for the REU). I used a 74139 to do the decoding of the > R/W lines. Makes sense. I was thinking of going that way. Speaking of the '139. I need one for IEC-ISA. I can't even easily get one here. And the DSE even had things like DACs and various uCs in stock. But very little standard logic :( Unfortunately the hardware is back in Perth, whilst I'm > currently in Japan. I also have some generic C64 expansion port PCBs. I > won't be back though until after Christmas - so probably no help to > you. Best to contact me through the 64HDD website (www.64hdd.com) > > - Nick Don't bet on it. I have to work on a longer timescale than most because of the situation around me and in life. I tried e-mailing you a few weeks back (or something like that) at the info64 email address. I got mailer daemonised. I'll give it another shot. In Japan? Nice. As a general note. I've done a decent chunk of the logic wiring for a test interface. Just going to talk to it via the RS232 pins on the C64. That way I can get a power supply and not worry about line level conversion. Anyway, The fires seem to be getting closish judging from the smoke so I suppose I'd better do the whole gathering valuables thing. Bleh. Tristan Mumford. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: agila61 on 8 Dec 2006 06:18
Tristan Mumford wrote: > At any rate because of my silly problem I took an alternate route. I > decided to use a uC for now to handle the low level stuff. This leaves me > free to conenct it to other things. > As it is my options seem to be either User port, or Tape port. > In the case of the user port I have no idea how to establish an effective > communication method. Parallel would be nice, but how would I do it? Also, I would suggest that if you use the User port, a good solution would be to solve the connection problem for homebrew User port devices once and for all with a board that has the relevant lines connected to a DB25 female, and use a DB25 male on the card holding the uC. And DB25 plugs are (at least for not) somewhat more readily available than classic spacing edge card connectors. |