Konference: Počítač SHARP MZ-800 a emulátory
| Od: | Zdenek Adler |
| Datum: | 4.6.2008 09:31 |
| Předmět: | 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.
---
Ostatní příspěvky vlákna:
[2008/1 (9)] [2008/2 (1)] [2008/3 (7)] [2008/4 (16)] [2008/5 (22)] [2008/6 (45)] [2008/7 (9)] [2008/8 (34)] [2008/9 (134)] [2008/10 (8)] [2008/11 (3)] [2008/12 (6)]