HTP formátum

[László Princz]

Sziasztok!

Próbálok egy BAS2HTP konvertert összehozni. A BASIC kód generálása már nagyjából rendben is van, a MAME emulátorba be is tudom tölteni, de a windowsos emulátorok nem töltik be. Úgy tűnik, nem megfelelő HTP formátumot generálok.

Tudtok valami információt adni az új HTP formátumról? Mintha a programnév után lenne még benne egy 143 bájtos blokk az adatok előtt.

A wav2htp program - úgy tűnik - még a régi formátumú htp kódot generálja.

Olyan forráskód is elég lenne, ami már az új HTP kódot generálja, vagy azt tölti be.

Előre is köszönök minden segítséget! :)

[László Princz]

Közben kiderült számomra, hogy azért nincs külön HTP formátumleírás, mert ez egy az egyben a kazettaformátum fájlváltozata, amiről meg már van némi dokumentáció, bár nem teljes.

Tudja valaki, hogy hogyan kezeli az Aircomp 16 betöltőjel a több blokkos rekordokat? Elvileg a rekord végén lévő bájt jelzi, hogy van-e még újabb blokk, de ez a bájt néha lemarad a htp fájlok végéről. Ha meg készítek egy megfelelő formátumú wav fájlt, ami több blokkból áll, akkor az Aircomp nem tudja betölteni. Az egy blokkból állót betölti, de a több blokkból állónál nem áll le a betöltés.

- Van konkrét érték, amit elvár blokkelválasztónak? Én most 0xFF értéket használok.

- Van konkrét mérete a folytatólagos blokkok headerjének, amit elvárna? A dokumentáció csak annyit ír, hogy rövidebb, mint az első.

- Van valami egyéb trükk, amit tudni kellene a több blokkból álló fájl betöltéséhez?

[László Princz]

Sikerült a ROM visszafejtésével kiderítenem, mi a pontos protokollja a több blokkos htp fájl elkészítésének - amit aztán wav fájlba lehet már egyszerűen konvertálni.

A kérdés, hogy mi pontosan a második blokk fejléce.

Tehát a teljes többlokkos HTP szerkezete

- sok darab 0 bájt. Ennek nem kell feltétlen 256 darabnak lenni. (Még talán 0-ának sem, bár ezt még nem teszteltem, de a ROM 0xA5 bájtig olvas.) Az első blokk esetén 256 szokás, a későbbiekben kevesebb, de úgy tűnik, lényegtelen a számuk.

- 0xA5 bájt. Mind az első, mind a későbbi blokkok esetén kell.

- A blokk neve. A legelső blokk esetén itt a rekord név állhat. A név végén egy 0 karakterrel. A további blokkok esetén csak egy 0x00 kód áll. Ez szükséges! Valószínűleg a legelső blokknál is elég egy 0x00 kód magában, név nélkül, ezt nem teszteltem.

- Adatblokk kezdőcíme, 2 bájt (low/high bájtsorrend)

- Adatblokk mérete 2 bájt (low/high bájtsorrend)

- Adatbájtok egymás után. Innentől kezdődik a CRC számítása, azaz egy külön bájtban összegezzük a kiírt adatokat - természetesen túlcsordulással.

- CRC bájt értéke

- Blokkvége jel. Ha nem 0, akkor egy fentieknek megfelelő új blokk következik. Ha 0, a betöltésnek vége.

Természetesen a BASIC automatikus start funkciója csak LOAD alkalmával hajtódik végre, tapasztalataim szerint az egyszerű HTP betötlés önmagában nem szimulálja az autóstartot.

[Attila Grosz]

Szia!

Köszi szépen, ez hasznos, már nagyon régen foglalkoztam a HTP-veligen, anno 2004 körül csak annyit csináltam, hogy pár ROM csapdával az emulátorban egy byte kisípolását mindeig egy file-ba irányítottam. Amit így abban találunk az egy az egyben az a bitfolyam amit a gép kiír a magnóra.

