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.

4

(45 odpowiedzi, napisanych Programowanie - 8 bit)

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 :)

5

(45 odpowiedzi, napisanych Programowanie - 8 bit)

Przy takich danych na wejściu to każda metoda kompresji będzie lepsza od tego co zaproponowałem na początku :)

6

(45 odpowiedzi, napisanych Programowanie - 8 bit)

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.

7

(28 odpowiedzi, napisanych Software, Gry - 8bit)

Tak, tak. I żeby można było pisać w javie, c++, php, i wielu wielu innych językach :D

8

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Nie będzie... Co robi 'jsr get' w poprawionej przez Ciebie procedurce?

9

(36 odpowiedzi, napisanych Programowanie - 8 bit)

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

10

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Zaproponuję jeszcze jedną poprawkę: skoro to depaker, to rejestru X użyłbym do adresowania pamięci przy zapisywaniu danych.

11

(36 odpowiedzi, napisanych Programowanie - 8 bit)

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 :)

12

(30 odpowiedzi, napisanych Software, Gry - 8bit)

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.

13

(30 odpowiedzi, napisanych Software, Gry - 8bit)

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.

14

(3 odpowiedzi, napisanych Sprawy atari.area)

nie bede bo nie umiem :P

Nie przesadzaj :)
Może wystarczy jak zamienisz indeksy w pliku lang_main.php : 'Outbox'<->'Sentbox'

15

(3 odpowiedzi, napisanych Sprawy atari.area)

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

16

(3 odpowiedzi, napisanych Sprawy atari.area)

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

17

(190 odpowiedzi, napisanych Software, Gry - 8bit)

.. 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  :(

18

(11 odpowiedzi, napisanych Scena - 8bit)

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.

19

(11 odpowiedzi, napisanych Scena - 8bit)

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.

20

(35 odpowiedzi, napisanych Bałagan)

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

21

(35 odpowiedzi, napisanych Bałagan)

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