[Senshu]

RGB2CON to zamiennik PPU dla Famicoma stworzony przez NX Labs, Japońskich fanów naszej ukochanej konsoli.

Urządzenie dodaje konsoli nowe możliwości:

• Wyjście wideo 15kHz (RGB+CSync), czyli sygnał przystosowany do telewizorów akceptujących RGB przez Scart - większość europejskich modeli.
  
• Wyjście wideo 31kHz (RGB+H/VSync), czyli "VGA", sygnał dla monitorów.
• Tryb SPEX (sprite enhancement function), który pozwala na wyświetlenie na ekranie do 15 sprite'ów w jednej linii obrazu (oryginalny PPU pozwala maksymalnie na 8 ). Największym plusem tego rozwiązania jest eliminacja migotania sprite'ów, mocno widocznego np. w Salamanderze.
• Możliwość wgrania własnej palety kolorów. Paletę wgrywamy na zewnętrzny EEPROM.

• Ceną za wyżej wymienione jest utrata wyjścia Composite Video.

Na ten moment RGB2CON można zainstalować w Famicom AV i Twin Famicom, ale dedykowany adapter do klasycznego Famicoma jest ponoć w drodze.

https://bakutendo.net/blog-entry-463.html

[Krisuroku]

Mega ciekawe rozwiązanie, które bardzo mnie korci. Byłbym skłonny pewnie w coś takiego się wyposażyć ale tylko wtedy, jeżeli posiadałbym dodatkowy egzemplarz HVC-101. W głowie zawsze pozostaje to uczucie, że podczas przeróbki coś może pójść nie tak a lipa potem zostać bez konsolki

Edit: Tylko, jeżeli zrozumiałem to cena takiej zabawki to jakieś 17 980JPY , czyli prawie 500PLN, co za tym idzie, cena w zasadzie konsoli.
Do tego gdy dojdą koszta wysyłki, to zrobi się duuuużooo.
Jeżeli kupować to chyba w kilka osób by chociaż przesyłka się jakoś rozbiła.

[Duobix]

Super sprawa, szczególnie SPEX. Ciekawi mnie w sumie jak to jest ogarnięte, gdyż normalnie to program musi się przejmować losowaniem/wybieraniem które sprajty mają się pojawiać w jednej linii -> więc ciekawi mnie, co tu jest zrobione że to działa.

[yojc]

Zastanawiałem się nad tym niedawno, i doszedłem do wniosku (nie mając żadnego doświadczenia z pisaniem gier na NES) że gry nie ukrywają spritów, tylko po prostu "żonglują" ich kolejnością. Jeśli tak jest, to proste zwiększenie limitu naprawi flicker bez ingerencji w kod gry. Można to przetestować w emulatorach, gdzie podobne rozwiązanie już jest.

[Mcin]

z nesdev:

In addition to the primary OAM memory, the PPU contains 32 bytes (enough for 8 sprites) of secondary OAM memory that is not directly accessible by the program. During each visible scanline this secondary OAM is first cleared, and then a linear search of the entire primary OAM is carried out to find sprites that are within y range for the next scanline (the sprite evaluation phase). The OAM data for each sprite found to be within range is copied into the secondary OAM, which is then used to initialize eight internal sprite output units.


The reason sprites at lower addresses in OAM overlap sprites at higher addresses is that sprites at lower addresses also get assigned a lower address in the secondary OAM, and hence get assigned a lower-numbered sprite output unit during the loading phase. Output from lower-numbered sprite output units is wired inside the PPU to take priority over output from higher-numbered sprite output units.

https://www.nesdev.org/wiki/PPU_OAM

W skrócie:
mamy 64 sprajty.
każdy sprajt ma swój indeks, liczbę porządkową mówiąc po polsku.
Podczas każdej klatki obrazu sprajt ma swoje położenie.
obraz jest rysowany linia po linii.
Na początku każdej linii układ graficzny skanuje sprajty po indeksie rosnąco, czy znajdą się w danej linii i umieszcza je w specjalnym obszarze pamięci. Jeden po drugim.
Ten obszar pamięci ma 32 bajty. sprajt zajmuje 4 bajt. Logicznym jest, że mieści się osiem. A co z pozostałymi? czekają na swoje szczęście w kolejnej linii.
i tak, yoyc, masz racje, programiści żonglowali indeksami tych sprajtów, żeby raz jeden miał mały indeks, raz inny.

