www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 6502 / 6510 (C64) Emulator (momentan noch PC, später Controller) - Einige Fragen


Autor: Nils S. (kruemeltee) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe vor kurzem einen sehr einfachen 6502 Emulator in C im Quellcode 
gefunden, siehe hier 
http://www.zophar.net/6502/no-name-6502-emulator.html .

Der Code stammt anscheinend "irgendwo" her, keiner weiss wo und der 
Autor dieses Archivs hat ihn übernommen und verbessert.
Ich habe meine Hände am Emulator selbst nicht dran gehabt, sondern ein 
Programm aussenrum geschrieben, um ihn benutzen zu können.

Aufgebaut ist das ganze so:
Ich habe zwei Threads und die ganzen Emulator-Funktionen in den C-Files. 
Der eine Thread stellt die CPU dar, der andere ein Monitor-Programm.

Beim Starten des Hauptprogramms lädt er den Inhalt der Datei "data.img" 
ins RAM (max 64kb).
Die data.img ist ein 1:1 Abbild eines 6502 RAMs/ROMs, also nur die 
opcodes/operanden/daten, kein Format wie ihex, srec o.ä.

Dann startet er die Threads, die ungefähr so aussehen (ganz 
vereinfacht):
cpu_thread() {
      while(1) {
      warte_auf_ok_vom_monitor_für_nächsten_schritt();
      führe_nächsten_schritt_aus();
      }

}

monitor_thread() {
      while(1) {
      warte_auf_user_input();
      entscheide_was_zu_tun_ist();
      tu_es();
      }

}

Das Programm läuft soweit mal, dass man was sehen kann. Die data.img, 
die Dabei ist, habe ich von Hand mit dem Hexeditor und ein Liste der 
Opcodes gebastelt. Wenn du ein paar Schritte weitersteppst, sieht du 
gleich, dass X und Y rauf und runter gezählt werden, mehr macht das 
Programm nicht, gerade mal 10bytes gross.

Mit 'h' im Monitor kommt eine kleine Hilfe.

So nun zu meinen Fragen.

Wenn ich sämtliche printfs und auf "dauerlauf" ohne durchzusteppen 
umändere, komme ich auf meinem Rechner (1.6ghz) auf ca. 130-140mhz für 
meine 6502 cpu. Da das viel zu viel ist (C64 = 985khz), muss ich das ja 
irgendwie stoppen. Das einfachste scheint mir eigentlich, erstmal rennen 
zu lassen und dann zeitlich richtig Audio/Video/IO usw zu machen.
Aber da ich früher oder später einen kompletten C64 nachbauen will, der 
auch Hardware-Kompatibel sein soll würde ich das eher so machen:
In dem CPU thread beim ausführen eines Befehls die Zeit messen und 
solange warten bis die Zeit für die benötigten MZ bei 985khz vergangen 
ist.

Was meint ihr dazu? Oder ganz andere Ansätze?



Den Chip zum Nachbilden eines C64. Ich habe hier noch ein mini2440 mit 
3,5", das würde sicher reichen um das zu machen. Doch irgendwie ist es 
mir auch zu Schade dafür, kann ja für viel mehr herhalten.
Ich hatte auch noch ein etwas älteres Board, ein DNP/1486, ist ein 486er 
mit 33mhz.
Auf der Seite des Emulators an sich steht ein 486er/100mhz schafft ca 
3mhz auf dem 6502. Nun würde das nahezu hinhauen die Geschwindigkeit vom 
C64 zu schaffen.
Allerdings habe ich bedenken, dass das noch funktioniert, wenn man die 
restliche Hardware noch in Software fertigstellt.

Da das DNP/1486 weder Audio noch Video hat, würde ich einen richtigen 
SID für die Audio Ausgabe und eine "Controller-Grafikkarte" 
anschliessen, so viel mehr hat dann das Board mit dem Simulator auch 
nicht mehr zu tun.
Wenn ich das so machen sollte, was meint ihr ist am besten geeignet für 
die Videoausgabe? Können muss es im Grunde nichts super-tolles, siehe 
hier
http://de.wikipedia.org/wiki/Commodore_64#Grafik
Ich denke mit 320x200px@16 Farben, jedes Pixel einzeln ansteuerbar kommt 
man da gut hin, die Textmodi, Sprites usw kann man ja in Software 
machen, entweder auf dem Grafik-Controller/Grafikkarte/wasauchimmer oder 
im Simulator.
Ich würde da am ehesten einen Parallax Propeller nehmen oder eine 8bit 
ISA VGA Karte, wobei ich aber lieber TV-Out habe.


