Ja mam odwrotne doświadczenie. Po kupnie FPGA jeszcze bardziej polubiłem prawdziwy hardware i moje zainteresowanie emulowaniem i/lub przyspieszaniem Amigi w tej sposób zmalało niemal do zera. Więcej przyjemności daje mi podkręcona 68000 w prawdziwej i leciwej A500 niż szybkie FPGA w czymś, co nie tylko nie różni się za wiele od Raspberry Pi, ale i często jest od niego gorsze (nie wspominając o cenie). Dla mnie użytkowanie urządzenia na FPGA może nazywać się jakkolwiek, co nie zmieni faktu, że jest to po prostu „WinUAE” na innej platformie.

Z drugiej strony, posiadanie zbyt wiele sprzętu, którego człowiek nie może lub nie jest w stanie używać, może powodować stan przygnębienia i uczucia bezsensowności tego wszystkiego (czywiście są wyjątki, więc nie generalizuję). Dlatego warto zastanowić się poważnie i zadać sobie pytanie, po co zbieram i nakreślić sobie konkretne granice. Zjawisko zbieractwa znane jest również w innych dziedzinach i jest określane jako przyczyna wspomnianych uczuć (nie należy mylić kolekcjonowania ze zbieractwem, bo to nie to samo. Łatwo przy tym wpaść w pułapkę tłumacząc sobie, że mnie to nie dotyczy). Oczywiście nie sugeruję, że u Ciebie jest taki problem, ale warto się nad tym zastanowić. Piszę o tym dlatego, bo sam miałem podobne tendencje i po przemyśleniu doszedłem do wniosku, że to, czego potrzebuję, to tylko tyle Amig w różnej konfiguracji, iloma jestem w stanie się bawić. Sprzęt używany daje satysfakcję, a jeśli nie, to dla własnego dobra lepiej go ograniczyć lub zupełnie się go pozbyć. Tylko nigdy nie robić tego pod wpływem emocji, bo to zły doradca

Mój pomysł na granice jest taki: bawię się w obrębie zasobów, które zgromadziłem kiedyś, tanio lub pół-darmo, albo wręcz ze śmietnika. Dbam i konserwuję ale nie gromadzę nowych. Swoistą satysfakcję w tej sytuacji daje mi śledzenie cen na Allegro i na giełdzie.

Jednakowoż, gdybym nie posiadał dawnych zasobów, to wracając do tematu po latach zdecydowanie ograniczyłbym się do jednej, fizycznej Amigi.

Ale FPGA można używać nie tylko do "reimplementacji" całego chipsetu, czy to w formie MiSTera, czy V4SA ... równie dobrze można zrobić Super Bustera, CIA czy Super Fat Agnusa (których to na rynku już brakuje), jeszcze tego ostatniego opakować z Chip RAM tak by pasował nawet do Rev5 i git majonez. Czy ECS Denise z wyjściem HDMI (patrz side-project na Tang Nano 9k obok PiStorm) to zły pomysł? FPGA ma swoje wykorzystanie w przypadku oryginalnego sprzętu też i to bez wywracania świata do góry nogami.

Moje pytanie brzmi, czy kogos spotkało podobne doswiadczenie, ze po kupnie jakiegos fpga, zatracil zainteresowanie w używaniu real hardware?

Jeśli chodzi o używanie starych platform to tak, ale to czy przestaje to mieć to sens czy nie i jak bardzo zależy od konkretnego przypadku. Głównie rozbija się to o wyjście Composite i to jak oryginalnie jest zrealizowane. Przykładowo Famicom/NES najlepiej grać na Composite w NTSC. C64 można powiedzieć też. Większość platform, a szczególnie Amiga nie ma takich wymagań więc MISTer od strzała działa idealnie. Oczywiście są opcje aby mieć Composite z MISTera (choć dalej Twin Famicoma z Everdrive N8 Pro to nie da się przebić )

Odnośnie wygaszenia rządz posiadania sprzętu to jednak nie pomógł MISTer nic a nic
Wręcz przeciwnie bo pograłem trochę to kupiłem PC Engine (taka konsola, nie mylić przypadkiem z pecetami!) i planuję kupno kilku komputerów 8-bit w tym C64 (aż dziw bierze że nigdy nie miałem) z stereo modem (takim mono stereo)

BTW. Jeszcze ważna jest kwestia wygody używania. Na MISTerze używam jednego pada od PS5 + bezprzewodowy zestaw logitecha kb+mouse. Real sprzęt trzeba przynieść, porozplątywać kabelki, podłączyć do monitora i wzmacniacza, podłączyć akcesoria... kto ma na to czas

Oczywiście, i w takiej formie sam też używam FPGA (wyjście HDMI, RTG na Warpie, itp.). Bardziej miałem na myśli zastępowanie Amigi w całości w takiej formie (chociaż Vampire FPGA jako dodatek do mnie kompletnie nie trafia, zwłaszcza po dosyć długim użytkowaniu).

Tak czy owak, to nie była krytyka z mojej strony, a jedynie przedstawienie mojego podejścia. Ja szanuję wybór „tylko FPGA” czy „tylko emulacja programowa”. Każdy bawi się jak lubi. Doskonale rozumiem, że sprzęt jest już bardzo stary i ciężko o niektóre układy. Sam potrzebuję Agnusa 8375 i gdybym mógł go dostać w FPGA w senownej senie, to pewnie długo bym się nie zastanawiał. Ale jeśli chodzi o Amigę, to dla mnie jest to tylko fizyczne 68k w klasycznym modelu.

Konkurencją dla Amigi 3000 było Atari TT, a Atari TT miało 256 kolorów.

Amiga 3000 posiada układ o nazwie copper, który z kolorami wyczynia
na Amidze cuda.

TT ma w palecie 4096 tak samo jak A3000, ale w Loresie ma aż 8 bitów na piksel stąd te 256 kolorów, z niezależnym kolorem w każdym pikselu, a tego A3000 nie ma w żadnej rozdzielczości. Bo z pełną swoboda to ma maks 5 bitów na piksel, z pewną zależnością doboru palety ma w EHB a z jeszcze mniejszą niezależnością ma w HAM ale tu bywa że potrzebuje nawet do 3ech sąsiednich pikseli pośrednich zanim uzyska oczekiwany kolor. A to nie to samo co dowolne wybieranie koloru w każdym pikselu i dowolne wybranie aż 256 kolorów w palecie. A w tym punkcie dopiero AGA dogoniła TTkę, choć jednocześnie ustępuje Falconowi który ma 16bitów na piksel a AGA tylko 8.

Tak więc te cuda nie polegają na tym że coś magicznie wisi w powietrzu, tylko na tym że wisi na sznurku. ;)

Jakie tytuły korzystały z 200 kolorów na tt? Tymczasem Amiga:

Lionheart
184 colours going on here: Two seperate copper fades, later you get some water reflection like in Fire & Ice. In areas with no copper bars/ reflection....it's in plain old 32 colours mode.

Trex Warrior
Getting complicated now. 87 colours on screen in this one, more elsewhere. It actually has three seperate copper fades going on, adding to the colour count: One for the sky, another for the sea, and another for the sun. A seperate screen with its own palette for the HUD and I'm betting the 3D is actually 16 colours (due to the lack of chunky, as we all know).

To o czym piszesz to nie jest FPGA, tylko mikroprocesor (jakaś odmiana ARMa) realizujący jakiś algorytm. Zasada działania FPGA jest zupełnie inna i zdecydowanie bardziej (niż emulacja z użyciem CPU) odpowiada działaniu prawdziwego układu w krzemie (ASIC).
FPGA to są rozmaite Xilnksy XC, Altery, itp. Można w nich zaimplementować cały CPU, albo ASIC (np. Agnus, Denise...) od poziomu bramek, czy bloków logicznych.
WinUAE zaś to program komputerowy wykonywany w jakimś systemie mikroprocesorowym, jako taki z FPGA nie ma nic wspólnego.
Istnieją układy które mają część FPGA (lub CPLD) i kilka rdzeni CPU. Przykładem takich układów jest seria Xilinx ZINQ. Jednak część FPGA jest programowana niezależnie od CPU, stanowią odrębne części układu.
I tak wszelkie Vampiry to maszyna oparta o FPGA (Altera Cyclone) i z WinUAE ma tyle wspólnego co prawdziwa Amiga.
Dla odmiany A500Mini to emulator oparty o UAE działające na jakimś ARMie. Zupełnie inna bajka. Emulator.

Ostatnia aktualizacja: 14.08.2022 12:08:02 przez wali7

Zasada działania FPGA jest zupełnie inna i zdecydowanie bardziej (niż emulacja z użyciem CPU) odpowiada działaniu prawdziwego układu w krzemie (ASIC

skąd takie przypuszczenia? Rozpatrzmy to wedle 2 czynników - masz układ, który jest czarnym pudełkiem. Wrzucasz do niego jakiś program i otrzymujesz jakąś funkcjonalność. I teraz możesz:
a) napisać program na zupełnie inny sprzęt, który załaduje program z badanego układu i zrealizuje tą samą funkcjonalność - emulacja programowa. Nie wiesz jak coś dokładnie jest zbudowane, ale znasz realizowaną funkcjonalność. Emulujesz zachowanie tej maszyny na innej maszynie realizując funkcjonalność w postaci programu komputerowego
b) zaimplementować określoną znaną (mniej więcej) funkcjonalność w postaci logiki programowalnej. Układ realizuje (mniej więcej) tą samą funkcjonalność bez konieczności uruchamiania programu komputerowego na innej maszynie. Niestety wewnątrz jest to zrealizowane na zupełnie innych blokach, a wynikowy układ połączeń może się zmieniać w zależności nawet od tego jakie opcje podczas syntezy logiki się włączy. Oczywiście same bazowe komórki nowych FPGA gdzie konfiguracja odzwierciedla działanie pamięci SRAM (konfiguracja istnieje po władowaniu tak długo jak jest zasilanie, potem się "resetuje") wcale nie muszą (i nie są) zbudowane jak 30 letnie ASIC od Commodore. Ergo - zamiast zastąpić sprzętu innym sprzętem realizującym daną funkcjonalność programowo zastępujesz sprzęt innym sprzętem realizującym funkcjonalność sprzętowo. To nadal JEST emulacja.

Wszystko zależy od tego co rozumiesz pod terminem "emulacja".
Układ ASIC jest dokładnie takim samym czarnym pudełkiem, tym bardziej, że dokładna dokumentacja układów C= nie jest opublikowana, równie dobrze Commodore mógł kolejne wersje swoich układów realizować w zupełnie inny sposób dbając jedynie o to, aby "czarne pudełko" zachowywało się na zewnątrz tak samo jak poprzednie "czarne pudełka".
Bloki w układzie FPGA działają równolegle, dokładnie tak samo jak w układach ASIC. Co więcej, zrealizowany w FPGA układ można przenieść wprost do ASIC z zachowaniem funkcjonalności. Nawet jeśli implementacja w Verilogu zostanie zoptymalizowana, to nadal taki układ działa w podobny sposób jak ASIC. Stað nie mozna tego nazwać "emulacją".
Emulacja programowa wykonywana jest sekwencyjnie, według zupełnie innych zasad niż FPGA. Algorytm krok po kroku tłumaczy instrukcje CPU, obsługuje wirtualne rejestry chipsetu i generuje efekty ich działania. Sekwencyjnie, w absolutnym oderwaniu od sprzętu.

No i są realizowane w inny sposób, ale z tych samych klocków. Poszczególne rewizje różnią się nieco funkcjonalnością (poprawki błędów jak super buster czy też większa ilość obsługiwanej pamięci chip jak wersje agnusa).

Stað nie mozna tego nazwać "emulacją"

Skąd? Dlatego że działa równolegle i w sprzęcie? Ależ w FPGA też są sprzętowe emulatory. I nikt ich nie nazywa inaczej niż ICE tylko dlatego, że metoda ich działania "aż tak bardzo" nie różni się od implementacji na sztywno w krzemie. Więc samo wsadzenie logiki do FPGA wcale nie oznacza, że nie można mówić o emulacji

link

Powiem ci dokładnie o co chodzi. Od dłuższego czasu możliwości jakie dają narzędzia FPGA wykraczają poza proste prototypowanie czy tylko syntezę logiki. Można analizować to co wypluwa soft i badać na układzie jak to działa. Samo to już jest zbliżone do tego co 20-30 lat temu robiły dedykowane emulatory sprzętowe za gruuuuuuby hajs. I teraz wiele osób reaguje na wyrażenie "emulacja" jak byk na czerwoną płachtę. A prawda jest taka, że jak architektura RISC i CISC przestaje mieć większe różnice w budowie (z wyjątkiem rozrośnięcia samych dekoderów i zastosowanego ISA - a dawniej różnice były potężne i jaskrawe) tak wiele innych terminów zaczęło się przenikać, a to co było jasne i wyraziste zaczęło się rozmywać. To co jest jednak pewne to że ten sprzęt ma działać jak zupełnie inny sprzęt, innego producenta i w oparciu o inne układy.

Profesjonalne, Amiga3000 i Atari TT nie były kupowane do gier. Porownaj oprogramowanie użytkowe.

Pecety również nie były kupowane do gier a wiemy, jak to się potoczyło.

In areas with no copper bars/ reflection....it's in plain old 32 colours mode.

To nie są niezależne kolory z palety, tylko kombinowanie copperem.
Nie możesz użyć tych wszystkich kolorów w dowolnym miejscu na ekranie.

Lata temu był program graficzny na Atari ST który pozwalał używać 512 kolorów na ekranie, no i co? No i nic, bo też był kombinowany :D

http://atariki.krap.pl/index.php/Spectrum_512

OK. Jednak w przypadku FPGA stosowałbym termin implementacja, w przypadku realizacji algorytmu przez CPU stosowałbym termin emulacja.
To, że kod w C, czy asemblerze realizuje algorytm, a Verilog to także algorytm, nie oznacza że oba robią to samo i tak samo. Różnice są ogromne. Zresztą układy ASIC także realizują jakiś algorytm.
Zresztą mi chodziło nie o sprzeczanie się nad stosowalnością terminów emulacja i implementacja, co zwrócenie uwagi, że np. zrealizowany w FPGA Wampir zasadniczo z WinUAE nie ma nic wspólnego (co do zasady działania), zaś A500Mini to czysty programowy emulator (tyle że odpalony na dedykowanym sprzęcie), jakaś odmiana UAE. A jeszcze z innej beczki taki Pistorm to także emulacja programowa, tyle że RPi wetkniętym w podstawkę 68000. Całe spektrum rozwiązań.

To czy coś jest emulatorem czy nie to dobra rozkmina dla filozofów.
Dla użytkownika końcowego liczy się kilka rzeczy
1. kompatybilność programowa z oryginalnym systemem
- czy programy wykonują się tak samo
- czy piksele są rysowane w taki sam sposób
- czy dźwięk brzmi autentycznie
2. kompatybilność sprzętowa z oryginalnym systemem
- jakie porty udostępnia
- jakie ekrany można podłączyć i czy obraz wygląda tak samo
- jakie urządzenia wejścia HID można podłączyć
3. czas reakcji emulowanego systemu na interakcję użytkownika

re. 1
Emulatory ze względu na moc obliczeniową zazwyczaj mają problemy kompatybilności wynikające z tego że obraz nie jest składany piksel po pikselu wykonując za każdym razem wszystkie operacje jakie robi emulowany system. Dla innych układów które mają zegar też wszystko powinno być wykonywane cykl za cyklem. Zamiast tego robione są pewne uproszczenia np. jeśli mamy system który ma sprajty i spodziewamy się że może ktoś zmienić coś podczas hblank to można w pewnym momencie np. pod koniec hblank-u wziąć stan rejestrów i na tej podstawie narysować linię. Większość gier będzie działała dobrze z taką optymalizacją a emulator będzie działał na słabszym systemie. Może się jednak okazać że jakaś gra zmienia coś podczas rysowania linii i to nie będzie odzwierciedlone.

Tego typu problemy są w emulatorach. Emulowanie wszystkiego w np. SNESie z rozdzielczością co piksel daje emulator który może się okazać potrzebuje procesora ponad 3GHz. I nie Pentium 4 a jakiegoś Core. Można natomiast zoptymalizować emulator aby wykrywać pewne rzeczy lepiej i nie próbować robić wszystkiego na brute-force. Tutaj może to zadziałać ale może się okazać że jakiegoś typu kombinowania programisty nie wykryje.

FPGA z drugiej strony zawsze wszystko robi cykl co cykl. Nawet jak jest kilka układów z różnymi zegarami to każdy jest odtwarzany co cykl. Zmienia to też sposób pisania kodu i effort zamiast iść na 'jak to sprytnie zoptymalizować' na 'jak to w ogóle mogło być zaimplementowane'. Gdy w MISTerze ktoś wykryje że w jakiejś grze piksel się nie zgadza w jakiejś grze (tak, nawet jedne piksel ) to siada developer i np. przestawia kolejność operacji aby ogólnie wynik był taki sam ale w przypadku jakiegoś race condition wynik był taki że ten piksel zgadza się z prawdziwym sprzętem.

Projektując układ fizycznie czasami zachodzi potrzeba dodania czegoś do układu albo poprawienia błędu i tutaj nie było tak że sobie inżynier dopisuje linijkę kodu a program mu zsyntezuje z tego układ w pół godziny. Jakiekolwiek zmiany wymagające poprzestawiania bloczków w układzie to miesiące żmudnej pracy. To jest później widoczne w grach. I jeśli nawet ten piksel co się nie zgadzał jest poprawiany tak aby właśnie efekt końcowy wyglądał na artefakt (tj. wcześniej gra wyglądała dobrze i się próbuje ją 'zepsuć') to się dodaje ten artefakt. To żmudny proces ale tam ludzie siedzą i dodają takie zmiany. W emulatorach zresztą też tylko jeśli chodzi o emulatory to pewne rzeczy są praktycznie niemożliwe do odtworzenia właśnie ze względu że nikt nie emuluje wszystkiego co cykle zegara a raczej używa optymalizacji aby emulator mógł być uruchomiony na typowym komputerze. Dzisiaj są to szybsze komputery niż np. 20-25 lat temu a same emulatory miały więcej czasu na dopracowanie więc i jakość emulacji jest lepsza. FPGA za to ogólnie cieszy się lepszą opinią jeśli chodzi o dokładność w przypadku tego typu dziwnego zachowania się gier wynikającego z działania oryginalnych układów.

re. 2
Emulator emuluje wszystko i nie ma portów. FPGA często są wynikiem prac nad konsolami FPGA gdzie używa się oryginalnych urządzeń we/wy czy źródła programów. Do tego stopnia że specjalne flash carty które używają najdziwniejszych workaroundów (np. zapis stanu gry) działają. Nie wszystkie wsady dla MISTera miały taką genezę ale technologia na to pozwala. Sam sposób pisania wsadów pozwala na to aby się zwyczajnie "wpiąć" w jakieś sygnały i wyprowadzić je na port I/O. MISTer ma opcje podłączenia oryginalnych padów/joyów i innych akcesoriów.

Odnośnie obrazu to domyślnym zazwyczaj wyjściem dla którego programuje się wsady to wyjście RGBS tj. jak mamy np. Amigę to zakładamy ze będzie podłączona do monitora/telewizora 15KHz i wyjście ma zachowywać się dokładnie tak samo jak te z prawdziwej Amigi. I tak właśnie jest. Cykl zegara za cyklem zegara wszystko co robiłby oryginalny układ na wyjściu video jest tak samo tutaj odtwarzane. Wszystkie dziwne tryby video działają tak samo.

Emulator natomiast musi złożyć użyteczny obraz tj. bitmapę z tego co robi emulowany system. Potem to sobie można wyświetlić tam gdzie się chce np. nawet monitor 15KHz. Ale jak ustawię sobie tryb 288 linii w 50Hz to to jest coś z czym emulator musi pracować.

re. 3
Emulator zazwyczaj tworzy bitmapy klatka po klatce i tak wysyła do systemu (np. Windows, Android, itp). Podobnie składa dźwięk w bloczki i później całe bloczki wysyła do systemu. To wynika z ograniczeń systemów które oczekują klatek i bloczków dźwięku ale i z tego że programy muszą walczyć o czas procesora a mając więcej czasu na przygotowanie outputu jest duża szansa że się wyrobią ze wszystkim. Z tego też powodu że tam jest walka o czas i potrzebne jest więcej czasu na wszystko to domyślnie emulatory wręcz buforują więcej niż jedną klatkę obrazu. To prowadzi natomiast do opóźnień w wyświetlaniu. Naciśniesz przycisk skakani a Mario odczeka cierpliwie 2-3 klatki (po 16.6ms każda) na zaczęcie animacji skoku. Podobnie dźwięk będzie trochę opóźniony.

FPGA robi wszystko w real-time. Program który czyta stan np. paletki (takiej jak z Atari 2600) i rysuje kropkę (np. ustawia sprite w tej pozycji) oddaloną od lewej krawędzi o tyle pikseli ile jest wychylenia paletki jak zaczniesz nagrywać kamerą z bardzo dużą ilością klatek na sekundę i zmieniać losowo ustawienie na potencjometrze wykaże że na FPGA masz dokładnie takie same opóźnienie jak na prawdziwym Atari 2600. Oczywiście podłączasz ten sam kontroler i tu i tu. Na emulatorze nawet jak podłączysz jakoś tą paletkę i uruchomisz taki test to będzie opóźnienie nie na zasadzie że w następnej linii jest sprajt już odświeżony tylko będą pionowe linie (tak wysokie jak częstotliwość odczytu stanu potencjometra - lub całkowicie pionowe jeśli emulator w sam czyta stan tylko raz na klatkę) które reagują z opóźnieniem liczonym w klatkach.

Oczywiście emulator mógłby być tak napisany aby próbował liczyć wszystko na bierząco. Nie jest jednak możliwe uzyskanie efektu jak na FPGA tj. całkowicie bez opóźnień. Samo z siebie w ogóle próba zrobienia czegoś takiego byłaby programistycznym koszmarem który skończyłby się szaleństwem programisty Systemy operacyjne zwyczajnie nie zakładają że ktoś będzie składał obraz linia po linii w czasie rzeczywistym. Tam są zawsze bufory i składa się obraz w buforach a potem daje systemowi całą klatkę.

Ale ot nie jest nawet aż taki problem. Dobrze napisany emulator na porządnym sprzęcie z szybki monitorem np. HDMI 2.1 ma na tyle zapasu i możliwości dostosowania prędkości wyświetlania że w grach opóźnienie będzie minimalne, poniżej jednej klatki. Problem jest tylko taki że tego typu aspekty nie są priorytetem. Tj. developer emulatora skupia się na poprawności emulacji a nie aspektach wyświetlania. Trochę lepiej jest dzisiaj bo są całe duże projekty które mają specjalne API dla emulatorów a rysowaniem zajmują się same. Tutaj gwarancji małych opóźnień nie ma a już szczególnie na każdym systemie (komputerowym powiedzmy) ale jest trochę lepiej i możliwości są aby na tyle ustawić emulatory aby przynajmniej te opóźnienia nie było za bardzo widoczne.

W FPGA za to jakakolwiek próba dodania opóźnień jest koszmarem programistycznym bo trzeba by specjalnie dodawać obsługę pamięci aby tam wrzucić bufor pamięci aby tam buforować klatki. Prościej jest cykl do cyklu w czasie rzeczywistym robić to co prawdziwy sprzęt by robił i tak też dzięki temu nie ma żadnych opóźnień.

Odnośnie dźwięku to w FPGA dźwięk jest składany jako stan wychylenia membrany cykl do cyklu i tak też trafia do prostego 1-bit DACa ΔΣ

BTW.
W FPGA takie zero zero opóźnień na 100% działa mając analog I/O board.
Używając HDMI sprawa się komplikuje o tyle że dochodzi problem buforowania audio. Tj. będzie lekkie opoźnienie w dźwięku. Zdaje się HDMI audio wysyła bufory dźwięku co klatkę obrazu. Oczywiście urządzenia wejściowe mogą mieć dalsze bufory.
Jeśli chodzi o video to można nie skalować obrazu i wtedy jest 1:1 to samo co z wyjścia VGA/RGB. Jak używa się skalera to są 3 tryby działania
1. buforowanie całych klatek - coś jak to jak działają skandoublery Indivision - to jest tryb kompatybilności. Ustawiasz tryb video np. telewizyjne 1080p i działa na każdy, telewizorze
2. buforowanie całych klatek ze zmianą zegara HDMI aby dopasować prędkość klatek - tutaj klatki dalej są buforowane ale przetaktowany jest zegar HDMI aby uzyskać płynny obraz. Kompatybilność jest gorsza niż trybu 1-szego bo tutaj już wyświetlacz musi obsługiwać tak przetaktowany sygnał. Monitory raczej nie mają problemów ale TV już mogą mieć. Czasami nie ma obrazu albo ma artefakty (np. u mnie na plaźmie) a czasami obraz jest ale wyświetlany z częstotliwością jakiej TV oczekiwał tj. on sobie buforuje klatki sam
3. buforowanie pojedynczych linii wraz ze zmianą zegara HDMI - tak jak w poprzednim trybie ale nie buforuje się całych klatek. W zasadzie kompatybilność powinna być taka sama jak poprzedniego trybu. Poprzedni tryb ostał się z historycznych powodów i dla ewentualnego debugowania bo bywają systemy które mają np. nierówną długość linii i one mogą lepiej działać w trybie 2 na niektórych wyświetlaczach.

W tym ostatnim trybie podobno ma być do chyba 3 linii opóźnienia niezależnie od rozdzielczości ekranu, odtwarzanego systemu i trybu skalowania. Ja w to nie wierzę bo za dużo analizowałem ten temat i mi się to zwyczajnie nie widzi. Zakładając że zrobili to optymalnie to będzie tych linii raczej na tyle niewiele że opóźnienie będzie liczone w pojedynczych milisekundach i daleko do nawet połowy czasu klatki.

Tutaj test z paletką który opisałem wcześniej na oko wyglądałby że działa tak samo ale można by wyłapać drobne opóźnienia szybką kamerą. Oczywiście testujac na odpowiednim wyświetlaczu który sam nie daje laga. Acha, i można też użyć prostego scan-doublera zamiast skalera i tutaj opóźnienie to faktycznie jedna-dwie linie ale wtedy z rozdzielczości systemu robi się zawsze 2x rozdzielczosć. Na CRT działa to świetnie i na dużej części monitorów LCD też. Gorzej telewizory... choć tryb 480p czy 576p to w zasadzie 2x 480i / 576i więc kompatybilność nie jest tragiczna.


---Suma sumarum, tl;dr---
FPGA i emulacja programowa są 'tym samym' tylko jeśli chodzi o to że oba rozwiązania są efektem inżynierii wstecznej bazującej na dokumentacji i obserwowaniu efektów działania oryginalnych układów. Za to pod względem technicznego działania to coś zupełnie innego. Inaczej programuje się emulator i inaczej się go debuguje. Pewne problemy kompatybilności emulatorów jest rozwiązać trudniej podczas gdy na FPGA jest prościej. Stworzenie wsadu FPGA wymaga innej wiedzy i trochę innego podejścia tj. należy zastanowić się nad tym jak działał sprzęt i z czego może wynikać dana różnica w efekcie działania. W emulacji raczej dodaje się workaroundy na efekt działania i tak masz w nich często specjalne tryby kompatybilności. Samo to sprawia że FPGA jest bliżej działania oryginalnego sprzętu.

Pod względem efektu dla użytkownika o ile nie ma problemów z kompatybilnością softwareową to FPGA daje dokładnie takie same doświadczenie jak oryginalny sprzęt tj. zero opóźnień. Jeśli chodzi o skaler to MISTer daje podobne możliwości i opóźnienia co prawdziwy sprzęt podłączony do zewnętrznych skalerów takich jak OSSC czy RetroTink

Tak więc... można sobie zrównywać FPGA z emulacją programową ale warto by się zastanowić czy nie robi się z siebie kretyna. Jak ktoś wybiera FPGA ze względów zalet jakie opisałem a my ciągle uporczywie piszemy że to zwykły emulator bo dla nas liczy się tylko czy to Amiga czy !Amiga a pomija się całkowicie kwestię użytkowe to właśnie wygląda się na niewyedukowanego idiotę.

ps. Acha, i jeśli chodzi o nowoczesne ekrany to zdecydowana większość użytkowników prawdziwej Amigi ma większe opóźnienia i gorszą jakość obrazu niż gdyby podłączyli MISTera do tych samych ekranów. Amiga -> takni skaler (np. wbudowany w telewizor/monitor albo za 100zł za allegro)-> monitor ma znacznie większego laga niż MISTer -> monitor

Amiga 3000 posiada układ o nazwie copper, który z kolorami wyczynia
na Amidze cuda.

To ma jakieś znaczenie przy 030+?
Bo raczej wychodzi na to, że lepsze są proste tryby chunky + brutalna siła CPU.

Pomyliłeś Blitter z Copperem.

Aleś się rozpisał tłumacząc coś co ja doskonale wiem...

można sobie zrównywać FPGA z emulacją programową

Jeśli wrażenie takiego przedstawienia sprawy wyniosłeś z moich komentarzy, to wybacz, ale zupełnie nie zrozumiałeś o co chodzi.

Jak ktoś wybiera FPGA ze względów zalet jakie opisałem a my ciągle uporczywie piszemy że to zwykły emulator

A gdzieś tak pisałem? "zwykły emulator"?

a pomija się całkowicie kwestię użytkowe to właśnie wygląda się na niewyedukowanego idiotę.

No to kwestie użytkowe są też takie, że Amiga na RPi potrafi ciągnąć z karty microsd nawet kilkadziesiąt MB/s i tyleż przez sieć czego nie potrafi nawet V4. Każde rozwiązanie ma plusy i minusy. Emulacja programowa "ssie" w zakresie obsługi chipsetu ze względu na synchro wielu procesów. I w sumie tylko tutaj FPGA ma przewagę. O ile ta "implementacja chipsetu w FPGA" jest 100% dokładna (a jest? dawno nie odwiedzałem forum mistera, ale jeszcze w zeszłym roku parę bugów jednak było co dziwić nie powinno bo pomimo emu... implementowania max ile się da z amigi jednak FPGA nie dostaje 2MB CHIP RAM w postaci kosterk DRAM 120ns tylko ma jeden duży kawałek wielokrotnie szybszego DDR3 SDRAM). A i w tym zakresie są prace by pożenić implementowany chipset z emulacją JIT 68k na ARMie w Cyclone V SE...

Ostatnia aktualizacja: 14.08.2022 18:32:40 przez abcdef

W fpga ważna jest jakość wsadu. Teoretycznie więc może
on być odpowiednikiem 100% real hardwaru, ale wymaga
dobrego zaprogramowania a to nie zawsze jest
gwarantowane.

Moja rozprawka to tak ogólnie była, niekoniecznie do Ciebie, bo widzę że te rzeczy nie są jednak aż tak powszechnie znane. Jeśli na pytanie Anioła ludzie zrównują FPGA z WinUAE to świadczy o niezrozumieniu tematu. Podstawowe pytanie jakie trzeba sobie zadać to dlaczego akurat MISTer skoro emulacja też istnieje. Szczególnie jeśli ktoś uważa że FPGA to inna forma emulacji

Twój post traktuje o braku powodu dla którego rozwój FPGA miałoby dać przewagę nad programową emulacją. Nie zgadzam się z tym i napisałem dlaczego. Ogólnie to emulacja programowa za bardzo zachęca do robienia workaroundów na efekty a nie ich przyczyny bo czasami przyczyny wymagają większej rozdzielczości niż co jest tak naprawdę emulowane. W FPGA nie ma łatwego patchowania bo ani nie jest to takie proste ani nie ma na to zazwyczaj w FPGA miejsca. Łatki się pojawiają i tam zmian może być bardzo niewiele, wydawało by się banał... no ale to zmiana pracy układu np. wzięcie pod uwagę czasu propagacji sygnału i nie jest to żaden fix na migającą teksturę w jakiejś grze a przybliżenie pracy odtworzonego układu.

Każde rozwiązanie ma plusy i minusy. Emulacja programowa "ssie" w zakresie obsługi chipsetu ze względu na synchro wielu procesów. I w sumie tylko tutaj FPGA ma przewagę.

No właśnie nie tylko bo przecież piszę że dla użytkownika są znaczne różnice w działaniu jak już gra.
Nie wszystko odnosi się do kompatybilności bo i tak jest w większości wystarczająco dobra dla większości gier.

W FPGA nie masz praktycznie opóźnień vs prawdziwy sprzęt a w emulatorze to wiele milisekund.

O ile ta "implementacja chipsetu w FPGA" jest 100% dokładna (a jest?

Nie od razu Rzym zbudowano...
Jak ludzie porównują MISTera do emulatorów ogólnie to wynika z tego że core'y dla MISTera lepiej odtwarzają drobne różnie renderingu w różnych grach, właśnie jakiś migający piksel czy linie. Jeśli gra cuduje z nadużywaniem pozycji sprajtów to MISTer lepiej to oddaje.

Odnośnie ogólnej kompatybilności to różnie to już jest. Zazwyczaj dany system potrzebuje wielu lat developmentu aby osiągnąć sensowną kompatybilność i to zarówno dla emulacji i FPGA a jakby nie patrzeć emulatory powstają od bardzo dawna.

jednak FPGA nie dostaje 2MB CHIP RAM w postaci kosterk DRAM 120ns tylko ma jeden duży kawałek wielokrotnie szybszego DDR3 SDRAM

MISTer jako platforma prawie uniwersalnie wymaga kostki SDRAM. Są też kostki z SRAMem czy też można mieć dwie kostki SDRAMu. Raczej tendencja jest taka aby unikać ich wymogu i aby wszystko dało się uruchomić na jednym SDRAMie. Jak potrzeba jest więcej RAMów i/lub określone timingi to można taktować pamięć SDRAM dużo wyższym zegarem.

Pamięć DDR3 raczej jest używana tam gdzie nie ma wymagań na niskie opóźnienia. W Minimigu można użyć jej jako Fast ale to bardziej jak ktoś potrzebuje duże ilości Fastu. Do gier raczej ustawia się te 8MB i wtedy użyta jest kostka SDRAM.

A i w tym zakresie są prace by pożenić implementowany chipset z emulacją JIT 68k na ARMie w Cyclone V SE...

Widziałem to, jakieś pół roku temu jak były pierwsze wyniki. Jak dla mnie pomysł bez sensu i lepiej byłoby się skupić na przyśpieszeniu softcore bo myślę że jest jeszcze duży potencjał. No ale to już potencjalny developer wybiera co chce robić a co nie. Każdy może sobie zainstalować Quartusa i zostać developerem

W FPGA nie masz praktycznie opóźnień vs prawdziwy sprzęt a w emulatorze to wiele milisekund.

Żeby być sprawiedliwym, trzeba przyznać, że programowa
emulacja może zejść poniżej 1 klatki. Widziałem testy
i retroarch robi tu dobrą robotę.
W przypadku użycia funkcji runahead, input lag może
być nawet niższy niż w prawdziwym sprzęcie.



Ostatnia aktualizacja: 14.08.2022 22:37:47 przez mmarcin2741

W FPGA nie ma łatwego patchowania bo ani nie jest to takie proste ani nie ma na to zazwyczaj w FPGA miejsca

DE10 nano można wsadzić całe V4SA i jeszcze zostanie na wszelkie wynalazki jakie Gunnarowi by przyszły do głowy ...

Ogólnie to emulacja programowa za bardzo zachęca do robienia workaroundów na efekty a nie ich przyczyny bo czasami przyczyny wymagają większej rozdzielczości niż co jest tak naprawdę emulowan

Jak rozumiem emulacja bardzo konkretnych konfiguracji (w tym rozszerzeń) jest zła, a ogólnych jest dobra. Bo ta pierwsza jest w WinUAE, a drugiej nie uzyskasz w FPGA (nie dlatego, że się nie da, ale dlatego że to zdecydowanie więcej pracy).

a jakby nie patrzeć emulatory powstają od bardzo dawna

Powstają, ale akurat teraz ciśnienie jest zdecydowanie mniejsze na niedociągnięcia emulacji chipsetu (choć niedawno była duża poprawka głównie AGA) a więcej na emulację określonych sprzętów. Czego MiSTer nie robi wcale. Dodatkowo WinUAE emuluje MMU (i FPU zresztą też, w takiej precyzji jaka nam odpowiada i w takim trybie jaki nam odpowiada), a gdzie jest z jednym i drugim FPGA? No właśnie. Coś za coś. Jedni lubią mizerię w plasterki, a inni w wiórki (a jeszcze inni nie lubią wcale).

W FPGA nie masz praktycznie opóźnień vs prawdziwy sprzęt a w emulatorze to wiele milisekund

Bez znaczenia. Amiga to sprzęt przygotowany do tego by strzelać elektronami w luminofor, a ta technologia umarła dawno temu. Cały chipset kręci się wokół pixel clock w różnych wariacjach. Emulacja programowa daje szereg filtrów by odwzorować ten efekt, kojarzę że w misterze chyba też część była wykorzystana. Zdaje mi się, że nie ma nic takiego w vampie.

Jak dla mnie pomysł bez sensu i lepiej byłoby się skupić na przyśpieszeniu softcore

Tego softcore za bardzo nie przyspieszysz bez mocnego przebudowania, a to nie jest celem tego projektu. TG68 jest dostępne od dawna, to co dało się w miarę prosto zrobić jest zrobione. Podobnie z FX68, J68, WF68k30 ... I tylko jeden softcore ma superskalarną architekturę z dwoma potokami wykonawczymi, ten który nieodzownie łączy się z innym projektem sprzętowym ze stajni Apollo. Zwyczajnie nie ma takiego ciśnienia na 68k, szczególnie że większość pary idzie w maszynę, która ma odpalać stare gry, a nie mającą zastąpić stary sprzęt by odpalać nowsze gry. Wydajność klasy pentium nie jest do tego niezbędna. I jak widzisz zbudowany w 28nm FPGA wyciąga w okolicach 100MHz na taki softcore. Względem 060 wygląda to na sporo, ale ... to jest 28nm. 28nm x86 latało na 4GHz. Nie brakuje naiwnych myślących, że przeniesienie AC68080 do ASIC da 2GHz. Gdyby to tylko było takie proste (już pomijając cenę) to przecież nikt nie miałby problemu z 3GHz RISC-V, tak? A jakie są? D1 od Allwinnera w 22nm ma 1 (!!) GHz.

Pozdrawiam wszystkich zdrowo myślących.

W FPGA nie masz praktycznie opóźnień vs prawdziwy sprzęt a w emulatorze to wiele milisekund


Bez znaczenia. Amiga to sprzęt przygotowany do tego by strzelać elektronami w luminofor,

Co pan ma na myśli? Amiga to zwykły cyfrowy komputer, którego zasada
działania jest taka sama jak dzisiejszego peceta.

Nie ma najmniejszego problemu podłączyć dzisiejszego
pc do monitora crt.


Ostatnia aktualizacja: 14.08.2022 23:10:55 przez mmarcin2741

Co pan ma na myśli

Przemyśl sprawę - czemu jest stosowany kwarc 28,37516MHz; czemu zegar CPU to 7,09379 (w wersji PAL oczywiście) czyli dokładnie 1/4 ... czemu tyle a nie np. 28,000 i 7,000MHz? Gdybyś wiedział to byś takich pytań nie zadawał.

Ostatnia aktualizacja: 14.08.2022 23:24:26 przez abcdef

Procesor może działać asynchronicznie. Zamontuje pan sobie w A500,
np. kartę z cpu taktowanym 50mhz i będzie działać.
Podobnie w A1200 z kartami aca.

Procesor Motorola działa w wielu różnych sprzętach, tych bez jakiegokolwiek wyjścia monitorowego również. To co jest istotne to jest jak działa w Amidze. A w Amidze działa we współpracy z chipsetem. Więc możesz sobie taktować 50MHz, ale adresując chipset będziesz i tak miał cykl dostępu jak 68000 7,09MHz. I nadal nie odpowiedziałeś na zadane pytanie. Bo najwidoczniej nadal nie rozumiesz tego dlaczego amiga zbudowana jest tak jak jest zbudowana.

dlaczego amiga zbudowana jest tak jak jest zbudowana.

Bo projektowano ją jako konsolę do gier. Stąd dość zamknięta architektura z dużym udziałem układów specjalizowanych i postulat maksymalnej integracji z ówczesnymi standardami audio-video.

To, że tak skonstruowany komputer okazał się świetny także do pracy w audio-video odkryto wtórnie i - tak naprawdę - nie wykorzystano tego potencjału w pełni i z pełnym zaangażowaniem.

Bo projektowano ją jako konsolę do gier. Stąd dość zamknięta architektura z dużym udziałem układów specjalizowanych i postulat maksymalnej integracji z ówczesnymi standardami audio-video

I o to właśnie chodzi. Maszyny z tamtych czasów działały na związaniu wielu sygnałów zegarowych z systemami nadawania TV - PAL albo NTSC. Stąd C64 PAL miał 0,985MHz, a NTSC 1,023MHz. Amiga PAL miała 7,09MHz zaś NTSC 7,16MHz. Co za tym idzie konkretne sloty DMA, zegar CPU, przerwania itp - wszystko to się kręciło wokół TV. I właśnie to powoduje że jest trudniej. W końcu nie ma żadnego problemu z emulowaniem Amigi z RTG w Zorro III, AHI i kilkuset MHz Motorolą. A taka A2k/3k/4k wykorzystująca rozszerzenia zamiast chipsetu to nadal Amiga. I tu nie było problemu tego typu komputer zrobić wcześniej (patrz Casablanca i DraCo).

To, że tak skonstruowany komputer okazał się świetny także do pracy w audio-video odkryto wtórnie i - tak naprawdę - nie wykorzystano tego potencjału w pełni i z pełnym zaangażowaniem

Tutaj bym nie przesadzał. To co było świetne to właśnie to synchro wszystkiego z PAL/NTSC przez co łatwiej było miksować źródła i nakładać efekty. I tak, duże znaczenie było tutaj blittera, ale szybszy CPU też by to ogarnął (co zresztą ostatecznie się stało). A myślę, że twórcy video toastera tutaj dali pełne zaangażowanie i spijali śmietankę. To Commodore przespało ;)