dzieki za wyjasnienia, jednak ciagle jest dla mnie cos niejasnego:

linia ma szerokosc 48 bajtow = $30, 4kb to $1000 czyli:
linia 0 = $0000-$002f
linia 1 = $0030-$005f
....,....
ostatnia = $0FC0-$0FEF
i zostaje kawalek wielkosci $10 ktory przeszkadza w tym, zeby ekran sie zawinal jak trzeba
to dlatego potrzebny jest ten drugi LMS? powiedzmy, zeby ostatnia linia byla $0FD0=$0FFF? czyli zawartosc pamieci ekranu wyglada tak:
0,1,2,3,4,....47
48,49,....95 ; i zmiana zestawu znakow co 2 linie lub:
0,1,2....,47
0,1,2....,47 ; i zmiana zestawu znakow co jedna linie
i tak przez np 24 razy + jedna taka linia pod koniec tych 4 kb zeby obraz sie zawijal

czyli po scroll 3 znakow poziomo pamiec ekranu wyglada tak:

3,4.......47,0,1,2 (w definiecje znakow 0,1 i 2 danego zestawu znakow kopiujemy dane klocka)

a scroll pionowy to zmiana zestawu znakow, i kopiowanie definicje klockow do 'uwolnionego' z gory lub dolu zestawu znakow? po co dodawac do wartosci po LMS $30 dla scroll pionowego?

wiekszosc tego 4kb jest wolna (gora jest zajeta i 48 bajtow z dolu)

tego nie rozumiem po co ruchomy LMS?

tak to wyglada?

---
no ale po co by bylo kopiowac cokolwiek do pamieci ekranu? tam definicja zawsze jest taka sama 0,1,...47,0,1,2....,47,0,1....???

ktos moglby wyjasnic metode "MWP"? z tego co zrozumialem to element graficzny 'klocek' moze byc maksymalnie 2 bajty szeroki? co to znaczy ruchomy LMS - ruchomy w sensie rozkaz z LMS jest przesuwany w Display liscie czy wartosc po rozkazie z LMS jest zmieniana?

takie posty sa zupelnie niepotrzebne.

plajer sidow swietego grajacy na d5:

http://atari.pl/SID_Player_d5.atr

mysle, ze to wystarczy do testow?

---
nie mam jak przetestowac, nie mam dostepu do atari, patcha robilem miedzy kawa a szarlotka w pracy wiec prosze o wyrozumialosc

jakis czas temu
http://atariarea.krap.pl/forum/viewtopi ... 912#p93912
http://atariarea.krap.pl/forum/viewtopi ... 57#p110557
juz Ci wysylalem.

poza tym maly patch na sidplayera swietego zalatwi sprawe (wylaczenie emulacji i podmiana bajtu odpowiedzialnego za strone gdzie zapisuje rejestry sida) - 'na szybko' to powinno wystarczyc

---
poprawka. nie trzeba nawet wylaczac emulacji.

oto patch:

                lda #$00
                sta $f0
                lda #$11 lub $20 zaleznie od wersji
                sta $f1

i zmieniamy na:

                lda #$00
                sta $f0
                lda #$D5
                sta $f1

i mamy funkcjonalnego playera sidow na atari. na szybciocha starczy.

pomyslec to za malo.

ale... moge zrobic tech demo (ale nie cala gre) do wyboru:
- scroll lewo/prawo tla z paralaksa na overlay (np 4 warstwy - powinno sie jeszcze wyrobic tilesy i blitter)
- shooter bez tla 1 ekran na overlay z kolizjami liczonymi programowo (sprity na blitterze)
moge to zrobic dla FX jesli bede mial pewnosc ze powsatanie rdzen (powiedzmy dla mnie) o ktorym mowie.

? tylko po co mam udowadniac ze moge cos napisac na fx ?

szybko by sie pojawilo na malym atari :-)

http://www.system16.com/hardware.php?id=760
http://www.system16.com/hardware.php?id=759

nie znam basica ale sprobuj w linii 910 zamiast "AND" wpisac ":".

