OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů

Registrace na OCP IV ZDE!

Právě je 22 říj 2018, 20:52

Všechny časy jsou v UTC + 1 hodina




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 5 ] 
Autor Zpráva
 Předmět příspěvku: Emulácia QD - otázky
PříspěvekNapsal: 19 dub 2015, 21:22 
Offline
Profík
Uživatelský avatar

Registrován: 09 říj 2013, 18:04
Příspěvky: 739
Has thanked: 86 times
Been thanked: 28 times
Robím jednoduchú emuláciu SIO. V podstate len tie výstupy a vstupy, ktoré vyžaduje QD, plus pár drobností navyše, bez ktorých by to monitorom neprešlo.

Keď formátujem QD, zapíše sa nejaká synchronizácia a od adresy 0002h na QD sa začne zapisovať obsah QD (spolu je to EFFFh + 2 bajty). Keď sa kontroluje naformátované, tak sa načítajú 2 synchronizačné bajty, potom 3+2 bajty akési CRC, ktoré sa ale pri formátovaní nezapíše a až potom sa začína kontrolovať obsah QD (spolu je to EFFFh + 7 bajtov). To znamená, že medzi zapísaným a prečítaným je posun 5 bajtov. Priznám sa, že nemám úplne naštudované správanie SIO, ale mám podozrenie, že tie CRC bajty nie sú fyzicky uložené na QD, ale sa jedná o niečo iné. Je mi jasné, že pre emuláciu QD netreba plne emulovať SIO a rád by som sa tomu vyhol.

Zaujímalo by ma teda toto:
1. Ako mám detekovať, že ide o CRC, aby mi nevznikol posun medzi čítaním a zápisom?
2. Ako toto CRC počítať, aby QD správne pracovalo?
3. Zdeněk nejaké CRC v obrazoch MZQ má, ale jeho formátu nerozumiem a dodnes sa mi jeho popis nepodarilo zohnať. Popis uvedený na http://www.sharpmz.org/qdinside.htm je so Zdeňkovým formátom nekompatibilný.
4. Ako dostať na QD obraz väčší súbor s adresou v ROM? Napr., 1Z-016? Cez ROM rutiny sa mi to nepodarilo a tiež sa mi nepodarilo nájsť ani kopirák, čo by to dokázal. V minulosti som už BASIC na QD dostal, ale žiaľ nespomínam si na postup, ktorý som použil.

_________________
Sharp MZ-821
Milsa MZ-841


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Emulácia QD - otázky
PříspěvekNapsal: 20 dub 2015, 11:08 
Offline
Prvnička

Registrován: 23 zář 2014, 10:30
Příspěvky: 12
Bydliště: Pelhřimov
Has thanked: 5 times
Been thanked: 2 times
Shodou okolností si pro sebe vyrábím program v Perlu, který má umět z několika MZF souborů sestavit obraz QD, či naopak z obrazu vyextrahovat program do MZF (už jsem to tu zmiňoval někdy kolem Vánoc, ale pořád se nějak nemůžu dostat k tomu to dodělat do publikovatelné podoby :-( ), takže jsem se zajímal o strukturu MZQ souborů a můžu vám dát pár informací ke třetí otázce.

Tady je popis struktury MZQ souboru (mám to jako komentář na začátku programu):
# Struktura MZQ souboru:
# 00 16 16 A5 aa 43 52 43 00 16 16 A5 bb cc cc ...
# SYNC aa CRC SYNC bb cc cc hlavicka CRC SYNC dd ee ee data CRC SYNC ... CRC
#
# SYNC 4 byty: 00 16 16 A5
# CRC 3 byty: 43 52 43
# aa 1 byte: pocet datovych bloku v souboru (= pocet souboru / 2)
# bb 1 byte: priznak datoveho bloku s hlavickou (mel by byt 00)
# cc cc 2 byty: delka datoveho bloku (hlavicka by mela byt 40 00)
# dd 1 byte: priznak datoveho bloku s daty (mel by byt 05)
# ee ee 2 byty: delka datoveho bloku
#
# Struktura hlavicky:
# ff jmeno gg gg hh hh ii ii komentar
#
# ff 1 byte: typ souboru
# nazev 19 bytu: jmeno souboru ukoncene 0D
# gg gg 2 byty: velikost souboru (mela by byt shodna s delkou nasledujiciho datoveho bloku = ee ee)
# hh hh 2 byty: zavadeci adresa
# ii ii 2 byty: spousteci adresa
# komentar 38 bytu, pry se nepouziva

V odkazovaném popisu je chyba v popisu hlavičky "DATA 40 length of the following data", kde je jen jeden byte, ale délka hlavičky je uložena ve dvou, stejně jako délka dat. Dále je tam udedeno, že datový blok má type byte 01, ale já všude našel 05.
Pak je tam ještě zrada v tom, že některé MZF soubory jsou delší, než udává délka v hlavičce. Už jsem to tu taky řešil a vzniká to prý tak, že když se soubor protáhně přes CP/M, tak to ho zarovná na násobek tuším 128 bytů. Tahle chyba/vlastnost se přenáší i do do MZQ soubrů, takže občas je datový blok delší než uvádí hlavička. Kupodivu nejen hlavička programu, ale dokonce i záhlaví samotného datového bloku - u mě byty označené ee ee. To už mi fakt přijde jako chyba, ale mají to téměř všechny MZQ, které jsem zkoumal, a emulátorům ani unikartě to nevadí. Plyne z toho, že při čtení se nedá spoléhat, že za koncem dat je hned další synchronizační sekvence, ale je třeba ji hledat.

S těmito informacemi jsem byl schopen vyrobit program, který mi spolehlivě přečte a rozebere všechny MZQ soubory, které jsem na Internetu našel, případně jinými programy vyrobil, takže další záludnosti tam snad nejsou (je fakt, že zatím nemám dodělanou tvorbu MZQ, takže na ně možná narazím, až začnu produkovat MZQ, které mi emulátory budou odmítat ;-) ).

