Ed Eastman wrote: >Michael J. Mahon wrote: >> Actually, the standard DOS physical formatting is sectors in >> physical sector order, from 0 to 15 around the track. > >Pull up a nibble editor and read a track, which will read all the bits >in a circle in one sequence. Then examine the physically adjascent >sectors and how they are numbered. >I< have never seen a track where >the physical sectors are numbered sequentaily. If DOS does >'interpretation' of physical sectors, that is news to me. (OK, I've had a chance to review the documentation and examine some disks. Up until now I've been going on memory... ;-) Check your nibble editor again. "4+4" encoding of sector numbers is a bit non-intuitive, so that may be clouding the issue. In "4+4" code, the sector numbers are: 0 = AA AA 1 = AA AB 2 = AB AA 3 = AB AB 4 = AA AE 5 = AA AF 6 = AB AE 7 = AB AF 8 = AE AA 9 = AE AB A = AF AA B = AF AB C = AE AE D = AE AF E = AF AE F = AF AF and they appear in this order in a nibble editor track image for both DOS 3.3 and ProDOS. (Of course, if your nibble editor doesn't analyze the track and align with track start, the sequence may be "precessed" rotatinally.) >SO if DOS interprets physical sectors with logical numbers instead, how >is it that a nibble editor and sector editor can pull up the physical >sector and not 'get' lost in translation? For specific referecne, waht >about track $11 where each sector references teh next and is in order >when viewed with utilities that interpret physical sectors and do not >'translate'? Nibble editors allow you to view tracks, and any "sector" interpretation is provided by the viewer--either a human or an "analysis" routine in the nibble editor. How the address marks are "translated" into physical (usually) or logical sector numbers is an OS-dependent convention. Sector editors apply the convention of the host OS (unless they are cross-OS editors ;-) to access _logical_ sectors, not physical sectors. Of course, all sector numbers in file system structures on disk will be in terms of the logical sector/block numbering applied by the OS, and will have nothing to do with physical sector numbers. Such is the power of abstraction. >No Apple II disk access routine can determine a physical location on an >Apple II disk. The reference hole is not used to determine start of >track, The tracks beginning starts at a 'random' location. When a >sector read occurs, RWTS reads bytes from the track sequentially until >it finds a sector header then decodes the sector number. If it is the >sector it is looking for, it continues reading and decodes the sector's >data, otherwise it conrinues to look for another header. Of course. The physical sectors I have been referring to are the sector numbers as coded in the address fields on the track. I have said nothing about counting physical sectors from some absolute rotational reference. However, the physical sectors are written consecutively on the track in strict ascending order if the disk was formatted by DOS 3.3 or ProDOS. Other formatters may, at their peril, employ some physical interleave structure when formatting, but not the standard Apple formatters. (I haven't checked any other 5.25" formatters, but would be surprised to find a non-consecutive one used routinely.) > From my experience, the skewing is physical layout, at no time if you >ask RWTS for sector 5 will you get somehting other than the data with a >sector header labeled as sector 5, regardless of where it is on the >circle of the track. No. Physical skewing of 5.25" Apple disks is rare--perhaps used in some copy-protection schemes...? Bag of Tricks has a program (INIT?) that permits re-formatting individual tracks of a 5.25" disk, and. IIRC, allows physical skew to be applied, but this is of little practical value and seldom used. If you ask the DOS 3.3 RWTS for sector 5, it will translate it to physical sector 5 (sectors 0, 5, and A are the only three for which logical = physical) and then access that sector. A more illustrative example would be an access to logical sector 1 (the original poster's problem), which the DOS 3.3 RWTS will translate to physical sector D to complete the operation. Then when the OP's code uses the boot ROM to read two physical sectors, starting with 0, he will get the logical sector 0 that he expected, but the next sector loaded, physical sector 1, will not be what he intended--since it corresponds to logical sector 7. * * * In the interest of full disclosure ;-), I said earlier in this thread that the DOS 3.3 skewing allowed an average of two sectors to be read per revolution. That is incorrect. The "2 descending" skew that DOS 3.3 uses allows fractionally more than one sector to be read (in ascending order) per disk revolution (since the next logical sector comes just 14 sectors after the current sector, not 16, as would be the case if no skew were applied. The reason that this skew works better than that is that most disk read operations, like loading a file, proceed in reverse order, from the last logical sector back to the first. For this common case, every other sector could be read, in principle, providing for reading up to 8 sectors per rotation. The bad news is that the internal data copying of DOS 3.3 takes longer than one sector worth of time, so it usually has to wait more than a full rotation for the sector to reappear. It was this miscalculation that allowed several "turbo" DOS's to appear, which eliminated much of the copying of sector data so that the speedup the skew enabled could be realized. ProDOS replaces sector skewing with block-to-sector mapping that does much the same thing. However, it is optimized for sequential _ascending_ access, and was coded to avoid all unnecessary data copying. The result is that it reads a disk track in two rotations. The bad news is that whenever it re-writes a block in a file, it must read it first, causing ProDOS to write at a rate of about one block per rotation. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ "Jim Cullen" wrote in message news:c094014f.0405240649.6f234d88@posting.google.com... : mjmahon@aol.com (Michael J. Mahon) wrote in message news:<20040522140448.15636.00001668@mb-m14.aol.com>... : > I wrote: : > : > >Jim Cullen wrote: : > > : > >>So, If I use RWTS to write sector $07, then the boot ROM would read : > >>Physical $01? : > >>Then It should work... I hope. : > >>Can I assume that this table is true for every sector? Probably a : > >>dumb question! : > >>If I'm using portions of the Boot ROM code to read from the disk, to : > >>read sector $07, I would tell the code to read sector $01 instead and : > >>vice-versa? : > > : > >Exactly. : > : > Not exactly. ;-) I should have read your reply more carefully. : > : > The DOS 3.3 sector skew table ("2 descending"), documented : > in Beneath Apple DOS and posted here by Bill Garber, shows : > the following correspondence between physical and logical : > sector numbers: : > : > > Phys. / DOS 3.3 : > > ----------------- : > > 0 ------ 0 : > > 1 ------ 7 : > > 2 ------ E : > > 3 ------ 6 : > > 4 ------ D : > > 5 ------ 5 : > > 6 ------ C : > > 7 ------ 4 : > > 8 ------ B : > > 9 ------ 3 : > > A ------ A : > > B ------ 2 : > > C ------ 9 : > > D ------ 1 : > > E ------ 8 : > > F ------ F : > : > which means that to read _logical_ sector 7, you would tell : > the boot ROM code to read _physical_ sector 1. If this is what : > you meant in your post, then you got it right. : > : > However, to read logical sector 1, you would need to read : > physical sector D using the boot ROM code, so the "vice-versa" : > part of your statement is not correct. : > : > To summarize, to read logical sector x, look it up in the "DOS 3.3" : > column of the table and find the corresponding physical sector in : > the other column. : > : > If you are using RWTS to create a disk (as you no doubt are), do : > the reverse: to write physical sector x, look it up in the "Phys" : > column and find the corresponding logical sector to tell to RWTS. : Thanks! : I did it this weekend and successfully read sector 0 to 02 with the : boot ROM! : Using RWTS to write the tracks, I created a lookup table with the : logical order and indexed into it when putting the sector into the : IOB....worked like a charm. : So far I have my boot code in sectors 00 to 02 and a splash screen on : tracks 20-22... : no real reason to be so far out, but it helps me to hear what the : drive is doing. : : My boot code is incomplete, basically what I've done so far is I have : code to move the ROM code that I keyed in from $900 to $9600...(Using : old ROM code, because I have a GS....the GS ROM boot code jumps all : over to other banks $FF etc...!) I put an ArmMove routine at $A00 that : I pulled from Beneath Apple Prodos. : : When it boots, It moves the code and moves the head to ,I assume, Trk : $20....sounds like it anyway! Now all I have to do is actually read : and decode data! : My plan is to call the ROM code at $965C after I place the Trk and Sec : info into the zero page locations referenced by the ROM code (I'm sure : that the nibble trans table created by the boot ROM is still intact... : at least I didn't touch it.) I placed RTS into my ROM code to avoid : recalibrateing the head and resetting the zero page..... : : Does any of this make sense? Or am I really screwing the pooch!!! ;() : : Thanks for all the info! Jim, On the Bag of Tricks disk, there is a program called INIT, which allows you to adjust the SKEW Direction and Factor. The default is Descending-02, and you can change it to just about anything. Make it Ascending-01 to Descending-01. This is very similar to what they call Disk Interleaving. Also, good to hear that you were successful. There is hope for me yet. :) Bill @ GarberStreet Enterprizez };-) Web Site - http://garberstreet.netfirms.com Email - willy46pa @ comcast DOT net Change DOT to a dot to contact me --- This email ain't infected, dude! Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.678 / Virus Database: 440 - Release Date: 5/7/04