XU1541 and more USB stuff
in [Commodore]
|
From: Jim Brain on 22 Jan 2008 01:22 Simon Scott wrote: > On Mon, 21 Jan 2008 18:43:11 +0000, Jim Brain wrote: > >> It does exist, but political infighting or something made the original >> author grow uninterested in the project. At the beginning of the year, > > Political in-fighting concerning the production of a cable to connect an > antique disk drive to a PC? > > Now I have, literally, heard everything. I may have taken some liberties. I wasn;t following the cable closely, but it was a serious concern for a few months early in the year, then it died down. I assumed the cable was done, so I was surprised to see the announcement. Later responses spoke of boards not paid for, lack of direction, etc. It's all in the archives. I am on other things, but VIP (Virtual IEC Peripheral) is still sitting here, waiting for me to fix the IEC routine bugs). It's next on my list after uIEC finish (I'm working on that now). THough, VIP goes the other way (64 to PC, like a 64HDD cable, but over serial port (and soon USB, once the other pieces are in place) All I can say is: Do *NOT* underestimate the effort of handling the IEC routines. The basic stock routines are tricky enough, though you can get them down by poring over the PRG and having a logic analyzer to check the corner cases. But, speeders like JiffyDOS and others are a whole new ball game. Jim
From: Suudy on 22 Jan 2008 09:10 On Jan 21, 10:22 pm, Jim Brain <br...(a)jbrain.com> wrote: > I may have taken some liberties. I wasn;t following the cable closely, > but it was a serious concern for a few months early in the year, then it > died down. I assumed the cable was done, so I was surprised to see the > announcement. Later responses spoke of boards not paid for, lack of > direction, etc. It's all in the archives. I'm glad you mentioned the archives. When I signed up for the OpenCBM list, I signed up for opencbm-users, and I couldn't find reference to this. Now of course, I found the opencbm-devel, where I subscribed. > I am on other things, but VIP (Virtual IEC Peripheral) is still sitting > here, waiting for me to fix the IEC routine bugs). It's next on my list > after uIEC finish (I'm working on that now). THough, VIP goes the other > way (64 to PC, like a 64HDD cable, but over serial port (and soon USB, > once the other pieces are in place) The VIP sounds like something I have been interested in doing also. And the hardware for the VIP and the cable idea I am working on could easily do both with different firmware (or modes in the firmware). And it could be USB instead of serial. What is the uIEC? > All I can say is: > > Do *NOT* underestimate the effort of handling the IEC routines. The > basic stock routines are tricky enough, though you can get them down by > poring over the PRG and having a logic analyzer to check the corner > cases. But, speeders like JiffyDOS and others are a whole new ball game.. The implemention of the serial protocol is a concern of mine. And implementing it on something fast and plentiful on resources would allow for a lot of flexibility. I don't know how well understood the protocol is--even amongst hobbiest "experts"--or how well documented it is. I hope, though, that the PC-->USB-->1541/71 would be significantly easier than the C64-->USB-->PC would be.
From: Jim Brain on 22 Jan 2008 16:21 Suudy wrote: > The VIP sounds like something I have been interested in doing also. > And the hardware for the VIP and the cable idea I am working on could > easily do both with different firmware (or modes in the firmware). > And it could be USB instead of serial. Yes, it could. TO reduce the variables, I chose serial first, knowing that once the protocol was solid, it would be an easy thing to add USB support. > > What is the uIEC? IEC to CompactFlah and IDE. > The implemention of the serial protocol is a concern of mine. And > implementing it on something fast and plentiful on resources would > allow for a lot of flexibility. I don't know how well understood the > protocol is--even amongst hobbiest "experts"--or how well documented The basic protocol is marginally documented, and none of the speeders are documentated officially at all. I have a JiffyDOS implementation that works (in so far that I have loaded and saved data with it), as does Unseen on the sd2iec project (his is in ASM, mine is C) Both of use used IEC2IEEE docs to create our implementations (and a logic analyzer) > it is. I hope, though, that the PC-->USB-->1541/71 would be > significantly easier than the C64-->USB-->PC would be. I think they are about the same. I suppose the advantage of your initial direction is the lack of need to watch for commands coming from the 1541. Jim
From: Suudy on 22 Jan 2008 18:20 On Jan 22, 1:21 pm, Jim Brain <br...(a)jbrain.com> wrote: > Suudy wrote: > > The VIP sounds like something I have been interested in doing also. > > And the hardware for the VIP and the cable idea I am working on could > > easily do both with different firmware (or modes in the firmware). > > And it could be USB instead of serial. > > Yes, it could. TO reduce the variables, I chose serial first, knowing > that once the protocol was solid, it would be an easy thing to add USB > support. Is the protocol work on the VIP already in the XU1541 or other X1541 related programs? If not, will it be available for porting to such? > > What is the uIEC? > > IEC to CompactFlah and IDE. Another excellent candidate for an embedded system. Though the CF (I assume you mean CF in IDE mode) interface is not something natively supported on many "easy to use" microcontrollers. ST has a part (the ST7265x) that has a native CF interface, though it lacks support for external memory, and is limited to 32K of flash and 5K of RAM. And Atmel actuall has a variety of 8051 based solutions. An interesting one is the AT80C51SND1C which has the CF/IDE interface and a USB controller. Again, limited in flash and RAM (64K + 4K boot and 2K, respectively), and lots of useless stuff (an MP3 decoder and PCM audio interface). (Reading a bit deeper in the AT80C51SND1C datasheet, it mentions support for external memory. There is no automatic chip- select generation, but this can be done via GPIO if the accesses aren't totally automatic, or via some external address decode (a CPLD?). Also the RD/WR for this memory is shared with the CF/IDE IORD/ IOWR lines. Perhaps not a problem if chip-selects are done via GPIO.) The reason I throw all these options out is that there could be a single board to meet a variety of needs. Basically a uC, an IEC port, a USB port, and a CF/IDE interface. Heck, throw in an SPI interface and you have support for SD cards as well. The trick is to find a single uC that supports USB, CF/IDE, SPI (and possibley MMC) with the lots of flash and ram (or at least support for external memory). Then just a PCB with the processor and stuffing options for all the connectors--possibly all of them--and we can do all the work on a single board. Of course, one could always bit-bang the CF/IDE interface.... > > The implemention of the serial protocol is a concern of mine. And > > implementing it on something fast and plentiful on resources would > > allow for a lot of flexibility. I don't know how well understood the > > protocol is--even amongst hobbiest "experts"--or how well documented > > The basic protocol is marginally documented, and none of the speeders > are documentated officially at all. > > I have a JiffyDOS implementation that works (in so far that I have > loaded and saved data with it), as does Unseen on the sd2iec project > (his is in ASM, mine is C) Both of use used IEC2IEEE docs to create our > implementations (and a logic analyzer) The sd2iec looks interesting, as well as the 1541 Ultimate. Both of which are interesting projects in themselves as well. I notice that often there is mention of limitations on all of these cables because of memory and/or processing power. This is making me question the suitability of using a simple 8-bit microcontroller for this development. Perhaps the UC3B is the best option. With the SPI interface, it can support SD cards. And (perhaps) the 32K of internal RAM would be sufficient (though external memory access would be a boon). And looking more closely at the UC3A, it appears to be more feature rich. It has up to 64K of internal RAM, support for external SRAM and SDRAM (a whopping 16MB for $2). It also has USB, an ethernet MAC(!), and SPI (for those SD cards). The static memory controller looks to be configurable and could directly support the CF/IDE interrface. And it runs up to 66MHz. Certainly a more complex device, but a device with much more flexibility. Pete
From: Jim Brain on 22 Jan 2008 18:58
Suudy wrote: > Is the protocol work on the VIP already in the XU1541 or other X1541 > related programs? If not, will it be available for porting to such? No, as the XU1541 was for the other direction. I've got the docs around here, but I was still working on the protocol. > Another excellent candidate for an embedded system. Though the CF (I Which describes the uIEC (www.jbrain.com/vicug/gallery/uIEC) It uses an ATMEGA128 uC for all the heavy lifting, with an option for the external memory (but not required). All of the hardware is finished, and SW is coming along nicely this week (FAT12/16/32/LFN support working for read and write, integrating the IEC routines and adding the CMD HD-style subdir support is progressing) I was working on my own FAT16/32 LFN library, but I recently found FatFs which did all of the pieces I had yet to do (cluster chaining, etc.), so I added LFN support to FatFs and modified it so it can use a single 512 byte buffer for all disk accesses. It works for IDE, CF, and MMC/SD, which is the target peripherals for uIEC. FatFs requires 512 bytes for FS/FP buffer, 256 bytes for LFN name, leaving 3.25K free on M128. LEaving some stack room (512-1K), that leaves room for 9 256 byte buffers, and removing 1 256 buffer for Channel 15 leaves 8 buffers for channels, more than the 1541. > The reason I throw all these options out is that there could be a > single board to meet a variety of needs. Basically a uC, an IEC port, > a USB port, and a CF/IDE interface. Heck, throw in an SPI interface > and you have support for SD cards as well. The trick is to find a > single uC that supports USB, CF/IDE, SPI (and possibley MMC) with the > lots of flash and ram (or at least support for external memory). Then > just a PCB with the processor and stuffing options for all the > connectors--possibly all of them--and we can do all the work on a > single board. Well, MMC/SD is easy, as SPI is most often available. When i finish uIEC and VIP, I intend to roll a new board with the AT90USB1287. My code will move nicely, and USB is built-in. The cost is $1 more than the M128/M1281. > Of course, one could always bit-bang the CF/IDE interface.... Which is what I am doing. PIO mode 1 is 3.3MB/sec, far faster than any C64 variant I am aware of. > The sd2iec looks interesting, as well as the 1541 Ultimate. Both of > which are interesting projects in themselves as well. The 1541 Ultimate is in a class by itself. But, we need to look at pricing. sd2iec is dirt cheap (M32 and a MMC/SD port). $50-$75 is the uIEC target. U1541 is $150 or so. With some work, I think uIEC and sd2IEC/mmc2iec can share a codebase, as they are so much alike. That would give the modder a tiny package, leaving cash for a single Ultimate purchase. > I notice that often there is mention of limitations on all of these > cables because of memory and/or processing power. This is making me > question the suitability of using a simple 8-bit microcontroller for I suppose, but the M32/M128 have plenty of HP for MMC/SD/IDE/CF purposes. USB might be a stretch, I don't know. Truly, though, if one wants to go after more, I think you either need to go the 1541 ultimate approach and make a 1541 compliant system, or go with a processor fast enough to emulate the 1541 is SW. By the time you get there, you're probably way over the pricing sweet spot. If you're looking to solve your own problem, a larger unit is probably best. But, if you're looking to re-use code and possibly share a codebase, I'd highly recommend an AVR8 derivative with USB. External RAM is easy to add for plenty of room, SPI is there, and you can re-use the SD2IEC or uIEC IEC routines wihtout having to re-invent the wheel. FatFs is already ready to go and is used in both projects, if that is of interest. For my part, I have been looking at the sd2iec codebase, to see where there is overlap. Jim |