Ještě dvě poznámky: Některé MZQ mají fixní délku 64 KB bez ohledu na obsah (ty vyrábí např. odkazovaný MZQDTool), jiné jsou kratší, končí za posledním datovým blokem. Zdá se, že emulátorům je to jedno.
Čísla typů souborů se kupodivu u nekterých typů liší pro kazeťák a QD, z nejpoužívanějších je to snad jen BSD, který má pro CMT 04 a pro QD 03 a BTX - CMT = 05, QD = 02 (nevím, jestli to pro Vás má význam).


Snad jsem Vám trochu pomohl, ať se práce daří!

AZ


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Emulácia QD - otázky
PříspěvekNapsal: 20 dub 2015, 13:46 
Offline
Profík
Uživatelský avatar

Registrován: 09 říj 2013, 18:04
Příspěvky: 739
Has thanked: 86 times
Been thanked: 28 times
Ja ešte doplním, že ak som správne pochopil text, na ktorý odkazujem, tak začiatok nového bloku sa hľadá práve podľa tých 16h 16h, takže zrejme to bude tak ako píšeš. Ono to prejde na koniec súboru a potom hľadá 16h 16h a pokračuje ďalej. Podľa monitora je dĺžka dát Quick disku presne efffh, čiže 60 kB. Reálne sa tam vraj vojde až cca 75 kB. Niekto to testoval.

Hlavne ma trápi, že ako rozpoznám koniec synchronizačných bajtov a začiatok dát, aby som nemal vyššie uvedený posun.

_________________
Sharp MZ-821
Milsa MZ-841


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Emulácia QD - otázky
PříspěvekNapsal: 20 dub 2015, 18:58 
Offline
Prvnička

Registrován: 23 zář 2014, 10:30
Příspěvky: 12
Bydliště: Pelhřimov
Has thanked: 5 times
Been thanked: 2 times
Když to po sobě čtu, asi jsem to nepopsal úplně přesně.
Odkazovaný popis sice popisuje jednotlivé byty jako BREAK, SYNC1, SYNC2 atp., ale fakt je ten (aspoň pokud jsem to správně analyzoval), že KAŽDÝ datový blok (včetně úvodního jednobytového udávajícího počet bloků), začíná čtyřbytovou magickou sekvencí 00 16 16 A5, kterou jsem si označil jako SYNC, a končí tříbytovou sekvencí 43 52 43, kterou si označuji jako CRC (ze začátku mi chvíli trvalo, než mi došlo, že 2 byty označované CRC ve skutečnosti zádný kontrolní součet neobsahují).
Dále ve všech MZQ, které jsem zkoumal, mezi datovými bloky vždy následuje SYNC sekvence bezprostředně po CRC sekvenci předchozího bloku, tedy se dá říct, že datové bloky jsou odděleny sedmibytrovou sekvencí 43 52 43 00 16 16 A5.

Z toho vyplývá, že data, která jsou navíc za datovým blokem, jsou ještě před ukončovací CRC sekvencí. Takže při pátrání po konci bloku nehledám, jak jsem chybně uvedl, následující synchronizační sekvenci, ale koncovou CRC sekvenci. A pak spoléhám na to, že po ní následuje SYNC dalšího bloku.
S tímhle jsem se nejvíc vyblb, když jsem napsal program, který prolézal MZQ podle údajů v hlavičce a on hned za prvním blokem s daty zařval, že na konci není CRC, které tam čeká. A já to pak louskal v hexaeditoru a divil se, proč je proboha o několik bytů dál, než by mělo být podle údajů v hlavičce.

Dal jsem do přílohy jednu ze starších verzí mého veledíla, která vylistuje seznam souborů uložených v MZQ souboru zadaném jako parametr. Pokud to chcete spouštět, opravte si příponu z .bas na .pl, nechtělo mi to povolit ani .pl, ani .txt... Je tam vidět algoritmus, kterým to prohledávám, snad to bude srouzumitelné i neperlistům, on je to trochu takový BASIC...

AZ


Přílohy:
MZQdir.bas [4.68 KiB]
108 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: Emulácia QD - otázky
PříspěvekNapsal: 26 dub 2015, 09:38 
Offline
Profík
Uživatelský avatar

Registrován: 09 říj 2013, 18:04
Příspěvky: 739
Has thanked: 86 times
Been thanked: 28 times
Ďakujem aj za toto. Určite mi to pomôže do budúcna. Teraz mám ale odlišný problem. Preto píšem až teraz, lebo skôr som sa k tomu nedostal.

Monitor totiž zapisuje na port F4h menej bajtov než číta z portu F4h. Tento problém neviem riešiť. Preto tam mám offset 5 bajtov.

_________________
Sharp MZ-821
Milsa MZ-841


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 5 ] 

Všechny časy jsou v UTC + 1 hodina


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 2 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz