Poprawka moich ostatniech poprawek PUTSHAPE:
TXA
ADC #$xx
BCS $0032 ; X nie może być większy od 255
TAX
wypada fragment:
DEC $45
BEQ $0032
Jeżeli niczego nie pokręciłem to w sumie wynik -9 cykli na każdy kopiowanym bajcie.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
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.
atari.area forum » Posty przez Magnus
Strony 1
Poprawka moich ostatniech poprawek PUTSHAPE:
TXA
ADC #$xx
BCS $0032 ; X nie może być większy od 255
TAX
wypada fragment:
DEC $45
BEQ $0032
Jeżeli niczego nie pokręciłem to w sumie wynik -9 cykli na każdy kopiowanym bajcie.
Proponuję kolejną poprawkę:
$0023 DEC $45 zamieniłbym na CPX #$xx.
Program inicjujący PUT SHAPE musiałby wyliczyć szerokość * wysokość (dane pobierane z tablicy), dodać początkowe X (to które trafia do $0005), a wynik wpisać do $0024.
Zysk znikomy: tylko 1 cykl na każdy kopiowany bajt, więc może nie pokryć strat spowodowanych obliczaniem końcowego X.
Proponuję następującą zmianę w procedurze PUTSHAPE:
0012 wstawiam CLC
potem tak jak było:
LDA $xxxx,Y
AND $xxxx,X
ORA $xxxx,X
STA $xxxx,Y
teraz zmiana, zamiast kombinacji z INX i NOP (5 bajtów, 10 cykli):
TXA
ADC #$x ; gdzie x to ilość INX z poprzedniej wersji
TAX
(4 bajty, 6 cykli)
Skoki do 0012 od teraz wykonywane są pod adres 0013.
Reszta bez zmian.
Pozdrawiam.
LZSS - ofset i długość na 5 bitach:
przykład 1 -> 14 bajtów,
przykład 2 -> 23 bajty.
...o ile się nie walnąłem w liczeniu :)
Przy takich danych na wejściu to każda metoda kompresji będzie lepsza od tego co zaproponowałem na początku :)
Jeżeli dobrze zrozuniałem...
Cztery różne znaki w wyniku, czyli wystarczą 2 bity na opisanie jednego z nich. Bez jakichkolwiek kombinacji zysk będzie czterokrotny.
pozdrawiam,
M.
Tak, tak. I żeby można było pisać w javie, c++, php, i wielu wielu innych językach :D
Nie będzie... Co robi 'jsr get' w poprawionej przez Ciebie procedurce?
A czy Basic można włączyć na czas dekompresji? Jeżeli tak, to proponuję:
src = $9D
dest = $24;
loop jsr get
beq stop
lsr @
tay
q0 jsr get
q1 sta (dest,x)
inc dest
bne q2
inc dest+1
q2
dey
_bpl bmi loop
bcs q0
bcc q1
get JMP $A293
stop rts
Wynik: 32 bajty na zerowej :)
Jakby ktoś się uparł, że musi chodzić na XL/XE z oryginalnym ROM'em to można i tak:
src = $9D
dest = $24;
loop jsr get
beq stop
lsr @
tay
q0 jsr get
q1 sta (dest,x)
jsr $E6D1
dey
_bpl bmi loop
bcs q0
bcc q1
get JMP $A293
stop rts
Wynik: 26 bajtów ;)
Trzeba się tylko upewnić, że obydwa ROMy są w odpowiedniej wersji :D
Zaproponuję jeszcze jedną poprawkę: skoro to depaker, to rejestru X użyłbym do adresowania pamięci przy zapisywaniu danych.
Obniżam adres danych źródłowych o jeden bajt, wycinam, zmieniam, zamieniam...
loop
ldx #($100-(_bpl-_lp0+2))&$FF
jsr _src
bpl _stored
_rle
cmp #$ff
beq stop
and #$7f
ldx #($100-(_bpl-_lp1+2))&$FF
_stored
tay
stx _bpl+1
_lp0
jsr _src
_lp1
_dst sta $FFFF
inw _dst+1
dey
_bpl
bpl _lp0
bmi loop
_src
inw _get+1
_get
lda $FFFF
stop
rts
... i o ile się nie mylę to zjechałem do 50 :)
Tablica ma oczywiście zostać. Po ustawieniu wszystkich rejestrów sekwencją
k1: LDA #kolor
STA rejest
zmodyfikuj kod nowymi wartościami koloru pobierając je z tablicy, czyli np. LDA kolor,X STA k1+1, itd.
troche szkoda, sa jeszcze dwa pociski "wolne", zawsze moga przyslonic prawa i lewa strone. musze pokombinowac z przerwaniami, niektore kolory, zmieniaja wartosci rzadziej... a to jest kwestia doslownie kilku cykli...
16 cykli wystarczy?
Czy ta procedurka krytyczna czasowo znajduje się pod adresem $3035?
Jeżeli tak, to zamiast LDA kolor,X zastosuj LDA #kolor.
nie bede bo nie umiem :P
Nie przesadzaj :)
Może wystarczy jak zamienisz indeksy w pliku lang_main.php : 'Outbox'<->'Sentbox'
Zauważyłem, że godzina i minuta ma tą samą wartość, np. 12:12, 06:06, 0:00 ...
Czyżby jakiś błąd w skrypcie?
pozdrawiam,
Magnus
Wygląda na to, że listy do wysłania mam zapisane w katalogu 'Wysłane', a wysłane w 'Do wysłania'. Czyli jest odwrotnie niż powinno być.
Proszę kierownictwo o sprawdzenie i ew. poprawienie (tj. zamianę nazw katalogów).
Może przy okazji dałoby się zmienić nazwę katalogu 'Wysłane' na jakąś bardziej adekwatną, np. na 'Doręczone'...
pozdrawiam,
Magnus
.. heh - Draco - ja jeszcze proponuje zapytać Magnusa, dlaczego na twoim OS nie działa żadna z częci THE TOP... ;-
Eeeee..., bo w OS dla modeli XL/XE pod adresem 50251/$C44B znajdowała się tablica wektorów przerwań (dla 512-549/$200-$225), a w nowym OS jej tam nie ma :(
Spróbuj tak (skoro juz musisz tak podchodzic do tematu):
lda katx asl @ tax lda katx+1 rol @ tay lda sinus,x sta _sinx lda sinus+1,y sta _siny+1
Tak się nie da. Tablica sinus ma 720 bajtów długości. Trzeba najpierw obliczyć offset, do niego dodać adres początku tablicy i dopiero wówczas wyciągnąć z niej dane.
Błąd w procedurce:
odj16:
sec
lda lsb1
sbc lsb2
sta lsb_3
lda msb1
lda msb
sta msb_3
rts
Zamiast lda msb powinno być sbc msb2.
Na początu chciałem wyjaśnić ...
Nie ma sprawy. Nie czuję się w żaden sposób urażony lub dotknięty.
Skoto nic takiego w twoim depakerze nie ma to pewnie SoTe nie mówił o Cruncherze 5.0 i wiem że skoro tego nie sprawdziłem to nie powinienem o tym pisać. Nie chce wszczynać kolejnej sprzeczki ale może mówił to depackerze z którejś części TheTop...
Na pewno mówił o The Top :) Do pakowania tego megadema używałem Cruel Cruncher'a z C64. W którymś demie była nawet wzmianka o tym.
SoTe analizując tego depackera rzeczywiście mógł znaleźć obsługę komórki 0 i/lub 1.
Może znalazłbyś chwilę czasu i opowiedział nam historię powstawania Crunchera 5.0 ...
Nie to żebym się wymigiwał, ale nie było to to, o czym warto by było teraz pisać. Nic ciekawego.
... i może chciałbyś powiedzieć parę słów o tamtych czasach? Jestem tego cholernie ciekawy ;)
Proszę o trochę cierpliwości. Już niedługo, na stronach AA, powinien ukazać się wywiad ze mną... :)
pozdrawiam,
Magnus/WFMH
Jeszcze trochę i musiałbym napisać 'Revenge of Magnus II'... :)
Wiem że SoTe analizował dogłębnie Cruncher 5 i bardzo mocno się zastanawiał czy procedury kompresji/dekompresji nie pochodzą z C64. Pokazywał mi kilka zastanawiających fragmętów kodu z Cruncher 5. Była chyba obsługa komórki $00 lub $01 która w C64 odpowiada za odłącznie róznych obszarów pamięci (tak jak $d301 w ATARI).
Oj, albo SoTe nie za bardzo się przykładał, albo Ty coś źle zrozumiałeś.
Przejrzałem kod packera i depackera w wersji 5 i nie znalazłem tam obsługi komórki 0 lub 1 w sensie o którym piszesz:
packer:
$0704 - adresowanie absolutne - STA $0000,Y
$0528 - komórka $01 używana jest jako licznik bitów (od 8 do 0)
$04F1 - komórka $00 używana jest jako licznik pętli (od 0 do 127)
depacker:
$0707 - adresowanie strony zerowej - STA $00,X
$0749 - adresowanie strony zerowej - STA $00,X , STA $01,X , później ROL $00,X , ROL $01,X
Do tego po załadowniu pliku procedury przepisywały wszystko jak najniżej się da i rozpoczynały proces dekompresji od konca do początku pamięci (zawsze tak robili na C64).
Tak jest po prostu praktyczniej.
Wcześniesza wersja Cruncher'a Magnusa (4.64) miała tylko jeden przebieg; specyficzne RLE, które ludzie z C64 nazywają char packerem. Czy nie zastanawiała was wersja *.64? bo ja się zawsze zastanawiałem czy to przypadek czy też nie.
Sam bym tego lepiej nie wymyślił :D
Niestety, prawda jest bardziej banalna niż można by się spodziewać - *.64 jak 64KB pamięci RAM.
pozdrawiam,
Magnus/WFMH
Strony 1
atari.area forum » Posty przez Magnus
Wygenerowano w 0.010 sekund, wykonano 67 zapytań