po tym jakie bzdury co chwile wypisujesz to smialo mozna ignorowac i te ;-) a poza tym nie nadymaj sie tak bo pekniesz i jeszcze smrodu narobisz. :D

> Translate function on Blitter. Programmer supplies a 256 byte lookup table, and source data is used as index into table which selects each byte to write to destination.
With that we can then perform easy shift/rotate operations, the data is precalculated for us. A 7 way set of Rotate lookup tables costs us less than 1.5 K

tab_adr         equ $00

                ldy #$00
_copadr         lda adresy,y
                sta tab_adr,y
                iny
                cpy #...
                bne _copadr

adresy  dta a(_adr1),a(_adr2),a(_adr3),a(_adr4), .....

and

            ldx #$00
            ldy #$00
_1          lda position,y
            sta (tab_adr,x)
            inx
            inx
            iny
            cpy #...
            bne _1

and then

            ldy #$00
_adr1 equ *-1
            lda (pzero),y
            ldy #$00
_adr2 equ *-1
            sta (pzero),y
            ldy #$00
_adr3 equ *-1
            lda (pzero),y
            ldy #$00
_adr4 equ *-1
            sta (pzero),y
...
or sth ???

>Graphics remapping function.  e.g. for doing C64 conversions, it'd be great to be able to just take 1 or 2 bit per pixel source data and have it automatically remapped to full byte destination per pixel.  Use of existing OR function allows easily giving each sprite it's unique range of colours.

> ADD operation on 16-bit data.

> Blit operation which loads data into a Palette.  As it is, it's not very practical to do pics with >1024 colours.  If a blit op could do a palette reload, then greatly increased colour range would be a reality.

maybe for such tasks better solution is vbxe with mini cpu instead blitter?
cpu in vbxe has access to vbxe registers...

---

> jeszcze sie zastanowcie nad kwestia "moralna" - na ile atari z 2ma cpu bedzie jeszcze atari - dla mnie przetwarzanie rownolegle na 8bitach to juz przesada

w latach 70 zeszlego stulecia atari w automatach juz to mialo. dla wielu vbxe w atari jest przesada, wpasowales sie w ogolny trend ;-)

> blitterem w tej chwili mozna zrobic dowolna gre bazujaca na tilemapie

no wlasnie... ale kopiowanie prostokatow to nie wszystko

wedlug Ciebie jedyny, wedlug mnie koncepcje nowego rdzenia do vbxe uratowac moze tylko grupa programistow (jeden - ja :p juz jest) ktora bedzie pisala programy na vbxe bo tylko wtedy mozna bedzie przekonac electrona do dzialania.

> Ręczne przełączanie rdzeni kładzie całą ideę na łopatki. Jeśli przed uruchomieniem każdego programu trzeba będzie ręcznie przełączyć rdzeń na inny (a niekoniecznie jest tak, że gdzieś tam ktoś trzeci nie myśli teraz o napisaniu swojego rdzenia do grafiki wektorowej na przykład), czyli uruchomić FC i zbootować nowy rdzeń rozwalając dotychczasową konfigurację (czyli np. SpartaDOS rezydujący w pamięci ext rdzenia R albo sterowniki siedzące w VRAM-ie), to jest to najlepszy powód, żeby pozostać przy FX-ie.

automatyczne przelaczanie jest o tyle problemem, ze oprocz sprawdzania core_version trzeba by bylo sprawdzac jaki rdzen jest w ktorym slocie i go ewentualnie uruchomic (co pewnie chwile trwa) po pierwszym inicie przy ladowaniu juz cala konfiguracja jak mowisz poleci i tak. nie mozna wymagac ze program za soba posprzata i przywoci poprzedni rdzen (bo byc moze wylaczylismy komputer przyciskiem power) wiec takie sprawdzanie musialo by sie odbywac przy kazdym np.wywolaniu sterownika ktory kozysta z funkcji ktoregos rdzenia - to moze byc strzal w stope... co do biblioteki grafiki wektorowej to nie trzeba kolejnego rdzenia, na tym ktory opisuje taka biblioteke mozna zaladowac nie tworzac nowego rdzenia...