[SharpMZ] pridana emulace QD

Michal Hucik - ORDOZ ordoz na ordoz.com
Čtvrtek Únor 18 13:30:14 CET 2016 

Ahoj Radku,

tech 32 souboru je limit v ROM ... filesystem, image, emulator, ani 
virtualni QD takove omezeni nezna.

Co se tyka omezeni QD filesystemu, tak pocet souboru, na ktery je v 
hlavicce QD vyhrazen 1 bajt, bude zrejme limitovan na 127. Jeden soubor 
totiz zabere 2 bloky - header a telo. Max pocet bloku je 255, nicmene to 
neni delitelne dvema.

Z toho co jsem dale vyzkoumal u filesystemu, tak datove bloky se zkladaji z:

- synchronizacni znacky
- 1 bajt typ bloku (0x00 - header MZF, 0x05 - telo MZF)
- 2 bajty velikost bloku
- telo bloku
- CRC

Tim je jasne urceno, ze velikost bloku nemuze byt vetsi, nez 0xffff.

Pokud by jsi zvolil svuj vlastni system organizace dat, tak samozrejme 
touto hodnotou limitovan nebudes a muzes ulozit, ci nacist tolik, kolik 
ti umozni samotne medium.

Co se tyka virtual QD, tak ten je vylozenym experimentem, ktery na PC 
nema az tak velky smysl, nicmene na Unikarte v tom vidim potencial s 
moznosti ukladat soubory za pomoci ROM primo na Unikartu.

Zdenkova i ma emulace je klasicky stavovy stroj, ktery kooperuje s ROM 
tak, ze zna filesystem, reaguje na presnou specifikaci synchronizacnich 
znacek, bloku, atd ... Pokud bude na Sharpu existovat alespon jedna 
jedina smysluplna aplikace, ktera bude ke QD pristupovat jinak, tak ma 
smysl uvazovat o emulaci v RAW mode - v takovem pripade bych vsak spise 
uvazoval o binarni podobe image.

Jinak Zdenek zrejme urcil velikost QD image podle poctu bajtu, ktere ROM 
posila pri formatovani media. Ja jsem to opsal podle nej, protoze QD 
zatim k dispozici nemam, takze jsem udelal siulaci jeho emulatoru :) 
Nevidim vsak problem v tom, aby se tato hodnota zvednula - pokud je 
fyzicka mechanika ochotna zapisovat nad tuto hranici.

Michal

Dne 18.2.2016 v 12:59 Radek Suk napsal(a):
>
> Michale ale nebylo by spatne pohovorit jak hodne kompatibilni ma byt 
> emulator. Protoze kdyz jsem prochazel rutinky v promce MZ800 tak jsem 
> zjistil, ze maximalni pocet souboru muze byt 32 ale to se mysli jen 
> 'info' (hlavicka). Co se tyce 'tela programu', zde neni zadne omezeni. 
> Nic nikomu nebrani aby klidne za sebou nahral tri tela. Rutinky Write 
> a Read jsou na to pripravene primo od Sharpa. Z toho plyne, ze udelani 
> image z mzf souboru neni obecne mozne. Samozrejme pro drtivou vetsinu 
> uzivatelu to bude dostatecne ale neemuluje to realny stroj a jeho 
> moznosti. Dokonce muzes ulozit na medium data tak, ze nezmenis FN a 
> tak ani nebudou videt ale pujdou precist. Pri zapisu se dokonce udela 
> i jejich verifikace. Take nezapomente ze QD ma minimalni kapacitu 60KB 
> ale jak Michal Medek zjistil muze se tam nahrat az skoro 75KB. Zdenkuv 
> emulator umi jen 60KB a pri zapisu nad tuto hodnotu uz hlasi error. Co 
> je OK ale bude problem az opravdu nekdo z realneho QD media udela 
> kopii a bude to chtit pouzit v emulatoru.
>
> Osobne si myslim ze image QD media by mela byt neco jako XML soubor. 
> Uz proto aby to bylo pekne citelne primo v nahledu total commanderu a 
> pripadne mala uprava by sla udelat v poznamkovem bloku.
>
> Kdyz by byl zajem tak jsem pro diskusi jak funguji rutiny Write a Read.
>
> Radek
>
>
> Dne 18.2.2016 v 10:18 Michal Hucik - ORDOZ napsal(a):
>>
>>
>> Ahoj,
>>
>> pridal jsem do emulatoru podporu quick disku. Podporuju dva typy: 
>> klasicky MZ 1F11 ve forme Zdenkovych MZQ image souboru a virtual QD, 
>> coz je namapovany adresar z PC, ktery se potom chova jako QD medium.
>>
>> Image:
>> ======
>>
>> Pokud pri mount image pouzijete jmeno doposud neexistujiciho MZQ 
>> souboru, tak se automaticky vyrobi novy image, ktery je pak potreba 
>> naformatovat.
>> Vsimnul jsem si, ze Zdenkuv emu zrejme vyrabi image o 1 bajt vetsi, 
>> nez je ve skutecnosti potreba. Netestoval jsem kompatibilitu, ale 
>> snad by s temi mymi mensimi MZQ nemel byt ve Zdenkovem emu problem.
>>
>> Virtual:
>> =======
>>
>> Emulator v adresari vidi jen soubory s priponou MZF. To jak jsou 
>> soubory nativne serazeny pri listovani adresarem  je zaroven 
>> presentovano jako jejich poradi na QD mediu.
>>
>> Ukladani souboru na QD: pokud na QD v emulatoru ulozite nejaky 
>> soubor, tak se nejprve vytvori qd_temp.tmp, ktery se po dokonceni 
>> operace pokusi emulator prejmenovat na soubor se jmenem, ktere 
>> odpovida nazvu uvnitr MZF + mzf pripona.
>>
>> Virtual QD umi rozeznat pokus o formatovani media a tento prikaz 
>> ignoruje. Pokud formatujete prazdny adresar, tak to probehne bez 
>> chyby. Pokud se v adresari nachazi nejake MZF soubory, tak se ROM 
>> pokusi formatovani 5x zopakovat a pak vyhlasi hardware error.
>>
>> Zrojak je zatim dost neucesany. Modul je jiz castecne pripraven k 
>> implementaci do unikarty. Z tohoto duvodu jsem zde udelal i nekolik 
>> kompromisu v tom jak se virtualni medium chova.
>> Po ulozeni souboru na QD si ROM provadi kontrolu ctenim. Pri tomhle 
>> kontrolnim cteni je nove ulozeny soubor vzdy zarazen jako posledni, 
>> nicmene pri jakemkoliv normalnim cteni je jiz zarazen v takovem 
>> poradi, jak mi jej vyda sluzba pro cteni adresare.
>>
>> Win32 snapshot devel verze:
>> http://duna.ordoz.com/emu_devel/mz800emu-1.0.2_devel-20016-02-18-win32-with_gtk_and_sdl_libs.rar
>>
>> Michal
>>
>>
>>
>> _______________________________________________
>> SharpMZ mailing list
>> SharpMZ na mail.ordoz.com
>> http://mail.ordoz.com/mailman/listinfo/sharpmz
>
>
>
> -- 
> *Radek* *Suk*
> Vedoucí administrátor sítě
> SOFTEX NCP, s.r.o., RĹŻĹžovĂĄ 1426, 434 01 Most
> Web: www.softex.cz, Tel.: 840 77 88 99
>
>
>
>
> _______________________________________________
> 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/20160218/4ccbf8c4/attachment-0001.html 
------------- další část ---------------
Netextová příloha byla odstraněna...
JmÊno: [Şådný popis není k dispozici]
Typ: image/jpeg
Velikost: 12005 bytes
Popis: [Şådný popis není k dispozici]
Url : http://mail.ordoz.com/pipermail/sharpmz/attachments/20160218/4ccbf8c4/attachment-0002.jpe 
------------- další část ---------------
Netextová příloha byla odstraněna...
JmÊno: [Şådný popis není k dispozici]
Typ: image/jpeg
Velikost: 24632 bytes
Popis: [Şådný popis není k dispozici]
Url : http://mail.ordoz.com/pipermail/sharpmz/attachments/20160218/4ccbf8c4/attachment-0003.jpe

Další informace o konferenci SharpMZ