Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » kodowanie korekcyjne
Zaloguj się lub zarejestruj by napisać odpowiedź
czy na atari ktorys system turbo dla magnetofonu (albo nawet bez turbo) wykorzystywal kodowanie korekcyjne przy wczytywaniu danych?
ale nie chodzi mi o rozpoznawanie bledu tylko o odtworzenie informacji.
to by zalatwialo raz na zawsze problem niewczytywania sie programow czy to przez bledy w OS czy przez "zagieta" tasme...
Kodowanie korekcyjne wymaga nadmiarowych danych.
Kodowanie korekcyjne wymaga zazwyczaj sporo obliczeń.
Już te 2 fakty sprawiają że raczej mało prawdopodobne by ktoś to zaimplementował.
Nawet stacje dysków nie mają zaimplementowanej takiej funkcjonalnoci, gdzie mają do tego celu własny procesor.
nie chodzi mi o zapis !
zapis tworzony jest na PC natomiast na atari dekodowanie (tylko ladowanie z magnetofonu). w polaczeniu ze skompresowanmi binarkami moze okazac sie ze nie tylko wynik jest krotszy (szbciej sie zaladuje na tej samej szybkosci) ale takze prawie 100% skutecznosc nawet przy czesciowo zniszczonych danych.
Miałem na myśli oczyt z fizycznego nosnika. A kompresji nie było... Jesteś pionierem.
nie wiem czy sie rozmiemy - nie chodzi mi o to ze urzadzenie czyta z nosnika dokonuje korekty i wysyla wynik do atari tylko "glupie" urzadznie czyta i wysyla do atari, atari robi korekte juz w buforze
Zerknij do dokumentacji do Turgen System, może tam coś jest przy opisach systemów.
Nie widze zadnej praktycznej roznicy miedzy
1) dyskietka/glowica/ram/cpu(stacji)
2) tasma/glowica/ram/cpu(atari)
W sumie niezły pomysł, mogłoby toto od razu usuwać z binarki nielegale i niepotrzebne odwołania do kopii rejejstrów sprzętowych :P
true, true. Mogło by też z dyskietek usuwać podejrzane loadery ;)
albo zabezpieczenie przed modyfikacjami, po patchu Voy-a suma kontrolna nie będzie się zgadzać i nie wczytacie
czytajcie między wierszami ;)
Nie widze zadnej praktycznej roznicy miedzy
1) dyskietka/glowica/ram/cpu(stacji)
2) tasma/glowica/ram/cpu(atari)
jest ogromna roznica:
1 - rozwiazanie sprzetowe, musisz przerobic stacje,
2 - rozwiazanie programowe - dziala bez przerobek
wylaczylbym z rozwazan stacje, przykladowo protokol SIO zaklada, ze stacja wysyla dodatkowe informacje do kompa ktore w tym przypadku nie maja sensu (np. suma kontrolna)
plik binarny pakujemy blokami natomiast kodujemy rekordami... mi sie podoba mysl ze zamiast ladowac w niepewnosci gre 10 minut, zaladujesz ja w 5 minut ze 100% skutecznoscia
.. ale czy ktoś ma takie problemy? Bo nie słyszałem.
Tak działają napędy CD i DVD, problem w tym, że takie kodowanie jest nadmiarowe i siłą rzeczy nadaje się do pojemnych i szybkich, ale zawodnych nośników. O wydajność bym się nie martwił, bo wczytując z taśmy bez turbo Atari się raczej nie przemęcza...
oczywiscie ze sa dane nadmiarowe ale zerknij tu: http://www.atari.org.pl/forum/viewtopic … 24#p258824
plik oryginalny z 41212 bajtow skompresowal sie do 18176 bajtow (44% oryginalnego rozmiaru)
o ile na urządzeniach szeregowych to pakowanie jest kompletnie nieodczuwalne czasowo tak na szybkich nośnikach dość znacznie spowalnia I/O. W dzisiejszych czasach to, co proponujesz to trochę rachityczny przeżytek, no ale - jak tam się chcesz bawić, to się baw przynajmniej dobrze.
Na poziomie skompresowanego kontenera, danych naprawczych używał np. RAR, ale tego typu algorytmy mogą być za dużym wyzwaniem dla 6502.
Ciekawe jak maluch sobie z tym poradzi: https://en.m.wikipedia.org/wiki/BCH_code
Może dla wprawy policz crc32 najpierw.
A może ECC bedzie prościej?
W dzisiejszych czasach to, co proponujesz to trochę rachityczny przeżytek,
- powiedział pasjonat 40-letnich komputerów.
zapis tworzony jest na PC
tego typu algorytmy mogą być za dużym wyzwaniem dla 6502
Ciekawe jak maluch sobie z tym poradzi: https://en.m.wikipedia.org/wiki/BCH_code
Na oko standardowa atarka koduje dziesiątki kilobajtów na sekundę. A atarka Pinokia to sami rozumiecie.
Może dla wprawy policz crc32 najpierw.
idealny model dla mnie wygladalby nastepujaco:
plik binarny poddajemy kompresji, podzialowi na rekordy, rekordy kodowaniu z korekta, do rekordu dodawana jest suma kontrolna na dane znaczace (maja stala pozycje w rekordzie). dopuszczalne uszkodzenie rekordu - 30%
nagrany plik ladujemy tak:
1. ladujemy do bufora roboczego (z nadmiarowymi danymi)
2. jesli suma kontrolna dla danych znaczacych sie zgadza to kopiujemy dane ze stalych pozycji do bufora sektora i 4.
3. jesli suma kontrolna sie nie zgadza. zatrzymujemy silnik i odzyskujemy dane. po odzyskaniu danch kopiujemy do bufora sektora
4. w buforze sektora znajduje sie rekord skompresowanej binarki ktory obslugujemy identycznie jak obecnie xboot obsluuje skompresowane binarki.
koniec bajki.
Musiałbyś mieć duże odstępy między rekordami, bo większość magnetofonów nie jest już w stanie złapać synchro po zatrzymaniu silnika... i to na pilocie.
Jeśli spowolni się ładowanie to tylko na plus.
.. ładowaniem danych należy się delektować :)
@_tzok_: ale chodzi o to zeby kodowac tak zeby dzialalo na wadliwym sprzecie ? ;-) skads to znam hehe
dlugosc rekordu czy dlugosc przerw mozna regulowac - jesli efekt kompresji nie skompensuje nadmiarowych danych to w najgorszym przypadku czas ladowania bedzie ten sam a zysk bedzie tylko na 100% skutecznosci ladowania nawet przy czesciowo uszkodzonym nosniku.
oczywiscie na wadliwym sprzecie nie bedzie dzialac...
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » kodowanie korekcyjne
Wygenerowano w 0.028 sekund, wykonano 66 zapytań