Egyébként a formátum némileg emlékeztet a TRS-80-ra (HT), legalábbis ott is ilyesmi fejléc van (érdemes a CAS file formátumot megnézni hozzá).

Ott egyébként még az sem garancia, hogy 8 egész számú többszörösét írja ki az elején a 00-kal, emiatt vannak olyan CAS file-ok, amik látszólag nem azok, az azért van mert el van shiftelődve.

üdv

Attila

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „Homelab/Aircomp levlista” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) homelab+u...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/homelab/124aaf37-a2d9-468c-bc6b-668b118a2149n%40googlegroups.com.

[Attila Grosz]

A CRC-t esetleg nem tudod hogy van? Sima XOR ugye? De hol kezdi pontosan?

köszi

Attila

On Tue, Aug 22, 2023 at 2:37 PM László Princz <princz.la...@gmail.com> wrote:

[László Princz]

Mármint a homelab 2 CRC? Az az adattartalomra vonatkozik, és egyszerűen csak összegzi a bájtokat. Még XOR sincs. Beolvassa start address 2 bájtját, majd a hossz 2 bájtját,és az ezután a CRC-ig következő adatbájtokból képzi a CRC értéket egyszerű összeadással.

Feltettem a konvertert a github-ra h2CreateHtp néven (forrást is és win/linux binarisokat):

https://github.com/linuxforum5/homelab2utils

A h2bas2htp csak egy kezdeti változat, a h2CreateHtp az, ami teljes értékű, és amit a későbbiekben is fejleszteni fogok.

Igaz, hogy egyelőre csak 2 blokkot kezel, ezek közül az első a BASIC, a másik meg a gépikódú. Ha jól láttam, a betöltés után nincs lehetőség direkt ugrással kódfuttatásra, ezért mindenképpen kell egy BASIC program, amiben van egy CALL. (???)

Továbbá még a TOKEN táblát sem értem teljesen, hogy miért van benne két lyuk. Így ugyan működik a BASIC értelmezőm, de azért nem szép ...

A TOKEN táblából a -l paraméter határása készít egy TOKEN listát, ami így lyukasan nem az igazi azért, de használható.

Annyit még érdemes tudni a BASIC htp blokk generálásáról, hogy képes sorszám nélküli forráskódból is futó BASIC programot generálni. Ilyenkor a sorok elején sorszám helyett "{" és "}" karakterek közötti címkét lehet elhelyezni, ha később ugrani akarunk rá, majd a BASIC kódban az adott sorszám helyett ugyanezt a címkét kell használni. Például 10 GOTO 10 helyett {CIMKE} GOTO {CIMKE} szerepelhet a forrásban.

Valamint alapértelmezésben a '"! karakterek utáni részt - ezekkel a jelekkel együtt -  kihagyandó szövegnek tekinti, így ez be sem kerül a htp fájlba.

Az üres sorokat is átugorja.

Így egy picit könnyebb BASIC programot írni.

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/homelab/CADu2e8tzepK7mTLLZA6zA-MxYvpf7JYj6KGYWvfmB5%3D8cHUFVg%40mail.gmail.com.

[Attila Grosz]

szia!

Igen, arra gondoltam. ROM-ban még nem kerestem a CRC számolást egyébként melyik címen van?

Köszi a linket, le is klónoztam a repoidat - látom kimaxolod a tape image témát :D Az EACA Colour Genie-n meg is lepődtem :-O

Egyébként klasszak ezek a tool-ok, kéne promózni. Nekem is volt egy projektem (emuwav) ami egy branchbe rendezte volna az összes emu image --> WAV konverziót, de aztán alábbhagyott a lelkesedésem, meg rájöttem jobb ha gép specifikus.

Ja, és csináltam egy "nem-standard" 1-bites WAV formátumot is, amit a legtöbb emum be tud tölteni, értelemszerűen 8-ad annyi helyet foglal mint egy 8 bites PCM.

Jó lenne támogatni (a HL emum is tudja), itt bele tudsz pillantani:

https://github.com/calmopyrin/mtapwav/blob/main/wav2tap.c

üdv