Im Anhang ein Screenshot vom Monitor mit dem kleinen Beispielprogramm 
nach ein paar Takten und ein Archiv mit meinen Quellcodes, dem 
veränderten Simulator, dem originalen Simulator, der Beispieldatei 
(data.img) und compiliertem Simulator für Linux.
Wer gcc drauf hat, sollte das Problemlos mit "make" compilieren können.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In dem CPU thread beim ausführen eines Befehls die Zeit messen und
> solange warten bis die Zeit für die benötigten MZ bei 985khz vergangen
> ist.

Es ist sinnvoll, solche Emulationen mit korrekter Zeit ablaufen zu 
lassen, weil viele Programme damals takzabhängig programmiert wurden.

Aber man will ja auch Deinge nebenbei machen, z.B. Umkopieren des 
Bidlschirmspeichers auf den echten Bildschirm.

Daher eine Methode die ich mal implementiert hatte: Jeder Befehl zählt 
auch, wie lange er gedauert hätte (zumindest ungefähr, also ich hab's 
nicht operandenabhängig gemacht, denn so genau kommt's nun auch nicht 
drauf an (ausser bei Apple ][ Disketten-Operationen aber das geht auf 
dem PC eh nicht)). Erreicht der Zähler 55 Millisekunden, die Zeit des 
damaligen timer ticks auf dem PC, wurde der Emulator gestoppt bis der 
nächste timer tick kam.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Emulator hat ein Array in dem die benötigten MZ für jeden 
Befehls gespeichert sind, würde das dann wohl so machen:

1. schaue auf die uhr
2. hole opcode,operanden / führe aus
3. rechne aus wieviel zeit auf dem echten 6502 drauf gegangen wär
4. schaue uhr/warte solange bis die zeit von schritt 3 erreicht ist

das dann direkt in dem Thread der die CPU darstellt.
Meinst du dass das so sinnvoll ist? Oder sollte ich schauen dass ich 
jeden Maschinen-Befehl solange dauern lasse wie im Original? Was ich 
aber nicht so rasend finde, so wäre kaum Platz noch was in den CPU 
thread nachträglich zu basteln. Und so hätte auch noch eine recht 
einfache Möglichkeit die Geschwindigkeit der CPU zu verändern, im 
laufenden Betrieb. z.B. auf die NTSC Version (geringfügig schneller) 
umzuschalten oder einen "free-running-modus".

Das kopieren in den Bildschirmspeicher usw würde ich über ein Flag 
gesteuert zwischen Schritt 4 und dem nächsten Schritt 1 in der Wartezeit 
über einen weiteren Thread machen.

Autor: asd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht was du vor hast, aber schau dir auch den VICE an. Ein 
fast perfekter C64/128 Emulator auf dem sogar viele Spiele laufen die 
mit Splitsceen oder ähnlichen Grafiktricks gearbeitet haben. Code sollte 
auch offen sein und evtl. gibt auch noch aktive Entwickler die man 
kontaktieren kann.

Autor: Tom M. (tomm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erinnert mich an einen interessanten Vortrag zu Reverse Engineering der 
6502:
http://events.ccc.de/congress/2010/Fahrplan/events...

Video gibt's hier:
http://events.ccc.de/congress/2010/wiki/Conference...

hmm wo bleibt das Video zum Vortrag?

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Momentan gehts darum die CPU nachzubilden, da kommt man mit einem 
Datenblatt weiter als mit Quellcode zu einem Simulator, später dann 
wenns darum WIE die "Hardware" simulieren+anbinden, momentan bin ich 
noch nicht so weit.

@Tom.M: diesen Java-Chip-Simulator, welcher auf der Wikiseite abgebildet 
ist hab ich mir sicher 3 Stunden angeschaut, das ist total genial :) Mal 
anhören und vlt. Kommt ja noch ein Video.

