<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Ahoj Radku,<br>
<br>
tech 32 souboru je limit v ROM ... filesystem, image, emulator,
ani virtualni QD takove omezeni nezna. <br>
<br>
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.<br>
<br>
Z toho co jsem dale vyzkoumal u filesystemu, tak datove bloky se
zkladaji z:<br>
<br>
- synchronizacni znacky<br>
- 1 bajt typ bloku (0x00 - header MZF, 0x05 - telo MZF)<br>
- 2 bajty velikost bloku<br>
- telo bloku<br>
- CRC<br>
<br>
Tim je jasne urceno, ze velikost bloku nemuze byt vetsi, nez
0xffff. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
Michal<br>
<br>
Dne 18.2.2016 v 12:59 Radek Suk napsal(a):<br>
</div>
<blockquote cite="mid:56C5B20D.9000907@radeksuk.cz" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=iso-8859-2">
<br>
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.<br>
<br>
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.<br>
<br>
Kdyz by byl zajem tak jsem pro diskusi jak funguji rutiny Write a
Read.<br>
<br>
Radek<br>
<br>
<br>
<div class="moz-cite-prefix">Dne 18.2.2016 v 10:18 Michal Hucik -
ORDOZ napsal(a):<br>
</div>
<blockquote cite="mid:56C58C61.5040606@ordoz.com" type="cite"> <br>
<br>
Ahoj,<br>
<br>
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.<br>
<br>
Image:<br>
======<br>
<br>
Pokud pri mount image pouzijete jmeno doposud neexistujiciho MZQ
souboru, tak se automaticky vyrobi novy image, ktery je pak
potreba naformatovat.<br>
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.<br>
<br>
Virtual:<br>
=======<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
Win32 snapshot devel verze:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://duna.ordoz.com/emu_devel/mz800emu-1.0.2_devel-20016-02-18-win32-with_gtk_and_sdl_libs.rar">http://duna.ordoz.com/emu_devel/mz800emu-1.0.2_devel-20016-02-18-win32-with_gtk_and_sdl_libs.rar</a><br>
<br>
Michal<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SharpMZ mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
</pre>
</blockquote>
<br>
<br>
<br>
<span>--</span>
<div><img src="cid:part4.06090603.02030601@ordoz.com"><b>Radek</b>
<b>Suk</b></div>
<div>Vedoucí administrátor sítě</div>
<div>
<div><span>SOFTEX NCP, s.r.o., Růžová 1426, 434 01 Most</span></div>
<div><span>Web: <a class="moz-txt-link-abbreviated" href="http://www.softex.cz">www.softex.cz</a>, Tel.: 840 77 88 99</span></div>
</div>
<div><br>
</div>
<div><img src="cid:part5.07010608.08070905@ordoz.com"></div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SharpMZ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<a class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
</pre>
</blockquote>
<br>
</body>
</html>