71

Inne konsole / Odp: SuperNintendo/SNES/SuperFamicom

« Ostatnia wiadomość wysłana przez sdm dnia Lutego 27, 2024, 15:48:14 »

Cudowna maszyna Kiedyś miałem w zestawie GameDoctor SF6 czyli copierem. Pamiętam za ile opylona była na Allegro - 299zł w zestawie z prawie nowym SNES 



Pierwszą styczność miałem gdzieś w drugiej połowie lat 90 - miałem pożyczaną od kolegi, który miał rodzinę w Niemczech - wcześniej tylko jakieś zazdrosne zerkanie na artykuły w gazetach

Masę najlepszych JRPG pokończyłem na konsoli, a nawet takie, które nie były dostępne poza Japonią bo gdy tylko pojawiły się translacje ENG to już miałem możliwość odpalania tych ROM'ów na konsoli.

Grafika i Muzyka do dziś zestarzała się świetnie!

72

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez krzysiobal dnia Lutego 23, 2024, 16:59:08 »

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.

73

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez Duobix dnia Lutego 23, 2024, 14:32:12 »

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.

74

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez Senshu dnia Lutego 23, 2024, 14:07:09 »

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ł?

75

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez krzysiobal dnia Lutego 23, 2024, 13:57:59 »

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

76

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez Senshu dnia Lutego 23, 2024, 12:36:33 »

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

77

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez Krisuroku dnia Lutego 23, 2024, 12:11:49 »

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.

78

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez krzysiobal dnia Lutego 23, 2024, 11:22:53 »

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

79

Hardware / Odp: NX Labs RGB2C02N

« Ostatnia wiadomość wysłana przez OsA dnia Lutego 23, 2024, 07:22:49 »

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

80

Hardware / Odp: Evedreive N8 Plus - chiński everdrive pro

« Ostatnia wiadomość wysłana przez OsA dnia Lutego 23, 2024, 07:15:37 »

Tak, wygląda na to że to możliwości zwykłego ED, po prostu pierwsza wersja chińskiego ED miała mniejsze możliwości.
Natomiast wersja pro chińskiego ma możliwości zwykłego ED (odpalanie muzycznych mapperów, gg, savy, większa ilość obsługiwanych mapperów). Swoją drogą nawet nie wiedziałem, że zwykły ED obsługuje game genie i save staty. Myślałem, że to możliwości Krzysiocarta z większą ilością obsługiwanych gier.


Apropo Game Genie.
Wczoraj chciałem przysiąść do gry, której nie wyobrażam sobie jak na razie przejść normalnie (Terminator 2). Chciałem więc uruchomić pierwszy  raz game genie na nieskończoną ilość żyć.... i.... zonk.
Próbowałem kilka razy, aż zacząłem szperać w  sieci i wygląda na to, że wszystko działa poprawnie, tylko trzeba to robić sposobem.
Krótko mówiąc trzeba najpierw zaznaczyć rom i kliknąć "Select Only" (nie select and start). Później wklepać kod game genie, a potem uruchomić grę przyciskiem start.


Wyjaśnia to ten gościu:

I prawdopodobnie mówi on o zwykłym ED, więc czy na zwykłym oryginalnym everdrive (nie pro) również trzeba to robić tą kombinacją? Czy może w kolejnych odsłonach softu zostało to skorygowane?