Autor: Peter Pippinger (uncle-sam7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin ja auch gerade dabei einen 6502 Emulator in Arm7 Assembler zu 
schreiben. Mein MC läuft mit ca. 50 MHz. Dem SID habe ich (bzw. Frank 
:-)) einen 1MHz Oszillator gespendet. Bei jedem Befehl zähle ich mit, 
wieviel Takte verbraten werden. Dabei sollte man auch bedenken, dass es 
Befehle gab, die bei "grenzüberschreitenden" Speicherzugriffen 
extra-Takte benötigten. Der 1MHz Oszi hängt sowohl am SID als auch am 
MC. Ich warte dann einfach die Takte ab, die die 6502 gebraucht hätte... 
In der Zeit kann ich dann auch noch mein Display refreshen und Taster 
abfragen.

op_a9:                // LDA #$xx
  r5_imm      // get address for #$xx into r5
  ldrb r10, [r5]    // get value from #$xx into r10 (A)
  affect_nz r10    // calculate affected flags
  add r8, r8, #2    // program counter
  add r7, r7, #2    // 2 clock cycles
  b drive_cpu

Was ich an der ARM Variante super finde: 64KB SRAM / viele Register

hab mir ne Sprungtabelle gebastelt, wo die ganzen Adressen für die 
Opcode-funktionen liegen. Läuft bisher super. Allerdings hab ich noch 
ein paar Befehle zum Übersetzen...

Als Grundlage nehm ich erst mal:
http://www.c64-wiki.de/index.php/%C3%9Cbersicht_65...

Den Audio-Out Schaltplan vom Sid zum Stecker fand ich hier:
http://www.zimmers.net/anonftp/pub/cbm/ALLFILES.ht...

So, jetzt muss ich noch ein paar Opcodes "übersetzen".

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dem SID habe ich (bzw. Frank :-)) einen 1MHz Oszillator gespendet. Bei >jedem 
Befehl zähle ich mit, wieviel Takte verbraten werden.
Also ich bin gerade dabei es so zu machen, dass ich die simulierten 
Befehle vollgas rennen lasse und in meiner cpu-schleife dann abwarte.
Ich habe ein Array in diesem Simulator, welches die Takte hält und mit 
denen rechne ich mir aus, wie lange ich noch warten muss bis der nächste 
op ausgeführt werden darf, ob die CPU dann nun mit 0.985 oder 1.15mhz 
rennt - drauf geschissen und ein wenig dran rumschrauben kann man ja 
immer noch ;)

>Dabei sollte man auch bedenken, dass es Befehle gab, die bei 
>grenzüberschreitenden" Speicherzugriffen extra-Takte benötigten.
So wie ich das sehe, beachtet dieser Simulator diese Takte nicht, bin 
mir aber nicht ganz sicher. Auf jeden Fall, führt er schonmal 6502 Code 
aus, das ist vorerst das wichtigste.

>Was ich an der ARM Variante super finde: 64KB SRAM / viele Register
Ich hab mich nun auch fürs Board so ziemlich entschieden. Ein DilNetPC 
DNP/1486. 33mhz, 2mb flash, 8mb ram, ethernet, seriell, 20 IO (8 davon 
5V tolerant, rest 3v3), ...
Und dieses Board hat anscheinend auch nen 16bit ISA Bus, nur hab ich das 
irgendwie noch nicht gefunden, habe aber auch keine wirkliche 
Dokumentation zu dem Board. Ich werd die Tage mal beim Hersteller SSV 
anrufen und nachfragen ob die mir da noch was haben, denke aber mal ja. 
Dann kommt da nämlich eine VGA Karte dran, ne ET4000 mit >512k Video 
RAM, da hab ich dann schonmal fürs Bild gesorgt.
Hier mal ein Überblick über das Board: 
http://www.dilnetpc.com/dnp0001.htm

SID soll ein echter drankommen, habe noch einen 64er mit kaputten CIA 
hier, der wird dafür geschlachtet.

Ich hab die Tabelle hier zum Spicken 
http://www.atarimax.com/jindroush.atari.org/aopc.html

Autor: Peter Pippinger (uncle-sam7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils S. schrieb:
> Also ich bin gerade dabei es so zu machen, dass ich die simulierten
> Befehle vollgas rennen lasse und in meiner cpu-schleife dann abwarte.
> Ich habe ein Array in diesem Simulator, welches die Takte hält und mit
> denen rechne ich mir aus, wie lange ich noch warten muss bis der nächste
> op ausgeführt werden darf, ob die CPU dann nun mit 0.985 oder 1.15mhz
> rennt - drauf geschissen und ein wenig dran rumschrauben kann man ja
> immer noch ;)

