51

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

http://atari.pl/hsc/ad.php?i=1.

52

Z biblioteką  obsługi VBXE jest jak z OSem - co nas obchodzi jak ona to zrobi? Wywołujesz funkcję i ma działać. Martwimy się jak OS ładuje dane z C:? Nigdy. Kwestia napisania odpowiedniej biblioteki/rozszerzenia OSu.

IMHO taka biblioteka pozwalająca na zarządzenie rdzeniami w VBXE mogłaby być przydatna koderom każdego rodzaju aplikacji do określenia konfiguracji sprzętu. Widziałbym to, jako rozszerzenie OS tak, żeby aplikacje miały dostęp zawsze do aktualnej wersji biblioteki w systemie, a nie do tego z czym aplikacja była skompilowana.

A skoro tak, to deklarowałbym się jako chętny do stworzenia takiego rozszerznia, oczywiście o ile Candle i Electron wyrażą zgodę. Potrzebowałbym jeno konsultacji oraz sugestii ze strony ludzi używających/piszących pod VBXE co mogłoby być w takiej bibliotece potrzebne. Uprzedzam z góry, że do tej pory nic, ale to nic nie napisałem dla VBXE.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

53

Na wyłączenie komputera przed zakończeniem programu lekarstwem jest defaultowy rdzeń, z którym VBXE będzie zawsze wstawać po włączeniu zasilania. To od biedy spowoduje, że nie trzeba będzie nic przywracać (tylko przełącznika szkoda).

Sprawdzenie rdzenia musiałoby zachodzić raz, przy ładowaniu programu, który z niego korzysta.

Co do biblioteki grafiki wektorowej, i że nie trzeba kolejnego rdzenia: to tylko tobie się tak wydaje. 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ą?

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

KMK
? HEX$(6670358)

54 Ostatnio edytowany przez xxl (2011-01-06 20:05:26)

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

http://atari.pl/hsc/ad.php?i=1.

55

To pomysł mono. Poza tym to jedyny sposób, żeby uratować twoją koncepcję.

KMK
? HEX$(6670358)

56

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.

http://atari.pl/hsc/ad.php?i=1.

57 Ostatnio edytowany przez drac030 (2011-01-06 20:39:54)

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.

Offtopic: Rybags właśnie wypuścił kolejną gierkę, Spectipede. Jeśli chodzi o ilość tytułów, to chyba jest najwydajniejszym z koderów.

KMK
? HEX$(6670358)

58

Pin napisał/a:

BartoszP - co określasz mianem - "- pin = niestandardowa platforma do testów" ?? :)

Co mam niestandardowego z racji na kompatybilność, co ma aż tak duże w tym względzie znaczenie? [ciach-ciach] ....... co takiego? :)

To wystarczy za odpowiedź :)
http://lh5.ggpht.com/_33kljA9uA3o/TQVIFfAWByI/AAAAAAAAB-0/_4H599ivEzQ/s640/DSCF8410.JPG

59

> 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

http://atari.pl/hsc/ad.php?i=1.

60

Myślę, że gier powoli, przynajmniej jeśli chodzi o Rybagsa, będzie przybywać :) Sam Rybags cieszy się, gdy ktoś chwali jego pracę i to go motywuje do dalszej pracy. A samo Spectipede jest dla mnie bardzo grywalne.
Osobiście myślę, że warto pisać gry na to, co już jest, a nie lobbingować Candle'a i Electrona do rdzenia pomysłu xxl'a. Pewnie, zmiany są fajne tyle tylko, że ludzie, poza pasją, mają inne sprawy na głowie. Mi by się nie chciało "ręcznie" wybierać rdzenia.

oto koło :r przyp "pole 3,142857 * :r * :r przyp "l 2 * 3,142857 * :r przyp "i l / 360 powtórz 360 [np :i lw 1] już

61

Pin napisał/a:
jellonek napisał/a:

pin: mozesz konkretnie podac o ktora "reszte" ci chodzi? wymien z tytulow.


... no chyba Cię bóg opuścił, że z tego właśnie powodu podmienię vbxe z D6 na D7 i będę sprawdzał co i dlaczego nie działa. Dotknięcie czegokolwiek w tym kompie wymaga interwencji w NASA ;)-

Pin, nie musisz sprawdzać "dlaczego", wystarczy podać, co. Swoją drogą, warto byłoby mieć (tzn. ja bym chciał mieć) na takie okazje przełącznik na obudowie Atari, który przełączałby VBXE ze strony D6 na D7 albo odwrotnie. Oraz może jeszcze z jeden, który blokuje zapisy do rejestru konfiguracyjnego (przypadek Gyrussa na czarno).

KMK
? HEX$(6670358)

62

jeszcze sie zastanowcie nad kwestia "moralna" - na ile atari z 2ma cpu bedzie jeszcze atari - dla mnie przetwarzanie rownolegle na 8bitach to juz przesada
blitter jako wyspecjalizowana jednostka graficzna do operacji na blokach pamieci jest super i myslac poza pudelkiem mozna sporo  nim zdzialac - a ze niektorzy najwidoczniej nie potrafia - coz

blitterem w tej chwili mozna zrobic dowolna gre bazujaca na tilemapie, uzywajac przezroczystosci i antica mozna zrobic paralaxe nie obciazajac dodatkowo blittera
levele sa praktycznie dowolnych rozmiarow jakie moga zmiescic sie w pamieci, a jedynym ograniczeniem jest tu 512k ramu
jakos nie widze zeby ktokolwiek to wykozystal, chociaz tebe moze cos chowac w rekawie

takim cpu mozna tez to zrobic? alez tak! pewnie jakies 5x wolniej...

przechodze na tumiwisizm

63

Można też zrobić cieniowanie gorauda :)

What can be asserted without proof can be dismissed without proof.

64

What I would like for VBXE:

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

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.

I'd gladly give up 2 palettes to be able to do that stuff.

65

koncert życzeń rozwija się w pełni :)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

66 Ostatnio edytowany przez xxl (2011-01-07 09:49:06)

> 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

http://atari.pl/hsc/ad.php?i=1.

67

o tak, np motorola 68k i z80...
w automatach drugi cpu byl zawsze do dzwieku, nigdy do grafiki
w niektorych masz oddzielne gpu dla 3d, ale to jakby inna bajka
w innych, nawet "droga" (wyscigi) jest generowana sprzetowo przez niezalezne uklady na osobnym overlayu

zamiast dowodzic jak wspanialy jest cpu moze pomysl jak dana funkcje zrealizowac blitterem

przechodze na tumiwisizm

68

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

http://atari.pl/hsc/ad.php?i=1.

69

to sprobojmy wprost

ani ja, ani electron nie napiszemy ci rdzenia z cpu - po prostu

napisac sobie mozesz sam, zaczynajac od zera - tak jak ja i electron

czy takie postawienie sprawy ci wystarczy? czy trzeba ci to narysowac?

przechodze na tumiwisizm

70

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

http://atari.pl/hsc/ad.php?i=1.

71

przecież cała zabawa polega na pokonywaniu ograniczeń sprzętowych na drodze programowej

ostatnie zmiany w VBXE typu dodatkowy kabelek, zmiany w MEMACA, MEMACB wymusił XXL, czy to spowodowało wzrost liczby programistów albo programów wykorzystujących to nowe podejście, wymusiło to tylko potrzebę poprawiania wcześniej napisanego softu

aż strach brać się za coś większego, kiedy nagle okaże się że trzeba wszystko poprawiać bo ktoś tam postanowił kogoś uszczęśliwić

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

72

Tebe odstrachaj się.
Rdzenie są kompatybilne od 1.5 (?) roku wiec śmiało bierz się za coś większego.

pomidor

73

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

http://atari.pl/hsc/ad.php?i=1.

74

BartoszP :) - tylko, że jak by to samo było zrobione na płytkach np. Lotharka, to już by nie stanowiło argumentu dla Ciebie, bo wyglądało by normalnie :P Nie szata zdobi Atari :D

Kontakt: pin@usdk.pl

75 Ostatnio edytowany przez BartoszP (2011-01-08 14:52:39)

@Pin ..mnie po prostu fascynuje ile modułów da się upchnąć  do środka i nie zamykać obudowy przy pomocy kolana.
Ale przyznać musisz, że mało kto ma tak wypasionego...ups...  standardowego i działającego XEGS jak Ty :)