User Port expansion
in [Commodore]
|
From: Vanessa Ezekowitz on 2 Feb 2010 05:13 On Tue, 02 Feb 2010 16:29:03 +1100 Chris Baird <abuse(a)brushtail.apana.org.au> wrote: > > IDE doesn't *have* to require a 16-bit connection; people have built > > 8- bit adapters for connecting IDE devices to small hobbyist > > projects. > > This -is- for a 8-bit IDE interface. There's 8 bits for DATA0-7, then > another 6 I/O needed for A0-2, /CS0, /RD, and /WR. > > What everyone else has built was full-on memory-mapped IDE controller > interfaces (they then sell the professionally-made devices to helpless > hobbyists for $50+...) Here, I've used software and straight-through > wiring w/ no semis to do the same thing, and still getting a respectible > 14kB/sec transfers. To port this project to the Commodore there's just > the small matter of the CIA only providing 8 external I/O lines.. > > > http://www.mylinuxisp.com/~jdbaker/oldsite/SmallSys/8bitIDE.html is > > one example. Just a thought. > > http://www.retroleum.co.uk/electronics-articles/an-8-bit-ide-interface/ > was a great reference when builting the SYM-1 IDE interface. > The User Port provides 9 general purpose I/O lines: PB0-7 and PA2. A few of the other lines can also be re-purposed: The Serial /ATN line is actually /PA3 and appears on the user port also. It is inverted, and is output only (thanks to the inverter). SP1 and SP2 can act as simple output lines (rather than as serial ports) by setting them up to cycle at the highest speed the CIA will allow, and by always writing either 0 or 255 to their respective registers. /PC2 is strictly a handshaking output. It goes low for 1 microsecond following each read or write of Port B. The /Flag2 line can be used as a sense input. It is the counterpart to /PC2, and sets an interrupt bit in response to a low-going edge (this can be masked off and polled manually). -- "There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves." http://starbase.globalpc.net/~ezekowitz Vanessa E. <vanDEesLEsaTEezTHekISowitz(a)gmail.com> (Delete the obvious to email me) --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Chris Baird on 2 Feb 2010 08:01 > The Serial /ATN line is actually /PA3 and appears on the user port > also. It is inverted, and is output only (thanks to the inverter). This could be an alternative to using a patch-wire for R/W... That and the rest was useful information, thanks. -- Chris
From: Jim Brain on 2 Feb 2010 13:50 On 2/2/2010 3:17 AM, Chris Baird wrote: > It was the concept of using an 9th I/O line to select between > buffers/transceivers that I was getting at. Yeah, I tried to design something in my head based on that, but I wasn;t getting very far. My idea was to "widen" the bus, but it was starting to look like 5 '574 devices (2 to latch input, 2 for output, 1 for the access signals, and that would probably blow your budget :-) It also required an 2 OE signals, 3 LE signals, which I didn't think you could get at the user port (I can see possibly 4 output lines, but no more). > I've done bit-banged serial I2C mass-storage before > <http://kildall.apana.org.au/~cjb/wordpress/archives/116>, and the > throughput was ~380 bytes/sec on a a 4MHz system. A rough guess with CIA shift registers run at CLK/4, so 16 bits can be clocked out/in in 32 cycles (16uS on a C128). If we say it takes 50uS to clock a byte out, 20 bytes/ms or 20K/second. That's not to shabby. I am not sure why your I2C device is so slow, but I am very confident you could get 10-20K via serial access on the C64/C128. > doing the ATA protocol through 16-bit shift registers and latches, I'd > be very lucky to see 100 bytes/second, along with the extra cost and > effort it'd take to make that interface (more than $5..) I dunno, the ATA protocol is not that heavy. Speaking as someone who implemented it on the AVR, I don't think it would affect the speed that much. As for cost, it looks like a pair each of the serial/parallel ICs is only USD$2.40. At the top end of your price range, I'd recommend buying a AVR ATMEGA168 and a '574 for the IDE port (USD$4.52 + USD$.40). You could then drop FatFs on the AVR and talk to the AVR from the user port using higher level commands. A printer port connector and a '125/'245 would create a simple parallel port programmer for the AVR. Jim
From: Jim Brain on 3 Feb 2010 14:02 On 2/2/2010 3:15 PM, Chris Baird wrote: > I'm thinking two 74245's and a 74139... I'd be interested in seeing the schematic, as I can't see a way to do IDE without at least 1 latch. (Well, I suppose if you're willing to only use the bottom 8 bits of each word of storage). > It's apart of a generic 6502 group effort (SYM-1, CBM, Homebrew), so > there's not much point designing around the 6526. Even IRQs are off the > spec. That's good information, but in my defense, you didn;t mention those design constraints before. > That's just making the whole thing more complicated and time-consuming > than it needs to be-- it's already been proven that it can be done 'with > scraps of wire' and portable software, plus the mass-storage needs to be > gotten out of the way so that other subprojects can go ahead. I would disagree there. Yes, an IDE interface can be created from nearly nothing, but if the design goal is to make this portable, the goal should include putting as little code as possible in the host. Many homebrew users would like to do something besides port a 4-8kB chunk of FAT code to their platform. Sure, the 6502 folks can probably just do a recompile, but what about the Z80 folks, the 6800/6809 folks, etc.? As well, some of the trainers had extremely limited RAM, so those folks would probably prefer something that kept many of the details away from them and their precious RAM. As a homebrew person, I can attest that if I wanted storage on my unit, and I was unwilling to build a controller of my own, I'd want something simple to use that I can attach to a PIO and be up and running in a few minutes. I don't want to fight with IDE command syntax and such. It sounds to me like the project is "find the least amount of HW that will allow an IDE interface using one PIO port and a bit of another. The smallest design I can theorize is 3 574s (one to hold the high incoming byte, one to hold the high outgoing byte, one to hold the address/CS lines/RESET line), and your '139 (unselected, load hi, read hi, Read, Write, Write CS/A2:0). The R/W would use the PIO port for the low byte, and the appropriate 574 for the high byte. That would give you IDE with 11 bits. I should point out that wiring will be a pain with that. In contrast, a uC approach uses the least wiring (bring IDE to uC, bring PIO to uC). I'm not saying the uC approach is best (some people would balk at wiring a uC to a trainer or a vintage machine, and that's a valid point). But, if the goal is quick assembly, full functionality, portability, and ease of use, I state the uC approach is a great fit. Jim
From: Chris Baird on 10 Feb 2010 03:50
> (Well, I suppose if you're willing to only use the bottom 8 bits of > each word of storage). 256 byte sectors makes it easier for the 6502, plus no-one on a 8-bit micro is going to miss 20GB on a 40GB laptop drive.. Alternatively, some? drives have a "8 bit transfer mode" Feature bit that I believe pushes the high-byte through the data0-7 lines. Filesystem note: with all that capacity to spare, there's no need to keep track of block allocation-- just use calculated allocations of 64kB for every file.. ("loadsectors(offset=directory_index*256,nsectors=filesize/256,startaddr)") > The smallest design I can theorize is 3 574s (one to hold the high > incoming byte, one to hold the high outgoing byte, one to hold the > address/CS lines/RESET line), and your '139 (unselected, load hi, > read hi, Read, Write, Write CS/A2:0). The R/W would use the PIO port > for the low byte, and the appropriate 574 for the high byte. That > would give you IDE with 11 bits. Additonal design constraint: the parts have to be available from the only half-assed electronic retail store here :/ (Jaycar) .. No 574s, only 573s. Your description is functionally the same as what I came up with: (2x 573s, 245, 139): http://www.twitpic.com/12d0bj -- Chris |