Jak bardzo możliwości VBXE zostały już wyryte w kamieniu, a jaki jest jeszcze potencjał na robienie rozszerzeń do tego boarda?

Po to jest forum, żeby rozmawiać, więc tak tylko się pytam, a nie wiem jakie są fizyczne możliwości w kwestii upychania w rdzeniu czegoś nowego oraz jaka jest ochota twórców na pochylanie się nad projektem.

Otóż z tego co pomyślałem trochę nad tematem, to coraz bardziej męczy mnie refleksja, że boardowi do ideału brakuje trochę balansu w stosunku do wydajności maszyny, z którą ma pracować. Temat jest chyba znany każdemu, kto próbował to programować, bo nie chodzi o to, że VBXE umie za mało, tylko że właśnie za dużo, żeby atari zadowalająco dało radę z obsługą tego wszystkiego i wyjście poza przeglądarkę plików BMP na graphics compo jest po prostu trudne.

Konkretnie to myślę nad rozszerzeniem istniejącego trybu działania na inne tryby graficzne, które w praktyce byłoby swoistym downgradem możliwości, ale powinno dać zauważalnego kopniaka wydajnościowego. W trybie HR każdy piksel jest opisywany przez nibel danych. Czy jest możliwe, aby taką organizację pamięci móc włączać dla trybów SR i LR? W zamian za 16 kolorów w pikselu (co dla atari jest wg mnie w zupełności akceptowalne) oszczędzamy dwukrotnie na pamięci ekranu oraz wydaje mi się, że dwukrotnie zwiększamy efektywność blittera.

Jak bardzo byłoby to trudne? Na pewno problematyczne jest rozszerzenie XDL, gdyż mamy tylko jeden wolny bit (2.6) którego nie powinniśmy zużywać na dokładnie ten cel, bo zamknęlibyśmy możliwość dalszego rozwoju, ale jakby użyć tego bitu na rozszerzenie komendy XDL do trzech bajtów, to wtedy wystarczyłby tylko jeden bit w trzecim bajcie na wymuszenie trybu 16-to kolorowego (i jeden na wyłączenie dla zachowania konwencji).

Ktoś ma jakieś refleksje? A może komuś zrodził się lepszy pomysł na uprzyjaźnienie VBXE?

2 Ostatnio edytowany przez tebe (2018-06-11 21:21:31)

Electron zamknął temat definitywnie, ostatnia modyfikacja rdzenia VBXE dotyczyła podmiany palety kolorów na opracowaną przez ROCKY-ego, jest ten rdzeń do pobrania ze strony madteamu

Electron już oświadczył że nie będzie się tym zajmował, informował też że kompilacja dotychczasowych rdzeni wymagała dużo pracy aby to upchać, walczył już o każdy bajt aby to zmieścić, więc jakiekolwiek zmiany dotyczyć mogą tylko nowych oddzielnych rdzeni nie kompatybilnych z dotychczasowymi

tak jak ma to miejsce obecnie, wybierasz rdzeń GTIA, albo rdzeń FX, a jak do tej pory tylko JEDNA osoba napisała te rdzenie, czyli Electron

uprzyjaźnić VBXE? a po co Mad Pascala tworzyłem? przykłady są? są ...

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

3

najwięcej możliwości to by dało jak by z poziomu ramu Rapidusa "widzieć" ram VBXE. Ale to zapewne inna bajka, bo obecnej wersji tak przerobić się chyba nie da ;)

Kontakt: pin@usdk.pl

4

każde takie nowe rozszerzenie stanowi odrębną całość, nikt nie myślał aby stworzyć najpierw układ DMA a potem do niego podłączać nowe urządzenia

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

5

Tego się spodziewałem, ale tak jak napisałem na początku, chciałem się spytać, bo nie jestem na bieżąco, a przebrnąć przez kilkuletnie zasoby forum mi się nie udało. Nie wiedziałem też, jak bardzo upchany jest rdzeń, bo skądinąd wiem, że rdzeń Rapidusa zajmuje tylko ułamek zasobów.
No i TeBe nie bulwersuj się tak, bo to przecież oczywiste, że nie chodziło mi o przyjazność dla programisty, która jest rewelacyjna, bo prościej oprogramować się tego nie da, tylko o przyjazność dla CPU, aby miał mniej danych do przewalenia
generując jakąś zawartość.

6

albo zeby vbxe moglo zapisywac do pamieci od $d000 (rejestrow sprzetowych)...

albo jakies trigery na pozycje x,y plamki...

albo ...

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

7

@xxl akurat obie rzeczy da się zrobić rdzeniem rapidusa. Nad prototypem "copperlisty" zapisującej rejestry sprzętowe nawet z Pasiem pracowaliśmy, ale nic z tego nie wyszło (było to możliwe, tylko zabrakło zapału), a trigger na pozycje plamki to po prostu licznik. Tak jak mówiłem w FPGA Rapidusa jest jeszcze masę wolnego miejsca, nie ma tylko komu się tym zająć.

