MicroUSB. Whats a preferred alternative interface?
in [Commodore]
|
From: Clockmeister on 13 Dec 2006 07:22 "Tristan Mumford" <nintendologist(a)nospam.gmail.nospam.com> wrote in message news:4578b4c0$0$61697$c30e37c6(a)lon-reader.news.telstra.net... > 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 :( DSE are useless for components now. Did you try Altronics or RS?
From: agila61 on 13 Dec 2006 17:20 christianlott1 wrote: > I'm in a different situation than maybe most users. My IEC and Userport > are being used by my 64HDD and my cart port is free. That would be as common a situation as any other! If I had obtained an upgrade back when I was using my C64 as my word processor for grad school in the early 90's, a fast parallel port to drive interface would have been number one on my list! I relied heavily on Big Blue Reader back then. > agila61(a)netscape.net wrote: .... > > Quick answer, yes. Get a USB controller for an 8-bit bus > > microcontroller with a register file, add a little glue ... > Woa. Going too fast for me. Are you talking about placing the PICs > control registers in C= memory? Bear in mind that while I never implemented any hardware, it was in old school days that I was learning about how these things work. So my first reflex is to think in terms of chips like the SID and CIA, where actual hard wired registers control what the chip does. A PIC or ARM microcontroller with enough general purpose IO pins and running fast enough can always pretend to be a device like that, by (1) assigning three input pins as "Chip Select", "R/W" and "CLK" (that is, *bus* clock) lines (2) assigning some input pins to address lines (3) assigning 8 I/O pins to the data bus (4) and reading the control pins to decide what to do with the data on the bus (for a Write) and what data to put on the bus (for a Read). But bear in mind that with a uC, a lot of the things I think of in terms of random logic can be done in software. For example, instead of having a demux split up one of the two cartridge port device I/O pages, you could have one uC that has GPIO lines it does not need for its task that also acts as bus master, receiving address lines a7 and a6 and generating select lines ... so you could have two, three or four PICs or ARMs in the same cartridge, each doing different things, and the ones that are not the bus master only need the eight GPIO lines to talk to the data bus and 1 input line to get the select from the bus master, freeing up more GPIO lines to do other things.
From: Tristan Mumford on 13 Dec 2006 19:00 I'll say first off, sorry for my sporadic posting. On Wed, 13 Dec 2006 14:20:55 -0800, agila61 wrote: > Bear in mind that while I never implemented any hardware, it was in old > school days that I was learning about how these things work. So my > first reflex is to think in terms of chips like the SID and CIA, where > actual hard wired registers control what the chip does. > > A PIC or ARM microcontroller with enough general purpose IO pins and > running fast enough can always pretend to be a device like that, by > (1) assigning three input pins as "Chip Select", "R/W" and "CLK" (that > is, *bus* clock) lines > (2) assigning some input pins to address lines > (3) assigning 8 I/O pins to the data bus > (4) and reading the control pins to decide what to do with the data on > the bus (for a Write) and what data to put on the bus (for a Read). The bus clock line isn't necessary, depending on how it's done. Example. If you look at the Atari MicroUSB schematics (I think there's an offsite link on my site) It's using something like demultiplexed read/write lines and an IO line for address select. This way, asynchronous IO is performed. Basically you just set up any data/addresslines or whatever. And when you are ready, momentarily bring the /read or /write line low to set it all in motion. Actually just have a look at the horribly twisted C source for my MicroUSB port on my site. "userusb.c" has functions using this method. Disregard the ones labeled /*UNUSED*/ though. for uC emulation of a register file you may even deem using an interrupt pin as a prudent solution. > > But bear in mind that with a uC, a lot of the things I think of in > terms of random logic can be done in software. For example, instead of > having a demux split up one of the two cartridge port device I/O pages, > you could have one uC that has GPIO lines it does not need for its task > that also acts as bus master, receiving address lines a7 and a6 and > generating select lines ... so you could have two, three or four PICs > or ARMs in the same cartridge, each doing different things, and the > ones that are not the bus master only need the eight GPIO lines to talk > to the data bus and 1 input line to get the select from the bus master, > freeing up more GPIO lines to do other things. Nothing wrong with doing that, as long as you have the uC running at a high enough speed. I kknow there was a good discussion years ago on using uCs for emulating logic on a c64. I believe it was deemed impractical at the time. They run faster now so it's not as much of a limitation. The code still needs tobe well written though. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: Tristan Mumford on 13 Dec 2006 19:20 On Wed, 13 Dec 2006 03:39:52 -0800, agila61 wrote: > Tristan Mumford wrote: >> Why not have DMA though? It's not too hard to implement. I know once I get >> hold of a cartridge port connector it's one of the first things I'm doing >> (NVRAM being the first). Both for experimental reasons. I have some small >> CPLDs I've been wanting to try. > > DMA is definitely the best expansion memory approach overall for > processing / graphics. But like I said, that's more hardware before I > get to the software part than I would personally be keen to do. > > I'll also note that while you couldn't do I2C on the datasette lines, > if the device does not have a minimum frequence you could definitely do > SPI on the datasette lines. You have four lines, and you bit bang them. > Skipping past the abstracting of the IRQ port and worrying about what > else is contending at the Cassette In line, which is an IRQ on a CIA, > its about 370 clocks per byte, or a bit over 2K bytes per second, minus > whatever time you spend handling interupts. Faster than Daniel > Dallman's 9600bps RS232-C serial port, slower than a UART serial port > cartridge. > > Say, Motor = Select, Cassette write=MOSI, Cassette Read=MISO, and > Sense=CLK. > > MOSI = $01:b3 > MOSI_1 = %00001000 > MOSI_0DN = %11100111 ; Combines clock and bit > > SCLK = $01:b4 > SCLK_DN=%11101111 > SCLK_UP=%00010000 > > SPI_SEL=$01:b5 > SPI_ON = %00100000 > SPI_OFF=%11011111 > > and I'd have to look up how to mask the IRQ, but I think its at > $DC0D:b4 ... so say it is. > > MISO = $DC0D:b4. > MISO_MASK = %00010000 > > Suppose that the part is Most Significant bit first by default. > > SPI_RW: ; 33/34 + 39/40*8 = 371 > STA DATA ; source byte, maybe $2? > ; Protect from transition garbage, start CLK hi (an output by default) > LDA $1 > ORA #SCLK_UP > STA $1 > ; Now set DDR and Select chip > LDA $0 ; CHIP I/O DDR > ORA #%00111000 ; All 3 output > STA $0 > LDX #8 > ASL DATA ; will be shifting read line in, but don't has it yet > SPI_LP > ; lo: 2 3 2 3 2 3 2 3 = 20 > BCS SPI_LP1 > ; Put out 0 bit > LDA $0 > AND #MOSI_0DN > STA $0 > ORA #SCLK_UP > STA $0 > CLC > BCC SPI_LP2 > ; Put out 1 bit > ; hi: 3 3 2 2 3 2 3 2 = 20 > SPI_LP1: > LDA $0 > ORA #MOSI_1 > AND #SCLK_DN > STA $0 > ORA #SCLK_UP > STA $0 > CLC > SPI_LP2: ; 1|0 merge again here > ; 4 2 3/4 5 2 3 = 20 > LDA MISO > AND #MISO_MASK > BEQ SPI_LP3 > SEC > SPI_LP3: > ROL DATA > DEX > BNE SPI_LP > ; 11+3-1=13 > LDA DATA > RTS It never ceases to amaze me how you do that so effortlessly. I'm not sure how my project is faring right now though. Now I have communications working it unearthed a problem in the other end. It seems as though something is causing it to be a little hard of hearing, or something to that effect. It's strange. It can detect a device connected to it But it can't finish initialising. The code gets stuck on process(3), which essentially means that the code goes into a busy wait. It's waiting for bit 1 to go high, signalling the end of a read operation (USB peripheral -> controller), but it never happens. The code gets stuck waiting forever. I've checked for anything too out of place on my board. I guess logically the USB IC is getting a clock signal because the USB detection part works. /nRD snd /nWR have to be working. Because in order to obtain any useful info from the IC they both need to work. D0-D7 seem to be working. I know I'm less sure on that, but They all seem okay. A0 is fine, because it couldn't access registers otherwise. The only real problems I found are that I used 17k pulldowns on the D+/- lines instead of 15k, and the 3.3v rail is a little low. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: agila61 on 13 Dec 2006 19:50
Tristan Mumford wrote: > I kknow there was a good discussion years ago on using uCs for emulating > logic on a c64. I believe it was deemed impractical at the time. They run > faster now so it's not as much of a limitation. The code still needs to be > well written though. And for someone like me, for logic its probably more attractive to learn how to program a SPLD like the PEEL18CV8. Then with one or a few chips I got all the old fashioned random logic I would every really need. |