David_W_Tamkin@cup.portal.com (11/02/88)
Sigh...and I can't even connect this to the same thread as the first partial
article since it takes a day's turnaround for a post from Portal to return.
At any rate, the relative file idea didn't work. Does anyone know a way to
protect sectors that are not in a file from being de-allocated by a validation
on a 1571 or 1541, short of using a write-protect tab or changing the DOS
version byte, so that other writes can still be done to the disk without
having to reallocate the boot sectors after each collect?
If Commodore had designed the 128 ROM to look for a boot signal in track 1,
sector 0, that began $00,$01 or $00,$00 instead of "cbm", then pointing a
dummy file would have worked. CBM really dropped the ball on that one.
David W. Tamkin Post Office Box 567542 Norridge, Illinois 60656-7542
David_W_Tamkin@cup.portal.com | | sun!portal!cup.portal.com!david_w_tamkin
Portal's other customers speak for themselves; I speak for myself;
and Portal's management speaks for itself ... in more ways than one.
Now I'm off to learn the difference between the O key and the P key so as to
stop posting fragments of articles.jbh@mibte.UUCP (James Harvey) (11/03/88)
In article <10763@cup.portal.com>, David_W_Tamkin@cup.portal.com writes: > > At any rate, the relative file idea didn't work. Does anyone know a way to > protect sectors that are not in a file from being de-allocated by a validation > on a 1571 or 1541, short of using a write-protect tab or changing the DOS > version byte, so that other writes can still be done to the disk without > having to reallocate the boot sectors after each collect? > > David W. Tamkin Post Office Box 567542 Norridge, Illinois 60656-7542 > David_W_Tamkin@cup.portal.com | | sun!portal!cup.portal.com!david_w_tamkin > Portal's other customers speak for themselves; I speak for myself; > and Portal's management speaks for itself ... in more ways than one. > I think the answer is to not validate the disk. A long time ago (in a galaxy far, far away... no, No.... It was in Detroit.) I wrote a program that would UNvalidate a disk. It would read the whole disk and allocate any sector that contained data. This is a useful thing if you have done a validation in error or want to save a "Splat" file from destruction. Actually, I wanted to be able to store other adventure games on my Zork disks, it worked fine for this. -- Jim Harvey | "Ask not for whom the bell Michigan Bell Telephone | tolls and you will only pay 29777 Telegraph | Station-to-Station rates." Southfield, Mich. 48034 | ulysses!gamma!mibte!jbh
David_W_Tamkin@cup.portal.com (11/05/88)
Jim Harvey in <2710@mibte.UUCP> offers me the suggestion: > In article <10763@cup.portal.com>, David_W_Tamkin@cup.portal.com writes: < At any rate, the relative file idea didn't work. Does anyone know a way to < protect sectors that are not in a file from being de-allocated by a validation < on a 1571 or 1541, short of using a write-protect tab or changing the DOS < version byte, so that other writes can still be done to the disk without < having to reallocate the boot sectors after each collect? [Jim's citation of my signature omitted] > I think the answer is to not validate the disk. A long time ago > (in a galaxy far, far away... no, No.... It was in Detroit.) I > wrote a program that would UNvalidate a disk. It would read the > whole disk and allocate any sector that contained data. This is > a useful thing if you have done a validation in error or want to > save a "Splat" file from destruction. Actually, I wanted to be > able to store other adventure games on my Zork disks, it worked > fine for this. Jim, the only time I would never validate a disk again is when I have stopped writing to that disk for good. At that point I can use a write-protect tab and not care whether the maverick sector is allocated or not, since nothing can be written over it anyway. Your program for undoing a validation wouldn't help me. For one thing, it would allocate all sectors that had been in files I had intentionally scratched, wasting space I'd rather use for current data (or, if there is still a lot of space on that disk, making DOS jump all over the place in writing files); for another, if I have to go through a second process after each validation, a quick open1,9,15:open2,9,2,"#":pR1,"b-a 0 1 0":close2:close1 (I don't trust dclose to close the files in predictable order) is probably less work than digging out a disk with your program on it and watching it allocate every sector that contained anything different from original formatting filler. Thank you for your suggestion, but it wouldn't work for me. Thank you also for reading both parts of the article before responding. [For those of you wondering why I abbreviated print# to pR but not open to oP nor close to clO, I am showing how I normally type those keywords. The annoyance of shifting is not worth typing only two fewer characters, so I type out "open" and "close", but "print#" has four more characters than its abbreviation and needs a shift for its octothorpe anyway.] David_W_Tamkin@cup.portal.com || sun!portal!cup.portal.com!david_w_tamkin