[emulatie] x86 emulator ontwerpen en bouwen

dinsdag 20 december 2005 19:52

Verwijderd schreef op dinsdag 20 december 2005 @ 11:50:
Vragen:
- Is dit als 'sole developer' haalbaar of moet je dit met een team doen?

Nee dat is niet haalbaar. Ik zou beginnen met een emulator voor een PIC, 8051, MIPS of iets dergelijks. Een x86 is erg complex. Je wilt naast de processor ook alles eromheen doen. Dit is waarschijnlijk veel meer werk dan de processor zelf.
Ik schat een paar jaar ontwikkelen met meer dan 100 man.

- Welke programmeertaal is het meest geschikt, ik denk aan C++ om het modulair op te kunnen bouwen, tijdskritisch te kunnen zijn en snelheid te behalen.

x86 is niet tijdskritisch. Sommige spelletjes hebben in de tijd van 8086 wel gebruik gemaakt van de snelheid van dat ding. Om deze oude spellen nog te kunnen spelen zijn er al veel programma's die je systeem kunnen vertragen.
Wil je toch tijdskritisch hebben, dan kan je gewoon libraries gebruiken in je OS. De taal maakt niet veel uit.

- Is er interesse voor een goede, tijdkritische, full system emulator voor 8088, 8086, 80286?

Nee. Je hebt al Bochs.
Bovendien gaat een emulator veels te traag. VMWare en VirtualPC zijn wel snel omdat dit geen echte emulators zijn. De instructies worden gewoon op je processor uitgevoerd. Alleen de randapparaten worden geemuleerd (bv harde schijven, videokaart, geluidskaart, printer).

Acties:

Verwijderd

Topicstarter

-NMe- schreef op dinsdag 20 december 2005 @ 19:05:
[...]

Dat hangt er eigenlijk helemaal vanaf wat je precies ermee wil kunnen. Ik denk wel dat je een verkeerd beeld hebt van wat emulatie inhoudt: waarom zou je bijvoorbeeld een floppy, HDD of CD-ROM willen emuleren? Je kan toch de drives gebruiken die al in het systeem zitten? En hoe wil je een netwerk emuleren? Ik denk dat je het in deze gevallen over implementeren moet hebben, niet over emuleren.

Ik zou de drives kunnen gebruiken, waare het niet dat ik liever met images werk, direct op de schijf is erg tricky, vooral bij harddisks. Als ik met images werk zou ik de controllers moeten emuleren. Het netwerk moet ook gedeeltelijk geëmuleerd worden omdat ik een virtuele netwerkkaart nodig heb, de echte is niet doenbaar omdat DOS enzo ze ook moeten herkennen.

[...]

Alles is in je eentje haalbaar, maar als je voor je pensioen nog wat af wil krijgen, dan kun je beter mensen zoeken die je willen helpen. Ter illustratie, aan DOSBox wordt al sinds 2003 gewerkt door een aantal personen, en nog steeds is het bij lange na niet perfect.

DOSBox is een vrij platte emulator, ik neig meer naar de x86 emulator van MESS.

[...]

C++ is een optie, maar in principe zijn alle talen wel een optie. Sowieso ga je er niet onderuit komen om assembly te gebruiken.

Waarom zou ik assembly willen/moeten gebruiken?

x86 is wel tijdskritisch iedere actie neemt een aantal msec in beslag, als die niet kloppen gaan je games bijvoorbeeld happeren, ik zit er wel aan te denken om multithreaded te gaan werken, elk onderdeel met zijn eigen thread . Dus VGA thread, CPU thread enzovoort/

[ Voor 9% gewijzigd door Verwijderd op 20-12-2005 19:53 ]

dinsdag 20 december 2005 20:07

Acties:

MisterData

Verwijderd schreef op dinsdag 20 december 2005 @ 19:52:
[...]

Waarom zou ik assembly willen/moeten gebruiken?

Nouja, ik denk dat je ook nog wel wat bootstrapping-code nodig hebt enzo... VMWare lijkt z'n eigen 'BIOS' te hebben, die zul je zelf moeten schrijven

dinsdag 20 december 2005 20:10

Acties:

Verwijderd

Verwijderd schreef op dinsdag 20 december 2005 @ 19:52:
x86 is wel tijdskritisch iedere actie neemt een aantal msec in beslag, als die niet kloppen gaan je games bijvoorbeeld happeren

Vermits je emulator een proces in een operating system is, en de meeste consumer operating systems een minimale timing hebben van 20 à 50 milliseconden, ben je toch zowiezo gebonden aan een benadering lijkt me.

dinsdag 20 december 2005 20:19

Acties:

dinsdag 20 december 2005 20:35

Ik zou eerst onderzoeken wat de mogelijkheden zijn om je doelen (snelheid, harddisk, cd-rom, soundblaster) te bereiken door zelf aanpassingen te maken in MESS. Als daar mogelijkheden voor zijn, dan scheelt dat waarschijnlijk veel tijd en daarmee groeit gelijk de kans van slagen, denk ik.

Acties:

Verwijderd

Topicstarter

kopjethee schreef op dinsdag 20 december 2005 @ 20:19:
Ik zou eerst onderzoeken wat de mogelijkheden zijn om je doelen (snelheid, harddisk, cd-rom, soundblaster) te bereiken door zelf aanpassingen te maken in MESS. Als daar mogelijkheden voor zijn, dan scheelt dat waarschijnlijk veel tijd en daarmee groeit gelijk de kans van slagen, denk ik.

Dat idee had ik ook al, lijkt me eingelijk ook wel leuk om aan zo'n opensoers project mee te doen. Alleen inlezen in andermans code is %$# werk, aangezien ik in het geval van mess de code al eens bekeken heb, doet mess zijn naam eer aan

(of ik kan niet lezen)

woensdag 21 december 2005 13:54

Acties:

woensdag 21 december 2005 14:20

Moderator Devschuur®

Demotivational Speaker

-NMe- schreef op dinsdag 20 december 2005 @ 19:05:
[...]

Dat hangt er eigenlijk helemaal vanaf wat je precies ermee wil kunnen. Ik denk wel dat je een verkeerd beeld hebt van wat emulatie inhoudt: waarom zou je bijvoorbeeld een floppy, HDD of CD-ROM willen emuleren? Je kan toch de drives gebruiken die al in het systeem zitten? En hoe wil je een netwerk emuleren? Ik denk dat je het in deze gevallen over implementeren moet hebben, niet over emuleren.

Je zult die hardware wel degelijk moeten emuleren, ook al map je het naar een fysiek apparaat. Je hebt namelijk te maken met software die direct de hardware aanspreekt; dat kun je simpelweg niet toelaten in een emulator, al is het alleen omdat je daar zelf als applicatie niet eens toegang toe hebt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 21 december 2005 14:26

[b]Verwijderd schreef op dinsdag 20 december 2005 @ 19:52
x86 is wel tijdskritisch iedere actie neemt een aantal msec in beslag, als die niet kloppen gaan je games bijvoorbeeld happeren, ik zit er wel aan te denken om multithreaded te gaan werken, elk onderdeel met zijn eigen thread . Dus VGA thread, CPU thread enzovoort/

x86 en andere processors met een complexe instructieset zijn nooit ontworpen om tijdkritisch te zijn. Tegenwoordig zijn de processors in PCs helemaal onvoorspelbaar met caches, branch prediction, virtual memory etc.

msec? milli is maar 10^-3.
4.77 MHz => 4.77 x 10⁶ kloktikken per seconden. Dat is dus 1 / (4.77 x 10⁶) = 2.1 x 10^-7 = 210 nanoseconden per kloktik (nano is 10^-9).
Volgens mij is de timer in je PC niet nauwkeurig genoeg om dit na te bootsen.

[ Voor 4% gewijzigd door Daos op 21-12-2005 14:57 ]

Acties:

woensdag 21 december 2005 14:32

Moderator Devschuur®

Demotivational Speaker

De timestampcounter op moderne CPU's natuurlijk wel, en bovendien ga je steeds vaker zien dat er speciale high-resolution timer hardware op het moederbord wordt geïntegreerd omdat de timestamp counters van CPU's niet in alle gevallen betrouwbaar zijn (zo kan een CPU bijvoorbeeld langzamer gaan draaien, en heb je niets aan een timestampcounter als de thread die de tijd uitleest op meerdere cores gescheduled wordt)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Topicstarter

Dat was mijn eerste probleem ook, dat ik geen timers had die 4.77 mHz nauwkeurig konden benaderen, maar waar zou ik mijn timing dan op moeten basseren? Spellen die bijvoorbeeld vertragen adhv de kloksnelheid moeten wel een eikpunt hebben (en een timer natuurlijk).

Maar na de kerst ga ik beginnen met de eerste emulatie, en ik denk dat dat de HDD controller wordt...

[ Voor 17% gewijzigd door Verwijderd op 21-12-2005 14:32 ]

woensdag 21 december 2005 14:48

Acties:

woensdag 21 december 2005 15:10

Verwijderd schreef op woensdag 21 december 2005 @ 14:32:
Dat was mijn eerste probleem ook, dat ik geen timers had die 4.77 mHz nauwkeurig konden benaderen, maar waar zou ik mijn timing dan op moeten basseren? Spellen die bijvoorbeeld vertragen adhv de kloksnelheid moeten wel een eikpunt hebben (en een timer natuurlijk).

Maar na de kerst ga ik beginnen met de eerste emulatie, en ik denk dat dat de HDD controller wordt...

Misschien is een grove benadering ook wel voldoende? Stel je kunt nauwkeurig 20ms afmeten, dan doe je in die 20ms gewoon 4.770.000 * 0.02 = 95400 instructies. Na die instructies wacht je tot de 20 ms voorbij zijn. Het zou me niet verbazen als je daar niks van merkt.

Acties:

woensdag 21 december 2005 15:36

kopjethee schreef op woensdag 21 december 2005 @ 14:48:
[...]

Misschien is een grove benadering ook wel voldoende? Stel je kunt nauwkeurig 20ms afmeten, dan doe je in die 20ms gewoon 4.770.000 * 0.02 = 95400 instructies. Na die instructies wacht je tot de 20 ms voorbij zijn. Het zou me niet verbazen als je daar niks van merkt.

Dat is nog eens een goed idee. Je moet er wel rekening meehouden dat instructies meerdere kloktikken nodig hebben afhankelijk van de instructies, locatie van de data en de data zelf.

Verwijderd schreef op woensdag 21 december 2005 @ 14:32:
Maar na de kerst ga ik beginnen met de eerste emulatie, en ik denk dat dat de HDD controller wordt...

Volgens mij verkijk je je nog steeds op de hoeveelheid werk. Heb je al eens naar de hoeveelheid code bij MESS gekeken?

Vroeger kon je in DOS maximaal 18.2 Hz krijgen van de timer. Veel oude spelletjes gebruikten daarom niet deze timer, maar iets van de videokaart (ik dacht vsync). Misschien moet je daar eens naar zoeken om je oude spelletjes goed werkend te krijgen.

[ Voor 19% gewijzigd door Daos op 21-12-2005 15:20 ]

Acties:

Verwijderd

Topicstarter

ik ken MESS erg goed en ook van binnen gedeeltelijk, dat MESS zolang in ontwikkeling is is omdat het een Multi Emulator Systeem is, alleen de x86 is minder moeilijk, ik ga denk ik de x86 emu er uithalen (qua processor dan) en ombouwen en onder GPL weer uitbrengen. Maar het project begint al vorm te krijgen en ik ga binnenkort op sourceforge een project aanmaken.

woensdag 21 december 2005 15:38

Acties:

woensdag 21 december 2005 16:01

Moderator Devschuur®

Demotivational Speaker

Daos schreef op woensdag 21 december 2005 @ 15:10:
[...]

Dat is nog eens een goed idee. Je moet er wel rekening meehouden dat instructies meerdere kloktikken nodig hebben afhankelijk van de instructies, locatie van de data en de data zelf.

En door de out-of-order execution kun je er al helemaal geen zinnig woord over zeggen

Vroeger kon je in DOS maximaal 18.2 Hz krijgen van de timer. Veel oude spelletjes gebruikten daarom niet deze timer, maar iets van de videokaart. Misschien moet je daar eens naar zoeken om je oude spelletjes goed werkend te krijgen.

De standaard tickrate van die timer was idd 18.2 Hz, maar die kon je wel anders instellen door een divider naar een bepaalde port te outputten (De frequentie van het crystal was 1.193.182 Hz, de standaard divider was 0xffff -> 1193182 / 65535 ~= 18.2 Hz). Later kwamen de AT's met een Real Time Clock die je kon laten tikken tussen de 2 Hz en de 32767 Hz, wat wat handiger was om te gebruiken aangezien het updaten van de clock door de IRQ0 handler gedaan werd die per se met 18.2 Hz aangeroepen moest worden

[ Voor 8% gewijzigd door .oisyn op 21-12-2005 15:39 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 21 december 2005 16:35

[quote].oisyn schreef op woensdag 21 december 2005 @ 15:38:
[...]

En door de out-of-order execution kun je er al helemaal geen zinnig woord over zeggen

[...]

Maar dat probleem is toch niet kleiner of groter wanneer je een nauwkeurige timer per instructie zou kunnen inzetten?

Acties:

woensdag 21 december 2005 16:44

Moderator Devschuur®

Demotivational Speaker

Het punt is dat een x86 geen timecritical CPU is en je geen zinnig woord kunt zeggen over hoe lang een instructie duurt. Het heeft dan ook geen enkel nut om een X aantal instructies per tijdseenheid uit te voeren, tenzij je echt een specifieke combinatie van hardware (cpu, mem, mainboard) nabootst en precies weet hoe de instructiepipelines en cache- en memorylatencies in elkaar zitten.

Games die afhankelijk zijn van CPU snelheid zijn verkeerd ontworpen en daarvoor zou je een globaal instelbare vertraging in je emulator kunnen inbouwen. De waarde die je voor een bepaalde game moet instellen is echter geheel arbitrair en puur door experimenten te bepalen. Gelukkig gingen de latere games over op timings aan de hand van de RTC of de refresh rate van de videokaart, die toen nog standaard op 60Hz lag.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 21 december 2005 16:55

.oisyn schreef op woensdag 21 december 2005 @ 16:35:
Het punt is dat een x86 geen timecritical CPU is en je geen zinnig woord kunt zeggen over hoe lang een instructie duurt. Het heeft dan ook geen enkel nut om een X aantal instructies per tijdseenheid uit te voeren, tenzij je echt een specifieke combinatie van hardware (cpu, mem, mainboard) nabootst en precies weet hoe de instructiepipelines en cache- en memorylatencies in elkaar zitten.

Games die afhankelijk zijn van CPU snelheid zijn verkeerd ontworpen en daarvoor zou je een globaal instelbare vertraging in je emulator kunnen inbouwen. De waarde die je voor een bepaalde game moet instellen is echter geheel arbitrair en puur door experimenten te bepalen. Gelukkig gingen de latere games over op timings aan de hand van de RTC of de refresh rate van de videokaart, die toen nog standaard op 60Hz lag.

OK, dan heeft het zoeken naar een nauwkeurige timer ook geen zin. Die gaat ook niet helpen. dan zou ik alsnog een experimenteel bepaald aantal instructies uitvoeren per tijdsinterval en daarna even wachten.

[ Voor 6% gewijzigd door KopjeThee op 21-12-2005 16:45 ]

Acties:

woensdag 21 december 2005 17:04

Moderator Devschuur®

Demotivational Speaker

Tja ik weet niet op welk platform de emulator moet gaan draaien, maar de meeste moderne platformen hebben toch wel nauwkeurige timingmogelijkheden hoor

. Onder win32 is dat QueryPerformanceCounter()

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 21 december 2005 17:11

.oisyn schreef op woensdag 21 december 2005 @ 16:55:
Tja ik weet niet op welk platform de emulator moet gaan draaien, maar de meeste moderne platformen hebben toch wel nauwkeurige timingmogelijkheden hoor . Onder win32 is dat QueryPerformanceCounter()

Maar dat heeft dus geen zin?

Acties:

woensdag 21 december 2005 19:13

Moderator Devschuur®

Demotivational Speaker

Naar mijn idee niet nee

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 21 december 2005 20:58

Ik denk dat het wel mogelijk is, maar het zal wel erg lastig worden. Bij de 8086 waren er nog geen optimalisaties. Het geheugen liep gewoon op dezelfde snelheid als de processor.

Een instructie die gebruik maakt van het geheugen wordt apart in de specificaties genoemd. Bij de mul zien de timings er zo uit:

Operand          Clocks
 reg8            70-77
 reg16          118-113
 mem8        (76-83)+EA
 mem16     (124-139)+EA

Effective Address (EA) is daarin zo te berekenen:

           Description                            Clock Cycles
Displacement                                            6
Base or Index (BX,BP,SI,DI)                             5
Displacement+(Base or Index)                            9
Base+Index (BP+DI,BX+SI)                                7
Base+Index (BP+SI,BX+DI)                                8
Base+Index+Displacement (BP+DI,BX+SI)                  11
Base+Index+Displacement (BP+SI+disp,BX+DI+disp)        12

- add 4 cycles for word operands at odd addresses
- add 2 cycles for segment override

Waar het verschil tussen die 70 en 77 bij de reg8 vandaan komt weet ik niet. Ik gok dat het afhangt van de data waarmee gerekend wordt. Dat moet je dan nog even opzoeken.

Acties:

MSalters

.oisyn schreef op woensdag 21 december 2005 @ 15:38:
[...]
En door de out-of-order execution kun je er al helemaal geen zinnig woord over zeggen

Een 8086 heeft geen OOE. Je telt dus ge-emuleerde instructies, en neemt stiekem aan dat je de 4.77Mhz haalt in je emulator (heel wel mogelijk, een 200Mhz Alpha kon dat met FX32)

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

woensdag 21 december 2005 21:57

Acties: