lol ;)
a pokaz mi chocby specyfikacje do v3

widzicie - zenua na calej linii ;)

pokazcie ze WARTO cokolwiek dla was zrobic

oczywiscie ze bedzie 100% kompatybilnosci, a na Głuchołazach zadnej rozmowy o v3 nie było
nikt nie zostanie z reka w nocniku jesli chodzi o v3
fx jest mainstreamowy i to wszystko, jesli ktos chce (np xxl) popelnic swoj rdzen, o nowych, wyuzdanych mozliwosciach (paleta CGA, rozdzielczosc 256xY, mapa atrybutów prosto z ULA, cycle exact Z80) ma do tego prawo
to nie jest takie trudne

zamiast smucic ze to czy tamto jeden czy drugi chce - zrobcie cos - powtarzam to w kolko, odpowiada tylko echo

swietnie, ze wyjasniacie sobie sprawy, ktore nie sa przedmiotem tego watku. juz na poczatku pisalem, ze sprawa dotyczy vbxe w obecnej wersji.

> zrobcie cos

zrobimy.

dajcie rdzen o ktorym pisze.

Nie neguję FX, bo zostałem być może źle zrozumiany. Jestem za opcją taką, by powstał jeden rdzeń w możliwie 99% zgodny z gtia (a może nawet 100% :) ), oraz drugi dowolnie wybajerowany rdzeń na którym działałoby 100% programów dla wybajerowanego VBXE :)

Candle - jak miałem kartę na $D7 to okazało się, że była jedynie możliwość uruchomienia FC, oraz może jednego, czy dwóch programów dla karty. Reszta, choć nie zawsze wywalała jakieś komunikaty w rodzaju, że w kompie nie ma VBXE ;)-

Poza tym - by sensownie napisać coś pod kartę, to musi ustabilizować się sprawa rdzeni, bo tak - to zostają programiki dla testów i zabawy. Skądinąd niejednokrotnie bardzo ciekawe i ładne :)- tylko, że obecnie większość na 1.22 mi nie działa i pieron wie pod czym to miało być uruchamiane :)

Widzisz, Candle - i tu dochodzimy do sedna sprawy. Otóż osobiście zajmuję się muzakami i nie ukrywam, że chętnie napiszę coś pod VBXE i dla przykładu rdzeń SoundBoard - bo z kodowaniem u mnie raczej kiepsko (chyba, że TBXL :) ). Problem jednak w tym, że rdzeń na VBXE1.x nie działa jak do tej pory w sposób prawidłowy. Zresztą - by nie było mowy o tym, że nic nie robię - przesiedziałem kilka dni sprawdzając temat wraz z Mono :).

Też jestem za tym, tzn. za stabilizacją rdzenia. Ta nastąpiła kilka wersji temu, tzn. od 1.20 rdzenie robią to samo. I z tego co pamiętam, electron z candlem już parę razy "ucinali spekulacje", ale mimo tego, jak widać, xxl raz za razem wraca do tematu (chciałoby się napisać, że "z uporem maniaka").

Kontrowersję, w której ktoś chce coś z rdzenia usunąć, a ktoś inny (np. ja) uważa, że wszystko się tam może przydać i niczego usuwać nie trzeba[1], można rozwiązać tylko w jeden sposób: budując nową kartę z większym FPGA. Tylko że to oczywiście grozi nowym koncertem życzeń.

Co do V3, pamiętam że coś o tym było mówione, ale być może było to tylko taki chwilowy pomysł (chyba electrona ale głowy nie dam) i być może tylko w kontekście powiększenia miejsca na rdzeń VGA. Nie chcę tu rozsiewać plotek, więc przyjmijmy, że nic takiego nie zaszło.

[1] Też mi się kiedyś wydawało, że np. tryb lowrez (160 pix w 256 kolcach) jest niepotrzebny. Do czasu, kiedy mi się jednak przydał. 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.

...

Pomyślałbym, bo on mi się przydał wcale nie ze względu na to, że mieści się w pamięci. Przeciwnie, wystarczyło okno 8k. Ale możność zmapowania trybu grafiki bezpośrednio do pamięci, tak żeby miał do tego dostęp 6502 (dokładnie tak jak w przypadku trybów standardowych) *oraz* blitter, to jest zaleta, bo nie trzeba bankować RAM-u (przynajmniej dla mnie jest to zaleta, bo ja nie lubię bankowania).

"Gdyby w VBXE był CPU" - no ale nie ma. W standardowym Atari też wielu rzeczy nie ma, a jednak programy powstają, bo programiści umieją wykorzystać to co jest zamiast przykrajać sprzęt do własnych umiejętności/pomysłów.

Co do CPU, z twoich słów wynika, zdaje się, że dążysz do tego, żeby zrobić z VBXE oddzielny komputer - w takim układzie, 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.

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

PS. Aha i jeszcze jedno:

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

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

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