Wlasnie sciagnalem sobie franny'ego skompilowalem bez zajakniecia pod cygwinem no i wlasnie to jest to co tygrysy lubia najbardziej :)
Kilka minut tylko dochodzilem jak sie tworzy nowa dyskietke (az zerknalem w zrodla i w glowe trace-owalem co tam sie w srodku dzieje) a jak skonczylem to stwierdzilem ze to banalne i nie wiem dlaczego odrazu nie wpadlem na to ze nowa dyskietke w double dla ataridos tworzy sie poprzez

franny.exe -f a -m a -t d -C dyskietka.atr

;)

xxl-owi chodzilo o program dzialajacy z CLI

Prawde mowiac juz mnie to irytuje... :/ Dlaczego jak ktos robi program do przenoszenia programow do/z atr'a do jest to albo plugin do TC albo program okienkowy bez mozliwosci uruchomienia wsadowego... nikt nie pomyslal o programistach ktorze chcieliby w skrypcie wrzucac jakies pliki do atr'ow. Mam nadzieje, ze inicjatywa z tego watku do czegos doprowadzi...

Myślę, że o emulację tego rozszerzenia (dokładniej jej brak) możemy być spokojni, gdyż pełna emulacja umożliwiająca programową modyfikację działania wewnętrznego układu (gdzie można np. przeprogramować blitter w koprocesor) jest delikatnie mówiąc praktycznie niemożliwa. A przynajmniej wątpie żeby znalazł się ktoś na tyle zdeterminowany, żeby doczepić to do atari800, skoro nie pojawiła się nawet jeszcze tak upragniona emulacja 65c816 (nie licząc ultraXE, który doprowadza mnie swoją topornością do pasji :) )

heaven: as far as i know output isn't mixed. New chipset completely replaces normal GTIA --- there is a separate RGB output.

Czyli nie ma problemow z dwoma monitorami. Na monitorze podlaczonym do starego wyjscia bedzie jedno, a na nowe wyjscie cały ekran bedzie zakryty dwoma sprajtami 160x200 obok siebie ktore cos tam beda wyswietlaly. I co innego moze byc na jednym co innego na drugim. brzmi fajnie :)

A gfx-board super... Czekam z niecierpliwoscia na dokladniejsza dokumentacjie (rozpiska rejestrow, tryby pracy itp)

Mysle ze troche chetnego luda nawet po 200 PLN od glowy by sie na to znalazlo, moze oplacalo by sie zlecic jakiejs firmie zrobienie plytki.

Co do Sc0rpi0 to tylko czekalem, ktory pierwszy napisze, ze "to juz nie jest przeciez atari!" :)
Prawde mowiac scena nie siedzi juz na prawdziwym atari od 10 lat, chociazby ze wzgledu na 2 pokeye i duzo ramu :)

Np wlasnie. Juz dawno temu rozbilem sie o brak porzadnego programu dzialajacego z CLI potrafiacego manipulowac ATRami. Plugin to TC jest super, ale jak pisze sie powiedzmy demo na atari i przy kazdej kompilacji chce sie umiescic wynik a ATRze bo bez programu, ktorego mozna umiescic we wsadzie ani rusz.

mikey: czyzby miala byc rybka na forevera?

moze
"Marek was asking who will be interested and who knows something about this because he will be interested."

Te ostatnie interested jest trochge niezreczne i w sumie nie potrzebne, ale chyba pomaga w zrozumieniu sensu zdania.

Pin! Bedziesz we Wroclawiu!? Ej! To super! Zrobimy maly sztabinx :P

Cyklujac najbardziej zagniezczone petle mamy

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.

Niestety nie rozumiem tego algorytmu:

a) dlaczego 2. bajt ma 9 bitow?
b) T - zupelnie nie wiem co sie dzieje? zmiana na draw jestli byl plot? w jakim kontekscie?
c) czym jest W?

jedyny pomysl jaki mam, to skoro sa 3 mozliwe wartosci, to zamiast na stale przypisac im 2 bitow az prosi sie kod przedrostkowy, czyli dla najczestrzej wartosci 1 dla drugiej 01 dla trzeciej 00. i oszczedzaby jeden bit przy najczestrzej wartosci. wada: mamy rozna dlugosc rozkazu, ale jesli drugi bajt jest 9-cio bitowy to i tak trzeba pobierac po bitach :P

Tak jak w moim opisie. po 4 bity. grupujemy po dwa zeby miec bajt. tablicujemy.

d_00000000   dta c'DDX'
d_00000001   dta c'DDDX'
d_00000010   dta d'DCX'
...
d_11111101   dta d'AAAAAAAAAAAAAAX'
d_11111110   dta d'AAAAAAAAAAAAAAAX'
d_11111111   dta d'AAAAAAAAAAAAAAAAX'

* gdzie X to znak o kodzie > $7f
* w sumie tablica na 900 bajtow
* srednio kazd tablica ma 3.5 bajta (900/256)

tableL dta l(d_00000000),l(d_00000001),l(d_00000010), ... ,l(d_11111101),l(d_11111110),l(d_11111111)
tableH dta h(d_00000000),h(d_00000001),h(d_00000010), ... ,h(d_11111101),h(d_11111110),h(d_11111111)

*tablica ma 512 bajtow

dekompresuj                 ;cykle
    lda #0                  ;2
    tax                     ;2
    sta strona_zero         ;3
loop
    ldy bufor_wejsciowy,x   ;4
    lda tableL,y            ;4 z kawalkiem
    sec                     ;2
    sbc strona_zero         ;3
    sta L+1                 ;4
    lda tableH,y            ;4 z kawalkiem
    sbc #0                  ;2
    sta L+2                 ;4
    ldy strona_zero         ;3
L   lda $ffff,y             ;4
    sta bufor_docelowy,y    ;5
    iny                     ;2
    bpl L                   ;3 bez kawaleczka
    sty strona_zero         ;3
    inx                     ;2
    cpx #dlugosc            ;2
    bpl loop                ;3 (bez kawaleczka dla ostatniego testu)
    rts                     ;2

srednio na wynikowy bajt mamy (40+14*3.5)/3.5 = 25 cykli (najmniej 16 cykli najwiecej 27, a zreszta srednia na zdekompresowany blok zalezy scisle od bloku)

Wiem, ze algorytm jest abstrakcyjny i nieoplacalny (bo wymaga 1.5 kB tablic) ale jest szybki :P

jellonek. Podnosisz rękawice? :cool:

(Mam nadzieje, ze nie pomylilem sie w obliczeniach)