5,851

(24 odpowiedzi, napisanych Programowanie - 8 bit)

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?

5,852

(6,258 odpowiedzi, napisanych Kolekcjonowanie)

http://allegro.pl/konsola-atari-xe-pist … 63515.html

obecna cena 200zl w jakich cenach to chodzi? chcialbym kupic ale juz wydaje mi sie wysoka... ?

5,853

(76 odpowiedzi, napisanych Bałagan)

takie posty sa zupelnie niepotrzebne.

5,854

(341 odpowiedzi, napisanych Fabryka - 8bit)

nie wylaczalem emulacji sida na pokey ale to nie ma znaczenia bo player oryginalnie zapina na SIDa zapisujac do D5xx a pozniej dopiero emulator interpretuje wartosci zapisane do rejestrow SIDa na wartosci dla POKEYa, ale... ale interpretuje zawsze to samo bo zmienilem strone gdzie player sida zapisuje... innymi slowy, dopoki na stronie $0100-$011f sa zera nie bedziesz slyszal dzwieku na pokey a pasek na ekranie bedzie mniej wiecej tej samej szerokosci, ale SID ma grac...

udostepnij jakis dzwiek

5,855

(341 odpowiedzi, napisanych Fabryka - 8bit)

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

5,856

(29 odpowiedzi, napisanych Fabryka - 8bit)

na d4 jest antic, ten player korzysta z antica (synchronizacja) ale nie zapisuje tam dzwieku, VBI atari os tez dziala wiec zapisuje tam wartosci ale nie sa to wartosci dzwiekowe plajera sidow...

5,857

(341 odpowiedzi, napisanych Fabryka - 8bit)

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.

5,858

(24 odpowiedzi, napisanych Programowanie - 8 bit)

na atari najprosciej zrobic tak, zeby caly obraz byl dostepny - bo po LMS mozna 4kb przyporzadkowac. ale ma to cala mase wad - pamieciozernosc jest chyba najwieksza z nich...

np. dla scrolla w jedna strone spotkalem sie z takimi sposobami:
1. ekran jest standardowej szerokosci, bufor jest szerszy o wielkosc 'klocka' i co ustalony czas bufor jest kopiowany na ekran (ekran jest zbudowany z grafiki 'na znakach') po przewinieciu, licznik linii wraca, bufor jest przepisywany nowa wartoscia i od poczatku procedura sie powtarza
2. nie ma bufora, ekran jest szerszy od widocznej czesci o wielkosc elementu graficznego (najczesciej widzialem 2 lub 3 bajty) po przewinieciu  licznik zerowany, ekran jest kopiowany a w wolne miejsce (teraz zasloniete) kopiowany jest pionowy pas z elementami graficznymi
3. podobnie jak na atari, tylko tak jakby po LMS mozna bylo zdefiniowac po ilu bajtach linia ekranu sie 'zawinie' i zawsze kopiowany jest tylko pionowy pas grafiki na znakach, licznik scrolla nigdy nie jest zerowany.

czyli w najlepszym wypadku trzeba kopiowac (w warunkach atari) ok 12-72 bajty co 4-12 ramek oraz < 1kb po przeladowaniu scrolla ?

5,859

(91 odpowiedzi, napisanych Sprzęt - 8bit)

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 ?

5,860

(76 odpowiedzi, napisanych Bałagan)

w ankiecie brak pozycji "pomidor" dla tych co nie chca glosowac.

5,861

(91 odpowiedzi, napisanych Sprzęt - 8bit)

szybko by sie pojawilo na malym atari :-)

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

5,862

(16 odpowiedzi, napisanych Programowanie - 8 bit)

zmienna "Z" nie jest wyrzucona poza warunek bo znajduje sie w tym samym wierszu (nawet po ":")...

5,863

(16 odpowiedzi, napisanych Programowanie - 8 bit)

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

5,864

(91 odpowiedzi, napisanych Sprzęt - 8bit)

@tebe: nikt nie mowi o jakichkolwiek zmianach w rdzeniu FX. to jest standard.

dopiero od memacA zaczely pojawiac sie moje programy na vbxe... a o jego zmianach dowiedzialem sie pewnie wtedy co Ty.

5,865

(91 odpowiedzi, napisanych Sprzęt - 8bit)

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

5,866

(91 odpowiedzi, napisanych Sprzęt - 8bit)

> o tak, np motorola 68k i z80...

:-) nie prawda, a wlasciwie nie tylko :-)

> w automatach drugi cpu byl zawsze do dzwieku, nigdy do grafiki

nie prawda, nie zawsze do dzwieku, do grafiki rowniez :-)

itd.

5,867

(91 odpowiedzi, napisanych Sprzęt - 8bit)

> 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

5,868

(91 odpowiedzi, napisanych Sprzęt - 8bit)

> Masz rację. Im więcej jest programów na FX tym mniejsze jest prawdopodobieństwo, że komukolwiek się będzie chciało *ręcznie* wybierać rdzenie przed uruchomieniem każdego kolejnego programu.

