[SharpMZ] Chyba v emulaci FDC - tyka se i Unikarty

[Michal Medek]

Ahoj Michale,



super postrehy. Na fw pro unikartu se v posledni dobe udelalo hodne prace, 
hlavne  souvislosti s podporou pro MZ-1500. Urcite zmeny jsou i v sekci 
podpory FDC, ale ne co se tyka opravy teto popisovane vlastnosti. Je snaha 
mit cely projekt kompatibilni pro MZ-700/800/1500 alespon na strane buildu. 
Mimochodem doslo k velkemu prepracovani manageru, rozsireni API, atd. 
Veskere zdrojove kody jsou na gitu, ktery spravuje Uunek a urcite je 
'komunitne' pristupny.

Pokud by jsi byl ochotny podporu FDC upravit, tak by jsme Ti byli urcite 
velice vdecni.




Mikes


---------- Původní e-mail ----------
Od: Michal Hucik - ORDOZ <ordoz na ordoz.com>
Komu: sharpmz na mail.ordoz.com
Datum: 16. 1. 2018 13:51:04
Předmět: [SharpMZ] Chyba v emulaci FDC - tyka se i Unikarty 
"Ahoj, 

nahodou jsem objevil docela fatalni chybu v emulaci WD279x, ktera se 
zrejme bude vyskytovat nejen v PC emulatoru, ale i v HW emulatorech, viz 
vsechny verze Unikarty. 

FDC podporuje 2 zpusoby cteni / zapisu. Bud jednosektorove, nebo 
sequencni - tzn., ze se radic nastavi nad nejaky sector a pak uz se jen 
cte / pise - ve chvili, kdy pocet datovych bajtu prekroci velikost 
sektoru se kterym se pracuje, tak se radic pokusi na stope vyhledat 
sektor s nasledujicim poradovym cislem. Pokud takovy sektor existuje, 
tak operace cteni / zapisu automaticky bez jakehokoliv preruseni 
pokracuje v tomto sektoru. Pokud sektor s nasledujicim ciselnym 
oznacenim neexistuje (tzn., ze jsme na konci stopy, nebo ze cislovani 
sektoru na stope neni kontinualni), tak radic vyhlasi RNF error a 
operace je ukoncena. 

Vetsina programu, ktere pouzivaji kontinualni cteni se spokoji s tim, ze 
ve status registru obdrzi RNF, bez pritomnosti jakekoliv jine chyby a 
povazuji operaci nad stopou za uspesne ukoncenou. 

Diskovy K&P BASIC pri zapisu na disk pracuje s disketou tak, ze nejprve 
data multiblokove ulozi. Pak probiha verifikace, ktera je realizovana 
multi blokovym ctenim, pri ktere se vsak zadne data nectou a pouze se 
vyhodnocuje status (podobne verifikuce i cp/m 4.1, nicmene jednoblokove). 

Dnes jsem zjistil, ze BASIC (pouze) pri verifikaci netestuje jen RNF, 
ale soucasne s nim nacita i obsah registru sektoru a testuje si, zda uz 
byl na stope precten posledni sektor z verifikovaneho souboru. Jestlize 
byl tento posledni sektor soucasne poslednim sektorem na stope, tak 
BASIC ocekaval, ze precte cislo sektoru 17, nicmene moje emulace WD279x 
mu vracela posledni cislo validniho sektoru, ktery jsme byli schpni 
precist, tzn. 16. K zapisu tedy z duvodu neuspesne verifikace nedoslo a 
BASIC zahlasil neco jako FD1: System id error. 

Ja jsem na to narazil tak, ze jsem na ciste diskete v BASICu ukladal po 
sobe nekolik jednosektorovych souboru - 15 se jich ulozilo v pohode a 
16. vyhlasil chybu, kterou popisuju. Kdyz jsem vsak do zdrojoveho kodu v 
BASICu pridal par radku, tak uz to bylo OK a verifikace prosla, protoze 
soubor narostl na 2 sektory a tak jeho posledni blok lezel na zacatku 
nasledujici stopy. 
Chyba se projevuje jen tehdy, pokud chcete v BASICu ulozit soubor, jehoz 
konec bude ulozen v 16. sektoru libovolne stopy, coz je ovlivneno 
nejblizsim volnym mistem na disku, velikosti souboru a take fragmentaci 
disku, coz zpusobilo, ze tam ta chyba existuje bez povsimnuti uz skoro 
10 let, protoze stejny kod emulace pouzivam i v Unikarte. 

No a ted zasadni otazka: v emulatoru jsem si to samozrejme opravil, 
nicmene co nase puvodni Unikarta? Pouzivate ji jeste nekdo? Budete mit 
zajem, abych vydal nejaky opravny firmware? 

Bohousi: pouzivas ve svem emulatoru stale ty moje puvodni zdrojaky? 
chces poradit co prepsat, aby sis to u sebe fixnul? 

Michal 

_______________________________________________ 
SharpMZ mailing list 
SharpMZ na mail.ordoz.com 
http://mail.ordoz.com/mailman/listinfo/sharpmz 
"