Attila

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/homelab/CAB%2BJiRdMmmVs1YL3fbuWmrUhVNF2X9Td1g3at0mJaQ4LWBNwrA%40mail.gmail.com.

[László Princz]

Egy blokk beolvasása a 0130 címen kezdődik (minden szám hexa lesz).
A CALL 057D rutin A-ba beolvas egy bájtot a kazettáról.
Az adatok konkrét betöltés a 05B3 címen kezdődik, már a fejléc elolvasása és értelmezése után:

A következő rész beolvassa a  betöltési címet a HL regiszterpárba
05B3 -  CALL 057D
05B6 - LD L, A ; Alacsonyat először
05B7 - CALL 057D
05BA - LD H, A ; Magasat másodszor

Majd a betöltési méretet BC-be
05BB - CALL 057D
05BE - LD C, A ; Alacsonyat először
05BF - CALL 057D
05C2 - LD B, A ; Magasat másodszor
05C3 -  LD D, 0 ; D nullázása. D-ben fogja a CRC-t tárolni.

Innentől kezdődik a BC bájt beolvasása a memóriába HL címtől, D-ben pedig a CRC- tartja nyilván.
05C5 - CALL 057D : Beolvas egy bájtot a kazettáról A-ba
05C8 - LD (HL), A
05C9 - ADD A, D : A-ba a megnövelt CRC érték
05CA - LD D, A : CRC visszaírása D-be
05CB - INC HL
05CC - DEC BC
05CD - SUB A : A nuzllázása BC==0 feltétel ellenőrzéséhez
05CE - OR B ; A = 0, Ha B==0
05CF - OR C ; A = 0, ha BC==0
05D0 - JR NZ, 05C5 : visszaugrás a loop elejére, amíg BC != 0

Be van olvasva a betöltendő adat. A kimentett CRC érték olvasása következik:
05D2 - CALL 057D : A CRC beolvasása A-ba
05D5 - CP D : Összehasonlítjuk a CRC értékével. Z flag = 1, ha rendben van
05D6 - LD A, D8
05D8 - RET ;Visszaugrás a 05DC címre. A-ban a D8, Z flag=1, ha CRC ok

CRC olvasása után ide ugrottunk
05DC : JR NZ, 05E6 : Ha hibás a CRC, akkor ugrás a 05E6 címre - gondolom, hibakezelés, de nem mentem már utána
05DE : CALL 057D : BLokkzáró bájt olvasása!
05E1 : LD C, 30
05E3 : JP NZ, 0130 : Ugrás a következő blokk beolvasására, ha a lezáró bájt nem volt 0
05E6 : JP 05FE : Ugrás a 05FE címre, ha befejeződött a betöltés. C=30

[László Princz]

A ROM visszafejtés CRC-t érintő részét külön küldtem, gondolom, így használhatóbb.

Kéne talán egy olyan repo is, amibe mindenki tölthet fel információkat, hogy egy helyen gyűljenek, de bevallom, azért repo téren sem vagyok még nagyon otthon.

A kazettaformátumokkal meg azért küzdök ennyit, mert ha el is jut hozzám egy gép, szint biztos, hogy csak magnóval lehet rá betölteni. De azért ezeken a régi gépeken fejleszteni ...

Tehát ha bármit is látni akarok rajtuk, kényszerpálya.

Amúgy, ha a forrásaimat nézed, ne lepődj meg, ha ismerős kódrészletekre bukkansz! :) Szerintem elég sok kódomat kezdtem úgy, hogy a Te valamelyik forrásodon kezdtem alakítgatni. (Köszönet érte!)

A wav-ok méretével én is küzdöttem, de csak mint felhasználó. Én egy kiöregedett telefont akartam magnó helyett használni, és így végül a bzip2-vel tömörített wav fájlnál maradtam. Ez hihetetlenül pici tömörítve, és a VLC-Player közvetlenül le tudja játszani.

Rá fogok nézni erre az 1 bites wav-ra. Izgalmasan hangzik!

Attila a következőt írta (2023. augusztus 27., vasárnap, 11:02:34 UTC+2):