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ć.
Lost Party 2025 startuje już jutro W Licheniu Starym rusza zlot fanów 8-bitowych komputerów
zeST 20250627 - Atari ST w FPGA z turbo! Nowa wersja zeST z trybem turbo 50 MHz i poprawkami Shiftera i MFP
UltraSatan - firmware 1.30 Nowa wersja firmware dla UltraSatana wspiera nowoczesne karty SDHC i SDXC
53 lata marki Atari 53 lata od założenia Atari - firmy, która odmieniła świat gier i komputerów.
Odtwarzanie układów z Atari Falcon Trwa zbiórka na odtworzenie chipów Videl, Combel i SDMA z Atari Falcon
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 80 zapytań