XU1541 and more USB stuff
in [Commodore]
|
From: BruceMcF on 25 Jan 2008 14:04 On Jan 23, 11:50 pm, BruceMcF <agil...(a)netscape.net> wrote: > 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? EG: MAX3421E http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639
From: Wolfgang Moser on 25 Jan 2008 13:55 Hello Peter, Hi Jim, Peter Schepers schrieb: > In article <t27mj.47$yE1.3(a)attbi_s21>, Jim Brain <brain(a)jbrain.com> wrote: >> Wolfgang Moser wrote: >> >>> Since V-Max! disks were recorded at drives spinning with >>> around 297,5RPM, the track size increases. WIthin the same >>> time frame (one disk revolution) at lot more byte can be >>> written to disk at a given bitrate. That's why you often >>> see more than 8000 Bytes per track, when dumping such >>> V-Max! disks. >> It sounds like the doc needs to be updated. not really, since the doc mentions: 000A-000B: Maximum track size in bytes in LO/HI format sooo, if one wants, he could make a track size of 65535 bytes within the image. If this would make sense ;-) > Hows this sound for the paragraph you quoted: > > "Second, the maximum track size is not a fixed value but depends on the > type of disk that is contained with the G64. Non-1541 images such as > SFD1001 or 8050 could make the track size larger or smaller. For 1541 > images, which are about the only ones in existance, the typical track size > is 7928 bytes. This value is determined by the fastest write speed > possible (speed zone 0), coupled with the average rotation speed of the > disk (300 rpm), and assuming normal Commodore GCR data formatting. After > some math, the answer that actually comes up is 7692 bytes. Taking into > account a rotation speed safety adjustment of -3%, which would allow more > data to be written, and some rounding, 7928 bytes per track was arrived > at. Note that imaging non-standard GCR disks such as V-MAX can result in > GCR tracks over 8000 bytes, but these are rare." > > Does this make things better? I've also made a few other smaller changes. I think it make things a bit betterr since now every reader does clearly recognize that the track size of non-fixed nature. Womo
From: Suudy on 25 Jan 2008 14:30 On Jan 25, 11:04 am, BruceMcF <agil...(a)netscape.net> wrote: > On Jan 23, 11:50 pm, BruceMcF <agil...(a)netscape.net> wrote: > > 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? > > EG: MAX3421Ehttp://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639 This option is intriguing as well. Using something like the ATmega with this SPI interface could provide for a cheaper solution. If you can get away with a bare-bones ATmega part coupled with this Maxim part, could make for a much simpler system. However, the package is QFP, which stinks for soldering. But so is the AT90USB and the UC3A/UC3B. And since we have to solder a surface mount part anyways, going with less parts would be better. And since the AT90USB runs about the same price as an ATmega (some of them), I think this is a better option. Just my $0.02. Pete
From: Peter Schepers on 25 Jan 2008 15:27 In article <fndbb4$stc$1(a)vs5413.vserver4free.de>, Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: >Hello Peter, Hi Jim, > >Peter Schepers schrieb: >> In article <t27mj.47$yE1.3(a)attbi_s21>, Jim Brain <brain(a)jbrain.com> wrote: >>> Wolfgang Moser wrote: >>> >>>> Since V-Max! disks were recorded at drives spinning with >>>> around 297,5RPM, the track size increases. WIthin the same >>>> time frame (one disk revolution) at lot more byte can be >>>> written to disk at a given bitrate. That's why you often >>>> see more than 8000 Bytes per track, when dumping such >>>> V-Max! disks. >>> It sounds like the doc needs to be updated. > >not really, since the doc mentions: > > 000A-000B: Maximum track size in bytes in LO/HI format > >sooo, if one wants, he could make a track size of 65535 >bytes within the image. If this would make sense ;-) When I re-read the original doc, as Jim saw it, I realized that except for some minor mention that the size really isn't fixed, it appeared to be fixed for 1541 at 7928. This maximum track size value is causing me some grief as I'm trying to understand why it is necessary. I can see it would be useful for a program to know what the max size of _any_ track is when working in a G64. I can see that you would need to set aside enough space in the file so that you can safely modify a G64 track and not worry about wrapping around over other data if the track's too small. But could you not have simply told people to use the track size value stored at the beginning of the track data stream? Also, since you know that V-MAX tracks can exceed this value, should or could we not change the 1541 default up a bit, say 8100 bytes? Surely this would encompass all possible track sizes? How does MNIB create it's G64's? Does it use the hard-coded 7928 byte track size as well? >> Does this make things better? I've also made a few other smaller changes. > >I think it make things a bit betterr since now every >reader does clearly recognize that the track size of >non-fixed nature. Well, I re-worked it many more times since I posted it, so it would be best if you read the doc again: http://ist.uwaterloo.ca/~schepers/formats/G64.TXT PS.
From: BruceMcF on 25 Jan 2008 16:05
On Jan 25, 2:30 pm, Suudy <pet...(a)mudplace.org> wrote: > On Jan 25, 11:04 am, BruceMcF <agil...(a)netscape.net> wrote: > > > On Jan 23, 11:50 pm, BruceMcF <agil...(a)netscape.net> wrote: > > > 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? > > > EG: MAX3421Ehttp://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639 > > This option is intriguing as well. Using something like the ATmega > with this SPI interface could provide for a cheaper solution. If you > can get away with a bare-bones ATmega part coupled with this Maxim > part, could make for a much simpler system. > > However, the package is QFP, which stinks for soldering. But so is > the AT90USB and the UC3A/UC3B. And since we have to solder a surface > mount part anyways, going with less parts would be better. And since > the AT90USB runs about the same price as an ATmega (some of them), I > think this is a better option. > > Just my $0.02. > Pete As always, I'm really looking in terms of the User Port of a real C64, and am still intrigued by the possibility of a User Port <-> SPI interface. There is very cheap flash RAM that runs on SPI, SD/MMC of course, and the MAX RS232 UART and USB parts. Permanent flash memory, portable flash memory, fast serial, and USB ... and the cartridge port is still clear. |