Konference: Počítač SHARP MZ-800 a emulátory

Od: Michal Hučík
Datum: 13.5.2013 15:53
Předmět: Re: MRS diskovy format


Ahoj, RTK2 ? Nevedel jsem, ze Vlastik neco oficialne vydal, tak jsem ani 
nehledal. Videl jsem vzdy jen nejake screenshoty ... Je to nekde na 
scavu ke stazeni?

Co se tyka tech her, tak tam asi nema moc vyznam zkoumat jejich 
souborovy system ... format bude zrejme stejny, jako u MRSu ci cp/m, ale 
vnitrni organizaci ulozenych dat maji asi vic maskovanou.



U MRSu jsem prozatim z jeho filesystemu vyzkoumal toto:

1.) Data jsou ulozena komplementovane coz je u Sharpa nativni zpusob 
ukladani na disk, takze pokud je chces cist jinde, tak musis obsah 
sektoru invertovat.

Strany media jsou komplementovany (opet nativni Sharp pristup) a tedy se 
ABSOLUTNI STOPY cisluji v obracenem poradi, nez fyzicke

0. stopa, 1. strana je 0. absolutni stopa
0. stopa, 0. strana je 1. absolutni stopa
1. stopa, 1. strana je 2. absolutni stopa
...

2.) Format 0. abolutni stopy je v Sharp formatu 16 x 256 bajtu.

3.) Nasledujici stopy jsou ve formatu 9 x 512 bajtu (u zminenych 
Lemmings se lisi akorat jedna stopa, ktera obsahuje navic jeste jeden 
sektor, ktery je tusim jeste navic ocislovan jako 12. - nepamatuji si uz 
presne stopu, ani cislo toho sektoru)

4.) IPLPRO header MRSu odkazuje na 2 sektorovy mikro zavadec (512 bajtu) 
ulozeny v 2. a 3. sektoru 0. absolutni stopy.

5.) MRS driver jsem podrobne nezkoumal, pro orientaci na disku pouziva 
ABSOLUTNI SEKTOR, ktery spocita podle vyse zmineneho pradi stop. Velmi 
specificky se musel zrejme vyporadat se Sharp boot stopou, kterou 
zahrnuje do vypoctu absolutniho sektoru tak, jako kdyby mela 9 sektoru 
po 512 B, coz samozrejme zadnym zpusobem nesedi. Predpokladam, ze se s 
tim Vlastik asi nijak netrapil, protoze ze Sharp stopou pracuje jen 
mikro zavadec, ktery natahne samotny system - ten zacina na 0. abolutni 
stope 4. sektoru

6.)  na 37. absolutnim sektoru je ulozena jakasi FAT tabulka, ktera 
zabira 3 sektory

Kazdy bajt v teto FAT tabulce reprezentuje jeden absolutni sektor na disku.

Pokud ma tento bajt hodnotu 0xff (napr. po naformatovani, bez MRS 
inicializace), tak je sektor povazovan za nedostupny. 0xff jsou po 
inicializaci oznaceny sektory od zacatku disku, na kterych je ulozen 
IPLPRO header, mikro zavadec a samotny MRS.

Pokud jsou na disku vadne sektory, tak jsou ve FAT oznaceny hodnotou 
0xfe. Sektory ve kterych je ulozena FAT maji hodnotu 0xfa. Sektory 
adresare maji hodnotu 0xfd. (Tady jsem objevil chybku - ve FAT jsou po 
MRS inicializaci diskety oznaceny jen 2 sektory jako 0xfa a 7 sektoru 
jako 0xfd. FS driver v MRSu zrejme udaj z tabulky ignoruje a pracuje 
natvrdo s adresami techto sektoru :)

Bajty reprezentujici volne sektory disku maji hodnotu 0x00. Pouzite 
sektory maji hodnotu, ktera odpovida poradovemu cislu polozky adresare.

Na 720 KB diskete neni delka teto FAT tabulky nijak vyznacena a po 
inicializaci je predevsim cely 2. a 3. sektor FAT vyplneny hodnotou 
0x00. Predpokladam, ze Vlastikuv driver pocita vzdy natvrdo  s delkou ( 
80 stop ) * ( 2 strany ) * ( 9 sektoru ) = 1440 sektoru = 1140 bajtu FAT.

U disket o velikosti 360 KB se zrejme vyrovnal s chybejicima stopama 
tak, ze horni polovinu FAT vyplnil hodnotou 0xff - to je vsak jen domenka.


7.) Ve 40. absolutnim sektoru zacina adresar, ktery ma delku  6 sektoru. 
Kazda polozka adresare ma 32 bajtu.

Prvnich 8 znaku je jmeno souboru, ktere JE case sensitive a musi zacinat 
znakem s vyssi hodnotou, nez 0x20 (mezera). Uvnitr jmena se vsak mezera 
mezi jednotlivymi znaky muze vyskytovat. Pokud je jmeno kratsi, nez 8 
znaku, tak je zprava vyplneno az do konce mezerami.

Pravdepodobne pokud nazev polozky zacina mezerou, tak je tato polozka 
adresare povazovana za volnou (smazanou).

Na konci posledniho adresaroveho sektoru je nekolik polozek adresare 
vyplneno hodnotou 0x1a. Predpokladam, ze takto oznacene polozky adresare 
jsou fyzicky nedostupne. (Tedy nedostupne je asi vse co ma v prvnim 
bajtu jmena znak s hodnotou mensi, nez 0x20.)


Za zminenymi 8 znaky jmena nasleduji 3 znaky extenze. Jsou tam vzdy 
pouzita velka pismena. Extenze pravdepodobne nema zadny jiny, nez 
informativni vyznam, kterym se sdeluje jak byly soubory ulozeny (tedy 
jakym prikazem v MRSu).

