XU1541 and more USB stuff
in [Commodore]
|
From: Peter Schepers on 24 Jan 2008 13:41 In article <Nw4mj.314700$Fc.170799(a)attbi_s21>, Jim Brain <brain(a)jbrain.com> wrote: >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? That's my write-up. While there may be a slightly newer version, the 7928 bytes only refers to images from the 1541 drive as those are the _only_ G64 files in existance (that I know of). You also didn't read the next paragraph. "Also note that this upper limit of 7928 bytes per track really only applies to 1541 (and compatible) disks. If this format were applied to another disk type with more sectors per track (like the SFD1001 or the 8050), this value would be higher." --------------------------------------------------------------------------- Peter Schepers, | Author of : 64COPY, The C64 EMU file converter Info Systems & Technology | http://www.64copy.com University of Waterloo, | My opinion is not likely that of the Waterloo, Ontario, Canada | University, its employees, or anybody (519) 888-4567 ext 36347 | on this planet. Too bad!
From: Wolfgang Moser on 24 Jan 2008 14:47 Hello Jim, Peter, Peter Schepers schrieb: > In article <Nw4mj.314700$Fc.170799(a)attbi_s21>, > Jim Brain <brain(a)jbrain.com> wrote: >> Wolfgang Moser wrote: >>> 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 > > That's my write-up. While there may be a slightly newer version, the 7928 > bytes only refers to images from the 1541 drive as those are the _only_ > G64 files in existance (that I know of). that 7928 bytes-per-track size was the result of some theoretical calculations we made over here in c.s.c and in private discussions, do you remember? The 7928 value really relies on the fact that the soruce disk was _recorded_ at a drive revolution speed of 300RPM. As soon as that drive speed for the drive that is used to record a disk varies, the resulting track size does vary also. 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. Otherwise the track length descriptor field within the G64 spec/dataformat would not be needed. > You also didn't read the next paragraph. "Also note that this upper limit > of 7928 bytes per track really only applies to 1541 (and compatible) > disks. If this format were applied to another disk type with more sectors > per track (like the SFD1001 or the 8050), this value would be higher." Yes, to splice hair a bit, one may consider a V-Max! raw track as 1541-incompatible track format in a way that you need a very custom format routine to create such one. However, it's a bit mindless to expect a G64 track's size to be always of the size of 7928 bytes. Womo
From: Jim Brain on 24 Jan 2008 15:59 Peter Schepers wrote: > That's my write-up. While there may be a slightly newer version, the 7928 > bytes only refers to images from the 1541 drive as those are the _only_ > G64 files in existance (that I know of). I was not clear enough in my original note. G64 specifies 7928 bytes per track *for 1541 images*. Since we were talking about a 1541 project, I didn't think the additional information was relevant. > You also didn't read the next paragraph. "Also note that this upper limit > of 7928 bytes per track really only applies to 1541 (and compatible) > disks. If this format were applied to another disk type with more sectors > per track (like the SFD1001 or the 8050), this value would be higher." I read it, but as we are talking about 1541 images, it was redundant information. I guess if the goal here is to ensure everyone is acutely aware that G64 format itself does not specify track size in general and that one could use the G64 image for other drive types with other track densities, that is fine. However, as a practical matter, G64 1541 images are the only ones I have ever seen, and they are defined to be 7928 bytes (as per the writeup), so the OP should plan for at least that much RAM. Jim
From: Peter Schepers on 24 Jan 2008 15:54 In article <fnaq0g$h6d$1(a)vs5413.vserver4free.de>, Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: >Hello Jim, Peter, > >Peter Schepers schrieb: >> In article <Nw4mj.314700$Fc.170799(a)attbi_s21>, >> Jim Brain <brain(a)jbrain.com> wrote: >>> Wolfgang Moser wrote: >>>> 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 >> >> That's my write-up. While there may be a slightly newer version, the 7928 >> bytes only refers to images from the 1541 drive as those are the _only_ >> G64 files in existance (that I know of). > >that 7928 bytes-per-track size was the result of some >theoretical calculations we made over here in c.s.c and >in private discussions, do you remember? Yes, but that's not what Jim was asking about. From what I gathered, he was wondering why the value appeared to be set at 7928, like all G64 images must use this value, when that isn't the case. It also seemed as though he didn't read the paragraph following the one he quoted which explains more about the value. >The 7928 value really relies on the fact that the soruce >disk was _recorded_ at a drive revolution speed of 300RPM. >As soon as that drive speed for the drive that is used to >record a disk varies, the resulting track size does vary >also. > >Otherwise the track length descriptor field within the >G64 spec/dataformat would not be needed. Of course is needs to be there, we live in a real world not perfect. Not all 1541 disks adhere to the theoretical max of 7928 and G64 doesn't limit itself to 1541 drives. Another drive would have a different maximum track size. >> You also didn't read the next paragraph. "Also note that this upper limit >> of 7928 bytes per track really only applies to 1541 (and compatible) >> disks. If this format were applied to another disk type with more sectors >> per track (like the SFD1001 or the 8050), this value would be higher." > >Yes, to splice hair a bit, one may consider a V-Max! raw >track as 1541-incompatible track format in a way that you >need a very custom format routine to create such one. Maybe this needs to be mentioned in the docs. Spruce up the explanation of the track size, and how _some_ custom speeders can influence it as well as other drive models. PS.
From: Jim Brain on 24 Jan 2008 16:03
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. |