Re: [SharpMZ] Chovani realneho FD radice u disket s "cizim" formatem

Ahoj Vasku,

a) nejedna se o 0. stopu, ale o 1. stopu (diky invertovanym stranam)

b) radici je uplne jedno jaky je format sektoru, prikaz znel jasne: READ SECTOR a nikdo uz do FDC nepredesilal zadny predpoklad o tom jak by mely byt ty data velka... Existuje jeste prikaz READ SECTOR(S) s platnosti do konce stopy, ale to nas nyni moc nezajima.

Problem je tedy v rutine vykonavajici cteni.

Po vyse zminenem prikazu si to radic chvili necha honit hlavou. Cteci program v tu chvili zurive stale dokola kontroluje status registr, dokud se mu v nem neobjevi flag DRQ - data request, to je pro cteci program signal, ze si ma vyzvednout bajt - coz udela zpravidla pres IN, nebo jeste lepe pres INI.

Jakmile si program prevezme svuj vytouzeny datovy bajt, tak se opet vrhne na cyklicke nacitani status registru a z nej si testuje:

1) je radic stale ve stavu BUSY? (resp. neskoncila ta uz operace cteni?)

2) je DRQ? (nejake dalsi bajty by nebyly?)

3) neni nahodou DATA_LOST? (treba pokud jsme se nekde zakecali a nestihli jsme si vcas prevzit vyse avizovany bajt)

V pripade, ze nedoslo k zadne chybe, tak nam radic predal vsechno co mel v sektoru, ve statusu neni zadny ERROR a status hlasi OK... Idealni vesmir - v takovem by se ten tvuj vetsi sektor nacetl.

Jedina neprijemnost, ktera by v tomhle idealnim vesmiru mohla nastat je to, ze by treba tech nadbytecnych 256 bajtu neco prepsalo.

Protoze programator nikdy nemuze zcela duverovat HW, tak bud uz u toho IN, ci INI, nebo alespon po ukonceni celeho cteni se provede kontrola poctu prenesenych bajtu ... Pri tehle kontrole jde ovsem o to, ze jsme cekali 256 bajtu - ani vic, ani min. Nikoho tedy nijak vyznamne nepotesi, ze jich bylo nacteno dvojnasob - cteci program se tedy neodvratne vyda cestou k FDC ERROR!


A to se porad bavime jen o tom 1. sektoru ve kterem se neocekaval zadny opravdovy program - jen IPLPRO header s informaci o tom od ktereho alokacniho bloku se ma program nacist a kolik bajtu bude mit. Kdyby jsme teoreticky preskocili tu cast, kdy si Sharp ROM nacte IPLPRO header, tak:

- ROM si spocita z cisla alokacniho bloku fyzicky sektor, stopu a stranu, odkud ma zacit cist zavadec: pocita natvrdo s tim, ze stopa ma 16 sektoru, mohlo by tedy dojit k tomu, ze ROM pozada radic o cteni neexistujiciho sektoru (tva disketa jich ma jen 9)

- (ted si nejsem uplne jisti, zda tohle dela jen BASIC, nebo zda to dela i ROM): aby se data nacitala "rychleji", tak se pouziva vyse zminene sequencni cteni od pozadovaneho sektoru az do konce stopy a az tam, kde se cteci rutina dopocita k tomu, ze uz nema duvod cist do konce stopy, tak zacne cist jednoblokove. Musel by jsi tedy ROMku i nejak sikovne mystifikovat o tom, jak je tvuj zavadec velky, aby byl nacteny spravne... Jenomze ouvej - IPL zavadec nacetl nas program na adresu 0x1200 a na pozadovanou adresu jej presune az po uspesne dokoncenem cteni - pokud jsme kecali s delkou, tak mame dalsi duvod ke kolizi ...


No a proto se na Sharp disketach pouziva 1. stopa v MZFS formatu ;)

Michal


Dne 24.1.2016 v 15:55 Vaclav Peroutka napsal(a):