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

[Michal Hucik - ORDOZ]

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):
> Ahoj,
>
> mam takovou kacirskou myslenku, nicmene nevim, nakolik je schudna. Je 
> to dotaz spise na Radka, Martina nebo Petra, kteri maji skutecne 
> floppy radice.
>
> Vim, ze nulta stopa pro Sharpa ma format 16 sektoru po 256B. Co se ale 
> stane, kdyz se da do Sharpa disk s nultou stopou 9x512B a korektnim 0. 
> sektorem s IPLPRO textem a v 1. sektoru loader pod 256B?
>
> Zkousne to WD279x nebo bude error ?
>
> Vasek
>
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz

------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20160124/eb02f117/attachment.html