Reading disk sectors -- weirdness!

[ralphb]

I want to read disk sectors using PAB >0110 and DSRLNK >A. This kind of worked, after I moved my workspace out of harms way.

 

And yet, it wouldn't read beyond sector 0 for my sample disk. No matter which sector I put into >8350, I always got sector 0.

 

After much hair pulling, I discovered that the read routine won't work for disks with random data on them, i.e., for disks without a (partially) valid TI file system. After I fudged a plausible sector 0 it works like a charm.

 

So what's the magic ingredient -- the sector allocation table, disk geometry, number of AUs? And if reading sectors depends on sector 0, how is sector 0 read?

 

[Tursi]

I don't think I've ever heard that for the sector access functions ... it does need to be /formatted/...

 

I don't think I've ever tried on a disk with a random sector zero, but I don't remember ever hearing it seeking unnecessarily. Anyone else remember more?

[+InsaneMultitasker]

Sector IO generally requires two things: (1) a properly formatted disks with tracks and sectors readable (recognizable) by the controller and (2) a properly set up sector 0 showing the maximum sectors accessible.

 

Some sector 0 parameters play into the various IO functions, such as the "density" and "side" bytes. In most cases, the controller expects them to be set during its initial read of sector 0, also referred to as the VIB or volume information block. If your VIB shows 0 total sectors, you won't be able to access sector 1.

 

The DSR -must- provide for direct access to sector 0 in order to write the VIB following a format. Beyond that, it will try to access other sectors, though success depends upon the controller and its ability to find/recognize the sectors in the track, and your VIB settings.

[+Lee Stewart]

As @Tursi said, the disk needs to be formatted. Attempting to read a sector of a disk necessarily requires the controller to read the sector ID block at the controller level, if I read Thierry Nouspikel's information correctly—see TI disk controller information on Thierry Nouspikel's site. That means that the sector ID block must have been previously written by a formatting routine with the proper information for that sector. So, I would not expect subprogram 010h to succeed on an unformatted disk.

 