ja, mit Vollgas laufen die bei mir auch. Und am Ende wird entschieden, 
was mit der übrigen Leistung passiert. Die C-Version des Emulators, der 
schon SID-Files abspielt, arbeitet auch mit diesen Arrays (Opcodes, 
Speicherzugriff und Timing). Was mir daran nicht gefällt, ist dass die 
Zugriffe aufs Array auch Zeit benötigen. In Assembler arbeite ich jetzt 
alles mit Makros um. Die 256KB EEPROM des ARM verkraften das :-) So wie 
ich das verstanden habe, möchtest Du doch einen kompletten C64 
"abbilden", oder? Ich denke, wenn Du auch was anderes als den Textmodus 
betreiben möchtest, dann ist das Timing nicht egal. Aber wenn Du 
wirklich auch Kompatibilität hinbekommen möchstes, dass wird´s schon 
schwierig. Was mich z.B. an den aktuellen Emulatoren stört, ist dass es 
noch keiner hinbekommen hat 50 Hz absolut Synchron auf dem Bildschirm 
auszugeben. Ich weiß schon, dass 50Hz nicht auf jedem Monitor 
darstellbar sind. Aber MAME z.B. kann das schon. Und das ist für mich 
total störend, wenn Laufschriften, Sprites etc. zwischendurch "ruckeln". 
Verstehe ich eigentlich nicht, dass da nicht viel passiert in diese 
Richtung.

>>Dabei sollte man auch bedenken, dass es Befehle gab, die bei
>>grenzüberschreitenden" Speicherzugriffen extra-Takte benötigten.
> So wie ich das sehe, beachtet dieser Simulator diese Takte nicht, bin
> mir aber nicht ganz sicher. Auf jeden Fall, führt er schonmal 6502 Code
> aus, das ist vorerst das wichtigste.

Wie gesagt, ich denke für Grafik-Spielereien wird das Timing sehr 
wichtig.

>>Was ich an der ARM Variante super finde: 64KB SRAM / viele Register
> Ich hab mich nun auch fürs Board so ziemlich entschieden. Ein DilNetPC
> DNP/1486. 33mhz, 2mb flash, 8mb ram, ethernet, seriell, 20 IO (8 davon
> 5V tolerant, rest 3v3), ...
> Und dieses Board hat anscheinend auch nen 16bit ISA Bus, nur hab ich das
> irgendwie noch nicht gefunden, habe aber auch keine wirkliche
> Dokumentation zu dem Board. Ich werd die Tage mal beim Hersteller SSV
> anrufen und nachfragen ob die mir da noch was haben, denke aber mal ja.
> Dann kommt da nämlich eine VGA Karte dran, ne ET4000 mit >512k Video
> RAM, da hab ich dann schonmal fürs Bild gesorgt.
> Hier mal ein Überblick über das Board:
> http://www.dilnetpc.com/dnp0001.htm

Die Hardware sieht ganz nett aus. Allerdings glaube ich es nicht, dass 
es möglich ist, den C64 auf einer 33MHz Plattform laufen zu lassen. Bei 
meinem ARM7 dauert bis jetzt jeder Assembler Befehl einen Zyklus. Wenn 
das beim 486er auch annähernd so wäre, dann hättest Du im Idealfall 33 
Befehle, um alles was im C64 in einem Zyklus passiert abzubilden. Ich 
denke nicht, dass das funktioniert. Bei meinem SID-Player werden auch 
nicht wahnsinnig viel Recourcen übrigbleiben...

> SID soll ein echter drankommen, habe noch einen 64er mit kaputten CIA
> hier, der wird dafür geschlachtet.

Ich hab 1:1 die Schaltung wie im c128 Servicemanual übernommen (weil ich 
den 8580 verwende). Irgendwie haben die anderen Dinge nicht 
funktioniert, die ich probiert habe. Falls Du da Probleme oder Fragen 
hast, kann ich Dir gerne versuchen zu helfen...

> Ich hab die Tabelle hier zum Spicken
> http://www.atarimax.com/jindroush.atari.org/aopc.html

der Link ist bei mir lila :-)

Gruß
Peter

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Hardware sieht ganz nett aus. Allerdings glaube ich es nicht, dass
>es möglich ist, den C64 auf einer 33MHz Plattform laufen zu lassen.
Hmm der Simulator an sich packt auf einem 486/100 etwa 3mhz. 33 dann 1. 
Viel Zeit bleibt da wohl nicht, aber mal gucken, mit ner ISA VGA Karte 
und den SID extern und ein wenig optimieren, den Simulator evtl auf 
Assembler umstricken usw. wird das ja vielleicht gehen.

>Und am Ende wird entschieden, was mit der übrigen Leistung passiert.
Noch is da bei mir gar nix, aber ich werd das so machen, dass er am Ende 
in der Wartezeit ein Flag setzt und ein zweiter Thread darf den Krams 
aussenrum erledigen. Im Grunde nix aufwendiges, wenn ich das mit VGA 
Karte und SID machen kann.

Mal sehen ob ich nen einzelnen CPU-Simulator in x86 asm finde um zu 
vergleichen.

Ich hab auch schon an irgend ein 486er PC104 mit ISA gedacht, da bekommt 
man nen DX4/100 Prozessor für n paar Euro hinterhergeschmissen, mal 
abgesehen von dem Haufen 20€-Ebay-Sofort-Kauf-Angeboten... grml 
(Schweine, Abzocke, nix andres). Aber irgendwie reizt mich das kleine 
Board, DIL64 und alles drauf was nen x86 an sich ausmacht :)

>Ich hab 1:1 die Schaltung wie im c128 Servicemanual übernommen (weil ich
>den 8580 verwende). Irgendwie haben die anderen Dinge nicht
>funktioniert, die ich probiert habe. Falls Du da Probleme oder Fragen
>hast, kann ich Dir gerne versuchen zu helfen...
Ich hab den SID vorhin mal 1:1 von der 64er Platine aufm Steckbrett und 
an einen 8051er gehängt, das tut soweit mal :), is ja auch nich schwer 
:)

>für mich total störend, wenn Laufschriften, Sprites etc. zwischendurch
>"ruckeln". Verstehe ich eigentlich nicht, dass da nicht viel passiert in
>diese Richtung.
Oh ja, sowas geht mir auch aufn Zeiger, aber an sowas ist jetzt noch 
nicht zu denken. Ich hab ja noch nichtmal den Prozessor ganz fertig bzw 
es ist noch nicht mehr als ein Konzept...


>der Link ist bei mir lila :-)
Bei mir werden die nicht lila, History aus :P

Autor: Peter Pippinger (uncle-sam7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...was ich Dir bezgl. Timing noch als gutes Tool empfehlen kann:
http://home.pacbell.net/michal_k/6502.html

Gruß
Peter

Autor: Peter Pippinger (uncle-sam7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hmmm hab gerade nochmal überlegt: Es gab ja damals auch so Effekte 
wie Char-Scrolling. z.B. einfach einen Punkt in einem Zeichen jeweils 1x 
um ein Bit rotieren. Wenn Du dieses Zeichen dann auf dem gesammten 
Bildschirm verteilt darstellst (40*25) und alleine nur dieses eine 
Zeichen veränderst, musst Du das gesammte Bild neu aufbauen und das sind 
bein 320x200x50Hz alleine schon 3,2 Mio Pixel / Sekunde. Dabei ist noch 
nicht mal der Rahmen mit berücksichtigt. Also meine Meinung nach wie 
vor. 6502 wird auf jeden Fall funktionieren. Aber wenn Du auf Grafik und 
all die Eigenheiten des C64 eingehst wird das - so denke ich - nicht mal 
auf nem 486DX/4 100 in x86 Assembler laufen (immer mit dem Hintergrund 
50Hz PAL 100%).

Ich habe mir auch schon ein paar Gedanken gemacht, was man denn so 
machen könnte. Was ich persönlich total cool fände: wenn man für jeden 
speziellen IC im C64 eine kompatible MC-Variante "nachbasteln würde", 
die vom Formfaktor auch noch passen würde. Wobei da sowas wie der C-One 
vielleicht auch schon ne passable Alternative ist, um "keep the spirit 
alive" zu spielen...

Gruß Peter

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da mir die Idee mit dem C64 auch schon länger im Kopf 'rum schwebt, kann 
ich ja auch mal meinen Senf dazu geben.

Was den 6510er betrifft, habe ich auf einem ATmega eine Zyklenexakte 
Emulation geschrieben die mit Faktor 20 läuft (20 AVR-Takte = 1 
6510-Takt). Bei den kurzen 6510er-Opcodes(2-3 6510-Takte) lässt sich da 
auch nichts mehr 'rausholen. So wie der Code aussieht, bekommt man das 
auch auf einem 486 nicht mit weniger Assembler-Code hin. Das ist aber 
'nur' die CPU noch kein IO geschweige denn Video.

Peter Pippinger schrieb:
> Was ich persönlich total cool fände: wenn man für jeden
> speziellen IC im C64 eine kompatible MC-Variante "nachbasteln würde",
> die vom Formfaktor auch noch passen würde.

Ich kenne mich leider mit der Hardware-Seite noch nicht so aus bzw. 
lerne noch, ich habe aber schon die Möglichkeit im Emulator 
berücksichtigt, dass man ihn als vollwertigen 6510er-Ersatz verwenden 
könnte. Entworfen habe ich die Hardware dafür auch schon, aber noch 
nicht besorgt und gelötet.
Der Swin-SID ist zwar nicht ganz kompatibel, aber für die grobe 
Sound-Wiedergabe gibt's den ja auch schon.

Um die Videoausgabe so hinzubekommen, dass mehr als der 
Basic-Interpreter läuft muss man wohl jede Zeile einzeln berechnen. D.h. 
144 Bytes aus RAM lesen, 8 Sprite-Zeilen verarbeiten mit Kollisionen und 
parallel 320x4-bit ausgeben. Dann funktionieren auch die ganzen Tricks 
bspw. mit dem Rasterinterrupt.

Würde es einen AVR mit ca. 100MHz geben würde ich sagen, dass es zwar 
nicht leicht wird, aber man das hinbekommen könnte 6510+SID+VIC-II zu 
emulieren. Sollte auf einem 486@100MHz somit wohl auch gehen, zumindest 
in Assembler.

Mark

Autor: Peter Pippinger (uncle-sam7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hmm. hab eben mal http://cbmmuseum.kuto.de/zusatz_6569_vic2.html 
überflogen. Schaut jetzt wirklich auf den ersten Blick nicht nach 
Hexerei aus. Aber ich denke nach wie vor dass alles in 100 MHz äußerst 
eng, eher unmöglich machbar ist. Hab gestern Nacht noch nen 
interessanten Beitrag zum Thema gefunden:

http://forum.6502.org/viewtopic.php?t=1603

Mein 6502 möchte ich auf ARM7 auch bestmöglich optimieren (zumindest 
sehr nahe am besten Zustand.) Ich bin von ARM irgendwie gerade recht 
angetan. Hab ganz früher auch mal was auf dem 286er-486er in ASM 
programmiert. War da bestimmt nicht gerade ne Leuchte, aber ich meine 
sagen zu können, dass man mit dem ARM mit einem Takt mehr erreichen kann 
(zumindest hier bei diesem Thema). Was ich bereits angefangen habe: 
Flags direkt vom ARM übernehmen. Hab heute noch gesehen, dass man 
Pointer nach dem Auslesen im gleichen Befehl automatisch erhöhen kann. 
Das werde ich auch noch irgendwie reinbauen.

Naja, wie dem auch sei. Meine Zeit ist leider dermaßen knapp, dass ich 
schon total stolz darauf bin, dass Sanxion-Loadertune auf meiner 
"Plattform" mir nem SID zusammen läuft. Wenn das jetzt dann mal alles 
soweit fertig ist, könnte ich mir gut vorstellen auch mal andere Teile 
des C64 "anzusehen".

Gruß
Peter

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenns schon länger her ist... Ich habe den Simulator mittlerweile 
soweit, dass er auf einem mini2440 ohne Betriebssystem läuft.

Die CPU habe ich wie im Eröffnungspost von Zophar genommen (no name 6502 
emulator). Stand so ca.:
SID ist ein echter angeschlossen
VIC wird später mal per Software gemacht werden
CIA in Software emuliert, Joystick 1 oder 2 über Felder auf dem 
Touchscreen steuerbar
Laden von Images übers Terminal (ROMs, komplette 64k-Speicher-Abbilder, 
ihex, d64 in Arbeit)
Einfaches durchsteppen von Code/Laufen lassen, komme so auf ca. 12mhz.

Momentan bastle ich an einem schönen Disassembler/Debugger für den 
Emulator, der dann über ein Terminal vom Rechner aus bedient werden 
kann, habe nach 2  Monaten nichts dran tun keine Lust gehabt, am 
Emulator weiter zu machen, darum den Disassembler angefangen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.