Announcement: there is an English version of this forum on Habe auf dem PC einen Nintendo. Möchte gerne eine Hand held Konsole bauen mit einem Mikrocontroller + Grafikdisplay und zubehör(Tasten) Nun stellt sich die Frage wie man einen solchen emulator programmiert oder ob man diesen irgendwie von windows portieren kann? Hat jemand Erfahrung oder hat ähnliche Ideen? mfg Martö
Hallo Wenn du den Quellcode von deinem Emulator hast, dann könnte eine Portierung möglich (aber wohl aufwändig) sein. Du musst dann halt sämtliche Funktionen, auf die der Emulator zugreift, auf dem Mikrocontroller zur Verfügung stellen. Auf jeden Fall hättest du mit dem Quellcode schonmal ne gute 'Dokumentation', wie so ein Emulator läuft. Ohne Quellcode wirds schwierig. Dann musst du dir von irgendwoher sämtliche Infos, wie so ein Game funktioniert, besorgen. Ich denke aber, sowas sollte sich grundsätzlich auch auf einem kleineren uC wie z.B. den AVRs hinkriegen lassen - jedenfalls die älteren Geräte Gameboy, NES und SNES basieren ja auf eher schwächeren Prozessoren. Gruss Michael
Ich denke nicht, dass ein AVR dafür genug Power hat. Ein Emulator braucht ein vielfaches mehr an Rechenleistung als das Original. Soll heißen, das Spiel von der Original-Kasette zu spielen war rein von der Leistung auf nem AVR möglich aber den Emu zum laufen zu bekommen eher net würd ich sagen.
Hi nur mal ein paar Daten zur SNES (In die gleiche Preisklasse gehören da auch Gameboy Advanc oder Micro): "16-Bit-Prozessor "5A22" kompatibel zum 65816, max. 3,579545 MHz (NTSC) und Soundchip "2a03". Beinhaltet einen programmierbaren DMA Controller für bis zu 8 DMA Kanäle und wählbarem HDMA Spezialmodus für besondere Grafikeffekte (ähnlich dem Amiga Copper). Grafikprozessoren: 2 PPU-Chips (PPU = Picture Processing Unit), 15 Bit Farbtiefe, 16 Bit Datenbus. Speicher: 128 kiB RAM, 64 kiB Video RAM pro PPU (128kiB), 2 bis 32 MBit Cartridge ROM" (aus http://de.wikipedia.org/wiki/Super_Nintendo) Das auf einem AVR zu emulieren, würde ich mich auch nicht trauen, wenn ich ein besserer Softwareentwickler wäre. Bei einem Emulator auf einem PC kann man zudem so mit Ressourcen klotzen, daß es nichts macht, wenn der Bildspeicher nicht direkt von Hardware ausgelesen wird. Auf einem Microcontroller sieht das vieleicht anders aus. Der Gameboy Advance hat einen ARM7. Den würde man vieleicht nicht mit einem AVR emulieren wollen. ciao Dirk
hab ich schon gemacht, infos kann ich auf wunsch zur verfügung stellen, tetris und mario world laufen dann hab ich das Interesse verloren.war nen mega16 mit 16mhz... greets jon
Hallo > Ein Emulator braucht ein vielfaches mehr an Rechenleistung als das > Original. Grundsätzlich ist diese Aussage sicher korrekt. Allerdings sind die AVRs in der Tat den ersten Nintendo-Prozessoren tatsächlich deutlich überlegen. Evtl. könnte man anstatt einen vollständigen Emulator zu schreiben, den Code der Spiele 'umcompilieren', so dass er direkt auf dem AVR läuft. Oder die Arbeit könnte von mehreren AVRs gemeinsam verrichtet werden. Gruss Michael
@jon bin interessiert! könntest du mir eventuell informationen schicken? und kurz mal posten kurzbeschreibung deines systems? mfg martö
An so etwas wär ich auch ausgesprochen interessiert. Gameboy zum selbstbauen. Insbesondere wie die Daten aus den Spielkassetten gespeichert werden und am Verfahren. In welcher Sprache ist dei Emu programmiert=
sowas hat schon jmd angefangen... http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2006/kwj5_mhw23/index.html die übersetzen nes code auf avr irgendwie mit ner riesigen lookup table. ist aber noch incomplete, deshalb haben sie nur die grafikkarte vorgestellt.
.. kleiner auszug ... Considering that an ATMega32 opcode is 2 bytes to the NES' 1-byte, this means that the translator generated on average 1.5 instructions for every instruction input. Since the NES was run at about 1.7 MHz and the ATMega32 runs at 16 MHz, this is an acceptable translation result as far as speed is concerned.
Hab mir das jetzt mal angeschaut! aber is auch nicht wirklich das was ich suche! Viel zu umständlich! Da muss es bessere Lösungen geben! JON seine würd mich interessieren wenn die wirklich so funktioniert wie er geschrieben hat.
Sorry, aber die Behauptung von jon will ich erst sehen, bevor ich das glauben kann. Alleine, dass ein GB schon mal 16 KiB Ram hat, macht ihn unglaubwürdig. Dazu noch so schöne Sachen wie Hardware-Sprites. Solange hier keine Beweise auftauchen: Attention whore! BTT: Ich glaube nicht, dass man einen Gamboy-Emulator mit weniger als einem ARM7 spielbar hinbekommt. Zum Vergleich: Auf einem 68040 @40 MHz war ein GB-Emu mit einem frameskip von 1 spielbar. SNES auf einem AVR ist echt mal ein Brüller. Dafür braucht man schon einige 100 MHz, damit es gut läuft.
Vielleicht kein sogenannter emulator sondern gleich ein direktumsetzter der befehle der alten cpu und den neuen atmel controller
Und wie bitte stellst Du Dir das vor? Mal abgesehen davon, dass der Mega16 noch nicht einmal die 16 KiB eines GB hat, würde ein JIT-Compiler noch viel mehr Speicher verbrauchen, wenn er denn schnell sein soll. Und HLE auf einem AVR ist auch illusorisch, da er selbst ja nur Low-Level ist.
auf einem AVR halte ich für ziemlich unwarscheinlich, dass man das emulieren kann, dafür ist zuviel hardware in so nem gb oder nes...sowas mit nem cpld oder fpga wäre sicher machbar
Ich glaube mit einem ARM 7 müsste das zu schaffen sein. wenn man das protokoll kennt. gibts da irgendwo seiten wo mann sich erkundigen kannn? hab schon gegoogelt aber nichts brauch bares gefunden
Ja mit ordentlich RAM dran... Was für ein protokoll? man könnte ja mal beim supplier nach nem data sheet fragen...
Ja, genau. Warum nicht gleich bei Nintendo nach dem VHDL Source fragen? Mit nem ARM und ordentlich Ram sollte es aber gehen. Sourcen von Emulatoren sollten sich ja auftreiben lassen. Stellt sich nur noch eine Frage: Warum sollte man sich soetwas antun?
frag ich mich auch, warscheinlich einfach nur weil er geizig ist, und sich keinen GB bei ebay kaufen will frech grins Ich fände ne GB lösung mit tv-out schon cool irgendwie aber die zeit dazu ist echt zu schade
Leute, ihr seit sooo geil! Vielleicht solltet ihr euch mal informieren, was ein Emulator und was ein Simulator ist. EIN EMULATOR BENUTZT IMMER EINEN TEIL DER ORIGIANLHARDWARE. Da das schon mit den einfachen Dingen wie Lesen und recherchieren nicht klappt, sehe ich für das Projekt schwarz. Ich habe schon mehrere Simulatoren geschrieben, und die Simulationshardware war 6 mal schneller als die Originalhardware, damit das klappt. Wenn man die Spezifikationen und Datenblätter der Originalhardware hat, dann ist das nur Fleißarbeit!
Vielleicht sollte man sich mal den GamePark 32 angucken. Darauf lief so ziemlich jede erdenkliche Konsole als Emulation. Selbst der SNES-Emulator wurde soweit optimiert, dass er letztendlich bei nem Prozessortakt von 133MHz lief. Dabei sollte man aber nicht vergessen, dass im GP32 ein ARM9 mit 8MB SDRAM werkelt. Der ließ sich bis etwa 166MHz übertakten und hatte auch schon nen Displaycontroller eingebaut. Für das NES sollte ein ARM7 tatsächlich reichen. Evtl. kann man die Sourcen vom GP32 für den ARM7 anpassen. Projekte für den GP32 gibts genug.
@lisa: What is VICE? VICE is a program that runs on a Unix, MS-DOS, Win32, OS/2, Acorn RISC OS, QNX 6.x or BeOS machine and executes programs intended for the old 8-bit computers. The current version EMULATES the C64, the C128, the VIC20, all the PET models (except the SuperPET 9000, which is out of line anyway), the PLUS4 and the CBM-II (aka C610). mmhh wenn doch vice auf nem unix oder windoof läuft, dann wäre es doch eher ein simulator, als ein emulator? dann kannst du doch nicht nur bei uns beschweren, dass wir nicht richtig lesen, sondern auch bei den ganzen leuten die sogenannte emulatoren veröffentlichen achso und bei wikipedia: Als Emulation (von lat. aemulari nachahmen) wird in der Computertechnik das funktionelle Nachbilden eines Systems durch ein anderes bezeichnet. Das nachbildende System erhält die gleichen Daten, führt die gleichen Programme aus und erzielt die gleichen Ergebnisse wie das originale System. Ein Emulator ist ein System, das ein anderes nachahmt. Zu unterscheiden sind Hardware- und Software-Emulatoren. da steht nix von originalhardware.
Ja klar, wikipedia hat immer recht! Deswegen üben die Piloten immer im Flugemulator...Wenn es keine Unterschiede zwischen Emulator und Simulator gibt, dann kann mal die wohl synonym verwenden. Mal im Ernst, nur weil die Bedeutung eines Worts in der Umgangssprache sich mit der Zeit ändert, hat man gerade als Ing. die Plicht, präzise Begriffe zu verwenden. Ich verweise hier auf IBM (die mit dem System/360 den ersten Emulator bauten): IBM's Early Computers [Bashe et al], A History of Modern Computing [Paul Ceruzzi]. Zusätzlich gibt es Anhaltspunkte unter "http://www.answers.com/emulator&r=67";, wobei die Qualität dieser Seite wohl ähnlich von Wikipedia ist. Heutzutage hören die Leute irgendwas, verstehen es halb und benutzen es dann unpräzise. Dass schreiben die einen Artikel in Wikipedia, und geben ihr Halbwissen an andere weiter. Nein Danke! (Ich will hier keinen beleidigen, aber ich hab heut nen schlechten Tag, also nehmt bitte meine Beiträge als sachlich hin).
Erstmal zum Projekt, eine Emulation des NES halte ich auf einem Prozessor, der weniger leistungsfähig als ein ARM7 ist, für reichlich unrealistisch. Zumal praktisch alle Systeme mit einem 6502-Derivat so exaktes Timing benötigen, daß für halbwegs gute Kompatibilität eine Single-Cycle-Emulation benötigt wird. Abgesehen davon dürfte es ein ziemlich aufwendiges und teures Projekt werden, wenn neben der reinen Emulation auch noch ein Farb-Display, Sound und ein Steuerkreuz anfallen. Wenn man wirklich einen portablen Emulator haben möchte, ist GP2X wahrscheinlich sogar die billigere Lösung. Im übrigen gibt es deswegen so viele NES-Emulatoren, aber sehr wenige wirklich gute, weil das Grundsystem zwar recht primitiv ist, recht viele Module dieses aber mit integrierter Zusatzhardware erweitern, die von den besseren Emulatoren als sog. Mapper behandelt werden. Zum Thema Emulator versus Simulator: So extrem einfach lassen sich die Begriffe nicht trennen, da sie sehr viele Überscheidungen haben und die Grenzen oft nicht ganz klar gezogen werden können. Ich persönlich sehe den Unterschied folgendermaßen: Ein Simulator ist meist genauer als ein Emulator, behandelt aber nur einen Teil des Gesamtsystems. Beispielsweise behandeln Simulationen moderner CPUs deren Caches und sogar die Pipeline, ein Emulator hingegen braucht diese Details zur reinen Ausführung der Applikationen nicht, wird aber normalerweise die CPU in ein emuliertes Gesamtsystem einbetten, damit der Originalcode überhaupt sinnvoll laufen kann. Eine andere Interpretation ist die von Marat Fayzullin, der mal schrieb, daß ein PacMan-Simuator sich nur wie der PacMan-Automat verhalten muß, während ein PacMan-Emulator mit einem Abbild des Original-ROMs läuft. Allein diese quasi gegensätzliche Ansicht sollte zeigen, wie problematisch die Definition der Begriffe ist. Zum Einwand, daß ein Emulator immer einen Teil der Original-Hardware verwendet: Ich glaube dabei sind wohl die virtuelle Maschine und die Emulation auf dem System 360 durcheinandergeraten. Bei der virtuellen Maschine wird wirklich die gleiche Hardwarebasis benötigt (wobei dieser Begriff über Bezeichnungen wie Java Virtual Machine leider auch schon aufgeweicht ist), während bei der ersten Emulation auf der IBM 360, bei der dieser Begriff auch geprägt wurde, der Microcode der CPU ausgetauscht wurde und damit also nicht wirklich die Originalhardware zum Einsatz kam. Inzwischen bin ich der Meinung, daß Simulation und Emulation je nach Einsatzgebiet unterschiedliche Bedeutungen haben können (siehe Unterschied zwischen CPU-Simulator und Flugsimulator), denn meine Definition hat mal jemand mit dem Begiff "Terminal-Emulation" sehr schnell ins wanken gebracht.
OK, diese Diskussion habe ich schon einmal miterlebt (und daraus gelernt). Ich zitiere aus der Originaldiskussion: An emulator is HARDWARE (usually but not always plus software/ firmware) which "emulates" (dictionary def.) some system or processor. Simulators are good, well written ones are great, and a bug free one is a piece of software "art", imho. But... they are NOT emulators... I only wrote this post because a few people I have seen on the 'net who wrote simulators are so (perhaps justifiably) proud of them that they call them emulators, insisting that their "emulator" is so good it's different. Well it isn't... it's software. (Calling a Goose a duck does not make it a duck; it's still a goose. Once a lot of people start calling geese ducks then they're well on the way to some real confusion...) This is only offered as my opinion: Calling a simulator an emulator brands one as an amateur... (which is okay of course). Es gibt Kataloge mit Emulatorbausteinen, jeder kostet über 1000, für Sachen, die sich nicht mit Software simulieren lassen. Wenn ein Gerät das OriginalRom verwendet, dann ist das kein Zeichen für Emulation. Solange die Originalinstruktionen umgewandelt werden, um auf dem Simulator zu laufen, ist es ein Simulator. VMWare ist ein Simulator, Java VM ist ein Simulator, beide mit Zugriff auf die darunterliegende Hardware. Ein Beispiel: Ich möchte PC-Programme auf meinem Microcontroller laufen lassen. Für jeden PC-Opcode schreibe ich eine Routine, die dasselbe auf meinem Microcontroller tut. Alle Register und Speicher simuliere ich mit Hilfe des Microcontrollers. Am Ende habe ich einen Simulator. Dann stelle ich fest, dass ich die Floating-Point operationen vergessen habe, und diese auch nicht mehr in meinen Programmspeicher passen. Deshalb hänge ich einen Pentium-Processor an meinen Microcontroller. Immer, wenn dann eine FLOP auftritt, sende ich diese an den Pentium-Chip, und hole das Ergebnis später ab. Da ich einen Teil der Originalhardware benutze, ist es nun ein Emulator. Beide Ansätze benutzen dasselbe ROM, nur ist einer ein Simulator und der anderer ein Emulator.
Lisa, Du bist hast vollkommen Recht. Alle doof außer Dich. ;-) Deshalb heißt "emulator" (engl.) auch "der Nachbilder". Und wenn man etwas nachbildet, braucht man das Original immer noch in Teilen. Is klar. Wenn Du Dich schon so viel besser mit Si- oder Emulatoren auskennst als wir, könntest Du ja auch was zum Thema beitragen. Nein? Das verbietet Dir Dein Ego? Danke fürs Gespräch.
> Ja klar, wikipedia hat immer recht! > Deswegen üben die Piloten immer im Flugemulator... Nach deiner Definition tun sie das. Denn in solchen Flugsimulatoren sitzt man im Allgemeinen im Original-Cockpit mit den Original-Displays und Schaltern und Knöpfen. Man benutzt also einen Teil des Originalsystems. > Mal im Ernst, nur weil die Bedeutung eines Worts in der > Umgangssprache sich mit der Zeit ändert, hat man gerade als Ing. > die Plicht, präzise Begriffe zu verwenden. Allerdings. Mir geht es immer auf den Senkel, wenn Leute von Bytes reden, obwohl sie Oktetts meinen, von binär, wenn dual gemeint ist oder von Bitmaps, wenn Pixmaps gemeint sind.
Wo wir gleich beim thema sind. ein Megabyte ist ja auch eigentlich nicht megabyte sonder mibibyte. 1 GB = 1024 MB 1 MB = 1024 KB 1 KB = 1024 Byte man kann schon anregen, dass vielleicht ein begriff falsch ist, aber im prinzip trägt das nicht zur lösung der frage bei, sondern es wird nur doofer laber draus, der immer länger wird und den author verärgert... Ich denke mit 3 avr und ein bisschen speicher ist das machbar. cpu, grafik und sound...
Wo wir schonmal beim Klugschiss sind: > 1 GB = 1024 MB > 1 MB = 1024 KB > 1 KB = 1024 Byte Nö: 1 GiB = 1024 MiB 1 MiB = 1024 KiB 1 KiB = 1024 Byte
Noch mehr Klugschiss: > ein Megabyte ist ja auch eigentlich nicht > megabyte sonder mibibyte. Nein. Mebibyte.
@Lisa: "Ich zitiere aus der Originaldiskussion" Zitate ohne Quellenangabe sind nichts, aber auch rein gar nichts wert, zumal Du nicht einmal angegeben hat, wer da meint, so einfach zwischen Amateuren und Profis unterscheiden zu können. Ich habe hier mal ein Zitat mit Quellenangabe: "Steward Tucker of IBM was saddled with the responsibility of porting software from the IBM 7090 to the new IBM 360. Thinking about the possibilities of microcode, he suggested expanding the control store to include simulators, or interpreters, for older machines. Tucker coined the term emulation for this, meaning full simulation at the microprogrammed level. Occasionally, emulation on the 360 was actually faster than on the original hardware." Patterson, Hennessy: "Computer Organizaton & Design", 2nd ed., 1998, p. 424. Daraus kann man herauslesen: 1. Emulation ist "komplette" (full) simulation. 2. Die erste Emulation war auf Microcode-Ebene realisiert. Da man heutzutage aber kaum noch die Möglichkeit hat, den Microcode eines Prozessors zu ändern, muß dies zwangsläufig auf die höhere Ebene der Instruktionen verlegt werden. Und falls Du die beiden Autoren des oben genannten Buches auch als Amateure abstempeln willst, die von nichts eine Ahnung haben, der eine ist der Vater von SPARC (Patterson) und hat nebenbei die Akronyme RISC und RAID erfunden und der andere ist der Vater der MIPS-Architektur (Hennessy). Aber klar, die können auch keine Ahnung haben... "VMWare ist ein Simulator" Um mal bei Deiner Ausdrucksweise zu bleiben: Du bist so geil! Vielleicht solltest Du Dich mal informieren! VMware ist eine Virtualisierung, weil 100% der Instruktionen von Applikationen und über 90% der Instruktionen des Betriebssystems direkt auf dem Prozessor ausgeführt werden. Daß es im letzten Fall nicht 100% sind, liegt daran, daß Intel bei der Architektur einen Fehler gemacht hat. Dieser wird aber bei Vanderpool (Intel) bzw. Pacifica (AMD) ausgemerzt, weswegen bis auf I/O alle Instruktionen direkt von der CPU abgearbeitet werden können. Das ist jetzt alles komplett am Thema vorbei, aber ich will hiermit nur aufzeigen, daß Deine Kategorisierung extrem zu wünschen übrig läßt. Mich würde echt mal interessieren, seit wann Du Dich eigentlich mit dem Thema Emulation/Simulation befaßt...
OK, dann mal was sinnvolles von meiner Seite:
Holt euch alle Informationen über Prozessoren usw., die man bekommen
kann. die dann zuerst durchlesen. Danach beginnt man mit einer
Implementierung auf dem PC, da dort die DEBUG-Möglichkeiten besser
sind.
Zuerst sollte man den Speicher un die Register simulieren. Dann
kommen die Operationen dran: Da gibt es zwei Möglichkeiten: Zum einen
kann man ein Array mit Funktionspointern erstellen, und über dieses
Array wird dann die konkrete Funktion aufgerufen. Das mach bei einer
späteren Portierung auf microcontroller meist keinen Sinn. Deshalb
schreibt man meist eine decode-funktion, die als parameter den opcode
hat. Diese kann Teile des Opcodes maskieren, und dann über eine große
SWITCH-Anweisung die Funktionen aufrufen.
Die Funktionen implementiert man der Reihe nach, zuerst erstellt man
nur Prototypen, damit es mit der Kompilierung klappt. Dann schrittweise
und genau nach Datenblättern implementieren.
Die Mainloop kann anfangs ganz einfach aussehen:
//Initialisierung...u.A. ProgramCounter setzen
P=0;
while(true)
{
opcode = getRom(P);
P++; //PC erhöhen
decode(opcode);
}
Zu dem increment des programcounters ist zu sagen, dass man den
entweder vor dem Ausführen der Operation oder hinterher inkrementieren
kann. Das ist immer durch die Originalhardware vorgegeben, wenn auch
oftmals nicht in den Datenblättern erwähnt. Dann muß man sich die
Codierung der Opcodes anschauen, und sieht das dann.
Zu den Datentypen: Auf der einen Seite kann es wünschenswert sein, die
originalregister in der originalwortbreite zu simulieren (z.B. beim
Programcounter, da man sich dann nicht um den Überlauf kümmern muß).
Bei arithmetischen Registern ist es manchmal nicht vorteilhaft, z.B.
wenn negative Zahlen anders dargestellt werden. Das muss man dann von
Fall zu Fall entscheiden, und vor allem gut dokumentieren.
Speicherzugriffe: Der Speicher wird oft als Array simuliert. Im
Hinblick auf Speichererweiterungen (die teilweise den Adreßraum
verändern) ist es anfangs vorteilhaft, nicht direkt auf das Array,
sondern über "getMem(adresse)" und "setMem(adresse,wert)"
zuzugreifen.
Ich wünsche dann noch viel Erfolg beim SIMULATOR!
Hier noch die Antwort auf Kritik an mir: 1. Da ja Zitate ohne Quellenangabe nichts sind, habe ich zufällig 2 Bücher von IBM als Beleg angegeben. Da diese schon recht alt sind, habe ich zusätzlich Zitate und Links beigefügt. 2. Leute, es ist mir wirklich egal, ob ihr jetzt das Teil Simulator oder Emulator nennt. Es mag ja sogar sein, dass in manchen Bereichen die Begriffe gleich verwendet werden. In den Bereichen, in denen ich mich damit beschäftigt habe, war da aber ein Riesenunterschied. 3. Wenn VMWARE ein Emulator ist, dann sollten sich alle Programme unter VMWARE ja genauso verhalten, wie ohne VMWARE. Das tuen sie aber nicht. Ich sage da nur mal "IV" (was vielleicht mit den 90% von dir gemeint ist). Ohne Quellenangabe, aber wer sucht, der findet. Und wenn alle Instruktionen meines Prozesses direkt auf der CPU ausgeführt werden, so ist mein Programm immer noch kein EMULATOR, und Windows/Linux genausowenig. Software ist Software, und damit kann man immer nur simulieren (wenn man bei der Definition des Simulators, wie ich die kenne, bleibt). 4. Wenn ich eine Definition eines Begriffes gelernt habe, und man mir eine Definition gibt, die meine Definition weiter einschränkt, dann mache ich mir doch zumindest mal Gedanken. Ich habe früher auch geglaubt Simulator = Emulator, aber die 2 von mir genannten Bücher und etliche Gespräche haben mich schnell belehrt.
> 1 GiB = 1024 MiB > 1 MiB = 1024 KiB > 1 KiB = 1024 Byte Prinzipiell finde ich die Unterscheidung gut. Ich weigere mich allerdings, diese so anzunehmen, weil es wie Babysprache klingt. "Und, wieviele Kibibit pro Sekunde hat deine DSL-Verbindung?"
@Lisa: "1. Da ja Zitate ohne Quellenangabe nichts sind, habe ich zufällig 2 Bücher von IBM als Beleg angegeben. Da diese schon recht alt sind, habe ich zusätzlich Zitate und Links beigefügt." WO? Also hier jedenfalls nicht oder ich brauche wirklich mal wieder eine neue Brille... "2. Leute, es ist mir wirklich egal, ob ihr jetzt das Teil Simulator oder Emulator nennt." Sicher, deswegen hast Du das Wort "simulieren" ja auch immer unterstrichen. Wen willst Du hier eigentlich veräppeln? "3. Wenn VMWARE ein Emulator ist" VMware is KEIN Emulator und auch KEIN Simulator! Es ist eine Virtualisierung, sicherlich keine vollständige im ürsprünglichen Sinn, aber das ist ein Problem der Architektur, die nicht für Virtualisierung ausgelegt war. Falls Dir der Begriff nichts sagt, dann schau mal in Deiner schlauen IBM-Literatur nach, denn da solltest Du auch fündig werden. "Ich habe früher auch geglaubt Simulator = Emulator" Ich glaube definitiv nicht, daß Simulator und Emulator das gleiche sind (rein linguistisch gesehen gibt es ohnehin keine echten Synonyme), aber die Grenze ist definitiv nicht so einfach zu ziehen, wie Du es Dir machst. Du behauptest, daß Emulation nichts mit Software zu tun hat. Aber was ist denn Microcode anderes als ein Programm und damit Software? Und genau so wird die erste Emulation von Hennessy und Patterson beschrieben, aber die Entwickler von zwei der bekanntesten RISC-Architekturen sind natürlich unwissende Blödmänner im Vergleich zu Dir! "aber die 2 von mir genannten Bücher" Welche Bücher? Entweder ich bin wirklich blind oder Du hast bei Deinen Ausführungen echt was vergessen... "und etliche Gespräche haben mich schnell belehrt." Hmm, dann scheinen Deine damaligen Gesprächpartner mehr Überzeugungskarft gehabt zu haben als Du. Wahrscheinlich waren sie auch etwas höflicher und haben Dich nicht gleich als Dummkopf hingestellt. Zumindest habe ich bisher keinen Grund, warum ich Deiner "Argumentation" irgendeinen Glauben schenken sollte.
Also, hier nochmal die von mir genannten Quellen (siehe oben):"Ich verweise hier auf IBM (die mit dem System/360 den ersten Emulator bauten): IBM's Early Computers [Bashe et al], A History of Modern Computing [Paul Ceruzzi]". Für die zitierte Diskussion gebe ich keine Quellen an, das natürlich jeder dann die Kompetenz dieser Personen anzweifeln kann. Ich will hier keinen veräppeln, denn diese Diskussion kostet Zeit, und rein zum Spaß mache ich das hier nicht. Zum Thema Höflichkeit: OK, ich hatte gestern einen schlechten Tag, und mein Ton war vielleicht etwas scharf. Aber ich finde es erstaunlich, mit welcher Arroganz hier die Leute reingehen: "Ich möchte einen Emulator bauen, habe aber keine Ahnung. Wer sagt mir, wie das geht?". Und Michael, ich will dir ja nicht zu nahe treten, oder deine Qualifikation anzweifeln, aber aus deinen Reaktionen sehe ich, dass du noch nicht allzulange im Berufsleben stehst. Frauen sind da etwas empfindsamer, bzw. Männer in Deutschland haben da kein Gefühl, wohingegen in anderen Ländern viel Wert darauf gelegt wird. Und noch ein abschließendes Wort zum Thema Flugsimulator: Wenn man ein Flugzeug mit einem Rechner vergleicht, dann ist das Cockpit wohl so etwas wie die Eingabe/Ausgabe, wohingegen der Prozessor wohl am Besten durch die Triebwerke und Seitenruder dargestellt wird. Wenn ich meinen Monitor und meine Tastatur an einen neuen PC hänge, dann habe ich weder eine Simulation noch eine Emulation des alten Rechners.
> Wenn ich meinen Monitor und meine Tastatur an einen neuen PC > hänge, dann habe ich weder eine Simulation noch eine Emulation des > alten Rechners. Schlechte Analogie. Immerhin hänge ich das Cockpit nicht an ein anderes Flugzeug, sondern an eine Anlage, die versucht, ein Flugzeug möglichst gut nachzuahmen und dazu auch die Eigenheiten des Cockpits nutzt. Ein Fluzgeugcockpit ist auch nicht gerade ein ganz alltägliches Computer-Ein-/Ausgabegerät, wie eine Tatatur und ein Monitor, sondern schon etwas recht spezielles, das normalerweise nur für das zu Simu-/Emulierende System genutzt wird.
@Lisa:
"Also, hier nochmal die von mir genannten Quellen"
Entschuldigung, aber die habe ich in dem Fließtext wirklich übersehen.
Solche Dinge kann man auch entsprechend formatiert besser herausheben
(eine brauchbare Darstellung sollten Ingenieure übrigens auch
beherrschen, aber auch das läßt seit einigen Jahren immer mehr zu
wünschen übrig):
* Bashe, et al: "IBM's Early Computers", 1985.
* Paul Ceruzzi: "A History of Modern Computing", 2000.
So sieht eine brauchbare Quellenangabe aus. Im übrigen bin ich
überrascht, wie "neu" die Bücher sind. Als Du geschrieben hast, daß
Du Dich auf IBM beziehst, hatte ich hier Texte von 1965 bis 1970
erwartet.
Als ich mal die Unterscheidung zwischen Architektur und Implementierung
wissen wollte, habe ich mir eine Kopie des Originalartikels über das IBM
System 360 aus dem Jahre 1964 besorgt, soviel dazu, daß es mit dem
"recherchieren nicht
klappt". Da könntest Du Dich übrigens auch gleich aufregen, daß Intel
ständig neue Architekturen vorstellt, obwohl es eigentlich nur neue
Implementierung der gleichen veralteten Architektur sind.
"Für die zitierte Diskussion gebe ich keine Quellen an, das natürlich
jeder dann die Kompetenz dieser Personen anzweifeln kann."
Na, entweder wirst Du es in einer anderen Diskussion selber geschrieben
haben oder jemand anderes, den niemand kennt. Aber wie gesagt, ohne
Quellenangabe sind Zitate immer etwas zweischneidig.
"Herr Richter, mir hat jemand erzählt..."
"Einspruch! Hörensagen!"
"Stattgegeben."
Mal abgesehen davon, bist Du auf mein Zitat, das immerhin von zwei
namhaften Personen stammt, die eigentlich jeder, der sich mit
Rechnerarchitektur beschäftigt, kennen sollte, überhaupt nicht
eingegangen.
Lügen die jetzt in ihrem Buch oder kam bei dem ersten Emulator etwa
doch keine Originalhardware zum Einsatz? (Denn letzteres ist in dem
Zitat definitv nicht erwähnt und aus meiner Sicht sogar ausgeschlossen,
es sei denn Du siehst den Microcode als Hardware an.)
So lange Du hier auf den Versuch einer sachlichen Diskussion nicht
eingehst und keine gegenteiligen Zitate aus Deiner allwissenden
Literatur zum besten bringst, sondern nur mit hohlen Behauptungen
("Emulation beinhaltet immer die Originalhardware Punkt") und
idiotischen Vergleichen ("Eine Ganz ist keine Ente!" - Ach!) glänzt,
erfüllst Du so ziemlich genau die Definition eines Forum-Trolls.
"Aber ich finde es erstaunlich, mit welcher Arroganz hier die Leute
reingehen: "Ich möchte einen Emulator bauen, habe aber keine Ahnung.
Wer sagt mir, wie das geht?"."
Anscheinend hast Du mit diesem Thema im Internet nicht ganz so viel
Erfahrung gesammelt, ansonsten wüßtest Du, daß ständig irgendjemand
fragt "Hey, warum kann ich eine PS2 nicht richtig emulieren, beim
Gameboy klappts ja auch". Wenn ich mich wirklich über jeden aufregen
würde, der die Komplexität dieser Thematik komplett unterschätzt, dann
hätte ich schon vor einer halben Ewigkeit einen Herzinfarkt gehabt...
Früher gab es mal die Faustregel, daß das emulierende System etwa
10-fach schneller sein sollte als das emulierte. Durch einige
Beschleunigung bei der CPU-Emulation (beispielsweise durch "threaded
interpretation" oder "binary translation") ist das zwar prinzipiell
besser geworden, aber dafür sind die Ansprüche bei der Emulation von
Grafik und Sound in den letzten Jahren deutlich gestiegen. Im Endeffekt
bin ich der Meinung, daß die Faustregel immer noch recht gut paßt.
"Und Michael, ich will dir ja nicht zu nahe treten, oder deine
Qualifikation anzweifeln, aber aus deinen Reaktionen sehe ich, dass du
noch nicht allzulange im Berufsleben stehst."
Ich arbeite seit über 20 Jahren mit Computern und beschäftige mich fast
genauso lange mit Emulatoren (sowohl denen, die Du als Simulatoren
bezeichnen würdest, als auch solchen, die mit einem Originalprozessor
arbeiten). Im Berufsleben bin ich seit ca. 9 Jahren unterwegs. Ich bin
hier sicherlich nicht der Älteste, aber ganz bestimmt nicht der
Jüngste.
Was meine Qualifikation betrifft, nein ich habe noch keinen eigenen
Emulator/Simulator entwickelt, aber ich könnte, wenn ich wollte. Viel
interessanter finde ich seit einiger Zeit aber das Thema der
"dynamischen Recompilierung" (wobei ich in dem Fall "dynamische
Binärcodeübersetzung" treffender finde).
Leider voller Rechtschreibfehler (weil ich es ziemlich schnell nebenher
heruntergetippt habe) und auch etwas veraltet, weil es inzwischen 4
Jahre her ist:
http://forums.ngemu.com/web-development-programming/20491-dynamic-recompilation-introduction.html
"Frauen sind da etwas empfindsamer, bzw. Männer in Deutschland haben
da kein Gefühl, wohingegen in anderen Ländern viel Wert darauf gelegt
wird."
1. Ein Frauenname im Internet deutet nicht zwangsläufig auf eine Frau
hin, weswegen ich alle Poster gleich behandle. Merke:
GIRL = Guy In Real Life
2. Wie heißt es so schön:
- "Wie man in den Wald hineinruft, so schallt es hinaus."
- "Behandle andere so, wie Du selbst behandelt werden willst."
Deine Auffassung, "Hey, heute habe ich mal einen schlechten Tag, also
darf ich alle mal wie Idioten behandeln" geht da schnell nach hinten
los.
"Und noch ein abschließendes Wort zum Thema Flugsimulator"
Nicht alles was hinkt ist ein Vergleich...
Wie gesagt, ich bin inzwischen der Meinung, daß man bestimmte Wörter,
die in unterschiedlichen Fachbereichen verwendet werden, nicht alle
gleich interpretieren sollte.
Der Ausdruck "Morphologie" beispielsweise findet sowohl in der
Biologie als auch in der Linguistik Verwendung, hat zwar eine ähnliche
Grundidee, aber definitiv nicht die gleiche Bedeutung.
Am Ende habe ich noch einen Literaturtip:
James E. Smith, Ravi Nair: "Virtual Machines", 2005.
Das zweite Kapitel heißt "Emulation: Interpretation and Binary
Translation", handelt also eigentlich von dem, was Du als Simulatoren
bezeichnen würdest.
Für Dich wäre dabei aber die Funktionsweise von sog. "System Virtual
Machines" (Kapitel 8) interessant, damit Du mal verstehst, warum
VMware kein Emulator oder Simulator ist, obwohl Du das Konzept der
Virtualisierung eigentlich von der IBM 360 kennen solltest.
Sagt mal, kann es sein, daß diese Diskussion sich überhaupt nicht mehr um das eigentliche Thema dreht? Hier will jemand ein Ding bauen, das sich -auf welche Art auch immer- verhält wie ein Gameboy, und ihr brecht eine Diskussion vom Zaun, ob das jetzt Emulation oder Simulation wäre. Das ist doch scheissegal, jeder, der nicht völlig vergeistigt ist, sollte doch kapiert haben, worum es Martö geht, oder etwa nicht?! Die Diskussion jedenfalls ist reine geistige Onanie.
> Das ist doch scheissegal, jeder, der nicht völlig vergeistigt ist, > sollte doch kapiert haben, worum es Martö geht, oder etwa nicht?! > Die Diskussion jedenfalls ist reine geistige Onanie. das dürfte zweifellos stimmen - aber, um ehrlich zu sein - ich habe den kompletten Thread mit gelesen und fand diese Diskussion durchaus unterhaltsam ;-) Ciao, Fabian
Jetzt mal eine themenbezogene Frage: Was für ein Nintendo-Gerät soll denn nun eigentlich emuliert werden? Denn irgendwie wurde das nicht wirklich präzisiert... Gameboy: Hat ein Z80-Derivat (erinnert mich ohne den Schattenregistersatz aber immer eher an einen 8080) und ist nicht wirklich der Hardware-Hammer. Auf einem 30MHz ARM610 lief ein Gameboy-Emulator ganz brauchbar, aber ob ein 8-Bit Mikrocontroller dafür ausreicht, bin ich mir nicht ganz sicher. Ist ja auch immer eine Frage des vorhandenen Speichers, etc. NES: Hat zwar nur ein 6502-Derivat, das man aber aus Gründen der Kompatibiliät besser zyklusgenau emulieren sollte. Dazu kommen dann noch Grafik und Sound, die eigentlich leistungsfähiger als beim Gameboy sein sollten. Wenn es wirklich auf Kompatibilität ankommt, sollte man die ganzen Mapper nicht vergessen, und dann wird es richtig aufwendig. Im übrigen habe ich immer noch keinen einzigen NES-Emulator gefunden, der Elite korrekt hinbekommt. Kann jeder mal selber ausprobieren, da das Spiel inzwischen Freeware ist: http://www.iancgbell.clara.net/elite/ SNES: Der 65816 mag nur 3,5MHz haben, aber man sollte das Komplettsystem nicht unterschätzen. Der Soundchip wurde entwickelt von Ken Kutaragi (dem Vater der Playstation, als er noch brauchbare Hardware machte) und scheint doch recht leistungsfähig zu sein. Der Grafikchip kann rotieren und skalieren, worüber auch Pseudo-3D-Effekte erzeugt werden. Um das Gerät mal in Relation zu setzen: Der direkte Konkurrent damals ware das Sega Megadrive mit einem 8MHz 68000er, einem Z80 als Soundcontroller, einem PSG und zwei Grafikchips, dennoch hatte das SNES in einigen Fällen die bessere Grafik. Viele SNES-Spiele wurden mehr oder weniger autentisch auf den GBA portiert, wobei dieser einen 16MHz ARM7TDMI hat. Zur Emulation vom SNES benötigt man definitiv einen ARM mit mindestens 100MHz. Ich bin mir jetzt nicht mehr ganz sicher, ob ich auf meinem Acorn RiscPC mit 200MHz StrongARM einen brauchbar laufenden SNES-Emulator hatte oder nicht. Neben der reinen Emulation wäre bei so einem Projekt dann ja auch noch die Hardware-Seite. Ich bin mir nicht ganz sicher, was es momentan an Soundchips gibt und ob man eventuell Grafikchips bekommt, die einem etwas Arbeit abnehmen könnten. VGA-Displays sollten aber immer noch nicht besonders billig sein. Alternativ könnte man natürlich auch versuchen, "einfach" die Hardware als Handheld nachzubauen. Ich glaube für den Atari 2600 hat das schonmal jemand gemacht.
Als einzigst sinnvoll und mit einfachen Mitteln technisch machbar erachte ich den Gameboy. Vorteile hier sind: * Kein Farbdisplay nötig und niedrige Auflösung bei den anderen wirst du ein TFT in der größe nur schwer beschaffen können und wenn dann nur mit analoger ansteuerung und sehr teuer. * Relativ einfache Emulation - Sollte ein ARM7 packen * Kleine Modulgrößen, maximal 2MB Nun frag ich mich, wo du das Spiel unterbringen willst - da wirst du einen großen ARM7 mit externem speicher brauchen. Am besten wäre es die original Gameboy module benutzen zu können - da musst du erstmal einen passenden schleifkontakt finden (hab ich bei einem großen Steckverbinder-Hersteller schon mal gesehen). Ansonsten, wenn du es noch einfacher haben willst kannst du ja versuchen den Pokemon Mini zu emulieren, der ist auch von Nintendo, hat nur 512kB große Module und nur 4kB RAM - das würde alles in einen ARM7 mit 1MB flash speicher passen (von TI zB) :-) Mit AVR kannst es ganz vergessen, damit kannst du vielleicht einen Chip8 "emulieren" ;)
Jetzt gebe ich auch noch meinen Senf zum Vergleich Emulator/Simulator dazu. Forderung an den Emulator: Er muß das zu emulierende System nahezu 100%-ig nachbilden. Originalhardware ist hierzu nicht zwingend erforderlich. Siehe Prozessorentwicklung. Forderung an den Simulator: Das Ergebnis muß gleich dem Ergebnis des Originalsystems sein, muß nicht den gleichen Zeitlichen ablauf haben. Es muß aber Möglichkeiten geben, den normalen Abfauf zu beeinflussen. Siehe Software-Simulator für Mikrocontroller am PC. Gruß Manfred
Ein interessanter Controller für solche Aufgaben ist der Propeller von Parallax. Er besitzt 8 Cores in denen dann sehr gut die einzelnen Spezialchips eines solchen Gerätes wie des NES, C64 etc. simuliert werden können. Hier die Homepage des Propellers: http://www.parallax.com/propeller/index.asp Und einer hat sich bereits daran gesetzt, einen kompletten C64 Emulator darauf zu programmieren: http://forums.parallax.com/forums/default.aspx?f=25&m=130455 Gruss Johnny
Öhh... man könnte ja versuchen den Pokemon Mini zu emulieren: http://pokeme.shizzle.it/ Aber selbst das ist für nen AVR unmöglich (hatte ich schonmal überlegt). Man braucht sowas um die 30 MIPS, und entsprechend viel speicher (denke mal so 16kB RAM und 1 MB ROM). Da kommt eigentlich nur ein ARM in frage. Würde mich freuen falls das jemand machen möchte :-P
Sorry, bitte outet mich nicht gleich als kontraproduktiv... aber was soll das alles? Ich mach auch gerne viel selber, auch wenn's sowas schon gibt! Ich würde z.B. nie in die Verlegenheit kommen, eine LCD Lib zu verwenden, die ich hier oder sonstwo gedownt hab! Aber warum muss man denn eigentlich nen GB emulieren? Mal von der Tatsache abgesehen, dass es sich Spiele-technisch absolut nicht lohnt!? Wenn man was emulieren will, dann macht man es doch so, dass man nachher auf dem PC GB und NES und SNES zocken kann oder nicht!? Wenn es tragbar sein muss, dann nehm ich nen Z80 und nen Display (woher auch immer) und lass den original Code laufen! Oder ich kauf mir nen GB für 5€ bei ebay! Ich persönlich halt sowas für vertane Zeit! Auch XBOX oder so, bei heutigen CPU Preisen lohnt sich sowas nichtmal fürs Hobby und man wird schnell Opfer hässlichen umcodierens. Um zum Eigentlichen zurückzukommen: ein Mega16 kostet nicht viel weniger, als ein Mega128 und der kann (evtl. mit ext. RAM) LOCKER nen GB nachbilden! Viel Spaß beim Xlaten
Angehängte Dateien:
Angaben Ohne Gewähr: Der 1st-Stage Bootloader(-Core) der Tegra-CPUs wurde auf Jetson Boards mittels "Glitching" gehackt - und der Bootcode Ausgelesen! Mittels USB-Paketen (DMA-Overflow im Recovery Mode) wurde dann an der Nintendo Switch, die eine fast ähnliche CPU hat, der Stack verändert, sodass dort selber Code ausgeführt werden kann. ... ... [...] Da die Switch ARM-Cores hat, ist es möglich, Switch-Games auf einem (Android-Phone oder) Raspberry auszuführen. Mit OpenGL4.6 / Vulkan1.1(?) + "skyline-emu" was ja scheinbar auf einem PI4 geht. ... ... [...] Dann kamen Chips und Modder-Kabel (Hacking-Kits) für die Nintendo Switch auf den Markt - unter anderem(?) von einem Herrn "Gary Bowser"! (Name gleicht dem finalen Endgegner von "SuperMario") - um jeden Homebrew zu ermöglichen ... Und was jetzt? Nintendo glaubt, ~60 Millionen $ verloren zu haben und drückt 40 Monate Haftstrafe, sowie +14 Millionen Dollar "Schadensersatz"-Zahlung innerhalb von sechs Monaten auf. ...(?) ... [...] ~25% des Einkommens soll er FÜR DEN REST SEINES LEBENS abdrücken! Freiheitsstrafe wurde schon vorzeitig beendet :-) Das wollte ich nur mal irgendwo loß werden. Mal sehen wie es weiter geht - vor allem bei den Hackern, die schon ein Switch 2 Devkit besitzen. #kick-proprietarys
:
Bearbeitet durch User
Wolfgang R. schrieb: > Völlig wirr und in einem seit 13 Jahren toten Thread. Gratulation! Danke! :-) Das war aber nur Simuliert.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.