OldComp.cz

Ahoj,

nová utilita pro nastavení magnetofonu je nyní součástí Ondra+ ROM, ale pro ty, kteří mají původní ROM v kombinaci s OndrouSD a přesto by si chtěli vyladit magnetofon, jsem tuto utilitu připravil pro nahrání z OndraSD. Viz příloha.

Zopakuji princip, stejně jako například na c64 se snažíme vyladit magnetofon tak, aby se na obrazovce vytvořily během přehrávání programového bloku pokud možno co nejužší dva svislé pásy s minimalizací okolního "smetí". Čím širší pásy, tím je horší opakované rozlišení nosných frekvencí. "Smetí" okolo znamená hodně šumu nebo parazitní jevy.

Trochu technických podrobností o principu:

Záznam je tvořen dvěma frekvencemi, čili délkami pulsů. Délka pulsu je reprezentována vzdáleností směrem vpravo. Čím delší puls, tím je vykreslen na obrazovku bajt směrem více vpravo. Vzhledem k principu Ondry mohu snímat vstup z MGF jen v době zatemnění, proto jsem zvolil poloviční zobrazení. Po každém půlsnímku se čeká na první hranu (nahodí se fáze), teprve potom je měřená doba k další hraně. Takto nashromáždím 50 pulsů, které jsou vykreslovány v jedné lince, a aby to líp vypadalo, vykresluju "náhodný" bajt z registru r pořád přes sebe.. ve výsledku to udělá plnou linku tam, kde je záznam konzistentní, anebo se to rozsypává po celé délce. Toto měření se opakuje na každou novou řádku. Resp. ob řádek... to je kvůli zjednodušení, přesná adresace po řádku u Ondry znamená více strojového času, což jsem takto obešel. Obrazovka se po dojetí "na konec" překreslí. Ondra na plynulý scroll nemá jako to má c64, natož aby u toho měřil délky pulsů.

Určitě by se tato úloha dala řešit různými způsoby, já zvolil toto a důležité je, že si můžeme konečně udělat obrázek o celkové funkci našich magnetofonů. V emulátoru z ideálního waw souboru se vytvoří krásné úzké pruhy, kam se v praxi přibližuji pouze s rekordérem SP-210 a kazetou nově nahranou Sony HF-90 nebo RAKS. Starý záznam z dobových emgetonek a kazeťáku K-10 je přibližně jako na přiloženém obrázku, kdy se čtení musí občas opakovat.

Kazetám zdar

_________________
https://github.com/72ka

Super. Možná by nebylo od věci tam nějak naznačit ideální kmitočty. Třeba k nastavení rychlosti pásku a nejen kolmosti hlav.

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

No uvažoval jsem o tom, ale v ROM zbylo 37 bajtů tak už jsem to nerozšiřoval. Do této verze bych to udělat mohl.

_________________
https://github.com/72ka

To mi pripomina ze nieco podone pod nazvom Recorder Justage som kedysi davno spravil aj ja pre ZX

A aj na ZX funguje presne ten isty princip. Dve rozne dlzky pulzov maju vytvarat dva jasne uzke pruhy.

Ako presne funguje tato verzia pre Ondru ? Myslim v suvislosti so zdrzovanim CPU kvoli zobrazovaniu.
Stiha vytvarat pruhy aj pocas zobrazovania (kde je tusim len 5 ms casu v kazdych 20 ms ak si dobre pametam),
alebo chvilu "naslepo" meria signal a potom ho zobrazi ?

Je to popsané v hned v prvním postu, jak jsem se s tím vypořádal. Pokud je potřeba širší vysvětlení, napiš konkrétně jaká pasáž je málo podrobná a zkusím lépe vysvětlit.

_________________
https://github.com/72ka

Aha, ano, vdaka, to nejak uslo mojej pozornosti, slubujem ze nabuduce budem citat poriadne
Inak podobny princip funguje aj v ZX verzii, tam musi vzhladom na pevnu videoramku scroll odmakat CPU. To zaberie cca polovicu casu kazdeho frejmu, takze pulzy snimam iba pocas tej druhej polovice frejmu.

Ahoj, napsal jsem o tom nějaké povídání zde:

http://www.ondraspo186.8u.cz/?p=724

No a rozhodl jsem se zveřejnit i zdrojový kód, třeba to někdo ještě vylepší, tu samostatnou verzi. V ROM už není moc více prostoru.
Je to na githubu.

_________________
https://github.com/72ka

V komentovanom kóde "ROM-SSM" v. 27 sa uvádza rýchlosť 3880 b/s, vo verzii 16 dokoca 4000b/s.
V článku sa spomína 2400.
m1

Opravdu? Já vycházel ze SAPI informace od Smutného. Tak to je opravdu hodně. Možná těch 2400Bd myslel jako efektivní rychlost včetně mezi blokových mezer? Každopádně článek upravím.

A popravdě absolutní hodnotu délky pulsů jsem nevypočítával ze strojového času. Typicky mi proběhne smyčka asi 9x u kratšího pulsu myslím, takže podle tstates by se to dalo vypočítat a ověřit.

_________________
https://github.com/72ka

stačí stopky a uložit obsah rom

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

Nestačí.
ROM se nejspíš neuloží jako jeden blok, ale standardně jako sekvenční soubor rozsekaný do více bloků, s meziblokovými mezerami a hlavičkami, což ovlivní měření.
Spíš bych řekl, že informace od Smutného se týká MIKOSu (kompatibilita zápisu se SAPI).
SSM ROM to má zcela jinak.

Uložiť blok so samými 1 a ďalší so samými 0, potom pozrieť cez nejaký audio editor, tam sa to bude dať zistiť celkom jednoducho.
m1

Když už se tu tak diskutuje, kdo používáte také rádi na Ondrovi magnetofon? Nebo je tu někdo kdo jedině magnetofon? Případně jaký? Jenom by mě zajímalo jestli to co dělám využije i někdo jiný než já

_________________
https://github.com/72ka

Trochu jsem si se záznamem na kazetu poslední dobou hrál a je to asi takhle:

Data kilobajtového bloku na kazetě (čistě datové bajty, bez hlavičky a leaderu dat) trvají ~4,1 s. Zaznamenává se při tom 1026 bajtů dat (1 bajt typ bloku, 1024 bajtů dat, 1 bajt kontrola). Pro každý bajt se zaznamenává 9 bitů (nejdřív invertovaný nejnižší bit, a pak 8 bitů bajtu od nejnižšího po nejvyšší). Takže fyzická rychlost vychází na 1026*9 / 4.1 = ~2250 bit/s.

Jedničky i nuly jsou stejně dlouhé (narozdíl třeba od Spectra), akorát nuly mají první půlku vlny na nízké úrovni a druhou na vysoké a jedničky naopak - ale klidně to může být i obráceně , není to fázově závislé. Fázi určuje první (jakoby synchronizační) bit za leaderem. Ten (leader) se skládá čistě z krátkých pulsů - při save se zaznamenává 768 jedničkových bitů.

Díky tomu přidanému invertovanému bitu na začátku každého je bajtu je zajištěno, že se nikdy nevyskytne víc než 16 "krátkých" intervalů mezi hranami - přechod mezi 0/1 nebo 1/0 je vždy "dlouhý" interval. Proto není možné chytnout "falešný leader" někde uprostřed dat. Pro rozpoznání leaderu je potřeba zachytit za sebou aspoň 32 krátkých intervalů, ty se pak načítají dál dokud se nenarazí na dlouhý - tam začíná sychronizační bit a ten určuje fázi jedničky.

Jako "mezibloková mezera" před leaderem hlavičky se zaznamenává 128 (krátká) nebo 384 (dlouhá mezera) bajtů od 0xD6AE (FCBFLAGS). Tedy konec systémové oblasti + zero page + začátek video RAM. Popravdě význam této meziblokové mezery mi není úplně jasný, resp. proč tam nemůže být "normální ticho"? Možná aby se nějak srovnalo nabuzení vstupních(při save)/výstupních(při load) obvodů v kazeťáku? Asi blbost, co?

_________________
Zdraví
joker

Vůbec to není blbost, když jsem si dával signál na osciloskop tak je krásně vidět, jak v tichu začne signál někam jet. Záleží tedy jaky kondik je na výstupu magnetofonu pro oddělení SS složky.
Ne že by to bylo nějak moc, ale lepší zachovat ten tón.

_________________
https://github.com/72ka