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

@mono, ciekawe, ale moim zdaniem zrodla rdzenia nie powinny byc publiczne, dlatego tez bylem i jestem przeciw jakimkolwiek zestawa devloperskim do generowania rdzeni vbxe. dlatego tez zwrocilem sie do electrona, i staram sie, i bede sie staram wszystkimi mozliwymi sposobami przekonac go do swoich racji ;-)

a uporem maniaka wracam do tego conajmniej od wersji w ktorej pojawil sie memacA w takiej postaci jak jest teraz...

powtarzam kolejny kolejny raz, nie chce zmieniac standardu ktorym jest FX. chce rdzenia 'na zlecenie' z funkcjami jak opisalem - byc moze jakiemus programiscie tez sie przyda...

obecenie jest tak, ze niektorych rzeczy nie da sie zrobic na vbxe, wiec musze niektore rzeczy upraszczac/zmieniac, a skoro juz to robie to wprowadzam modyfikacje tak, zeby gra ruszyla na standardowym atari.... i tym sposobem gry nie bedzie na vbxe... tak to niestety wyglada obecnie :/ nie stawiam sprawy na ostrzu noza bo to nigdy do niczego nie prowadzi ale z mojego punktu widzenia FX nie ma nalezytego wsparcia dla tych ktorzy chca pisac gry na vbxe.

@draco30 z tym trybem 160 i jego zaleta, ze miesci sie w pamieci ktora bezposrednio moze adresowac 6502. przedstawiasz wade vbxe jako zalete. gdyby w vbxe byl cpu z dostepem do calej pamieci vbxe to nawet bys nie pomyslal o trybie 160. co wiecej, dzieki cpu w vbxe mozna by ja zorganizowac np. tak jak jest w TMS9918 - ale znowu... to jedna z wielu, wielu mozliwosci...

co zmieni kolejna versja vbxe w moim przypadku? co zmieni w przypadku tych kilkudziesieciu osob ktore maja wersje obecne?

jeszcze raz powtarzam, nie chce zmieniac standardu ktorym obecnie jest rdzen fx. mowie o rdzeniu ktorego baza ewentualnie moze byc fx ale nie bede sie upieral jesli baza bedzie rdzen emulacji gtia !

---
jesli miejsca jest tak dramatycznie malo to mozna wybrac tylko to co jest faktycznie uzyteczne a bajery wylatuja, przyklad:
- tylko 3 tryby: tekstowy 80, tekstowy 40, graficzny 320, tylko 2 szerokosci obrazu
-  tylko 2 priorytety dla overlaya (nad/pod playfieldem)
- mapa atrybutow wlaczana zawsze z xdl wielkosc zawsze taka jak komorka trybu xdl (dla trybu graficznego overlaya brak mapy atrybutow)
- planarna organizacja mapy atrybutow dla pixela i tla (duzo prostrza)
- kolor0 zawsze przezroczysty dla overlaya i m.atrybutow
- usunac detekcje kolizji overlaya
itp.

dla mnie najwazniejsze jest to co napisalem w pierwszym poscie, co do reszty mozna zawsze podyskutowac...

to ze nie ma miejsca wszyscy wiedza (ja tez ;) rozchodzi sie o to co usunac, zeby miejsce sie znalazlo...

tak, blitter w takiej formie zniknie ale pojawi sie cos bardziej uzytecznego co zreszta moze 'emulowac' rowniez blitter, pytanie czy szybkosc bedzie do zaakceptowania.

> do rejestrow sprzetowych nie zapisze ci mini cpu, midi cpu, ani nawet haj tower cpu - ka pe wu?

a gdzie napisalem ze zapisze?

wyraznie napisalem ze nie zapisze:

>(zapis do rejestrow oraz do pamieci vbxe - wiadomo, ze z poziomu np blittera nie zapiszemy rejestrow sprzetowych ale jak bedzie minicpu w rdzeniu to przynajmniej bedziemy mogli czytac co zostalo do rej.sprzetowych wpisywane)

to teraz wolniej napisze: bedzie mozna czytac to co zostalo do rejestrow sprzetowych zapisane przez 6502 a znajdzie sie jako cien w pamieci vbxe poprzez:

> oraz kontroli zapisu do pamieci vbxe gdy zaslaniana jest przez rejestry sprzetowe

jeszcze wolniej:

umozliwic konfiguracja memacA gdy czesc pamieci vbxe zaslania rejestry sprzetowe aby zapis do rejestrow sprzetowych (przez 6502) powodowal zapis rowniez do pamieci vbxe (tej zasloietej)

a to jest mozliwe.

zestaw:
1. przelotka/przedluzacz eci + cart (z podlaczonym sygnalem audio in) dla karin
2. kompletny poskladany interfejs i w obudowie
3. wysylka

taki zestaw ile kosztuje?

rozumiem, ze jest to kopia karin maxi geislera? one nie mialy zadnych problemow z dzialaniem z roznymi modelami atari - tu jest tak samo?

i jeszcze jak sie ma sprawa z napedem? nie wiem czy dobrze pamietam, ze stacje 3'5 z pc lub st podlaczalo sie bezposrednio? czy moze przecinalo sie jakis kabelek w tasiemce?

no to jest juz dwoch chetnych

o cos takiego prosilem swojego czasu electrona, odpowiednio skonfigurowany memacA, oraz konfigurowalny rownoczesny zapis do rejestrow sprzetowych oraz pamieci vbxe ktora znajduje sie 'pod'.