A moja metda tez ma 34 bajty. Brzydki przypadek :P

moja metoda tu sie calkowicie wyklada : 34 bajty

Moja wykłada się jeszcze bardziej. :)

Bezczelnie zapierniczyc lepiej nie próbuj, ale jeśli grzecznie zapierniczysz, to proszę bardzo. ;)

moglbys spakowac i sprawdzic ile bajtow ma

przyklad5:
aaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaa
aaaaabbbbbaaaaaa
aaaabaaaaabaaaaa
aaabaababaabaaaa
aaabacaaacabaada
ddabaacccaabaadd
ddaabaaaaabaaada
daaaababbbaaaada
daaaaaaaaaaaaada
daaaaaaaaaaaadaa

moja metoda tu sie calkowicie wyklada : 34 bajty

i taka mala prosba  :-) czy mozna bezczelnie zapierniczyc Twoja procke do rozpakowania plansz w gierce? oczywiscie wymieniajac Cie na liscie plac ?

A gierka super!

reszta danych? - nie bierzesz pod uwage wartosci P - zwroc tez uwage ze zmienia sie jego interpretacja wraz z T.

dobrze kombinujesz - to bylo moje zadanie przy rekrutacji kolesi na informatykow. wlasciwie to czesc zadania - glownie chodzilo o zerzniecie gry: http://www.jarkey.net/playgames/crabs_game.htm tak sie sklada ze napisalem to w c i kto wie... jak znajdzie sie jakis grafik i muzyk to portne to na atari? chetny jest ktos?

-- dodane

http://atariarea.krap.pl/forum/viewtopi … 795#p50795

Dane wejściowe były następujące:

_1____________1_
_1____________1_
_1____________1_
_1___3____3___1_
_1_____11_____1_
_1_____44_____1_
_1____________1_
_1___3____3___1_
_1____________1_
_1____________1_
_1____________1_
_1____________1_

Po spakowaniu otrzymałeś  %10,%11011100,%1111,%11011100,%110110,%10110101,%1110110,%10110101,%1001000,%10010001,%1011000,%10100001.

M jest zawsze ustawione, a z analicy danych wychodzi mi, że zawsze robisz plot.
Zakładam, że pierwszy bajt równy zero kończy dekompresję, stad wartość pierwszego bajtu jest zwiększana o 1.
czyli:

%10,        - na poz $1 i +$c
%11011100,    - stawiasz znak 1

%1111,        - na poz $10 i +$c
%11011100,    - stawiasz znak 1

%110110,        - poz $35 i +$5
%10110101,    - stawiasz znak 3

%1110110,    - poz $75 i +$5
%10110101,    - stawiasz znak 3

%1001000,    - na poz $47 i $48
%10010001,    - wpisanie znaku 1

%1011000,    - na poz $57 i $58
%10100001    - wpisanie znaku 4

A co z resztą danych? Poza pierwszym i drugim wierszem brakuje mi jedynek występujących po lewej i prawej stronie...

%10,%11011100,%1111,%11011100,%110110,%10110101,%1110110,%10110101,%1001000,%10010001,%1011000,%10100001

12 bajtow

ciezko napisac pakera... depakera o wiele prosciej

        asl @
        ror @

to rzeczywiscie mialo dac najstarszy bit w C, ale i ewentualne jego skasowanie - a ze dawno w 6502 klepalem
to i bladnie przyjalem ze 'ror' rotuje z pominieciem C...

loopp   lda (ptr3),y    ;5
        sta (ptr2),y    ;6
        inc ptr3        ;5
        inc ptr2        ;5
        dex             ;2
        bne loopp       ;3

26 cykli

oraz

rle     sta (ptr2),y      ;6
        inc ptr2          ;5
        dex               ;2
        bne rle           ;3

16 cykli.

Dodatkowo zauwazylem, ze w mojej procce jest blad bo zapomnialem, ze iny tez ustawia bit N. Rozwiazaniem jest dodanie np lsr @ czyli

L   lda $ffff,y             ;4
    lsr @                   ;2
    sta bufor_docelowy,y    ;5
    iny                     ;2
    bcc L                   ;3

i mam 16 cykli zamiast 14 i moje obliczenia sredniego czasu zwiekszaja sie do  27 cykli (najmniej 18 cykli najwiecej 29) oczywisice pamietajac zeby dane byly przesuniete w lewo i konczacy znak miał ustawiony najmlodszy bit.