If the disk you are attempting to read by sector is, indeed, formatted, it puzzles me that you cannot read any but sector 0 without a “proper” VIB in sector 0. TI Forth does its normal block I/O via subprogram 010h and I am pretty sure I have successfully read/written TI Forth blocks from/to all sectors, with a totally invalid VIB in sector 0. [edit: Probably not! See posts #3 & #5.]

 

...lee

Edited August 28, 2015 by Lee Stewart

[+Lee Stewart]

H-m-m-m...It appears I was wrong about subprogram 010h not needing a valid VIB, at least in Classic99 running with the TI controller emulation (Type=3 in classic99.ini). Actually, Tim (post #3) ought to know. I just thought I remembered actually doing it without a valid VIB. My test overwrote sectors 0 – 3 with blanks—or, at least, attempted to. The process threw a disk error and then I could not read any sector on the disk.

 

...lee

[+InsaneMultitasker]

H-m-m-m...It appears I was wrong about subprogram 010h not needing a valid VIB, at least in Classic99 running with the TI controller emulation (Type=3 in classic99.ini). Actually, Tim (post #3) ought to know. I just thought I remembered actually doing it without a valid VIB. My test overwrote sectors 0 – 3 with blanks—or, at least, attempted to. The process threw a disk error and then I could not read any sector on the disk.

 

...lee

 

You should be able to write to sector 0 provided the track is not damaged. Once that happens, you may need to read sector zero, then the other sectors should be accessible. There are probably ways to get around the DSR's insistence on a valid VIB, though I don't know of any programs that have attempted to do so. Track hackers and track copiers bypass the DSR and do their own things

[ralphb]

Sector IO generally requires two things: (1) a properly formatted disks with tracks and sectors readable (recognizable) by the controller and (2) a properly set up sector 0 showing the maximum sectors accessible.

 

Thanks for the clarification (and to the others as well), that figures.

 

"Formatting a disk" could mean many things, and I assumed it referred to a low-level format, i.e., creating tracks, syncs, marks, CRCs, and stuff. Creating a filesystem on top would be a totally separate step, and not required for low-level sector access. At least that's how the Unix world sees it.

 

So what happens with the info in sector 0 once it's been read? Is it re-read for every single sector access, or cached (which would be quite difficult as there is no disk-changed event, is there?)

[Tursi]

As far as the TI goes, formatting the disk and creating the filesystem are the same step - I've never seen any tool that splits them up. Formatting includes filling in sector 0, and creating the filesystem is pretty much just zeroing sector 1 to indicate no files.

 

Looking at the DSR, it doesn't appear to be re-read for every sector access, but I think I'll defer to the Insane one on this one!

[+InsaneMultitasker]

As far as the TI goes, formatting the disk and creating the filesystem are the same step - I've never seen any tool that splits them up. Formatting includes filling in sector 0, and creating the filesystem is pretty much just zeroing sector 1 to indicate no files.

 

Looking at the DSR, it doesn't appear to be re-read for every sector access, but I think I'll defer to the Insane one on this one!

Deferrer!

 

I have never mapped out when each controller reads (or re-reads) sector zero. Certainly file IO that impacts the bitmap for sector allocation/de-allocation will access sector 0, as will some of the high level operations. Sector 0 is cached at different times, along with other information, which as you know is related to VDP disk buffer allocation and the 0x8370 pointer.

 

Ralphb: The file system is not "necessary" for direct sector IO. However, most DSRs constrain sector IO reads to the parameters found in sector 0. What I think you are looking for is a blind read/write routine that doesn't care how the disk was configured. The controllers generally do not allow that.

Edited August 28, 2015 by InsaneMultitasker

[ralphb]

Ralphb: The file system is not "necessary" for direct sector IO. However, most DSRs constrain sector IO reads to the parameters found in sector 0. What I think you are looking for is a blind read/write routine that doesn't care how the disk was configured. The controllers generally do not allow that.

 

Yeah, my use case doesn't require sector-level access without sector 0, it's just that I spent hours trying to get it to work this way as I didn't know this side condition. I've adapted my code now.

 

BTW, I snatched your DSRLNK routine from here. Would that be OK? Is there an "official" source for that routine as implemented by the E/A module? I also tried the version included in TurboForth, but as it's been cleverly tempered with I couldn't get it to work.

[+InsaneMultitasker]

 

BTW, I snatched your DSRLNK routine from here. Would that be OK? Is there an "official" source for that routine as implemented by the E/A module? I also tried the version included in TurboForth, but as it's been cleverly tempered with I couldn't get it to work.

 

The DSRLNK routine isn't mine. Honestly, I don't even recall where I first came across this particular version though if you inspect source code in the wild, many will contain a similar DSRLNK routine down to the names and labels. For disk access, this routine will satisfy most needs. The Smart Programmer series has some articles about DSRLNK and GPLLNK that may be of interest, though you don't need to go down that path unless you want to use the cassette tape or search grom for subprograms.

 

There is a more advanced DSRLNK that many of us worked on years ago. It added error checking for the 0x0A calls and made some other tweaks. You can probably find it in the SWPB Yahoo group mail history.

[RXB]

Would a Track Read be a better tool than Sector Read?

 

Could you do a track read without a sector map?

[ralphb]

Would a Track Read be a better tool than Sector Read?

 

That's an intriguing idea that might work around the issue of having a valid sector 0.

 

In my particular case, though, I actually need to deal with emulator disk images, which are sector based, so I cannot go the track route.

 

@InsaneMultitasker: I found the DSRLNK code in the Smart Programmer, which is ... terse!

 

Duh, and as I just noticed it's so clever it won't run in cart space, as it modifies itself. Well, no problem, dumbing stuff down is one of my specialities!

Edited August 31, 2015 by ralphb

[Willsy]

http://turboforth.net/source/Bank1/1-06-Blocks.html

 

The dsrlnk in TurboForth runs in cart space, since its a cartridge

[+Lee Stewart]

I use the Smart Programmer code in fbForth 2.0, which is copied from cartridge space to low RAM when fbForth starts up. You are welcome to the code.

 

...lee

[+InsaneMultitasker]

 

That's an intriguing idea that might work around the issue of having a valid sector 0.

 

In my particular case, though, I actually need to deal with emulator disk images, which are sector based, so I cannot go the track route.

 

@InsaneMultitasker: I found the DSRLNK code in the Smart Programmer, which is ... terse!

 

Duh, and as I just noticed it's so clever it won't run in cart space, as it modifies itself. Well, no problem, dumbing stuff down is one of my specialities!

Yea. I have found little reason to use the Smart Programmer version. In fact, some sources refer to the DSRLNK you found in my code as the "ultra standard". My suggestion is to stick with it if you can, as it has a proven track record across multiple systems and configurations.