MicroUSB. Whats a preferred alternative interface?
in [Commodore]
|
From: christianlott1 on 12 Dec 2006 16:37 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. agila61(a)netscape.net wrote: > christianlott1 wrote: > > Would it be easier to stick 64k and a USB interface to the cart port? > > Is it possible to just mirror the whole 64k from the cart port using > > it's 16 address lines? > > Quick answer, yes. Get a USB controller for an 8-bit bus > microcontroller with a register file, add a little glue to make it talk > to a 6502 bus, use one of the two device select lines, and multiplex it > with a spare address line. F'rinstance, if its organized as 1 data > register and 15 control registers, it will have 4 address lines, there > are 8 address lines plus the cartridge port device select, SO ... > > Demultiplex a7 and a6 into four select lines, with the cartridge port > device select line as chip select for the demux, and you can have four > register based chips that show up in: > $00-$3F - chip 1. > $40-$7F - chip 2. > $80-$BF - chip 3. > $C0-$FF - chip 4. > > Coping with chips with up to 64 register files each. Woa. Going too fast for me. Are you talking about placing the PICs control registers in C= memory? No... (though I'm starting to like that idea, just not in page zero!) I think I see. $0000-$3F00 is first of the physical ram chips. Still don't know what 'register file' means, but I haven't read the uC docs. (don't let me slow you down.) > If you wanted to keep it simple (that is, not DMA copy to C64 memory), > you could put an couple of eight bit latches on one of those line, and > have R/W access via the other cartridge port select line, and a second > latch that made one of four 16K banks show up as a soft-cartridge, so > for read at least you'd have instant access. Oh, so you can't replicate the entire 64k on the cart - meaning, the 6510 can't just use a 64k ram chip on the cart port instead of it's own internal ram. I thought all 16 address lines were available on the cart port.. > However, now that you mention it, since my Commodore at the moment is > virtual rather than real, a device that plugs into the C64 that an > emulator program can actually access as hardware would be kinda cool. ? I didn't know I mentioned it! Sounds fun though! (I still don't understand what you just said, however - I thought you were talking about doing a real c64 to emulated c64 (C642VICE) 'shared memory' thing with the 16k available on the cart port.. ) Anyway, having 16k ram available - downloaded from the PC - you could use that 16k as a window into PC memory since a 16k block copy with USB would be instantaneous... or maybe it would be slower since the speed of the ram chip and bus is slower.. but like you said, just use the other slices of memory as buffer for that 16k window. I still don't know which is the bigger winner, cart or user port. I think I'd prefer cart port but I'm probably the only person who's reading this thread who doesn't have something on it. I could still use 64HDD and instead of copying a program to floppy first by just downloading to the USB cart and saving off the 16k slices into the 64HDD computer. That may just be toooo lazy. I still can't picture the speed of 1 byte/cycle. In KBps for 64k, how fast is that? 1Mhz = 1,000,000 cycles/second = 1,000,000 / 64,000 = .064 seconds? Is that right?
From: agila61 on 12 Dec 2006 19:22 christianlott1 wrote: > Woa. Going too fast for me. Are you talking about placing the PICs > control registers in C= memory? No... (though I'm starting to like that > idea, just not in page zero!) No ... I was talking about the address WITHIN one of the two pages where a device in a cartridge "shows up" in the memory space There are two lines on the cartridge port that select when the devices are mapped into memory and there is a R/W in that page. That is how the cartridge works as for "expansion" devices. .... I waved my hands at that but didn't actually give the addresses. They are Pin 7, /IO1, when $DE00-$DEFF is accessed and Pin 10, /IO2, when $DF00 to $DFFF is accessed. So if you have a chip that can connect to an 8-bit bus, with up to 256 register (that is, up to 8 device address lines on the chip), you can put it on a cartridge and if you connect everything right, don't screw up the soldering, and haven't fried anything, make it react so that it shows up in one of those two pages in the memory map. According to the datasheet, some versions of the PIC that Tristan is using have a port set up to be connected to an eight bit data bus. > Oh, so you can't replicate the entire 64k on the cart - meaning, the > 6510 can't just use a 64k ram chip on the cart port instead of it's own > internal ram. I thought all 16 address lines were available on the cart > port. Yes, the cart port knows gets all 16 address lines, but there's a lot of memory mapping in the C64 that dictates what the 6510 is connected to ... RAM, or program ROM (Kernel, Basic, program on a cartridge) or Screen font ROM or a memory mapped device ... etc. That's why it would not be that intricate to read from a 16K block on a cartridge if its made available just like a cartridge ROM ... that access is built in. You could also write, with a bit more effort, but it would be a copy of what is written into the RAM, unless you write it a page at a time using the device space. True memory paging like in the C128 would only be inside one of those two cartridge device pages, or else cracking open the case and doing a hack .. > ? I didn't know I mentioned it! Sounds fun though! > (I still don't understand what you just said, however - > I thought you were talking about doing a real c64 to emulated c64 > (C642VICE) 'shared memory' thing with the 16k available on the cart > port.. ) Nah, the User Port device ... Win32 and Linux are fast enough that they can do 250kbps SPI on a parallel port in software. A real, bone fide C64 is the only way to address Cartridge envy. > I still don't know which is the bigger winner, cart or user port. Its not a race. The more options, the better.
From: Tristan Mumford on 12 Dec 2006 21:12 On Tue, 12 Dec 2006 16:22:53 -0800, agila61 wrote: > christianlott1 wrote: >> Woa. Going too fast for me. Are you talking about placing the PICs >> control registers in C= memory? No... (though I'm starting to like that >> idea, just not in page zero!) > > No ... I was talking about the address WITHIN one of the two pages > where a device in a cartridge "shows up" in the memory space There are > two lines on the cartridge port that select when the devices are mapped > into memory and there is a R/W in that page. That is how the cartridge > works as for "expansion" devices. > > ... I waved my hands at that but didn't actually give the addresses. > They are Pin 7, /IO1, when $DE00-$DEFF is accessed and Pin 10, /IO2, > when $DF00 to $DFFF is accessed. > > So if you have a chip that can connect to an 8-bit bus, with up to 256 > register (that is, up to 8 device address lines on the chip), you can > put it on a cartridge and if you connect everything right, don't screw > up the soldering, and haven't fried anything, make it react so that it > shows up in one of those two pages in the memory map. That's right. It's this same concept that allows one to connect some 8-bit ISA cards to the userport with little work. I believe the original 8 bit ISA cards have 512bytes of IO max. > According to the datasheet, some versions of the PIC that Tristan is > using have a port set up to be connected to an eight bit data bus. Indeed. That port is called a Parallel Slave Port. Oddly enough the uggestions in datasheets for its use are for things like virtual printer devices. The PSP has an interrupt which is triggered on any change to the port. This allows the host device to blindly pump data into the uC without fear of it not getting the data. > >> Oh, so you can't replicate the entire 64k on the cart - meaning, the >> 6510 can't just use a 64k ram chip on the cart port instead of it's own >> internal ram. I thought all 16 address lines were available on the cart >> port. > > Yes, the cart port knows gets all 16 address lines, but there's a lot of > memory mapping in the C64 that dictates what the 6510 is connected to > ... RAM, or program ROM (Kernel, Basic, program on a cartridge) or > Screen font ROM or a memory mapped device ... etc. > > That's why it would not be that intricate to read from a 16K block on a > cartridge if its made available just like a cartridge ROM ... that > access is built in. You could also write, with a bit more effort, but it > would be a copy of what is written into the RAM, unless you write it a > page at a time using the device space. True memory paging like in the > C128 would only be inside one of those two cartridge device pages, or > else cracking open the case and doing a hack .. When I actually get hold of something that plugs into the cartridge port one of the first thigs I'll be doing is putting one of the NVRAMs on there to help speed development. I hate waiting a few minutes for a terminal program to load only to discover that my device isn't working as planned, and have to turn everything off again. >> I still don't know which is the bigger winner, cart or user port. > > Its not a race. The more options, the better. Exactly. Any this thing I'm workingon really offers the option of connecting it to whatever you please. One thing I forgot to mention. I used portd (which has the PSP) to the USB IC. But It'd be easy enough to attach a CS pin and use it for both system and USB access. Using something like a '245 on the system end of things that is. By the way. On my site \/ I have an update of here I'm up to on the USB thing. Incidentally I was chatting to a friend of mine online and we both came to the conclusion there may be a short on D0. Going to check that later. -- -----> 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 12 Dec 2006 21:38 On Tue, 12 Dec 2006 13:37:53 -0800, 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. I see no reason why it couldn't be connected to the tape port (such a waste of precious IO) or dare I say it... one of the joystick ports ;) > > > agila61(a)netscape.net wrote: >> christianlott1 wrote: >> > Would it be easier to stick 64k and a USB interface to the cart port? >> > Is it possible to just mirror the whole 64k from the cart port using >> > it's 16 address lines? >> >> Quick answer, yes. Get a USB controller for an 8-bit bus >> microcontroller with a register file, add a little glue to make it talk >> to a 6502 bus, use one of the two device select lines, and multiplex it >> with a spare address line. F'rinstance, if its organized as 1 data >> register and 15 control registers, it will have 4 address lines, there >> are 8 address lines plus the cartridge port device select, SO ... >> >> Demultiplex a7 and a6 into four select lines, with the cartridge port >> device select line as chip select for the demux, and you can have four >> register based chips that show up in: >> $00-$3F - chip 1. >> $40-$7F - chip 2. >> $80-$BF - chip 3. >> $C0-$FF - chip 4. >> >> Coping with chips with up to 64 register files each. > > Woa. Going too fast for me. Are you talking about placing the PICs > control registers in C= memory? No... (though I'm starting to like that > idea, just not in page zero!) > > I think I see. $0000-$3F00 is first of the physical ram chips. Still > don't know what 'register file' means, but I haven't read the uC docs. > (don't let me slow you down.) Register file is roughly the equivalent of RAM. Except in the uC, it's just a massive, multipaged array of registers. Although the one I'm using is 16 or 18 bit (can't remember. Using C so don't particularly care), I believe the mentioning of accessing register files pretty much means having random access to multiple virtual 8 bit registers on the uC. This is done either with a few virtual adsresslines and a databus, or a databus and a single addressline. Sort of like the USB IC. The (1 bit) address is set to 0, and data is written to that address specfying what data is available on A1. Then it's switched to A1, and a read or write operation is performed on the data at the prescribed address. > >> If you wanted to keep it simple (that is, not DMA copy to C64 memory), >> you could put an couple of eight bit latches on one of those line, and >> have R/W access via the other cartridge port select line, and a second >> latch that made one of four 16K banks show up as a soft-cartridge, so >> for read at least you'd have instant access. 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. Also there's that 8051 compatible uC I have from Dallas Semiconductor that I've been aching to use. I've never really looked at the 8051s before buit this one has a few nice features that got my attention. * Optional external bus (8 bit multiplexed) for running programs on external memory, which can be mapped in with internal memory. * Builtin RS232 bootloader and ability to have custom bootloaders. * 1 tick per instruction from internal memory (external memory based ones are at least 4 ticks.). * 33MHz max speed. Doesn't compete with that ARM board, but still good. You can see that the chip would open up a few interesting possibilities. Everything from DMA to some kind of scary coprocessor with some shared memory. I'm thinking vector calculations and other such things. Also it would enable me to use the DMA ability of the USB IC. > I still don't know which is the bigger winner, cart or user port. I > think I'd prefer cart port but I'm probably the only person who's > reading this thread who doesn't have something on it. Not true. I don't. The only things I have that plug into the cartridge port are game carts and the Viatel adaptor. -- -----> 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 06:39
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 |