[Coco] Segment List Full on backup

[Allen Huffman]

> On Jan 27, 2015, at 4:56 PM, Gene Heskett <gheskett at wdtv.com> wrote:
> 
> I was not aware that we had a backup program that functioned like dd does 
> on linux other than the backup that is part of the os9 cmds available.  
> And it demands identically formatted disks as its safety mechanism.

Yes, it’s not like DD. It does sector-by-sector (so it copies “unused” sectors), but it does match LSN0 first. I have a program that reads LSN0 off of the source device, then writes it to my blank .DSK image. Boom! Instant backup-friendly destination ;-)

> Does this "backup" program you refer to actually clone one complete disk 
> to another, effectively making a carbon copy of the original?  IOW, are 
> you using the backup from the nitros9 cmds tree?

Yes, Microware “backup” or whatever is in NitrOS-9.

> The os9 backup command is the only command in the box that does that. 
> neither BRU nor Backar do that. But backar is what got me into trouble as 
> it needs a single bit, someplace in the fd.sector to function as intended.  
> But every bit is already spoken for. So I'll just drop backar until such 
> time as I can come up with a fix that works.

I ran in to issues reading an OS-9 EZ135 disk on my old PC laptop for the same reason. I wrote a similar program to save the OS-9 LSN0, then I copied over a PC EZ135 LSN0 to the OS-9 disk. After that, I was able to access it from a DOS C program. Seems like the BIOS must look at the disk too — if it doesn’t look valid, I couldn’t access it. But this was back in the 90’s. Maybe DOS has changed.

> So what I do, and not nearly often enough, is dsave the operating drive to 
> a subdir on the second drive as I have 2 identical 1Gb scsi drives, and 
> with what I have on the main drive, I could setup at least 5 such subdirs 
> on the second drive if I needed multiple generations for mistake recovery.

Yeah, in my case, I want all the sectors. I want to preserve any deleted files, etc. that I may want to go peek at. A full clone of what I had that last time I used the system.

> How much data is there? That FAT/DAM limit of $FFFF, translated to bytes 
> assuming a 1 sector cluster, is 134,215,680 bytes.  A full EZ135 might be 
> able to exceed that but I'd have reservations it could based on the 
> Seagate marketing depts legendarily wishful thinking.

The EZ135 capacity, based on what the old SCSI query command returned, was right on the money for 128MB. 128MB compact flash cards, however, are not (1000 byte Ks).

> FWIW, I have an LS-120 drive and a 6 pack of disks for it, but have never 
> acquired the IDE interface it needs.  I should do that when it becomes 
> available again.

I just noticed SuperIDE was no longer available. No wonder folks have been buying up the Glenside boards.

>> I think RBF is returning it because the sector exceeds the number of
>> clusters that the DAM ($FFFF * 8 = 524,280) supports.
> 
> Now that is a possibility. It is also possible that os9 ran out of bits in 
> the LSN# issued, but since that number is in LSN's, not bytes, its well 
> north of 3.5Gb by then.  So I can't see that occurring.

Yeah, in this case, once it reads LSN0 it shouldn’t care. I *think* what I did was give it too many sectors ($7FFFF) — when it only reads to 0x7FFF8. This would explain why BACKUP failed, and a normal GET/PUT in BASIC09 did at the end sector (524,287).

I should really go back and read all my old EZ135 articles. I dove in to all of this. But, relearning is fun!

		— A