XU1541 and more USB stuff
in [Commodore]
|
From: Jim Brain on 25 Jan 2008 16:47 Peter Schepers wrote: > 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. I can vouch that is what I understood. Reasons: o It did make a minor mention about a flexible format and flexible track lengths, but then spent a great deal of time talking about a maximum track size, including a sub discussion on the 3% margin added. o If the track length was truly changeable within a drive family, I wondered why all of the participants spent so much time figuring out how much length was needed for a 300RPM drive writing at the fastest rate on the longest track. It seemed like, if the number could change per X64 image, the image maker would simply dump the track data to a temp data store, keep a tally on the maximum number of bytes read per track, and use that value in the track-length field. That would always be correct and would not need to worry about tacking on an experimental 3% margin. > 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? Or, put the track length as part of the record pointers at the beginning: ERRLO,ERRHI,DATALO,DATAHI,LENLO,LENHI > 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? That was my question as well. If a bunch of really smart people got their heads together to figured out 7928 (which sounds very specific, unlike 8000, or 8192), then it must truly be an upper bound. If you decide to bump it up, I vote for 8192, which would be eaiser to handle math-wise.
From: Wolfgang Moser on 26 Jan 2008 03:16 Hi Peter, Peter Schepers schrieb: > Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: >> 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. well, for me, as I was into the details beginning from the first discussions about a GCR format back in the late 1990'ties, I really seem to have difficulties to understand the recipient's understanding of the G64.txt doc. > 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. Indeed it is really useful for a certain software implementation of a G64 image reader. If someone wants to allocate a two dimensional _array_ of tracks instead of successively allocating a list of vectors of tracks, he would need that maximum size value to correctly declare dimensions (number of track stored in image and maximum track size). This saves for a two-step parsing of all the descriptors of the file to find the max value. Maybe there was another reason once, but for me it's simply some useful redundancy. > 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? You don't want to mess up with the don't-waste-my-bytes-people, do you? Once there were big discussions, if the G64 format shoudl include compression, single compressed tracks, smart GCR specific encoding/compression techniques to save as much space as possible. > 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 Peter, I don't know, if this sections is new, you mention some tables with track sizes and MNib track sizes. The is one column named "Tail GAP". What do even and odd sectors mean here? I never seen a disk where _every_ inter-sector GAP is at 19 bytes, when every even inter-sector GAP is at only 9 bytes. In fact every inter-sector GAP is at 9 bytes, but for the last sector, which I call the track tail GAP. Maybe you want to have a deeper look into the MNib dump source to verify that. Womo
From: Kris Vorwerk on 27 Jan 2008 23:19 > > (though the new BFI mode will make regular flash more usable). Actel > > has flash based FPGA, and theActelparts are much easier to generate > > power supply rails for. The Xilinx parts all have difficult power > > rail requirements, and strict power sequencing that makes design > > difficult. > > I think Xilinx and Altera parts are used due to their free tools being > available. Minor aside: Actel also makes a version of its tools available for free download and use. (AFAIK, it comes with Modelsim, Synplify, and supports programming up to the mid-size Flash devices.) c.f., http://www.actel.com/techdocs/litrequest/default.aspx http://www.actel.com/products/software/libero/licensing.aspx
From: Peter Schepers on 28 Jan 2008 09:04 In article <fneq92$lrb$1(a)vs5413.vserver4free.de>, Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: >Hi Peter, > >Peter Schepers schrieb: >> Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: >>> 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. > >well, for me, as I was into the details beginning from >the first discussions about a GCR format back in the >late 1990'ties, I really seem to have difficulties to >understand the recipient's understanding of the G64.txt >doc. It's hard to make yourself an objective observer when it was subjective. Since I wasn't involved in G64's creation I can try to be objective. even for me it's not always easy. >> 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. > >Indeed it is really useful for a certain software >implementation of a G64 image reader. If someone wants >to allocate a two dimensional _array_ of tracks instead >of successively allocating a list of vectors of tracks, >he would need that maximum size value to correctly >declare dimensions (number of track stored in image and >maximum track size). Now who in their right mind would hold the image in memory? In reality, all you need to do is read the real track size preceeding each track data stream, dynamically allocate that + small overrun buffer and you should be fine. Like a disk drive, you are only working on a single track at a time. You allocate memory for only one track, only when you read it, and only the size you need. >This saves for a two-step parsing of all the descriptors >of the file to find the max value. Maybe there was >another reason once, but for me it's simply some useful >redundancy. Why do you need to know the maximum? You should only need to know what you are working with at that specific track. That's the point I am trying to make. If indeed the 7928 is only a "glass ceiling" then either not use it or bump it up a bit more to be all inclusive. Obviously the VICE authors thought it was a hard value as someone said images with values other than 7928 won't work. This means either their understanding was flawed or the write-up I provided wasn't clear enough and, like Jim, they thought it was indeed the "max" value. >> 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? > >You don't want to mess up with the >don't-waste-my-bytes-people, do you? Once there were >big discussions, if the G64 format shoudl include >compression, single compressed tracks, smart GCR >specific encoding/compression techniques to save as >much space as possible. Silly argument especially when G64 is not prevalent enough to worry about unused space. I couldn't care less about those that complain about wasted space... bring em on! Compression would only make dealing with G64, especially interactive read/write, very difficult. Since you brought it up, I find the max value defined _creates_ much wasted space as most disks never reach that maximum so you end up with a lot of extra padding bytes for each track, especially the higher tracks. Why not deal with that loss? >Peter, I don't know, if this sections is new, you >mention some tables with track sizes and MNib track >sizes. The is one column named "Tail GAP". No, it's been there since the earliest writeups. >What do even and odd sectors mean here? >I never seen a disk where _every_ inter-sector GAP >is at 19 bytes, when every even inter-sector GAP is >at only 9 bytes. >In fact every inter-sector GAP is at 9 bytes, but >for the last sector, which I call the track tail GAP. > >Maybe you want to have a deeper look into the MNib >dump source to verify that. Nope. This, if I remember correctly, is taken from two sources: Inside Commodore DOS and using MNIB on my original factory disks several years ago while decoding F64. I'm not going to setup the Commodore equipment just to re-verify what I originally found and wrote up. PS.
From: Peter Schepers on 28 Jan 2008 09:12
In article <fneq92$lrb$1(a)vs5413.vserver4free.de>, Wolfgang Moser <wn0612(a)d81.de.invalid> wrote: > >This saves for a two-step parsing of all the descriptors >of the file to find the max value. Maybe there was >another reason once, but for me it's simply some useful >redundancy. I forgot to address this. The header max track size is not a redundant value. The header value of 7928 is fixed and not representative of the real tracks stored in the image. The individual track sizes are virtually always less than the max. Thus my argument against the very need of the header value. It seems specious at best. PS. |