Reasumujac petlę ofsetującą masz bardzo dluga, a RLE jest identyczna. Nie wiem jak ulozy sie srednia, bo jest inna reprezentacja danych, ale chyba na moją korzysc :P

PS.: wydaje mi sie, ze

        asl @
        ror @

jest równoważne

        clc

wiem ze chciales skoczyc jesli najstarszy bit byl ustawiony ale tak sie nie da. (no i dodatkowo skaczac do rle jest ustawiony bit N i bedzie się krecilo troche dluzej :) ) Ale da sie samym lsr @ jesli bedzie sie inadzej pamietalo ten bajt w buforze.

ptr1    equ $80
ptr2    equ $82
ptr3    equ $84

        org $2000

qniec   rts
decomp  lda ptr2+1
        sta ptr3+1
        ldy #0

loop    lda (ptr1),y
        beq qniec
        inc ptr1
        asl @
        ror @
        tax
        lda (ptr1),y
        bcc rle

; offsetowanie
        sta ptr3
loopp   lda (ptr3),y
        sta (ptr2),y
        inc ptr3
        inc ptr2
        dex
        bne loopp
koniec  inc ptr1
        bne loop
        inc ptr1+1
        jmp loop

; rle
rle     sta (ptr2),y
        inc ptr2
        dex
        bne rle
quit   inc ptr1
        bne loop
        inc ptr+1
        jmp loop
; w miejsce od "quit" wpisac: beq koniec (co da krotszy kod, ale sie wolniej wykona... )

policzy ktos cykle? ;)

dekompresja do tego co wczesniej opisalem - tylko zaznaczam - to moj pierwszy kod od jakichs 15 lat ;)
pewnie cos spartolilem...
ptr1 - wskaznik na dane wyjsciowe
ptr2 - wskaznik gdzie dekompresowac
zalozenie - bufor wyjsciowy zaczynaja sie od adresu w miare niskiego wzgledem poczatku strony (<64), bo brak sprawdzania przepelnienia ;)

nie wiem tylko jak obliczana jest ta ilosc literek 'b' do pominiecia i od ktorego momentu pomijamy, ale wierzę, ze to jest zakodowane jakos w P :) Jezeli te kodowanie w P jest dobre, to powinno dzialac :P

Tak czytam co Ty tu napisales ... i mysle, ze chyba nie zrozumiales

Tia, cofnalem sie i przeczytalem, że WYJSCIOWYCH bedzie 3k, a wczesniej
nie wiem czemu mi sie przeczytalo, że wejsciowych :), czyli nawet liczac te 3k
jako bajty, a nie symbole wyszlo mi ze trza spakowac 768 bajtow do <256 :)
czyli do 33,(3)% co się takie łatwe nie wydaje jak nie ma odpowiedniego rozkladu
danych :). No, ale jak widac wzialem pod uwage gorszy problem niż był w rzeczywistości.

rozpakowane bloki maja po 192 bajty, wypelniamy go wartoscia wystepujaca najczesciej

pobieramy dlugosc 'programu z opisem dekompresji'
pobieramy kolejno 2 bajty

co zawieraja te dwa bajty:
pierwszy bajt - index - od ktorego miejsca w boku 192 b zaczynamy
drugi bajt bity od najstarszego:

|M|T|D|D|P|P|P|P|W|

M - metoda fill, plot
plot stawia dana na poczatku i po przesunieciu innymi slowy moze zrobic tak: ABBBBBA lub tak: A (A istotny),
fill wypelnia, moze zrobic tak:AAAbbbAAAbbbAAA (A istotny) - nie z przykladu powyzej

T - tryb patrz P dla plot automatyczna zmiana na draw
jesli M bylo plot to przy ustawieniu T mamy draw oraz zmiane interpretacji P

D - dane - sa juz tyklko 3 rozne elementy
dane: 01, 10, 11

P - przesuniecie 1-16 lub index+x*16
w zaleznosci od T mozemy zrobic przy plot tak: A lub AbbbbbA a przy draw tak: AAAAAA lub tak: AbbAbbA (A dane istotne)
to dekompresor musi zadbac i obliczac koniec dzialania rozkazow ale to jest akurat b.proste.

analogia w nazwie fill, draw i plot jest trafna w przypadku tego algorytmu i TYCH konkretnych danych.

W - jakas wartosc bitu 9
moj poprzedni post byl zaszumiony i to jest wlasnie ta niechciana tresc ;-)