MRS - zdrojovy kod
DAT - data ulozena odkudkoliv z RAM
RAM - ulozena 64 kB stranka RAM disku
SCR - soubory z MZpaintu do ktereho Vlastik implementoval svuj souborovy 
system

MRS identifikuje duplicitu jmena na zaklade shody prvnich 8 znaku jmena, 
bez ohledu na extenzi.

Jmena a extenze jsou ulozeny v kodovani SKUTECNE ASCII - nikoliv v te 
Japonske zpatlanine co mame v ROM !

Nasleduje 1 bajt s poradovym cislem polozky. Prvni polozka tam ma 0x01, 
druha 0x02 ... Pokud do polozky adresare ulozim jmeno souboru, tak timto 
poradovym cislem jsou potom v ve FAT oznaceny sektory, ve kterych se 
prislusny soubor rozleha.


Za poradovym cislem nasleduji 2 bajty s FILE START adresou - tedy adresa 
prvniho bajtu v pameti, kam ma byt soubor pri nacteni ulozen.

Nasleduji 2 bajty ve kterych je pocet sektoru, ktere soubor teto polozky 
zabira. (Soubory maji tedy vzdy delku v nasobcich 512.)

Pak nasleduje 6 bajtu, jejihz vyznam mi unika. Nektere polozky tam mely 
vyplneny nejake hodnoty, jine tam maji 0x00. Zatim jsem jeste nezkousel 
hazet bomby do rybnika, abych zjistil co se v techto 6 bajtech skryva.

Dalsi 2 bajty nam sdeluji FILE EXEC adresu na kterou se jumpne po 
nacteni souboru prikazem "run" z MRSu.

Pak nasleduje dalsi obskurni blok 8 bajtu, o jejihz vyznamu nemam ani 
tucha. Kazda polozka ma na tomto miste naprosto stejnou hodnotu: 4x 0x00 
a pak 0xcd, 0x49, 0x02 a 0x21 ... Zrejme nejaky Vlastikuv vzkaz pro 
dalsi generace Sharpistu :)

================
To je vse, co prozatim vim.

Jak uz jsem napsal, tak cca 4 posledni polozky adresare jsou v cele sve 
delce vyplneny hodnotou 0x1a.

Samotne rozlozeni obsahu FAT nabizi moznost priradit sektory az pro 250 
jedinecnych FILE_ID, ci jak to nazvat. Od Vlastika bych vsak ocekaval, 
ze pri praci s tou tabulkou bude ve FS driveru pro test dosazitelnosti 
sektoru testovat zda je obsah bajtu nenulovy a zaroven zda nema nastaven 
7. bit, coz by pak odpovidalo jen 127 jedinecnym FILE_ID.

Do jednoho  adresaroveho sektoru se vejde 16 polozek adresare. 16 * (6 
sektoru) = 96 = 0x60 ... Posledni FILE_ID, ktere jsem videl v poslednim 
sektoru pred tim 0x1a blokem bylo asi 0x5c - tedy o 4 polozky mene, nez 
umoznuje plna delka adresare...

Jak to je uz dnes bohuzel netusi ani samotny Vlastik Vesely, ktereho 
jsem se na souborovy system MRSu pred par lety ptal.

Kdysi jsem mel od Vlastika MRS, ktery umel inicializovat disketu se 
systemem a nebo bez systemu a tedy mel o 4 sektory vice mista pro data. 
Je mozne, ze od toho dvojiho formatu pozdeji upustil.


Nevim, zda jsem popsal srozumitelne to jak ten FS funguje. Prozatim jsem 
si napsal jen funkce, kterymi ctu adresar. Pokud bych chtel precist 
nejaky soubor z MRS diskety, tak nejprve v adresari vyhledam polozku s 
jeho jmenem. Z polozky adresare si zjistim adresu kam se ma soubor 
standardne ulozit a jaka je jeho pripadna spousteci adresa. Dale si 
prevezmu poradove cislo (FILE_ID) teto polozky a pocet sektoru (BSIZE), 
ktere soubor zabira.
Nasledne prochazim postupne sektory s FAT a v nich od zacatku az do 
konce a hledam sektory - bajty obsahujici stejne FILE_ID jake ma muj 
soubor. S kazdym nalezenym a prectenym sektorem snizim hodnotu BSIZE, 
dokud nedojdu k nule. Tim jsem precetl soubor.

Michal


Dne 13.5.2013 12:26, Mikes Medek (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
> Ahoj,
>
> ja asi moc nepomuzu. Jedine co mam je MRS.dsk, RTK2.dsk a LEMMI.dsk, ktere
 jsou asi ve stejnem formatu. Ale to ma vetsina. Jinak jsem neprisel na nic, co 
bylo takto delane.
> Co Te vede k nazoru, ze existuji ruzne verze pro systemovy a datovy disk?
> Jestli si s tim chces hrat, tak to udelej podle sebe a treba se neco casem
objevi.
> Zatim drzim palce a budu rad, kdyz budes informovat.
>
> ---
> Pobyty na horách se slevou
> http://raketa.cz/slevy/pobyty/hory/
>


Ostatní příspěvky vlákna:

 
[2013/1 (17)] [2013/2 (52)] [2013/3 (60)] [2013/4 (68)] [2013/5 (60)] [2013/6 (42)] [2013/7 (9)] [2013/8 (48)] [2013/9 (1)] [2013/10 (40)] [2013/11 (45)]


[1999 (1)] [2000 (168)] [2001 (733)] [2002 (459)] [2003 (654)] [2004 (224)] [2005 (105)] [2006 (182)] [2007 (201)] [2008 (294)] [2009 (363)] [2010 (782)] [2011 (522)] [2012 (642)] [2013 (442)]