Także o ile nie ma jakiejś innej blokady np na przepustowości kartridża czy w innym miejscu które mi nie przychodzi do głowy, mogliby dać miejsce na 64 sprajty. 256 bajtów ramu to chyba nie zrobi różnicy w nowoczesnym układzie FPGA.

Jak coś uprościłem za bardzo albo pomyliłem - bijcie mnie.

Co do oceny samego urządzenia, to ja mam mieszane uczucia. niby fajne, że mamy zastępstwo dla umierających układów, ale przy każdym takim podbijaniu parametrów to pojawia się u mnie pytanie czy to jest jeszcze granie na NESie? No, z racji ceny na pewno na razie nie kupię.
Brak composite to nie problem, RGB możeby przechwycić i skonwertować do kompozytu, w drugą stronę jest gorzej.

[OsA]

Pytanie zasadnicze: Czy ktokolwiek bądź Ty Senshu zakupiłeś to ustrojstwo?
Czy na razie to tylko znaleziony nowy bajer dla konsolki.


Dla mnie to bardziej ciekawostka.
Oczywiście fajnie by to było przetestować i zobaczyć, ale jakoś nie zależało by mi aby to koniecznie mieć.


Migotające sprite'y to urok naszej konsolki

[krzysiobal]

Ale czemu robić coś takiego w postaci jakiegoś "rozszereznia" wpinanego do konsoli i męczyć użytkownika koniecznośćią wylutu oryginalnego procesora PPU (którego wcale tak łatwo bez rozlutownicy, a nawet i z nią) usunąć sie nie da.
Powinni zrobić dedykowaną płytę główną do konsoli famicom z tym układem, aby tylko podmienić ją.
Reszta elementów (pamięći RAM, CPU, układy 74, gniazdo kartridży) to są grosze. Najdroższy może być CPU NTSC (ok 15$) , ale można wykorzystać CPU od pegasusa (Dendy) i tylko dodac mu więcej cykli zegara, aby dzielnik pozostał ten sam. Ten kosztuje ok 2$.

[Krisuroku]

Przyznam krzysiobal, że Twoje rozwiązanie jest zdecydowanie bardziej do przyjęcia. Gdyż oryginalną płytę główną, można sobie schować/ zabezpieczyć przed uszkodzeniem i bawić się na tej nowej. Potem można w każdej chwili wrócić do oryginału.

[Senshu]

@OsA, niestety dowiedziałem się o tym za późno i już nie było na stanie. Postaram się to dorwać do czasu zlotu jeśli fundusze pozwolą.

@krzysiobal, uważam podobnie, ale rozumiem też twórcę. Widocznie jemu zależało wyłącznie na PPU i w tym widział wartość i swój cel. Jeśli byś kiedyś zaprojektował dedykowana płytę główną, to ja chętnie kupię i prawdopodobnie bardzo duża część społeczności międzynarodowej z naszego środowiska. Myślę, że jest to spokojnie w Twoim zasięgu patrząc na Twoje dotychczasowe projekty.

[krzysiobal]

Także o ile nie ma jakiejś innej blokady np na przepustowości kartridża czy w innym miejscu które mi nie przychodzi do głowy, mogliby dać miejsce na 64 sprajty. 256 bajtów ramu to chyba nie zrobi różnicy w nowoczesnym układzie FPGA.

Procesor PPU nie ma żadnej wewnętrznej pamięci (nie licząc tych 256 bajtów pamięci OAM).
Podczas generowania linii obrazu, musi on na bieżąco sprawdzać, jakie kafelki tła oraz jakie kafelki sprite-ów na tej linii obrazu nalezy "wyświetlić"


 W tym celu sięga on do nametables (zwykle pamięc RAM w konsoli) aby odczytać, jakie kafelki tła (=jakie numery) maja się znaleźć.
Potem sięga do Pattern Tables (zwykle pamięć ROM/RAM w kartridżu) aby pobrać dane graficzne tych kafelków.
Schemat działania PPU jest zawsze taki sam, tzn. w kazdym cyklu ma dokładnie zaplanowane, jaką komórkę pamięci ma odczytać aby te informacje pobrać.
https://www.nesdev.org/wiki/PPU_rendering

W cyklach `257-320` dokonuję odczytów z pamięci pattern tables, aby pobrac dane graficzne 8 sprite-ów które ma wyświetlić.
Gdybyśmy nagle chcieli wyświetlać więcej spriteów niż 8, to nie ma gdzie upchnąc tych dodatkowych cykli odczytu, które PPU musiałby wykonać aby pobrać dane o dodatkowych spriteach.
Wszystkie konsole od oryginalnych Nesów/Famicomów, po późniejsze klony na pojedynczym scalaku (UM6561=iq502 rev 2), glucie (terminator, sp60) czy współcezsne klony zachowują się IDENTYCZNIE jak pierwowzór (NES/FAmicom). Dlaczego?