no mam racje, poza tym jesli powstanie rdzen z funkcjami o ktorych pisze i zaczna sie na niego pojawiac programy to prawdopodobienstwo ze user bedzie uzywal tego rdzenia zacznie rosnac. rosnac szybciej jesli programy beda dobre, lepsze, najlepsze ;) to zmotywuje programistow :)

a tego zeby programy na vbxe byly lepsze chyba sobie wszyscy zyczymy :D

5,869

(91 odpowiedzi, napisanych Sprzęt - 8bit)

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.

5,870

(91 odpowiedzi, napisanych Sprzęt - 8bit)

> Sam jesteś niezadowolony z możliwości FX-a, a sądzisz, że wszyscy inni będą zadowoleni z rdzenia twojego pomysłu na tyle, żeby nie spróbować zrobić po swojemu czegoś, co potrzebują?

i po to jest ten watek, zeby programista ktory jest niezadowolony z FX przylaczyl sie i podyskutowal co go boli. przypominam: progrmaista ktory chce na taki rdzen pisac programy.

> Co do reszty, sam widzisz, jak to komplikuje życie.

nie, nie jestem za automatycznym przelaczaniem Twojego pomyslu. nie chce sobie komplikowac zycia :-)

5,871

(91 odpowiedzi, napisanych Sprzęt - 8bit)

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

5,872

(91 odpowiedzi, napisanych Sprzęt - 8bit)

@draco30: http://atariarea.krap.pl/forum/viewtopi … 90#p118790

@mono, tylko reczne przelaczanie rdzenia (jesli juz) jest bezpieczne

5,873

(0 odpowiedzi, napisanych Bałagan)

> Nikt tego nie proponuje - to właśnie ty twierdziłeś, że konieczność mapowania pamięci obrazu do przestrzeni adresowej 6502 to wada. Teraz, jak widzę, już tak nie twierdzisz. A więc tu się zgadzamy: tryb lowres się przydaje

zgadzamy sie co to tego ze lowres sie przydaje ale:
przydaje ale w FX i wynika to z wady vbxe z FX jesli chcemy miec dostep do pamieci ekranu w jednym kawalku na raz to jedyny sposob a tak wlasnie sugerujesz tu:

> Ma ważną zaletę: pamięć obrazu (w 160x192) zajmuje tylko 30 KB, przez co od biedy można ją w całości zmapować do pamięci Atari.

5,874

(91 odpowiedzi, napisanych Sprzęt - 8bit)

> Co do CPU, z twoich słów wynika, zdaje się, że dążysz do tego, żeby zrobić z VBXE oddzielny komputer

zupelnie nie...

> Ogólnie dyskusja jest akademicka, bo jak nadmienił electron, w rdzeniu nie ma miejsca na nowe rzeczy.

i kolejny raz... nie chce dolozenie nowych funkcji do rdzenia ktory jest standardem FX i ktorego ja nie chce ruszac.

> Łatwym do przewidzenia skutkiem będzie to, że soft będzie wykorzystywał tylko to, co działa w obu rdzeniach. Albo nie będzie powstawał wcale (vide postawa tebego, ja szczerze mówiąc też już w pewnej chwili miałem dość, kiedy się okazało, że blitter zmienia się z wersji na wersję - na szczęście się ustabilizował i mi przeszło).

najprawdopodobniej nie bedzie funkcji ktore beda tak samo dzialac na tym rdzeniu (jesli powstanie) i FX. jesli programisci uzywaja FX to dlaczego mieli by przestac skoro FX jest standardem? dlatego ze xxl bedzie mial inny rdzen? myslisz ze mam taka moc? :D
skoro odnajdujesz radosc w programowaniu na FX to raczej nie jest temat dla Ciebie... szukam progrmistow, ktory chcialby uzywac tego 'zamowionego' rdzenia - sam nie przekonam electrona ale w grupie... dlatego rozpisywanie sie osob, ktore nie beda tego uzywac to tylko zaciemnianie tematu

---
ale do tego sie ustosunkuje:
> zauważ, to CPU, żeby można było uniknąć mapowania trybu do przestrzeni adresowej 6502, musiałoby być co najmniej złożoności normalnego procesora typu 6502 albo Z80. Już nie mógłby to być uproszczony procesorek pomocniczy, gdyż w takim wypadku konieczność mapowania VRAM-u do dostepu dla 6502 ciągle by zachodziła, a tu możność zmapowania jej w jednym kawałku - to zaleta.

dlaczego ograniczac mozliwosc mapowania? dlatego w pierwszym poscie napisalem tez o rozwinieciu memaca, a jesli nie mapowac tylko zalatwoc to cpu w vbxe to wystarcza 2 lub 3 tryby adresowania (zalezy jak realizowac) i 2 rejestry cpu + 1 lub 2 znaczniki procesora.

5,875

(91 odpowiedzi, napisanych Sprzęt - 8bit)

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