XU1541 and more USB stuff
in [Commodore]
|
From: BruceMcF on 23 Jan 2008 23:50 On Jan 22, 6:58 pm, Jim Brain <br...(a)jbrain.com> wrote: > 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. If the sd2iec can get to the MMC/SD via the standard mode 1 SPI, why not go for USB via an SPI-USB part?
From: Wolfgang Moser on 24 Jan 2008 11:13 Hello Jim, Jim Brain schrieb: > == 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. Nope, G64 does not specify a specific track size. There are fields reserved in the descriptor tables, where someone can specify how many bytes should be reserved to hold actual track data. When dumping VMax! you need a lot more space than only these 7928 bytes. Nevertheless 8192 bytes should be enough room to handle these protection reliably. > 32K > would be a boon, in case someone wants to MNIB 8050/8250/SFD1001 > disks, though I am not sure anyone would care. My favorite solution would be to follow the Burstnibbler routine, instead of dumping to a RAM buffer, directly transfering over a highspeed connection onto the destination cotnainer. With 1 GCR byte to transfer every 25/26 microseconds, this would result in a raw GCR data rate of 40 KiB/s. Am I a bit overoptimistic, when I say that a Fullspeed USB link should be able to handle this datarate for bulk transfers ??? >> 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. Well, same here... I got a small EZ-USB FX2 development board over here and then the AT90USBKey development board. But beside some blinkin' lights developments I did not manage to create some really usable stuff :-( Womo
From: Suudy on 24 Jan 2008 12:45 On Jan 24, 8:13 am, Wolfgang Moser <wn0...(a)d81.de.invalid> wrote: > My favorite solution would be to follow the Burstnibbler > routine, instead of dumping to a RAM buffer, directly > transfering over a highspeed connection onto the > destination cotnainer. > With 1 GCR byte to transfer every 25/26 microseconds, > this would result in a raw GCR data rate of 40 KiB/s. > Am I a bit overoptimistic, when I say that a Fullspeed > USB link should be able to handle this datarate for bulk > transfers ??? The throughput is there. But I think the issue with USB is latency. It takes a while for the transfer to start (I remember hearing something in the ms range), but once going, it is fast. Given that data comes off at a rate of 25uS, and assuming it takes 1ms for the transfer to start, that is only 40 bytes of data to buffer. So every 1ms, 40 bytes are transferred. More about this below. USB describes 4 types of transfers: control, interrupt, isochronous, and bulk. Of those, interrupt transfers are maybe the best option. Control is for control/status. Isochronous guarantees latency, but does not guarantee delivery (packets can be dropped). And bulk guarantees delivery but cannot guarantee latency. But even interrupt endpoints depend upon the host polling the device for interrupt status. This status can be specified in the endpoint descriptor, but at best this is 125uS for high-speed devices, and up to 1ms for low/full-speed devices. Now, if the host lives up to its commitment, we wouldn't need a lot of buffering. But this now requires coordinating the transfers from the drive with the USB interface. Not necessarily difficult, but a lot easier to buffer a full track, then blast it over using a bulk transfer. A great website for this stuff is: http://www.beyondlogic.org/usbnutshell/ Pete
From: Jim Brain on 24 Jan 2008 13:10 Wolfgang Moser wrote: > Hello Jim, > > Nope, G64 does not specify a specific track size. There Dunno, I took my information from here: http://unusedino.de/ec64/technical/formats/g64.html "At first, the defined track size value of 7928 bytes may seem to be an arbitrary value, but it is not. It is determined by the fastest write speed possible (speed zone 0), coupled with the average rotation speed of the disk (300 rpm). After some math, the answer that actually comes up is 7692 bytes. Why the discrepency between the actual size of 7692 and the defined size of 7928? Simply put, not all drives rotate at 300 rpm. Some can be faster or slower, so a upper safety margin of +3% was built added, in case some disks rotate slower and can write more data. After applying this safety factor, and some rounding-up, 7928 bytes per track was arrived at." Your name is listed on the contrib line at the top. Is there a newer version of the document? Jim
From: christianlott1 on 24 Jan 2008 13:14
old thread that may still be of interest: http://groups.google.com/group/comp.sys.cbm/browse_thread/thread/f89c49bd15a019fe/ |