mop píše:
Testoval jsem zatím jen ve Windows, vybral jsem pár kratších her (Addtris, Man Hunt, Bomber Man) a zapisoval je do WAVů různými rychlostmi v Turbo Copy V1.21 v emulátoru a přikládám postřehy:
Ve kterem emulatoru? V mojem, nebo v emulatoru Zdenka Adlera? Ten Zdenkuv totiz ty ulozene WAV soubory mnohdy neumi precist ani sam po sobe
mop píše:
1) hry uložené rychlostí 3/1 utilita nepřečte, hlásí "Found 0 file(s)" když jsou uložené bez loaderu, resp. "Error when reading file TURBO body '4'! Found 0 file(s)" s loaderem
'TURBO body 4' - znamena, ze nacetl header, nacetl normal body, identifikoval ho jako TURBO loader, nasel a zacal cist zrychleny body, ale pocet bajtu mu nesednul a narazilo se na EOF (konec WAV souboru)
Pokud ten soubor pochazel odjinud, nez ze Zdenkova emulatoru, tak ma smysl se na nej podivat - mozna zkusit i zmenit polaritu
mop píše:
2) délka ticha na konci WAVu má velký vliv na dobu zpracování, např. addtris.wav s cca 1,5sekundovým tichem na konci utilita chroustala asi 6 sekund, kdežto ta samá hra s cca 3,5sekundovým tichem na konci trvala asi 28 sekund
To zni dost divne ... Mam tady napr. zaznam, ktery jsem nahral zvukovkou kabelem primo ze Sharpa a je tam pomerne dost "ticha" pred i za i mezi headerem a body a veskere tohle ticho je vyplneno neskutecnym sumem, ktery zpusobuje to, ze tam mam primo nad audio konektorem pripevneny FPGA scandoubler. Zaznam jsem nahral v TC 1.21 rychlosti 3:1, bez loaderu a Intercopy u toho zaznamu pri nacteni napsal, ze to ma 2756 Baud.
Takhle vypada zpracovani s verbose vystupem - doba behu programi pri zpracovani je 0.038 sekundy:
$ time ./dist/Release-Linux/GNU-Linux/cmttool ../mz800emu/CMT/WAV/save_TC31_2756.wav -v
MZ cmttool ver 1.0
Analyzer open file: ../mz800emu/CMT/WAV/save_TC31_2756.wav
Polarity: normal
Start time: 0,000000 s
Searching MZF header
Search block - tapemark: 40, size: 0x0080, position: 0
Header found! (4091 Baud/s). End at position: 369026
fname: OOO
ftype: 0x01
fstrt: 0x0000
fsize: 0x1001
fexec: 0x0000
Search block - tapemark: 20, size: 0x1001, position: 369026
Body - OK! (3226 Baud/s). End at position: 1017498
Searching MZF header
Search block - tapemark: 40, size: 0x0080, position: 1017498
Found 1 file(s)
ID Format Type File name Size Start Exec Pos.(s)
0 NORMAL 0x01 OOO 0x1001 0x0000 0x0000 0,000000
real 0m0.038s
user 0m0.030s
sys 0m0.006s
Kdyz tak mi nejake zajimave WAV posli - podivam se na to.
mop píše:
3) výsledné MZF soubory mají na 17. bajtu hlavičky (počítáno od nuly) natvrdo hodnotu 0x0d (což ničemu nevadí, akorát výsledek pak nemusí být úplně shodný s předlohou)
Ano, to je zamer, protoze podle definice MZF by tam ten 0x0d mel byt. Narazil jsem uz na par MZF, ktere za jmenem nemely zadny terminacni znak, takze moje knihovna pro praci s MZF to timhle zpusobem fixuje - kdyby to nekomu melo v necem vadit, tak tam lze samozrejme pridat option, kterym se tohle chovani vypne, ale jak rikam - spravne to tam ma byt.
PS: Tohle je ten muj WAV 3:1 nahrany ze Sharpa - obsah neres - je tam dolni ROM
https://ordoz.com/nesmysly/save_TC31_2756.wav