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
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
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.
> 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
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
>> 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
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 :-(
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/
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:
"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?
From: christianlott1 on 24 Jan 2008 13:14
old thread that may still be of interest: