moge ja optymalizowac pod wzledem szybkosci - 20 bajtow na stronie zero na procke putbyte i store i bedzie smigac az milo.
===
... 2,5% szybszy... 24 bajty krótszy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TONY - Ark of the Covenant Kontynuacja przygód Tony'ego na Atari 8-bit, bez przemocy, z naciskiem na spryt i eksplorację.
ABBUC Software Contest 2025: Zgłoszenia Sprawdź aktualną listę programów zgłoszonych do konkursu ABBUC Software Contest 2025. Termin mija 31 lipca!
Gopher2600 0.50.0 Nowa wersja emulatora Atari 2600 z usprawnieniami i nowymi funkcjami debuggera.
Steem SSE 4.2.0 już dostępny Nowa wersja emulatora Steem SSE z istotnymi usprawnieniami i nowościami
Powrót Head Over Heels! Thalamus zapowiada Return to Blacktooth - kontynuację klasyka na Amigę i Atari ST
atari.area forum » Posty przez xxl
moge ja optymalizowac pod wzledem szybkosci - 20 bajtow na stronie zero na procke putbyte i store i bedzie smigac az milo.
===
... 2,5% szybszy... 24 bajty krótszy
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)
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
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
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.
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...
subsizer potrzebuje 188 bajtowego bufora.
jak potwierdzisz to pozwoli Ci to zapisac ale jesli chcesz z tym cos zrobic na atari to musze Cie zmartwic...
wedlgu mnie kompiluje pod dowolny adres
pelna wersja... raczej sporo rozbudowana i odrobine zmieniona gra. mysle ze do karta konsument dostanie tez wersje cyfrowa.
Tebe opublikowal Super Pakera i mozna juz tworzyc spakowane binarki dowoli :-)
gra wygrala konkurs: Atari Homebrew Awards 2019
:D bomba.
w zalaczniku:
oryginalna dlugosc binarki: 15169
skompresowana binarka: 4271 - czyli ponad 3x krotsza
GTIA music czyli jesli emulator to nie AtariWinPlus.
mp3 nie umieszczam bo forum mowi ze zalacznik za duzy - bedzie na AtariAge
jesli autor umiescil konfig to grzechem jest go kasowac.
niespakowana wersja laduje sie 2:58 czyli dwa razy dluzej niz spakowana... poza tym nie zaladujesz jej ze stacji bo nie miesci sie na nosniku. stosujac retoryke patosceny mozna powiedziec ze zostala specjalnie tak przygotowana zeby nie ladowac sie z okreslonego nosnika ;-)
odnosnie konfigu. odpowiadalem juz kilka razy (poki mi sie nie znudzilo z 50 stron temu), poza tym podpowiedzi jakie dajesz ludziom sa po prostu bledne - juz ich nawet nie prostuje i traktuje jak spam. wiec i kolejna rade przeinaczsz. po co.
ale wiesz, ze porownujemy czasy dla dwoch spakowanych wersji...
odpakowujace sie PO zaladowaniu i W CZASIE ladowania. zmierz czas do uruchomienia.
bedziesz musial zapisac ta druga wersje na jakims atr albo odjac czas na ladowanie loadera :-)
bj na pewno nie laduje sie tyle co napisales z hdd,
sprawdz na hdd i nie grzesz wiecej...
===
a to i tak nie optymalizowana procka... moze byc jeszcze szybciej
tak, w testach (te same warunki ladowania):
plik podlinkowany przez Pina 96 KB dekompresja po zaladowaniu - do uruchomienia 1:27
plik dekompresujacy sie podczas ladowania - do uruchomienia 1:16
wygrywa na dluosci pliku i czasie uruchomienia...
===
natomiast na emulatorze z patchem (czas ladowania = w przblizeniu 0) do uruchomienia w obydwoch przpadkach czas = 0:28
xxl napisał/a:przykladowo Bomb Jack (zajmuje 275 KB w jednym pliku) nie miesci sie na dyskietce dla stacji 1050.
no to juz sie miesci - 94 KB
Jest przecież v5 BombJack, spakowana do 96kB, ładuje się i rozpakowuje dokładnie tyle czasu co Twoja, ...
gdyby ktos mial jeszcze jakies watpliwosci...
wersja z ostatnim dekompresorem zajmuje 77 KB (przypominam ze oryginalnie 275 KB)
co oznacza ze deklasuje pod tym wzgledem binarki rozpakowujace sie po zaladowaniu.
.... rewelacja ...
6502 w kazdm cyklu czyta lub zapisuje, chodzi o to ze w pewnych sytuacjach pojawiaja sie dane (byc moze podczas czytania, byc moze nie pierwszego) ktore na 100% nie sa losowe a ich zmiennosc jest wlasciwie stala (cykliczna)...
dwie dobre wiadomosci.
- bedzie plajerek
- bedzie intro
:D
zauwazylem pewna prawidlowosc w zmiennosci "niestabilosci" pewnego rozkazu niepublikowanego i mam podejrzenie...
dlatego chcialbym sie dowiedziec:
mozliwe jest to, ze cpu moze przechwycic "szum" z cyklow odswierzania pamieci?
co pojawia sie na szynie (adresow / danych) podczas odwierzania pamieci?
atari.area forum » Posty przez xxl
Wygenerowano w 0.198 sekund, wykonano 12 zapytań