8 Ostatnio edytowany przez mono (2018-06-12 11:13:28)

Warto by poprawić błędy wyświetlania przy przełączaniu trybów w rastrze.

Moje pobożne życzenia wynikające z różnych potrzeb powstałych podczas eksperymentowania, a które się do tej pory uzbierały:
1. blitter
- wait do punktu x:y
- skoki - chodzi o to, żeby program mógł być rozstrzelony w różnych miejscach w pamięci
- przesunięcia z przeniesieniem i/lub dodawanie z przeniesieniem - przy współpracy z trybami Atari
- dx/dy z częścią ułamkową - obroty i skalowania nie tylko do grafiki, ale i dla np generowania sampli (ogólnie dla różnych danych)
- możliwość dokonywania AND i XOR na target przed wykonaniem operacji z mode
- tryb mappera - dana z pamięci służy jako indeks do przemapowania wartości (osobny rejestr adresowy map w blitterze) - do realizacji dowolnej funkcji przekształcającej bajt
2. xdl
- skoki - program w pamięci powinien być roztrzepany po różnych miejscach
- dx/dy z częścią ułamkową - rotacje/skalowania fragmentu ekranu
- możliwość generowania przerwania w punkcie x:y ekranu
- uruchamianie/zatrzymywanie blittera w punkcie x:y ekranu
3. memac
- dodatkowe rozmiary okna MEMACA np. 2K, 1K, 512B, 256B - przydatne kiedy blitter VBXE realizuje jakieś operacje a w pamięci RAM chcemy wystawić tylko "rejestry sprzętowe"
- konfiguracja priorytetów MEMACx/RAM/ROM/VRAM/XRAM
- tryb readonly okna MEMACx - do emulacji cartridge :]
- wrap MEMACA dokoła 64K
4. ogólne
- paleta pobierana z VRAM
- dodatkowe 7 rejestrów kolorów dla trybu 10 OS (%10 GTIA)
- obsługa całości pamięci VBXE przez PORTB w rdzeniach r
- rejestry MEMAC i blittera w rdzeniu g

Edit:

laoo/ng napisał/a:

Na pewno problematyczne jest rozszerzenie XDL, gdyż mamy tylko jeden wolny bit (2.6) którego nie powinniśmy zużywać na dokładnie ten cel, bo zamknęlibyśmy możliwość dalszego rozwoju, ale jakby użyć tego bitu na rozszerzenie komendy XDL do trzech bajtów, to wtedy wystarczyłby tylko jeden bit w trzecim bajcie na wymuszenie trybu 16-to kolorowego (i jeden na wyłączenie dla zachowania konwencji).

Bit rozszerzenia w XDL mógłby zmieniać znaczenie obydwu bajtów XDL a nie dokładać 3-ci :)

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

9 Ostatnio edytowany przez tebe (2018-06-12 11:30:27)

błędy emulacji w rdzeniu GTIA i FX były zgłaszane Electronowi, ale nic z tym nie zrobi, brak miejsca, musiałby wyjść nowy VBXE z większą pamięcią dla FPGA, czyli cała dotychczasowa linia VBXE idzie do piachu

- VBXE nie wyświetli rozszerzonych duchów na całą szerokość ekranu (błąd GTIA przy zmianie szerokości 2 -> 3) w określonym cyklu linii obrazu

- VBXE źle wyświetla duchy gdy następuje przejście w linii obrazu z piorytetu GTIA = 0 na GTIA = 1 (obrazek 'APPClown_Atari_Rocky.g2f' z przykładów G2F, katalog 'Rocky', program rastra od linii 59, obecna wersja jest już po poprawce, VBXE powinien sobie z tym radzić)

trzeba przestać narzekać, jęczeć i nauczyć się korzystać z tego co się ma

czekacie aż Electron umrze, pochowacie go i wtedy już nie będziecie tworzyć wymówek i zaczniecie robić na tym co zostało ?

czego brakuje? brakuje tytułów na wyłączność, czyli to co napędza rynek konsol, https://en.wikipedia.org/wiki/Console_exclusivity

trzeba pisać, pisać choćby najmniejsze 'pchełki' bo to zwiększa doświadczenie i powoduje że kolejne projekty 'same się piszą' kiedy zaczynacie korzystać z wcześniejszych doświadczeń, fragmentów napisanego kodu, teraz tego się nie dostrzega, nie chcecie marnować czasu i stworzyć gotowy projekt idealny i wydajny, nie da się, trzeba pisać i jeszcze raz pisać, małe pierdoły które okazują się później dużymi 'pierdołami' kiedy zaczynasz łączyć je razem

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

