DiskCopy asi nepozna nejakou chybu

Hlášení chyb a problémů programu Altap Salamander. Buďte, prosím, ve svých popisech co nejpodrobnější a vytvořte pro každý incident nový příspěvek. Nevkládejte programem generovaná hlášení o pádu programu, pošlete je e-mailem.
Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

DiskCopy asi nepozna nejakou chybu

Post by Jan Patera »

Snazim se udelat image asi dvaceti 5.25" single-sided disket nahranych pred 20 lety na mem Laseru (8-bit computer). Predesilam, ze jsem si nedaval nadeji na uspech. DiskCopy na nekterych nahlasi chybu "Cannot read disk in drive B. No ID address mark was found on the floppy disk" (vesmes se jedna o vyrobne oboustranne diskety, lec zformatovane jen z jedne strany) a image nevyrobi, na jinych prohlasi "reading disk in drive B: has been finished successfully", progressbar ma 0% a image soubor ma nula bajtu (zde se jedna o diskety, ktere zrejme byly i vyrobeny jako jednostranne). Ten druhy pripad nevypada prilis korektne, jako kdyby DiskCopy spolknul nejakou chybu.

-- Honza
P.S. Pokus o nacteni v panelu skonci dle ocekavani "(1785) The disk media is not recognized. It may not be formatted."
Last edited by Jan Patera on 28 Feb 2008, 13:34, edited 1 time in total.
-=Majkl=-
Posts: 80
Joined: 12 Dec 2005, 14:51
Location: Brno, Czech Republic
Contact:

Post by -=Majkl=- »

Tohle asi nepujde tak jednoduse. Vzpominam si, ze kdyz jsem pred lety dostaval image 5.25" disket z C64, museli jsme pouzit disketovou jednotku od Commodore (asi 1541ka ?), pripojenou pres seriovy port specialnim kabelem (par dratku stacilo). Data se pak prenasela nejakym specialnim softwarem, pracujicim pod DOSem.

Nerekl bych, ze to slo udelat beznou 5.25" disketovou mechanikou pro PC.
User avatar
Datalog
Posts: 244
Joined: 10 Dec 2005, 11:21
Location: Prague, Czech Republic
Contact:

Post by Datalog »

8 bit Laser neznám takže jen obecné povídání, co mi ještě zůstalo v hlavě (takže brát s rezervou).

Někdy to jde, ale není to legrace, napsat na to vlastní sw, někdy to v principu nejde. Diskety mají standardně hlavičku sektoru a tělo sektoru. A pak další sektor hlavička, tělo. Atd. V mezerách mezi sektory i hlavičkou a tělem je smetí. Obojí (hlavička i tělo) startují určitou sekvencí tak se rozpoznají, na to se obvykle synchronizuje. Obvykle na HW úrovni. Stejně tak se hlavička rozpoznává a částečně parsuje na už na HW úrovni (WD broučci to měli jinak než ?intel?).

V hlavičce je číslo sektoru, strana disku a velikost dat sektoru (a možná i velikost hlavičky pro různé verze, už si nepamatuji přesně). Plus crc, další blbosti pro nás nyní nedůležité.

----

A teď problémy. Někdo (různé OS i broučci) poctivě vyplňoval všechny údaje, někdo ne. Třeba číslo strany bývalo ignorováno a dělalo se jako pokračující čísla sektorů z 1. strany. Nebo velikost sektoru zapsaná v hlavičce, někdo dal default (tuším 128) i když data byla velká 512 (tuším v hlavičce šlo jen o info - jeden bajt kde 0=128,1=256, ... Datový úsek má svůj leadin, délku a crc nezávislou ještě v sobě.

Takže záleží, jak moc byl původní formát prasácký a jak moc (jako že moc) mají noví broučci pro četní zadrátované automatickou vazbu hlavičky sektoru a zbytku - očekávání následujících dat/strany.

Plus, někdo hustil sektory těsně za sebe (aby se jich vešlo více) a dělal malé mezery a teď to dělá problémy při synchronizaci.

A i když byl náhodou původní formát OK, hlavička také správně popsané a místa dost, tak začnou sw problémy na MS. Někdo začínal sektory od 0, někdo od 1. A MS (tuším od DOS5 či 6) mívá i problémy, je-li velikost sektoru jiná než 512. Takže to často znamená napsat komplet novou low-level read rutinu, odříznout kopmplet od zbytku systému, aby do toho omylem nehrábl a nepoužil např. malou cache pro čtení delšího sektoru, ...

A i když už načteme data, jsou soubory (existovaly-li tam soubory) pochopitelně v nějakém tehdejším divném filesystému. Takže další sw, tentokrát nový filesystém - alespoň pro čtení.

----

P.S.: Je také teoretický způsob, přečíst celý track najednou (to broučci dokáží), ignorovat vše kolem a pak se snažit rozpoznat sektory (hlavičky a těla) softwareově. A šum mezi nimi zahodit.

Má to jeden katastrofální problém. Toto šlo jen těsně po naformátování a ještě pár dní po. Pak se (asi vlivem času na opotřebení serva, vlivem dalších zápisů, či kdo ví proč) stalo, že od určitého místa se začaly načítat blbosti. Ostatně to, že bylo posunuté čtení právě o jeden bit, se stávalo, i když se synchronizoval na sektory (špatný sync). Čili u čtení celého tracku neudrží (asi) stabilní rychlost (možná problém i tepelná roztažnost materiálu) a po chvíli se mu rozjede synchronizace a čtou se blbosti. Takže tudy cesta nevede. Musí se sektor po sektoru.
User avatar
Datalog
Posts: 244
Joined: 10 Dec 2005, 11:21
Location: Prague, Czech Republic
Contact:

Post by Datalog »

Takže, abych se vrátil k %subj%.

Za takovéto situace je možné, že rozpoznání chyby je nemožné. A pokaždé se vrátí jiná a jiná (či žádná) při různém systémovém požadavku. Může to dělat roztodivné blbosti.

A pro starší OS (W9x či DOS) klidně shodit celý systém - jen ten jiný formát na disketě (to se mi, svého času, poměrně úspěšně dařilo). A bylo (to shození) závislé na typu služby jakou jsem volal - zda via int13 či ioctl.
Post Reply