OldComp.cz

Ahoj všem,

po 27 letech jsem objevil magnetofonovou kazetu se záznamem mých výtvorů na osmibitovém stroji PLAN80A.

Původní počítač už nemám, pokoušel jsem se to dekódovat pomocí PMD 85 PTP Manager od pana Bórika, ale neúspěšně.

Mátě někdo zkušenosti s touto věcí?

Vzorek záznamu je tady: https://drive.google.com/open?id=128eX3 ... bBv1dWEP-r

Díky za pomoc.

Tonda

Možná naemulovat dekódování podle výpisu zdrojáku ovládacího programu magnetofonu? http://www.sapi.cz/plan80/data/1d_lst.php

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Děkuji Vám za odpověď. Samotná emulace ovládacího programu stačit nebude, v procesu zpracování byl zařazen i poměrně sofistikovaný hardware - v kontextu tehdejší doby samozřejmě: http://sapi.cz/plan80/prilohy.php#odkazs11


I Vám děkuji za odpověď, tudy tedy cesta nevede, alespoň jsem ušetřen dalších marných pokusů. Vycházel jsem z informací o PLAN80A, kde byla zmiňována určitá kompatibilita s PMD85.

Ten hardware není nic zázračného, nedělá nic zvláštního. Dělá zjednodušeně jenom to, že 512 kHz dělí děličkami na volitelnou záznamovou rychlost 600 až 4800 Baud, datovým vstupem přepíná mezi úzkým a širokým pulsem a přes Frame se software synchronizuje zda byl puls odeslaný. Přes odporový převodník dělá buď digitální nebo analogový výstup. Stačí tedy jen v záznamu rozlišit 0 a 1 podle širokého a úzkého pulzu (mezery se mohou ignorovat, 1 bit je 1 puls, úzký impuls je "1", široký "0") a podle zdrojáku jen detekovat způsob formátování dat. Ve zdrojáku funkce BYTOUT dělá zápis 1 bajtu na kazetu, z toho se může vyjít (start bit, 8 datových bitů v pořadí od nižších bitů k vyšším, 2 stop bity). Funkce WRBUF zapisuje 1 blok dat - mezera z "1", 3x preamble 10h, data bloku, název 10 znaků, číslo bloku, číslo souboru, kontrolní součet, preamble 10h, koncová 0, mezera z "1".

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Panda38 to popsal tak dobře, že jsem zkusil napsat program na převod toho zvuku na bajty a hele co mi z toho vypadlo...
Vypadá to na program v BASICU, kde místo příkazu jsou jednobajtové tokeny. Ale kvalita toho zvuku je hrozná, takže rozluštění bitu 0/1 je někdy problematické...

_________________
http://maximalne.8u.cz

Možná kolísá rychlost záznamu a muselo by se průběžně synchronizovat na šířky pulzů.

Jestli jsem správně pochopil výpis Tiny Basicu (možná že ne), měl by řádek programu začínat číslem řádku v binární formě (2 bajty) a za ním řádek programu v textově formě ukončený jedním CR (0Dh).

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

A tokeny nejsou, příkazy jsou jako normální text, ale lze je zkracovat tečkou.
P. ve výpisu je tedy PRINT.

Vypadá to, že se občas přečte špatně bit (VINUTI MA ZAVITU, zAVITU, ...).

Potvrzuji, že se jedná o programy psané v PLAN80A TINY BASIC V3Q. Vliv kolísání rychlosti záznamu, resp. synchronizace se záznamem nejspíš musela být nějak softwarově ošetřena, neboť si matně vzpomínám, že když jsem nahrával programy z kazety do počítače, kolísání bylo slyšitelné, ale nahrávání neklopýtlo a bylo vždycky v pořádku. Je to přece jen skoro 30 let, možná za tu dobu pásek degradoval.

Obdivuji přehled Panda38 a schopnosti zdenek6, na základě dostupných informací záznam dekódovat.

zdenek6, pokud je to možné, mohl bych poprosit o poskytnutí PLAN80Mgf.EXE?

Děkuji.

No jo, tokeny tam samozřejmě nejsou, zmátlo mě to zkracování příkazů, přitom hned vedle je GOTO/IF...
Zapracoval jsem na detekci bitu: záznam je rozdělen do bloků a u každého používám úvodní posloupnost jedniček ("pilotní tón") pro určení správné prahové hodnoty, kdy to je jednička a kdy nula.
Program nakonec umí převést celý wav soubor do textových souborů se zdrojovým kódem v BASICu. Samozřejmě si ho nenechám pro sebe, stáhnout se dá zde: http://maximalne.8u.cz/plan80a-analyzator-zvukoveho-zaznamu/
Tak snad poslouží dobře.

Mimochodem, jaké kazetopáskové zařízení bylo použito?

_________________
http://maximalne.8u.cz

Tak když to mělo podle popisu Panda38 chodit, tak jsem si to zkusil taky, a vážně z toho něco leze. Ale v některých místech se mi to nechytá, buď tam přebývají nebo chybí bity. Taková místa jsou označená dvojicí znaků [] (tj. tyhle znaky v původních datech nejsou).

