30. 8. 2008

Menší průzkum: Zápis na FAT16

Ačkoliv je práce na samostatné utilitce neustále v proudu (denně věnuji tomuto prográmku několik hodin), nejde vše tak ryhle jak jsem si původně myslel. Jsou dvě věci, které by jsme rádi prezentovali.

První je název projektu. Logout svým bystrým úsudkem, vtipem a citem pojmenoval tento projekt trueware. :) Takže v příštích oznámeních se budeme odkazovat na tento název :)

Další věc, kterou bysme rádi probrali na veřejnosti, je samotný trueware (sakra mě se ten název moc líbí). Resp. to co má dělat.

Logout to shrnul v předcházejícím článku takto:

Jen bych doplnil fakt, ze nebude treba shanet zadne FDD rutinky a nic portovat; pokud uz jsem Shreka dostatecne presvedcil aby utilita fungovala pres kazetove load/save operace, pak pujde bez uprav na BS-DOS, MDOS3, DEMFIR a FATWARE; nastavi se ukazatel virtualni kazety v BS-DOS, pusti se utilita, zada se kolik souboru od aktualni pozice se ma loadnout z BS-DOSu a sejvnout na FAT16 a je hotovo; stejne to pak muzou delat v TAPE-emulatoru v MDOS3.

Což je sice pěkná věc, jistě by fungovala, ale má jeden nedostatek. Soubor, který by jsme chtěli přenášet na FAT16 by byl omezený délkou (volnou pamětí na ZX Spectru) a jelikož TAP soubory (qůli kterým to vlastně děláme) mají občas několika násobně větší velikost než 48 kB, je tento princip fungování trueware nevhodný.

Druhý způsob je, že se bude používat sequenční čtení souboru a postupně se bude loudovat na FAT16tku, což vyřeší problém, který je uveden v prvním případě, ale na druhé straně bude HW závislý na diskových operacích daného řadiče. (tzn. bude verze pro BS Dos, MDos 3, ...).

Tak a teď se lidi pod článek vyjádřete co byste radeji...

btw. během zítřka budu mít již fungující zápis... fakt na tom pracuju ;)

9 komentářů:

hood řekl(a)...

Mirdo, jednoznacne jsem pro podporu dlouhych TAPek a verzi pro kazdy system zvlast. Nemusi to byt jen TAPky, ale samozrejme i jine binarni soubory (128k snapy, image disket....) tam bysme si se sobory o max delce RAM Spectra vubec nepomohli.

tot muj nazor

Hood

Z řekl(a)...

No, koukam, ze uz i MB-02 maniakum dochazi, ze to neni az takova prdel, a to nikoli kvuli lacinemu "divide ma proste malo pameti", ale z principu veci - voila, prvni krok bychom meli.

Hood si jeste zkusi douvedomit, jestli chceme opravdu ukladat soubory, a to jeste speccyficky pro kazdy system zvlast, a nebo jestli chceme nacitat po jednom bloky ze standardniho volani tap-load 0562h (neprepsal jsem se, toto je ten spravny vstupni bod, heh), a z nich na fatce appendovat vysledny tap. Jsem si jisty, ze temer vsichni cheme to druhe, protoze je to nejuniverzalnejsi reseni, jen o tom nekteri jeste nevi.

prudsvih je, ze tapkovy interface neumi data fragmentovat, a dlouhy blok proste bude chtit ulozit do pameti celistvy. Nejsou vyjimkou bloky dlouhe treba i Bxxxh, a je treba s nimi pocitat.

reseni jsou dve - bud vyuzit 128k, a emulator tapky schovat do stranky, ktera bude v pripade volani loadu prekryta volnou stranku, takze se blok i zapisovac vedje do pameti soucasne, a zapisovaci uz nebude delat problem po sektorech banku vycist.

na 48k je to horsi, a bylo by nejlepsi, kdyby se utilita vesla napr. do videoram, do prvnich 4k, viz tapky vznikle konverzemi M1 snapu a pod, kde se dlouhe bloky vyskytuji.

takze vidime, ze nakonec 8k pameti v bance divide je prostredek, co ma vetsi moznosti, nez omezeni, dana samotnou filozofii systemu Spectra. a to je presne to, o cem mluvim - ze nema smysl montovat do trabantu motor z tanku, protoze ho pri kazde vyssi rychlosti stejne neudrzi ram...

Z řekl(a)...

nebo jeste to reknu jinak - ta utilitka bude muset byt kratsi nez 16kB, aby vubec mea sanci na ZX v tomhle rezimu tap-readu fungovat (sanci schovat se pod stranku, nebo do spodnich 16kB).

pak ale muze byt rovnou ve strance mb-02, nebo v bance divide, a mame k dispozici 48kB kontinualne - jednoduse receno, jestli ORG 4000, nebo ORG 2000, uz neni velky rozdil.

Shrek řekl(a)...

Zilogu ono to az tak tezke neni - udelat ten zapis do FAT16. Aspon se mi to tak jevi, ja mel v tom zdrojaku vyslovene chyby. Ted to jen pisu pekne skoro znova od zakladu.

Jinac to co jsi napsal je moc pekne, ale co s TAPkama, ktere jsou delsi jak 48kB (treba ZeroPoints ma neco kolem 90 kB). :)

Hood aspon neco dela, narozdil od lidi, kteri porad jen kafraj.

Z řekl(a)...

No, my cheme konkretne "append", spis nez 0-based-write, protoze ten soubor bude vznikat po blocich, co nebudou nasobkem ani clusteru, a ani sektoru. ostatne uz zalozeni souboru/adresare je vetsinou appendem, nebo overwitem adresarove polozky (coz se mimo root chova jako soubor).

nerikam, ze fatka je tezka - je to primitivne navrzeny primitivni system, ale efektivni obsluha fat neni tak easy, jak se na prvni pohled zda. no, rozhodne jsem zvedav, jak toto dopadne :)

Z řekl(a)...

tapy >adresovy prostor spectra prave resi ten pristup, co jsem psal - prace po bloku. blok v tapce je totiz jediny usek, kde si muzeme byt jisti, ze se do ram souvisle vejde (yes, jde vyrobit tap, kde toto neplati, ale pak nemusime nahravat cely, protoze zbytek je usek z romky).

Logout řekl(a)...

Pozor! Tady si Zilog a Shrek nerozumi v pojmech!

Zilog rika "budeme loadovat ze Spectra LOAD rutinou bezne soubory, delat z nich TAPku a tu ukladat na FAT16"

Shrek rika "budeme loadovat ze Spectra LOAD rutinou hotovou TAPku a tu sejvovat na FAT16"

v tom Shrekove pripade muze mit TAPka jako celistvy jeden soubor klidne i nasobne vic nez RAM spectra a beznym LOADem ji proste neloadneme...

Shrek řekl(a)...

Nehlede na to, muzes saveovat aj SNA, Z80... vlastne cokoliv...

nejen TAPy.

dex řekl(a)...

Nějak si v poslední době říkám - není Zilog náhodou na tvrdých drogách?