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

Ostatnio edytowany przez Pin (2011-01-06 15:18:10)

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.

Ostatnio edytowany przez drac030 (2011-01-06 15:35:45)

Ależ Panowie (i Panie). Jeśli ktoś chce zmian w rdzeniu, to sprawa jest prosta (i chyba jedynie taka opcja wchodzi w grę).
Należy pójść do Electrona i Candle, porozmawiać z nimi i przekonać do dwóch rzeczy:
1. Że znamy się na VHDL/Verilog (nie znam się).
2. Że źródło rdzenia nie wycieknie do osób postronnych.
Następnie zmontować sobie zestaw developerski do testowania własnych zmian w rdzeniu, no i implementować co tam sobie kto chce.
Oczywiście, że nie zrobi tego KAŻDY (w końcu Autorzy też mogą powiedzieć "nie, bo nie" i nic nikomu do tego), ale oczekiwanie, że nasze zachcianki zrealizuje Candle lub Electron przy braku oprogramowania i jakichkolwiek inicjatyw niestety są niepoważne, bo oni też mają ograniczoną ilość czasu do zainwestowania w swoje pasje, a przecież nie muszą być przekonani do naszych pomysłów.
Jest też inna droga (jeśli sami nie znamy się/nie umiemy/nie chcemy się znać na VHDL/Verilog) - przekonać jakiegoś developera żeby wydobył rdzeń od Candle i Electrona i wprowadził zmiany, które chcemy zobaczyć.

Edit: A jeśli ktoś sądzi, że to niewykonalne to niech sobie wyobrazi że chciałby wprowadzić zmiany w kernelu M$ Windowsa. W przypadku VBXE ma przynajmniej dostęp do Autorów...

Ostatnio edytowany przez mono (2011-01-06 16:10:45)

...

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

Ostatnio edytowany przez drac030 (2011-01-06 17:20:51)

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

Ostatnio edytowany przez xxl (2011-01-06 18:06:37)

Właściwie to najprostszy CPU to taki, co potrafi przesłać z pamięci do pamięci i w przestrzeni adresowej ma:
- program counter,
- rejestr(y) realizujący jakiś operator - najprościej A NAND B bo ono tworzy system funkcjonalnie pełny (za jej pomocą można zrobić każdą operację), choć wygodnie byłoby mieć też A NOR B, A ADD B i A MUL B.

Ale przecież FC jakoś potrafi zbootować wybrany rdzeń? Slotów jest 4 (VBXE1) i 13 (VBXE2) więc oprogramowanie, które chciałoby użyć konkretnego rdzenia mogłoby sprawdzić czy takowy jest dostępny, po czym go łaskawie włączyć, a po zakończeniu działania przywrócić stary. Jak user zaś nie ma rdzenia, to ERROR! i dziękujemy.

Edit: ...lub też "ERROR! Proszę załadować wymagany rdzeń", lub jeśli sami go dostarczamy z aplikacją, znajdujemy wolny slot i pakujemy do VBXE. Mogłaby przecież być biblioteka do takich rzeczy dostępna.

Ostatnio edytowany przez mono (2011-01-06 18:47:09)

Może w większości przypadków wystarczyłoby tylko skasować zawartość VRAM i zbootować. W końcu rdzeń musi umieć pracować na jakiejś początkowej zawartości VRAM.

Ci co mają problem z wektorami to pewnie nie :) Ale inni...

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