XU1541 and more USB stuff
in [Commodore]
|
From: Peter Schepers on 24 Jan 2008 19:06 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. 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. PS
From: Pete Rittwage on 24 Jan 2008 21:39 Jim Brain wrote: > 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 Keep in mind that the current implementation of VICE only works with 7928 byte tracks. You can specify in the header another size, but it is ignored and will crash when mounting the image. I believe CCS and HOXS parse the header correctly, so they will use larger or small sized tracks as defined. -- - Pete Rittwage http://rittwage.com C64 Preservation Project http://c64preservation.com
From: Peter Schepers on 25 Jan 2008 09:37 In article <g%6mj.1710$v.908(a)attbi_s22>, Jim Brain <brain(a)jbrain.com> wrote: >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. OK, I've updated G64, and a few other formats, on my web site http://ist.uwaterloo.ca/~schepers/formats.html Anything dated past May 2007 is a new version. I've also bundled the entire updated collection on the downloads page in formats.zip. I find it interesting that the knowledge about V-MAX, and possibly other, oversize tracks was known to some, and the G64 writeup has been around for several years, but no one contested the description of the track size value until now. The way the original discussions went did make it sound like the 7928 byte count was fixed on the 1541 so the writeup was done accordingly. At least that fallacy is corrected now. PS.
From: Jim Brain on 25 Jan 2008 10:25 Peter Schepers wrote: > http://ist.uwaterloo.ca/~schepers/formats.html Thanks for the link. I've been thinking about image formats for non 1541 disks, and I had no idea CMD Native Partitions and such were already supported. It looks like 1 codebase could be used for D64,D71,D80,D82 formats, but D81 needs a special handler and the CMD one is a superset. If one wanted to emulate an entire CMD HD Native Partition, would D2M DNP be extendable to support a 16MB partition? Jim
From: Peter Schepers on 25 Jan 2008 11:04
In article <Dbnmj.1146$yE1.780(a)attbi_s21>, Jim Brain <brain(a)jbrain.com> wrote: >Peter Schepers wrote: > >> http://ist.uwaterloo.ca/~schepers/formats.html >Thanks for the link. I've been thinking about image formats for non >1541 disks, and I had no idea CMD Native Partitions and such were >already supported. > >It looks like 1 codebase could be used for D64,D71,D80,D82 formats, but >D81 needs a special handler and the CMD one is a superset. > >If one wanted to emulate an entire CMD HD Native Partition, would D2M >DNP be extendable to support a 16MB partition? DNP is for the 16Mb partitions. D2M is a container for DNP and emulated partitions. PS. |