Sector Copy - Write Blank Sectors?

[OmaOhneBH]

  

 

 

 

Write Blank Sectors - what's the purpose of this option? And why is YES the default setting when Format Destination is answered with NO and vice versa?

 

 

[+CharlieChaplin]

Well,

 

if you do not format the destination disk and it was already in use (and contains old data), then it is best to write blank sectors, so the already used sectors (with old data) get overwritten. Otherwise you may end up with a disk that has data from two or more different programs... 

 

(For example, if the old data occupied 200 sectors and the new data occupies only 100 sectors on the destination disk, then writing the new data to the destination disk without formatting and without writing blank sectors would end up with 100 sectors new data and 100 sectors old data - and that should be avoided most of the time.)

 

However, if you format the destination disk, then there is no need to write blank sectors, since formatting the disk will clear/blank all the sectors anyways. This old sector copier does not do a fast/quick format, so it really formats the whole disk (and does not simply clear VTOC+DIR)...

 

[+Larry]

The Black Patch Sector Copier from CSS suggested that a sector copier should  write out whatever it read, even if the read was an error sector.  It claimed that many more disks having bad sectors could be successfully copied by doing this. (YMMV) The whole idea of the "Black Patch" was make a copy of everything it could, then to re-write/bypass copy protection, similar to the Chipmunk.

 

 

 

[flashjazzcat]

I would think this is just a means of copying more sectors during each pass. If a sector on the source disk contains nothing but $00, then that sector can be represented in the buffer with perhaps a single bit of data (0 = empty sector). When writing to the destination disk, the empty sectors can be either filled with zeroes or skipped entirely.

 

[+Nezgar]

6 hours ago, flashjazzcat said:

If a sector on the source disk contains nothing but $00, then that sector can be represented in the buffer with perhaps a single bit of data (0 = empty sector).

I don't know about other copiers, but MyCopierR for sure does this - for example a 180KB DD disk can be copied in 1 pass on a stock 64K machine (maybe even 48K) if there's enough empty sectors. Also SCOPY makes smaller disk image files this way.

 

10 hours ago, OmaOhneBH said:

Write Blank Sectors - what's the purpose of this option?

Another reason is that not all drives format disks with $00 initially in all the bytes of blank sectors. Earlier Percom drive firmware formats blank sectors filled with  "1A" hexidecimal. I confirmed that a blank percom formatted disk results in a maximum size disk image file with SCOPY....

 

This led to programs like "Pervert" that would write '00' to all empty sectors... some software like LJK's Letter Perfect wouldn't work with disks formatted by these Percom drives.

 

Also I recall that the HDPHFMT9 utility to physically format hard drives on the ICD MIO would also place nonzero blank sectors initially. I think there was some science behind that, to increase reliability if the sectors had a some sort of bit pattern, instead of just 0 when stored over time. *citation needed.

 

[HiassofT]

Another thing to keep in mind is that several SIO emulators, SIO2xx and PBI hard drive devices  don't actually blank the (ATR) image space on a format command. Personally I consider such behavior a bug (as it's differing from what standard floppy drives on the Atari do) but if you have one of these devices you might need to enable "empty sector writes" in case you're not 100% sure the image space was really blank.

 

so long,

 

Hias

Edited October 24, 2019 by HiassofT

[+Nezgar]

18 hours ago, HiassofT said:

...several SIO emulators, SIO2xx and PBI hard drive devices don't actually blank the (ATR) image space on a format command.

Oh, this is good to know, especially if the intent of your ATR it to make an archival copy from a real disk. Non-blank sectors could mislead forensic analysis of a disk image...

 

At least with SpartaDOS X's formatter and real drives, there is a clear distinction between "format" (erase everything and build directories) and "Build directory" (only re-write directory, without full erase). With PBI/RamDisk/hard disk partitions it disables the option to format, leaving only the build directory option, so it is implied that all sectors are not blanked...

 

Do you know the beaviour of various SIO2PC type software? I primarily use RespeQt, and usually create a new disk each time when archiving, but I suspect it properly blanks when it receives a format command...

[HiassofT]

I think RespeQt and other current SIO2PC software versions should be fine. But I'm not 100% sure, it's been too long since I looked into it. Pretty sure original SIO2PC versions for DOS had issues and ISTR I also noticed that issue with some (early?) SDrive or SIO2SD version.

 

so long,

 

Hias

[EddyFree]

I think the purpose of that option is to speed up the time a user has to wait for the copy process. Especially if the user is using pre-formatted destination disks and has source disks that may not be completely full.

 

Personally, I would never skip blank sectors with a destination disk that contains data. I would be concerned about "trash"(residue) being left behind in the VTOC area of the destination disk afterwards on DOS 2.x compatible disks.

 

This was an issue I had when I imaged some disks with an old version of SIO2PC years back. IIRC, for some reason it didn't clear the buffer memory when you "create a disk image". I didn't realize this until I had made several disk images. As a work-around I ended up creating a blank image file(zeroed) and using the "load image from file" option to manually zero the buffer so I wouldn't end up with residue on the destination.

 

 

[ijor]

On 10/24/2019 at 4:48 PM, Nezgar said:

Another reason is that not all drives format disks with $00 initially in all the bytes of blank sectors. Earlier Percom drive firmware formats blank sectors filled with  "1A" hexidecimal. I confirmed that a blank percom formatted disk results in a maximum size disk image file with SCOPY....

 

I believe that was indeed the original reasons that sector copiers at that time had that option.

 

Btw, the $1A hex is actually $E5 inverted, which is the actual data written to the disk surface. And not by chance it's the same value written normally when you format a floppy on a PC. In theory, the MFM pattern produced by $E5 is the most stressing to the magnetic surface. So the idea is that if you format the whole disk with that value and it can verified ok, then probably the disk is fine.