Tak jeste jedenkrat pro testery - v priloze je Basic nahrany 7/1 vcetne zavadece 1/1 ktery by mel fungovat na skutecnem Sharpovi kdyz ho pripojita na vystup zvukove karty PC. Kdyby to nahodou neslo, zkuste DIP prepinacem obratit polaritu signalu z ext. magnetofonu. Budu se tesit na vysledky, ja sam aktualne doma Sharpa nemam tak nemohu vyzkouset
Zdenek
----- Original Message -----
From: Zdenek Adler (sharpemupandora.cz)
To: Konference "Počítač SHARP MZ-800 a emulátory"
Sent: Wednesday, June 04, 2008 9:06 AM
Subject: Basic MZ-1Z016 za 39 sekund
Tak se mi za pouziti predchozi teorie jeste o neco podarilo optimalizovat casovani signalu tak, aby sel az na hranu rychlosti rutin ROM monitoru - vic uz to skutecne nepujde:
Samply pro obe log. urovne jsou poskladane nasledovne:
log. 0 = 0 0 0 1
log. 1 = 0 0 0 1 1
prvni tri bity vlastne vyplnuji cas pri cekani na nabeznou hranu s testovanim na BREAK a nasledujici 1 nebo 2 jednicky teprve rozlisuji uroven.
Nahrani 41978 Bytoveho Basicu tedy trva jen 39 sekund coz je vice jak 7x rychleji nez originalni rychlost.
V priloze posilam i zrychleny BASIC, prozatim je ale i se zrychlenou hlavickou. Kdo by ho chtel zkusit nahrat, je treba v ROMce modifikovat byte na adrese 0xA4B na hodnotu 01 - na skutecnem Sharpovi by to melo jit zkopirovanim ROMky do RAM ve ktere se byte upravi a spusti se nahravaci rutina z RAM. Druhou moznosti je si vypalit EPROMku - nechtelo by se nekomu zkusit? :-) V emulatoru na PC se da samozrejmne ROMka modifikovat lehce....
Z.
----- Original Message -----
From: Zdenek Adler (sharpemupandora.cz)
To: Konference "Počítač SHARP MZ-800 a emulátory"
Sent: Wednesday, June 04, 2008 8:31 AM
Subject: Re: rychlonahravani
Ahoj,
jenom na upresneni.... data se nahravaji v podobe Start bit (long)+8 bitu data - tedy celkem 9 bitu je treba k preneseni 1 bajtu programu. Paritni bity zadne nejsou, jen na konci bloku se nachazi tusim dva bajty kontrolniho souctu ktery obsahuje pocitadlo prenesenych jednicek.
Po pravde mne stale laka upravit standartni rutiny monitoru (kod pro upravu by se vesel do hlavicky MZF) a zachovat tim alespon nejakou kompatibilitu. Jinak cteni za pomoci ROM rutiny probiha asi nasledovne:
- cekani na nabeh jednicky
- cekaci smycka s pevne nastavenou dobou (pro 1200 Bd je to tusim 23 uS) - je to konstanta na adrese 0x0A4B, modifikovala ho Turbo copy pri pouziti Loaderu.
- na konci cekaci smycky se precte vystup z magnetofonu, ktery by mel byt roven ctenemu bitu
z tohoto plyne ze nulova hrana signalu se muze bez problemu zkratit na minimum. Pokusy jsem dospel ke 3 samplum pri 44 KHz, pri kratsi dobe uz dochazelo k prebehum pri cekani na nabeznou hranu signalu. V tomto pripade uz je ale treba dbat na spravnou polaritu signalu - pokud se obrati, nenahrajete do Sharpa ani bajt...
Z.
----- Original Message -----
From: Feri (sharpemupandora.cz)
To: Konference "Počítač SHARP MZ-800 a emulátory"
Sent: Tuesday, June 03, 2008 11:47 PM
Subject: Re: rychlonahravani
mozno objavujem ameriku, ale napada ma taketo riesenie...
fyzicky format:
===============
inspiroval by som sa ciarovym kodom. je sice patentovany, ale pokial pojde len o inspiraciu, nemuselo by to vadit :-)
sucasny MZ format je neefektivy, hlada sa nabezna hrana a v stanovenom case sa meria ci je HI alebo LO. potom este logika okolo, start bit, paritny bit... ak pojdeme cestou detekcie hran (co barcode, ale napr. aj harddisky robia), usetrilo by sa vela. ak za zakladnu sirku povazujeme 1 sampel (realne bude musiet byt niekolkonasobok sampla), tak kodovanie jedneho bajtu teraz:
HHLL start bit
8x: HHLL bit 1 alebo HL bit 0
HL/HHLL parita
(uz si nepamatam presne, ci tam bol stop bit)
dokopy asi 4x4 + 9x3 = 55 samplov (59 so stop bitom)
pri hranovej detekcii:
8 x HH/LL pre 1 alebo H/L pre 0
dokopy 8x1,5 = 12. to je len 24% (realne 17% pri 0x00 a 25% pre 0xFF) z dlzky prenosu u originalneho formatu. takze tych 60s (rychlostou 4x) na basic by bolo ~15s! (teoreticky, plus pár sekund hlavička a loader)
pozn.: to "3" a "1,5" je štatistický priemer ak pomer jednotiek a nul je 50:50
encoder (PC):
=============
tu by sa dalo tazit z kompresie - ak nechceme "turbocopy" pre MZ, ale pre PC, mozeme si dovolit proces kompresie s vyssim narokom na memory aj CPU. ten by potom mohol pripravit viacero verzii kompresie a pre fyzicky zaznam (vystup na zvukovku/MP3/WAV) by pouzil najmensi vysledok. ako kompresiu by sa dalo uvazovat o vselicom - len aby velkost dekodera (loadera) nebola vacsia ako ziskany rozdiel (casovo, nie objemom, nahrava sa pomalsie - aj ked ma napada ze by mohol ist najprv nekomprimovany loader a potom komprimovany obsah, pripadne by sa dekomprimovalo az po nahrati).
zakladne rutiny by mohli vychadzat z huffmanovho stromu alebo RLE (efektivne pri vacsich blokoch rovnakych bitov za sebou)
na zvazenie by mohlo byt aj zavedenie blokoveho prenosu - kazdy blok by mohol mat ine - najefektivnejsie - kodovanie.
decoder (MZ loader):
=================
zakladom dekodera je schopnost spocitat cykly, ako dlho trvala doba medzi dvomi hranami a potom na zaklade tresholdu povedat, ci to bolo L alebo H. z coho vyplyva, ze rychlost (paradoxne) nesmie byt moc nizka, kvoli preteceniu registra :-)
dekoder by mal byt dostatocne jednoduchy. cisto len s hranovou detekciou bez kompresie by sa myslim zmestil do radovo stoviek bytov (hacknutim zakladych rutin v ROM a presmerovanim len rutiny na citanie bajtu do tela loadera).
s kompresiou to moze byt horsie, tam by som to videl aj na kilobajty (len tabulka huffmanovho stromu by zabrala 256), co pri teoreticky najvacsom 30-40k programe uz je prilis.
tolko moja uvaha.
---
---
---