Vzal jsem část z toho záznamu, kde výsledek vypadal smysluplně, a pak jsem ho ručně rozdělil na řádky, jestli tam bude nějak líp vidět struktura. Potvrdilo se, že bloky začínají 3x znakem 10h, ale pak, kde mají začínat data, tak je jeden znak 'A' 41h, nebo někdy 04h. To už tam možná dává samotný Basic. A možná by to šlo ještě někde dohledat, pokud od toho Basicu je zdroják.

Každopádně na nějaké restaurování by to asi chtělo lépe sejmout ta data do počítače. V některých místech je signál silný, ale jinde je mnohem slabší, a tam to asi bude dělat problém. I když to jsem podrobně nezkoumal, kde jsou ty problémy, jestli to jsou zrovna ta místa potichu. Ono se v tom dá dost špatně vyznat (myslím vykoukat okem jednotlivé bajty v těch datech zvuku, to mi teda zatím nejde).


Upraveno: několik málo míst s [] už nahoře zmizelo

Zdá se mi, že nechybí nebo nepřebávají, spíš se bit načte nesprávně (1 místo 0).
Na několika místech je viditelně třeba zbytečně nahozený nejvyšší bit ve znaku.



Pro Apple II vznikl software, který má upravovat kvalitu nasnímaného wavu. Něco podobného by se hodilo i pro rekonstrukce na ostatních počítačích.
Program není dlouhý, třeba by si ho někdo zvládl upravit.
https://github.com/cmosher01/Apple-II-Cassette-Recover/wiki

To už vypadá hodně dobře. Ještě změnit binární číslo řádku na čitelnou formu a odstranit hlavičky bloků:

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Pro doplnění ještě obrázek, jak vypadá signál ve wavu. Je tam jakýsi patrný rozdíl mezi šířkou 0 a 1 pulzu, ale jsou si dosti podobné.

Dělal jsem nějaké pokusy s kazetami ze ZX Spectra. Formát záznamu je sice odlišný, nicméně i zde dlouhá vlna=1, krátká vlna=0

Takže:
Téměř vždy signál plave, tj. kolísá mu ss složka. I když signál je víceméně symetrický vůči vodorovné ose. Důvod je jednoduchý, signálová cesta mgf je kapacitně vázaná s poměrně velkými kapacitami, aby stroj přenášel dobře i basy. Používá se přeci primárně na muziku. A kondenzátory se nabíjejí a vybíjejí.
Je tedy nutné udělat kruhový buffer, vzorky z wavu do něj zapisovat, průběžně vyhodnocovat minimální a maximální vzorek a z nich průměr. A proti tomu průměru vstupní signál testovat.

Zde je příslušný kousek z mého emulátoru Ondry v Javě.
první funkce je konstruktor, který inicializuje buffer
do druhé se vstupuje s 8bit vzorkem bez znaménka a výstupem je obdélník. Z toho se pak v emulátoru detekují hrany signálu.


Tenhle kousek kódu spolu s běžným měřením intervalu mezi hranami mi v Ondrovi přečetl zatím všechny wavy, co mi lidi poslali. Tedy pokud neměly vyloženě výpadek.

Jak z oscilogramu vyplývá, tak okolní bity se někdy docela ovlivňují, je to vidět třeba na sekvenci 101. Magnetický záznam je také od přírody dosti kmitočtově závislý, zvláště, když má někdo blbě seřízenou kolmost hlavy.

Stálo by za to vyvinout nějaký adaptabilní algoritmus, který by opravdu nějak analyzoval ty vlnovky. Jelikož všechny počítače jsou v podstatě o vzdálenosti hran v signálu, udělat něco univerzálního, do čeho by lezl wav a z něj by lezl soubor, kde jsou vzdálenosti mezi hranami. No a k tomu už je sranda udělat programy pro jednotlivé počítače.

Takhle je to udělané i v signálovém procesoru, co zpracovává signál z hlaviček ve skutečném HDD.

Možná by tu někdo dokázal rozpracovat takový algoritmus...

Brát za průchod nulou střed mezi špičkami vypadá být dobrá metoda. Jen v bufferu rozlišit kdy se mění křivka na opačný směr, aby se vyhodnotila jen 1 hrana - tedy jen sledovat znaménko rozdílu sousedních vzorků. Tj.:
- hledám maximum
- rozdíl je negativní?
- uchovám maximum a jeho čas
- hledám minimum
- rozdíl je pozitivní?
- uchovám minimum a jeho čas
- z rozdílu minima a maxima interpoluji přesný čas středu mezi nimi, to je 1 hrana signálu
Rozdíl vzorků na hraně považovat za platný jen pokud dosáhne nějaké minimální hodnoty, aby se tím odfiltrovaly malé šumy. Na hledání minima a maxima signálu není potřeba kruhový buffer, jen si uchovávat dosaženou nejlepší nalezenou hodnotu hranice a její čas.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement