Czy powstanie kiedyś 100 procentowy emulator PC?

0

Pytanie niby głupie ale póki co mamy emulatory, które dają radę uruchamiać stare oprogramowanie ale wciąż daleko im do wiernego odtwarzania/emulowania obszarów związanych ze sprzętem. Z jednej strony w wirtualnym środowisku możemy już uruchamiać dość zaawansowane gry a nawet systemy operacyjne a z drugiej wciąż nie potrafimy dobrze emulować MIDI serwowanego np. przez Gravis Ultrasound czy zwyczajnie rejestrów specjalnych karty VGA.

Dzisiejsze komputery są już ponad 1000 krotnie szybsze od takiego PC/AT z procesorem 286 jednak nie widziałem dobrego emulatora, który potrafi poprawnie odtwarzać niektóre dema z przed ponad 25 lat...

Wiem, że są już bardzo zaawansowane emulatory Commodore 64 czy nawet Amigi, które "prawie" wiernie odtwarzają zachowanie się fizycznego sprzętu jednak wciąż jeszcze coś im brakuje...

Myślicie, że kiedyś coś takiego powstanie? Ewentualnie jak blisko lub daleko nam do osiągnięcia takiego celu?

2

Jakby dało się na tym zarobić to by powstały, widocznie jest to nieopłacalne.

0

Problem polega na tym, że nie ma jednego PC, są różne modele z różnymi specyficznymi funkcjonalnościami.

0
Manna5 napisał(a):

Problem polega na tym, że nie ma jednego PC, są różne modele z różnymi specyficznymi funkcjonalnościami.

Póki co nie ma nawet dobrej emulacji zwykłego standardowego VGA z 256kB RAM.

O bardziej wyrafinowanych sprzętach nawet nie ma co myśleć bo to faktycznie potężne wyzwanie.

1

@katakrowa:

w 100% dokładny emulator sprzętu metodą 100% softwarową nigdy nie powstanie.
Wiele wpisów w rejestry sprzętowe mieści sie w bardzo ścisłych timingach, outputy z róznych dziedzin kompuetera są absolutnie niezależne (grafa nie powie moniotorowi "hej poczekaj z ta linią, bo mi tu przerwali", / cpu algorytm głowny), choć synchronizowane ...

Mając szybkosć 1000% pierwotnej, pewnie wiele timingów bedzie nawet szybszych, ale nie będą dokładne, a wszelkie nasze timerki odwzorowują bardziej mS, trochę w dziedzinie uS, ale w dziedzinie bliskiej nanosekund to można tylko siąść i płakać.

Przecież kontrolery sprite'ów Atari / Commodore to majstersztyki sprzętu mikroprocesorowego, tam WSZYSKO jest w timingach, i w l 1980 działało to nad wyraz wydajnie - i nie chodząc sobie po odciskach

0

Poniżej przykładowy efekt, który był dość powszechnie używany pod DOS'em ale także w grach na komputerach 8-bitowych (chodzi o efekt w tle po 15 sekundzie).
Niby opiera się jedynie na zmianie palety w synchronizacji z powrotem plamki. Niby są to informacje, które mamy w systemie i byłoby możliwe przekazani ich do emulatora jednak póki co nie widziałem emulatora, który by to ogarnął.

Filmik z aplikacją uruchomioną pod FreeDos (fizyczne odpalenie DOS na współczesnym PC):

0

Wsiadam w auto , jadę do rodziców , wchodzę na strych i mam tam kolejne generację PC od 386 które używałem , po co emulować ?
Technologia jeszcze ołowiowa to pewnie jeszcze nie uległy samo-rozlutowaniu :D

A poważnie to ktoś potrzbuje takiego emulatora ?

2
Adamek Adam napisał(a):

A poważnie to ktoś potrzbuje takiego emulatora ?

Kilka tys z miliarda użytkowników komputerów. Ale wyłącznie za darmo.

1

Urządzenia sprzętowego nie da się prosto emulować za pomocą oprogramowania, to co jest w demach to często niskopoziomowy dostęp do sprzętu
pewnie jeszcze trochę za wolne te nasze komputery

0
ZrobieDobrze napisał(a):

Kilka tys z miliarda użytkowników komputerów. Ale wyłącznie za darmo.

Nawet jeśli kilkadziesiąt tysięcy to najprawdopodobniej to prawda.
Kiedyś jednak wszystkie 386 zalegające na strychach padną. Kondensatory wyschną, procesory zostaną uszkodzone i możliwość odpalenia starego programu zniknie.

Dziwi mnie jednaj fakt, że takie emulatory ZX Spectrum, Commodore czy innych konsol 8 i 16bit są wciąż rozwijane... nawet jest jakiś pasjonat co zabrał się za emulację MERA-400 (a to już poważna nisza):

Youtube - MERA 400

W kontekście powyższych brak dobrego emulatora PC wydaje się być czymś dziwnym.

2

Takie emulatory powstają głownie żeby uruchomić gry na te systemy, a w przypadku x-86 nie ma na razie takiej potrzeby, bo na super-hiper nowoczesnej maszynie wciąż można uruchomić stary OS i gry pod niego.

PS emulacją PC zajmuje się Apple, po przejściu na ARM-a wciąć chcą zachować kompatybilność wsteczną

0

tzn w sumie takie symulatory istnieją, przecież jakoś te gry na stadia były odpalane.

0
katakrowa napisał(a):

Dzisiejsze komputery są już ponad 1000 krotnie szybsze od takiego PC/AT z procesorem 286 jednak nie widziałem dobrego emulatora, który potrafi poprawnie odtwarzać niektóre dema z przed ponad 25 lat...

a DosBox nie ogarnia tego?

1
LukeJL napisał(a):
katakrowa napisał(a):

Dzisiejsze komputery są już ponad 1000 krotnie szybsze od takiego PC/AT z procesorem 286 jednak nie widziałem dobrego emulatora, który potrafi poprawnie odtwarzać niektóre dema z przed ponad 25 lat...

a DosBox nie ogarnia tego?

Nigdy go w zakresie gier nie męczyłem.

Na pewno target twórców to 100% odwzorowoania DOS, BIOS, RAM we władaniu BIOS, powszechnie używane porty "w ogóle" - ale nie pa pewno z precyzją czasową sprzętu np karty graficznej

0

A propos istotności nawet głupich timingów, pamiętacie nie gry, a "nasze" zwykłe programy do prowadzenia magazynu w Pascalu, które na szybszych pecetach wylatywały w powietrze z charakterystycznym errorem 200 ?

0
LukeJL napisał(a):

a DosBox nie ogarnia tego?

słabo, odpalałem djs 2,1 na tym to coś było nie tak z timingami, czasem miało sie wrażenie jakby ruch był x1,5 a czasem jak x0.5

1

Nie ma co porównywač ze sceną emulatorów konkretnych maszyn - a500, c64, PSX, etc bo mamy tu do czynienia z emulowaniem konkretnej zamkniętej architektury.
W przypadku PC tak łatwo nie ma, plus fakt że to jest żywy system i wiele aplikacji/gier da się odpalić na nowoczesnych systemach.

1

Tak patrzę na ten film i kompletnie nie mogę dostrzec co jest tam takiego specjalnego.

Akuart kiedyś pisałem swojego kernela nie był zbyt perfekcyjyny, ale tam vesa z biosu był podmapowany za pomocą MMIO, chodź jak sam robiłem podobną implementację na FPGA to zupełnie mam inne doświadczenie z programowaniem tego.

Zegar aż taki duży nie jest potrzebny starczy 10-100Mhz, zależy jaka rozdzielczość, przepustowość za to potrzebna spora, takie układy zwykle phase locked loopem można do 400Mhz podkręcić,
Liczy się po prostu tyknięcia zegara i wyciąga po bajcie z tablicy jeśli tryb 256 kolorów lub więcej, dane ustawia się logicznie, ale VGA działa na napięcie, czyli musimy zrobić jakiś prosty DAC, digital to analog converter np 000 bitowo to 0.0V, a 111, to 0.7V.

Problem może się pojawić przy próbie transferu danych z komputera w czasie rzeczywistym, układy zwykle mają mało pamięci i trzeba kolejkami FIFO problem rozwiązywać gdy jeden wiersz został wczytany inny się wczytuje, układy działają równolegle, to nie ma problemu jak się wiele rzeczy jednocześnie dzieje, dopóki ci komórek starczy.
Dodatkowo można się pokusić o implementacji dekompresji obrazu i transfer przez usb jako awaryjna karta graficzna.

Ogólnie jitowanie do kodu maszynowego, ale jest też jitowanie do hardware, ale jak na razie to i tak jest AOT, trochę trików wymaga, można cały procesor wygenerować chodź są open source implementacje, jak na razie istnieją kompilatory, które pozwalają sieci neuronowe od razu do sprzętowej implementacji skompilować.
Można by było też skompilować do czegoś innego niż architektura tranzystorowa, jakiejś w ogóle egzotycznej zbudowanej na DNA/mRNA, na spinotronice, albo neuromorficzne, gdzie te ostatnie już funkcjonuje.

Ale wygenerowanie akurat całego hardware jest nieco skomplikowane bo najlepiej i tak po prostu mieć procesor, gdyż powtarzanie się różnych operacji może szybko wyczerpać zasoby.
W końcu będzie trzeba open source projekt amd64 wykonać, jak będą możliwości wygenerować procesor na dowolnym hardwarze, z dowolnej materii to nikt tego ręcznie nie będzie robił tylko się fizykę ogarnie, a układy się wygeneruje, które będą jak dany procesor pracować.

1

Nie widzę większych przeszkód, wszelkie timingi moim zdaniem można emulować wystarczająco żeby dojść do identycznego z punktu widzenia użytkownika zachowania. Sygnał fizycznie nie musi dojść z precyzją nanosekund; wystarczy obliczenie który sygnał wygrałby race condition i dostarczenie go znacznie wolniej.
Ale obecne emulatory są na tyle dobre że spełniają 99% potrzeb a kasy z tego nie ma dużej więc raczej nigdy taki nie powstanie.

Każdy kto chce się bawić w taką archeologię i zależy mu na 100% odwzorowaniu dawno się zaopatrzył w stary sprzęt, moim zdaniem cena takich zestawów będzie tylko rosnąć. Są większe problemy niż emulowanie karty VGA - LCD nie zastąpi choćby monitora CRT, ma inne proporcje pikseli przez co obraz jest rozciągnięty i sposób działania przez co na przykład nie ma szansy użyć oryginalnych light gunów.

1
Wypierdzistyy napisał(a):

Tak patrzę na ten film i kompletnie nie mogę dostrzec co jest tam takiego specjalnego.

Chodzi o kolorowe paski w tle.
screenshot-20221111230424.png

Pod linkiem: https://ms.xksi.pl/_DOS_TXT_DEMO/run.html można zobaczyć to samo "demo" w DOSBOX.

Jeśli weźmiesz pod uwagę, że ten obraz to zwykły tryb tekstowy z 16 kolorami a nie graficzny to okaże się, że teoretycznie osiągnięcie takiego efektu nie jest możliwe.
Został tu wykorzystany prosty "trick", który umożliwiała i do dziś umożliwia każda karta graficzna zgodna z VGA (obraz nagrywałem na swoim i5 bootując dosa z pendrive).
Polega to na tym, że 16 kolorów, które można było wykorzystać w trybie tekstowym było definiowane w palecie karty graficznej.
3 pierwsze bajty palety odpowiadały kolorowi 1, trzy kolejne kolorowi 2 itd... (te mogły wyświetlać w trybie graficznym maksymalnie 256 kolorów a w tekstowym 16).
I teraz zmiana tych wartości w odpowiednio szybkim tempie w czasie jakim rysowana jest jedna linia na ekranie te wartości się zmieni to można "oszukać" sprzęt i wymusić wyświetlenie większej ilości kolorów w jednej klatce obrazu.

Akuart kiedyś pisałem swojego kernela nie był zbyt perfekcyjyny, ale tam vesa z biosu był podmapowany za pomocą MMIO, chodź jak sam robiłem podobną implementację na FPGA to zupełnie mam inne doświadczenie z programowaniem tego.
Zegar aż taki duży nie jest potrzebny starczy 10-100Mhz, zależy jaka rozdzielczość, przepustowość za to potrzebna spora, takie układy zwykle phase locked loopem można do 400Mhz podkręcić,
Liczy się po prostu tyknięcia zegara i wyciąga po bajcie z tablicy jeśli tryb 256 kolorów lub więcej, dane ustawia się logicznie, ale VGA działa na napięcie, czyli musimy zrobić jakiś prosty DAC, digital to analog converter np 000 bitowo to 0.0V, a 111, to 0.7V.

Piszesz o rozwiązaniu sprzętowym a mowa o poprawnej emulacji programowej.

obscurity napisał(a):

Nie widzę większych przeszkód, wszelkie timingi moim zdaniem można emulować wystarczająco żeby dojść do identycznego z punktu widzenia użytkownika zachowania. Sygnał fizycznie nie musi dojść z precyzją nanosekund; wystarczy obliczenie który sygnał wygrałby race condition i dostarczenie go znacznie wolniej.

Też mi się tak wydaje, że przy dzisiejszych szybkościach przetwarzania danych nie powinno to być wielkim wyzwaniem.

Ale obecne emulatory są na tyle dobre że spełniają 99% potrzeb a kasy z tego nie ma dużej więc raczej nigdy taki nie powstanie.

Jak już wcześniej pisali najprawdopodobniej to jest odpowiedź na moje pytanie i uzasadnienie dlaczego tego nie ma.

Każdy kto chce się bawić w taką archeologię i zależy mu na 100% odwzorowaniu dawno się zaopatrzył w stary sprzęt, moim zdaniem cena takich zestawów będzie tylko rosnąć. Są większe problemy niż emulowanie karty VGA - LCD nie zastąpi choćby monitora CRT, ma inne proporcje pikseli przez co obraz jest rozciągnięty i sposób działania przez co na przykład nie ma szansy użyć oryginalnych light gunów.

Przypuszczalnie jak te fizyczne sprzęty się skończą a odpalenie DOS'a na komputerach w nowych architekturach niekoniecznie zgodnych x86 nie będzie już możliwe to pewnie powstanie jakiś hardware open project wykorzystujący FPGA, który wszystko załatwi...

0

Mister FPGA

Tylko taka droga jest możliwa

1
katakrowa napisał(a):

wciąż nie potrafimy dobrze emulować MIDI serwowanego np. przez Gravis Ultrasound czy zwyczajnie rejestrów specjalnych karty VGA.

Ale jak nie? Taki DOSBox ogarnia VGA i GUS w miarę dobrze. Chyba że czegoś ci brakuje, no to siadasz do kodu i poprawiasz :)

0
Azarien napisał(a):

Ale jak nie? Taki DOSBox ogarnia VGA i GUS w miarę dobrze. Chyba że czegoś ci brakuje, no to siadasz do kodu i poprawiasz :)

Właśnie masz powyżej w poście, że nie ogarnia VGA. (link)

Co do GUS to nie jest źle jeśli chodzi o sam strumień sygnału w jego przypadku chodzi o to, że GUS sam w sobie miał dobrą dość elektronikę w części analogowej więc przeciętna karta na płycie głównej nie ma prawa zadziałać tak samo. Ale faktycznie na dobrych kartach dźwiękowych emulacji GUS nie ma się co czepiać.

1

Ale jak nie? Taki DOSBox ogarnia VGA i GUS w miarę dobrze. Chyba że czegoś ci brakuje, no to siadasz do kodu i poprawiasz :)

Właśnie masz powyżej w poście, że nie ogarnia VGA.

Ale ustawiałeś machine=vgaonly? Bo defaultowo DOSBox ma machine=svga_s3 co nie jest w 100% zgodne z VGA (a co widać np. po glitchach palety w grze Lemmings)

A 86Box patrzyłeś?

1
Azarien napisał(a):

Ale jak nie? Taki DOSBox ogarnia VGA i GUS w miarę dobrze. Chyba że czegoś ci brakuje, no to siadasz do kodu i poprawiasz :)

Właśnie masz powyżej w poście, że nie ogarnia VGA.

Ale ustawiałeś machine=vgaonly? Bo defaultowo DOSBox ma machine=svga_s3 co nie jest w 100% zgodne z VGA (a co widać np. po glitchach palety w grze Lemmings)

A 86Box patrzyłeś?

OD wczoraj czytam o znaczeniu parametrów w konfiguracji:

  1. fulldouble
  2. vsyncMode, vsyncRate itp...
    ....

nawet kody źródłowe pobrałem i widzę, że teoretycznie obsługa rejestru 3DAh jest oprogramowana...

Bitu vga_read_p3da(Bitu port,Bitu iolen) {
	Bit8u retval=0;
	double timeInFrame = PIC_FullIndex()-vga.draw.delay.framestart;

	vga.internal.attrindex=false;
	vga.tandy.pcjr_flipflop=false;

	// 3DAh (R):  Status Register
	// bit   0  Horizontal or Vertical blanking
	//       3  Vertical sync

	if (timeInFrame >= vga.draw.delay.vrstart &&
		timeInFrame <= vga.draw.delay.vrend)
		retval |= 8;
	if (timeInFrame >= vga.draw.delay.vdend) {
		retval |= 1;
	} else {
		double timeInLine=fmod(timeInFrame,vga.draw.delay.htotal);
		if (timeInLine >= vga.draw.delay.hblkstart && 
			timeInLine <= vga.draw.delay.hblkend) {
			retval |= 1;
		}
	}
	return retval;
}

**... Po chwili .. **

@Azarien: jesteś Bogiem!

machine=vgaonly zadziałało.

screenshot-20221112120652.png

Nareszcie będę mógł oglądać stare demka bez konieczności resetowania całego kompa po tym jak się któreś wykrzaczy.
@Azarien Dzięki!

Dziwne, że w domyślnym SVGA tego nie obsługują.

1

@Azarien Dzięki!

Dziwne, że w domyślnym SVGA tego nie obsługują.

Chyba chodzi o kwestię wydajności. Obsługa hacków (jak zmiana palety w połowie rysowania ekranu) kosztuje, a svga_s3 jest targetowane dla gier z czasów późnego DOSa gdzie takich numerów już się nie robiło, za to wydajność emulacji ma znaczenie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1