10

mono napisał/a:

- wait do punktu x:y

mono napisał/a:

- możliwość generowania przerwania w punkcie x:y ekranu
- uruchamianie/zatrzymywanie blittera w punkcie x:y ekranu

czli nie jedna osoba dostrzega taka potrzebe ;-)

xxl napisał/a:

albo jakies trigery na pozycje x,y plamki...

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

11

Amazing that so little software was written using the features available (despite lavish frameworks created by tebe, Drac030, etc), and yet the focus is on what's not working properly or how the device could do more. :) I would have found the ability to generate an IRQ at line x useful, but I guess we can work around these things.

12 Ostatnio edytowany przez mono (2018-06-12 13:36:21)

@flashjazzcat: We just talk. As I said - these ideas born in my head during some experiments, but they're not blocking me to use VBXE. It would be nice to have these features in the (near) future :)

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

13 Ostatnio edytowany przez lemiel (2018-06-12 15:54:09)

Ja jako laik nie rozumiem dlaczego brakuje pamięci a mogą być równocześnie cztery rdzenie załadowane i przełączane. Chyba, że to inne pamięci są.

14

w sumie to sobie sam odpowiedziałeś :)

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

15

laoo/ng napisał/a:

Konkretnie to myślę nad rozszerzeniem istniejącego trybu działania na inne tryby graficzne, które w praktyce byłoby swoistym downgradem możliwości, ale powinno dać zauważalnego kopniaka wydajnościowego.

A co za problem powiększyć przy pomocy blittera?

flashjazzcat napisał/a:

Amazing that so little software was written using the features available (despite lavish frameworks created by tebe, Drac030, etc), and yet the focus is on what's not working properly or how the device could do more.

Welcome to Poland! ;)

mono napisał/a:

- dx/dy z częścią ułamkową - obroty i skalowania

Skoro już marudzimy, to to jest rzecz, której najbardziej mi brakuje w tym sprzęcie.

https://www.youtube.com/watch?v=jofNR_WkoCE

16

Zaczynanie tego wątku było błędem, bo skoro nawet Fox nie zrozumiał intencji, a ludzie zaczynają narzekać dlaczego vbxe niem ma obrotów i skalowania, to wnioskuję, że w naszym światku nie ma jednak gruntu na merytoryczną dyskusję na ten temat.

17 Ostatnio edytowany przez mono (2018-06-12 21:48:17)

Ej, Laoo. Ale kto tu marudzi? Rozmawiamy po prostu o swoich zachciankach. Prosiłeś przecież o refleksje...

Edit: Fajnie byłoby gdyby blitter potrafił adresować rejestry sprzętowe VBXE.

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

18 Ostatnio edytowany przez cedyn (2018-06-15 13:42:24)

TEBE: czego brakuje? brakuje tytułów na wyłączność, czyli to co napędza rynek konsol

absolutnie, totalnie, w calej rozciaglosci, podpsujac sie obiema rekami i nogami sie z Toba zgadzam!

takoz zgadzam sie z opinia ze mala ilosc powstalego softu, owocuje malym dowidczeniem i brakiem iteracji w domenie jakosci. zeby bylo smiesznjej, to o czym pisal Tebe to jest historia platformy Atari. na poczatku soft wygladal jak crap, ale dzisiejsze gry na hardware sprzed 40 lat wygladaja o niebo lepiej, bo ludzie nauczyli sie wyciskac te cytrynke ;)

19

Zmiana na dwa pisksele w jednym bajcie nie zwiększy wydajności tylko zmniejszy.
Teraz jak bajt w źródłowym obrazie równy zero, to nie jest kopiowany.
Jest odczyt źródła i zapis lub nie do wyniku - jedna lub dwie operacje na pamięci.
Przy dwu pikselach w jednym bajcie trzeba będzie łączyć źródło z wynikiem.
Będzie konieczne pobranie bajtu z wyniku and/or z źródłem i zapis - razem zawsze trzy operacje na pamięci.

20

copperlista vs chunky pixels i szbki blitter.
copperlista to rozszerzone przerwania rastra - sztuczki i kruczki z wyświetlaniem tego co wcześniej zostało przygotowane.
szybli blitter - dynamiczne tworzenie obrazu.
Pomieszanie idei z różnych czasów.
W przypadku copperlisty lepiej zostać przy a500.

dx/dy z częścią ułamkową - rotacje i skalowania - to już byłoby coś w stylu 3D0 i sega saturn.
Dodanie skoków, może jeszcze operacje arytmetyczne.
Robi się karta graficzna z własnym prockiem.

Fajne!!!

Tylko czy to jeszcze atari?

@xxl,

albo... MapRam do VBXE ;)

Atarowiec... inżynier elektroniki, informatyki i automatyki. Programista i przedsiębiorca.