XU1541 and more USB stuff
in [Commodore]
|
From: Suudy on 22 Jan 2008 20:44 On Jan 22, 3:58 pm, Jim Brain <br...(a)jbrain.com> wrote: > 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) Thanks for the website link. Nice projects! I used the ATmega2561 on a project for work (a drop-in replacement for the ATmega128L we had in a previous project). Given that this is doing all the IEC stuff pretty flawlessly, it sounds very doable. > 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. We used the FlashFile code from Priio (see https://www.priio.com/productcart/pc/viewCat_P.asp?idCategory=10) for our last project. It doesn't support FAT32, but it was a commercial product, and there is a fear of Microsoft patents on FAT32. It doesn't support AVR GCC, but we used ImageCraft anyways for the project. Heck of a lot easier than trying to write our own. > 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 FlashFile library we used was pretty light on the RAM end of things, but then we configured it to only allow 2 open files at a time. But it sounds like you have consumed about the same amount of space. The discussion of memory was more to address the nibbler aspect of such a project. A parallel cable would require more RAM in order to support reads of an entire track. Having the excess RAM also allows for significantly more buffering reducing the overhead of the USB interface--though latency may still be an issue. > > 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. That lines up well with what I am trying to do. Perhaps we can coordinate on the development of such a board. The AT90USBKEY is a great springboard for this development. Since all the GPIO ports are available as through-hole connectors, a simple breadboard development for the IEC interface could be done until a PCB is developed. > > 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. $150 for the the U1541? I can't find a website for the development, though I did find something here: http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm I can't figure out all the parts, but it appears to have an FPGA (and an accompanying platform flash), an Intel flash part, and (perhaps) some RAM/SDRAM. If I were to do this, I'd shy away from the Xilinx parts, since they require separate configuration prom/flash part (though the new BFI mode will make regular flash more usable). Actel has flash based FPGA, and the Actel parts are much easier to generate power supply rails for. The Xilinx parts all have difficult power rail requirements, and strict power sequencing that makes design difficult. The expense has to come from being Xilinx based. Not just the part cost ($38 for a Spartan3-1200!), but all the power regulation requirements, extra platform flash, then the external flash and RAM/ SDRAM. I'm not sure why all the external devices, like the flash and RAM/SDRAM, are required. Though I imagine they need code and data memory, and there probably aren't enough block RAMs available with the part they chose. Using a uC should be considerably less expensive, and going with a faster part (say a 50+MHz 16- or 32-bit uC) could accomplish the same. And RTL development takes a lot longer, and more tools, than to do than firmware. RTL development would get you closer to cycle accurate. And it allows implementations of actual 1541 parts in RTL. That's a plus. But the cost sure seems prohibitive. > > 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. The UC3A runs at 66MHz and goes for about $15. The AT90USB1287 goes for about $16. I think the UC3A could maybe handle the 1541 ultimate. And if you find a similar processor that doesn't have USB, etc, it probably goes for less. > 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. If a big chunk of the code is already in C, then it should be easy to port to any architecture. All that is needed is to write low-level drivers. And running something like FreeRTOS, allows direct access to the hardware, while running things like the USB driver in a separate task. Much easier than trying to coordinate code blocks, especially for something as timing critical as the IEC protocol.
From: christianlott1 on 22 Jan 2008 22:33 On Jan 22, 7:44 pm, Suudy <pet...(a)mudplace.org> wrote: > > $150 for the the U1541? I can't find a website for the development, > though I did find something here: http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm http://groups.google.com/group/comp.sys.cbm/browse_thread/thread/e88622f5ed6af619?hl=en#
From: Jim Brain on 22 Jan 2008 23:00 Suudy wrote: > We used the FlashFile code from Priio (see > https://www.priio.com/productcart/pc/viewCat_P.asp?idCategory=10) for > our last project. It doesn't support FAT32, but it was a commercial > product, and there is a fear of Microsoft patents on FAT32. It > doesn't support AVR GCC, but we used ImageCraft anyways for the > project. Heck of a lot easier than trying to write our own. Easier, but it would introduce a nasty dependency on what could otherwise be an open source project. That was a price I did not want to pay. Besides, adding LFN support was pretty easy, as I had alreayd done it once. > The discussion of memory was more to address the nibbler aspect of > such a project. A parallel cable would require more RAM in order to > support reads of an entire track. Having the excess RAM also allows > for significantly more buffering reducing the overhead of the USB > interface--though latency may still be an issue. Once the parallel interface is in place on the 1541, Mnib only requires a track's worth of RAM. 8kB of RAM would be large enough for a track buffer. Essentially, read a track, including all sync marks and others items, store to host, advance to next half track or next track, repeat process. Storing an entire disk in uC RAM is not needed. > That lines up well with what I am trying to do. Perhaps we can > coordinate on the development of such a board. The AT90USBKEY is a > great springboard for this development. Since all the GPIO ports are > available as through-hole connectors, a simple breadboard development > for the IEC interface could be done until a PCB is developed. That's fine. source for uIEC is available, although I've been working hard over the past week to get it into shape to publish. > I can't figure out all the parts, but it appears to have an FPGA (and > an accompanying platform flash), an Intel flash part, and (perhaps) > some RAM/SDRAM. If I were to do this, I'd shy away from the Xilinx > parts, since they require separate configuration prom/flash part > (though the new BFI mode will make regular flash more usable). Actel > has flash based FPGA, and the Actel parts are much easier to generate > power supply rails for. The Xilinx parts all have difficult power > rail requirements, and strict power sequencing that makes design > difficult. I think Xilinx and Altera parts are used due to their free tools being available. The Xilinx handles 6502/6522/drive electronics, while the Flash and the RAM are the ROM/RAM of the 1541, I would believe. But, FPGA is truly not my forte. I don't want to detract from the solution, as it's truly a wonder, but it is a bit expensive. sd2iec is probably at one end of the spectrum, while U1541 is at the other. > The UC3A runs at 66MHz and goes for about $15. The AT90USB1287 goes > for about $16. I think the UC3A could maybe handle the 1541 > ultimate. And if you find a similar processor that doesn't have USB, > etc, it probably goes for less. I always thought a fast ARM core could emulate a 1MHz machine, especially like a 1541/1571. Maybe that is the better mousetrap. Same functionality as U1541, but lower price. > If a big chunk of the code is already in C, then it should be easy to FatFs and the DOS, yes. IEC routines, no. They are hand tuned for the architecture. > for something as timing critical as the IEC protocol. Have a go at it. Jim
From: Suudy on 23 Jan 2008 12:11 On Jan 22, 8:00 pm, Jim Brain <br...(a)jbrain.com> wrote: > Suudy wrote: > > We used the FlashFile code from Priio (see > >https://www.priio.com/productcart/pc/viewCat_P.asp?idCategory=10) for > > our last project. It doesn't support FAT32, but it was a commercial > > product, and there is a fear of Microsoft patents on FAT32. It > > doesn't support AVR GCC, but we used ImageCraft anyways for the > > project. Heck of a lot easier than trying to write our own. > > Easier, but it would introduce a nasty dependency on what could > otherwise be an open source project. That was a price I did not want to > pay. Besides, adding LFN support was pretty easy, as I had alreayd done > it once. Oh, I wasn't suggesting a replacement. It was meant more as commentary on how it makes sense to get a library integrated, than coding from scratch. I agree that the Priio option doesn't make sense for a hobby project. > Once the parallel interface is in place on the 1541, Mnib only requires > a track's worth of RAM. 8kB of RAM would be large enough for a track > buffer. Essentially, read a track, including all sync marks and others > items, store to host, advance to next half track or next track, repeat > process. Storing an entire disk in uC RAM is not needed. In that case, a parallel cable solution needs 8K + firmware overhead. So probably 16k or so. And the AT90USB only has up to 8K of internal RAM. So in this case, it makes sense to make use of the external memory interface. And Jameco has 32Kx8 SRAMs for as cheap as $2, and they are cheaper than other sizes. > > That lines up well with what I am trying to do. Perhaps we can > > coordinate on the development of such a board. The AT90USBKEY is a > > great springboard for this development. Since all the GPIO ports are > > available as through-hole connectors, a simple breadboard development > > for the IEC interface could be done until a PCB is developed. > > That's fine. source for uIEC is available, although I've been working > hard over the past week to get it into shape to publish. I'm going to focus on getting the USB interface up and running, and perhaps do so simple digital I/O and see how that goes. Once I think the USB is working pretty well, I'll ping you about perhaps future development. > > The UC3A runs at 66MHz and goes for about $15. The AT90USB1287 goes > > for about $16. I think the UC3A could maybe handle the 1541 > > ultimate. And if you find a similar processor that doesn't have USB, > > etc, it probably goes for less. > > I always thought a fast ARM core could emulate a 1MHz machine, > especially like a 1541/1571. Maybe that is the better mousetrap. Same > functionality as U1541, but lower price. > > If a big chunk of the code is already in C, then it should be easy to > FatFs and the DOS, yes. IEC routines, no. They are hand tuned for the > architecture. By hand-tuned, do you mean they are also dependent upon the platform, not just the architecture? Are you dependent upon processor frequency, RAM/flash access times, etc? If only tuned to the processor architecture, then porting to the AT90USB should be pretty painless. > > for something as timing critical as the IEC protocol. > > Have a go at it. Baby steps. :) That is way out there. Perhaps a future project. Pete
From: Jim Brain on 23 Jan 2008 14:41
== Quote from Suudy (petela(a)mudplace.org)'s article > In that case, a parallel cable solution needs 8K + firmware overhead. > So probably 16k or so. And the AT90USB only has up to 8K of internal > RAM. So in this case, it makes sense to make use of the external > memory interface. And Jameco has 32Kx8 SRAMs for as cheap as $2, and > they are cheaper than other sizes. Yes, external RAM would be very useful. The target would be a track of G64 data, and G64 specifies 7928 bytes per track. 32K would be a boon, in case someone wants to MNIB 8050/8250/SFD1001 disks, though I am not sure anyone would care. > By hand-tuned, do you mean they are also dependent upon the platform, > not just the architecture? Are you dependent upon processor > frequency, RAM/flash access times, etc? If only tuned to the Mine are not so dependent on CLK freq, as they use timers, but I can't say for sd2iec. As well, I factored in calling latency when creating the timer values, so they would need to be tweaked for a different frequency. Note that the standard IEC protocol is frequency invariant, it's the speeder code I am talking about. External RAM will impose some additional delay, but I think a tweak is all that is needed. > Baby steps. :) That is way out there. Perhaps a future project. Preach to the choir. It unnerves me at times for folks to ask why I did PS/2 protocol or use RS232 for something when USB is here. Every project starts somewhere, and if you bite off too much, you never see success. Have a go with the 90USB and keep my email handy. Jim |