Niektóre mappery (tylko MMC5) dokładnie śledzą cykl po cyklu co robi PPU aby m.in. wykrywać kolejne linie obrazu (potrzebne do zgłaszania przerwań).
Inne mappery śledzą np. tylko ile razy w "zmienia" się stan linii PPU A12 (8 razy) lub PPU A13 (43 razy o ile dobrze pamiętam) aby zliczać linie obrazu. Jeśli dodamy "dodatkowe" cykle odczytu aby sięgać po dodatkowe spritey, wszystkie dotychczasowe zależności obrazu sie rozjadą.

W wielu emulatorach jest opcja `allow more than 8 sprites per scanline`, bo emulator ma wszystkie te dane graficzne w pamięci i mu nie robi różnicy, czy wyświetla tylko 8 czy więcej spriteów (=nie musi fizycznie sięgać do pamięci po te dane tak jak PPU).

Nie wiem jak działa opisywany w tym temacie projekt (nie czytałem szczegółów), ale ten układ FPGA Lattice który jest jego sercem mui trzyać gdzieś wewnątrz kopie pattern tablesów, aby do nich nie sięgać z kartridża, albo musi robić jakieś czary.

Ja to bym w ogóle nie ruszał konsoli, preferowałbym stworzyć rozwiązanie w postaci kartridża-adaptera z którego wystawałby tylko przewód (albo gniazdo) video.

Kiedyś się za coś takiego zabierałem, jakiś prototyp nawet stworzyłem, ale kłopot był z synchronizacją drugiego PPU (=tego w adapterze) z tym w konsoli. Gdybym miał do dyspozycji jakieś pętle zegarowe może by się udało.
https://forums.nesdev.org/viewtopic.php?t=19033

[Senshu]

Ja to bym w ogóle nie ruszał konsoli, preferowałbym stworzyć rozwiązanie w postaci kartridża-adaptera z którego wystawałby tylko przewód (albo gniazdo) video.

Kiedyś się za coś takiego zabierałem, jakiś prototyp nawet stworzyłem, ale kłopot był z synchronizacją drugiego PPU (=tego w adapterze) z tym w konsoli. Gdybym miał do dyspozycji jakieś pętle zegarowe może by się udało.
https://forums.nesdev.org/viewtopic.php?t=19033

Świetny pomysł i Krikkz wypuścił już coś takiego.. nieco później niż Twój temat z nesdev, może się zainspirował?

[Duobix]

Nie wiem jak działa opisywany w tym temacie projekt (nie czytałem szczegółów), ale ten układ FPGA Lattice który jest jego sercem mui trzyać gdzieś wewnątrz kopie pattern tablesów, aby do nich nie sięgać z kartridża, albo musi robić jakieś czary.

No właśnie ciekawi mnie to niezmiernie, jakbym miał kombinować pod górę to bym robił laga na 3 klatki (żeby zebrać dane), i podpatrywał które sprite'y się powtarzają między nimi, i na tej podstawie łatał output w jakimś buforze klatki.

[krzysiobal]

No właśnie ciekawi mnie to niezmiernie, jakbym miał kombinować pod górę to bym robił laga na 3 klatki (żeby zebrać dane), i podpatrywał które sprite'y się powtarzają między nimi, i na tej podstawie łatał output w jakimś buforze klatki.

Może po prostu FPGA trzyma wewnątrz kopię 256 sprite-ów (256 * 16bajtów).
W momencie, gdy PPU sięga do pamięci aby pobrać dane sprita z kartridża, FPGA uaktualnia odczytaną wartością zawartość kopii swojej pamięci. Gdy układ będzie chciał wyświetlić więcej niż 8 spriteów w linii, dane tych `nadmiarowych` zostaną pobrane z wewnętrznej kopii.
Jeśli gra żongluje tymi samymi spiteami ("miganie"), powinno działać to dobrze (pierwsze kilka klatek po każdej zmianie banku spriteów będzie zawierać złe dane tych nadmiarrowych spriteów).
Dla gier które nie zmieniają ciągle banków spriteów podczas takiego migania, będzie w miare `znośnie` działać.

A jak gra ciągle zmienia  (np. Av Girl Fighting - postacie  w każdej pozie walki mają odmienny bank spriteów)  to nie bedize dobrze.