Announcement: there is an English version of this forum on Hat schon wer eine 6502 Emulation auf einen AVR hinbekommen ? Hintergrund ist die Überlegung einen SID-Player für die SID Files zu bauen. Ich habe bei näherer Betrachtung dann festgestellt das im SidPlay für für so ziemlich alle Systeme eigntlich ein C64 nachgebildet wird. Also 6502 oder 6510 plus EA 6526 und ebend der SID selbst. Die SID Files beinhalten auch immer eine Playerroutine für den 6502 Prozessor unter Anwendung der C64 Memorymap... Ist es möglich einen AVR mit 16MHz so hinzubiegen das er einen 6502 mit 1MHz emulieren kann ? Grüße Björn
So würde ich das nicht sehen. Einen nackten 6502 kann man sicher emulieren, 6526 sollte auch drin sein und mittels einem AVR mit Memory-Interface auch der Speicher. Aber den SID selbst bekommt man nicht so einfach emuliert. Eine "Ein-Chip-Lösung" wirds wohl nicht, aber ausprobieren könnte man es ja mal.
Er wollte einen 1MHz-6502 mit einem 16MHz AVR emulieren. Und das ist sicherlich nicht möglich. Er will ja SID-Files abspielen. Da spielt das Timing eine entscheidende Rolle. Und das bekommt er mit einem AVR schlichtweg nicht hin. @Björn: Greif doch zu einem ARM, z.b. den ARM9 (STR9) von ST. Damit ist das kein Problem. Und der ist auch noch für einen Hobbyisten nicht zu komplex.
Hallo, komisch.... Gestern beim aufräumen noch 2 SIDs gefunden, da kam mir ein ähnlicher Gedanke. Original-SID am AVR und eine Emu auf den AVR für CPU usw. Speicher selbst wäre nicht zwingend nötig, den könnte eine "Software-MMU" ummappen, weil die CPU sowieso emuliert werden muß. Die Playerroutinen sind normalerweise relativ einfach. Vom 6226 wird eigentlich nur der Timer benutzt, der Rest dürfte unnötig sein. Wenn man Tabellen benutzt, könnte es vielleicht sogar schaffen. Den SID selbst emuliert ein ATMega auf keinen Fall, der hat mehr benutzte Ausnahmen und Tricks als offizielle Funktionen. ;) Ich habe mal "SynthSample" im Netz wiedergefunden und es mit mehreren Emus auf dem PC abgespielt, irgendwas stimmte immer nicht. Ich habe dann einen C64 mit altem SID vorgekramt und von da gesampelt. Ich hatte mich nicht geirrt, keine Emu hat es 100% hinbekommen... Wäre eigentlich lustig, einige Chip-Tunes auf eine SD-Card kopiert, reingesteckt und wirklich Original abgespielt. Hmmm.... Gruß aus Berlin Michael
Michael sowas gibt es schon (für parallel port und auch mit controller, vlt nicht avr)
Einen 6502 zu emulieren, geht mit dem AVR sicher nicht. Auch bei stärkeren Prozessoren kann sich so eine Portierung als halbe Lebensaufgabe erweisen, z.B. wenn der SID-Player mit aktiven Warteschleifen und ähnlichen Sauereien arbeitet, die in der Zeit des 6502 häufiger benutzt wurden, als heute im Zeitalter der geschenkten Timer. Schreib lieber den Player für einen aktuellen Prozessor neu ;-)
Hallo, @Uhu Uhuhu: sicher? ;) Der 6502 (6510) wird im C64 mit rund 1MHz getaktet. Es stehen also maximal 16 Takte pro Befehl zur Verfügung. Der 6502 hat 3 8Bit-Register, davon 1 Akku und 2 Index-Register. Der Befehlsumfang läßt sich wohl zu 80% mit AVR-Befehlen direkt abdecken, Sonderbehandlung brauchen die Adressierungsarten, die sollten sich aber relativ elegant mit X,Y,Z abdecken lassen. Das Verhalten der Flags wird vermutlich ein paar Unterschiede aufweisen, die Behandlung der Dezimal-Befehle macht Probleme, die dürften aber in den Playern kaum genutzt werden. Das C64-Wiki hat die CPU so schön auseinandergenommen, da muß ich nichtmal alte Bücher suchen. ;) Ich sehe im Moment das größte Problem ganz woanders: der Chip-Tune muß zum Abspielen komplett im Ram verfügbar sein, Es kommen also wohl nur ATMega mit Hardware-Raminterface in Frage, weil der AVR beim Emulieren keine Zeit hat, irgendwoher Daten zu holen. Ein CTC auf auf Prescale 1 und Wert 8 sollte den E-Clock erzeugen können, der Rest wäre geschicktes Sortieren der AVR-Befehle... Ich halte es noch nicht für aussichtslos. PS: ja, nutzlos vielleicht, aber das stört ja beim Hobby weniger. ;) Gruß aus Berlin Michael
... und es kommt noch hinzu, dass der 6502 zwischen 2 und 6(7?) Takte pro Befehl benötigt. Je komplizierter der Befehl, desto mehr Taktzyklen - das käme einer Emulation sehr entgegen.
Hallo, @Marvin: ja, die aufwändigsten sind vermutlich die Indirekt Indiziert Zeropage mit Offset, die dauern aber auch besagte 5-7 Zyklen. Ich habe gerade mal 32k Ram und einen Mega8515 auf das STK200 gesteckt, ich schau mal, wie eine Single-Step-Emu einiger dieser Befehle aussehen könnte... Muß nur mal schnell die 6510-Register definieren und die UART-Debug-Ausgabe rumbasteln. Ein Glück, daß man sich auch in Assembler schöne Baukasten-Routinen machen kann. ;) Ich werde mal pro Befehl 4 Byte in der Flashtabelle reservieren, ist dann erstmal 1k weg. ZH auf Tabellenanfang, dann den 6510-Befehl in ZL laden und indirekt springen. X erstmal für den 6510-Programmcounter und Y für den X/Y indizierten Kram... Mal schauen. ;) Gruß aus Berlin Michael
Habt Ihr auch an Interrupts auf dem AVR gedacht? Ich vermute, die werden das Timing im Player ganz schön zerknittern... Außerdem sind knapp 160 Takte - selbst wenn 160 AVR-Befehle reinpassen - viel zu wenig, um eine saubere Emulation hinzubekommen. Die Ähnlichkeiten verleiten zu Fehleinschätzungen. Der Teufel steckt in den Unähnlichkeiten und darauf, daß die im Player keine BCD-Arithmetik verwenden, würde ich mich schon garnicht verlassen. (Mal abgesehen davon, daß diese Art von Überlegung - vornehm ausgedrückt - nicht gerade professionell ist.) Letztlich entscheidet das schwächste benutzte Teil im Emulator über die Qualität und das Ohr findet unerbittlich die Schwachpunkte...
Uhu Uhuhu wrote: > Habt Ihr auch an Interrupts auf dem AVR gedacht? Ich vermute, die werden > das Timing im Player ganz schön zerknittern... > > Außerdem sind knapp 160 Takte - selbst wenn 160 AVR-Befehle reinpassen - > viel zu wenig, um eine saubere Emulation hinzubekommen. > > Die Ähnlichkeiten verleiten zu Fehleinschätzungen. Der Teufel steckt in > den Unähnlichkeiten und darauf, daß die im Player keine BCD-Arithmetik > verwenden, würde ich mich schon garnicht verlassen. (Mal abgesehen > davon, daß diese Art von Überlegung - vornehm ausgedrückt - nicht gerade > professionell ist.) > > Letztlich entscheidet das schwächste benutzte Teil im Emulator über die > Qualität und das Ohr findet unerbittlich die Schwachpunkte... Es gibt auch noch beschleunigte Nachbauten den 6502. Den 65C02 von Western Design Center und Pheripheriechip. Der 65C02 läuft mit 14MHz. Vertrieb ist DEMA
Die Frage war, ob man den 6502 auf einem AVR emulieren kann um darauf den SID-Player in 6502-Maschinencode laufen zu lassen. Daran, daß man das Teil auf einem 65C02 zum Laufen bringen kann, habe ich keine Zweifel - aber das wäre dann in Hardware, nicht emuliert.
Uhu Uhuhu wrote: > Habt Ihr auch an Interrupts auf dem AVR gedacht? Ich vermute, die werden > das Timing im Player ganz schön zerknittern... > > Außerdem sind knapp 160 Takte - selbst wenn 160 AVR-Befehle reinpassen - > viel zu wenig, um eine saubere Emulation hinzubekommen. > > Die Ähnlichkeiten verleiten zu Fehleinschätzungen. Der Teufel steckt in > den Unähnlichkeiten und darauf, daß die im Player keine BCD-Arithmetik > verwenden, würde ich mich schon garnicht verlassen. (Mal abgesehen > davon, daß diese Art von Überlegung - vornehm ausgedrückt - nicht gerade > professionell ist.) > > Letztlich entscheidet das schwächste benutzte Teil im Emulator über die > Qualität und das Ohr findet unerbittlich die Schwachpunkte... @Uhu, verstehe die ganze Dískussion nicht. 1.) Kein Wort darüber, in welcher Programmiersprache Ihr die Emulation schreiben wollt. 2.) Das Verhältniss steht nicht 1/160 sondern 1/16 (ca.) 3.) Wie wollt Ihr die Emulation vornehmen? Was heiss7, der AVR kann 80% der Befehle direkt übernehmen. Denke, das spielt wohl keine Rolle, da ja eine Art 6502Assembler-Interpreter geschrieben werden muss und damit kann kein Befehl direkt emuliert werden. 4.) Der AVR ist eine Art Billig-FPGA Design, man hat Befehle auf biegen und brechen auf eine Nahezu einheitlich Datenbreite reingequetscht. Manche Register nur mit bestimmten Befehlen. Ist wohl der ungeeignetste µC für Sowas. Ein ARM9 is dagegen ja wohl total abgefahren und mit Kanonen nach Spatzen geschossen. Glaube kaum, daß Ihr den in Assem programmiert und würdet dadaurch jeden Geschwindigkeitsvorteil wieder tot machen. Mit einem 32Biter nen 8 Biter emulieren, naja.
Hallo, @Uhu Uhuhu: ich denke hier im Moment nur laut darüber nach, den 6502 Taktgenau nach außen zu emulieren, um einen echten SID an den AVR zu hängen und spielen zu lassen. 160 AVR-Befehle, um selbst ein LDA ($50),Y zu emulieren sollten wohl mehr als reichen. Iterrupts sollten nicht stören, weil es in meiner momentanen Überlegung keine gibt... Befehlsdecoder: Befehlsbyte des 6510 mit LD ZL,X+ aus dem Ram nach ZL holen, IJMP dahin. Dort Datenbytes des Befehl holen und bearbeiten. Programmzähler (X) zeigt dann schon auf den nächsten Befehl, wenn es ein Sprung war eben dort hin. Timing mit passender Anzahl AVR-NOPS auffüllen Dann Sprung zurück zum Befehlsdecoder und wieder von vorn. Zeropage im AVR-Ram, über die nötige Initialisierung denke ich später nach... Selbst die Behandlung der Dezimal-Geschichte sollte reinpassen, von "professionell" war sowieso nicht die Rede. ;) Den C64 mit der Nordic-Power kann ich immernoch aus dem Schramk holen, um zu debuggen, was nicht freiwillig spielt. Nenn es Back2Roots, ich habe ewig nichts mehr mit dem C64 gemacht. :) Schlimmstenfalls habe ich ein paar Stunden Freizeit "nutzlos" verbracht, darüber würde ich mich aber überhaupt nicht ärgern.... Gruß aus Berlin Michael
@ Dirk Hofmann: Ich halte das Projekt für wenig aussichtsreich - egal in welcher Programmiersprache man da ran geht. (Auch mit Deinem heißgeliebten Assembler wirds nicht gehen.) @ Michael U.: Du kannst natürlich Deine Erfahrungen sammeln und ich will Dir da nicht reinreden. Ich habe bereits etliche Erfahrungen mit Interpretern/Emulatoren und schöpfe nur daraus. Der Teufel steckt wie immer im Detail - das man auf den ersten Blick natürlich übersieht...
Hallo, @Dirk Hofmann: zu 1) ASM zu 2) das bezweifle ich mal: ADC $hhll,X addiert zum Akku den Inhalt von ($hhll + X) Z - Zeiger auf Befehlstabelle X - PC des 6510 Y - 16 Bit Hilfsregister befehlsdecoder: ld ZL,X+ #2# Befehlsbyte des 6510 in ZL, ZH zeigt sowieso auf Tabellenanfang. ijmp #2# Sprung 6510adc: mov XH_TEMP,YH #1# ; für Seitenwechsel des 6510 ld YH,X+ ; #2# H der Adresse cp XH,XH_TEMP ; #1# Seitenwechsel der Quelladresse? breq no_wait ; #2# nein, nur 4 6510 Takte nop ; einen Takt warten, also 15 nop (-1 wegen breq) nop ... nop nop no_wait: ld YL,X+ #2# L der Adresse add YL, 6510_X #1# adc YH,NULL #1# Hilfsregister, immer 0 ld TEMP,Y #2# add 6510_AKKU,TEMP #1# ob Flags behandelt werden müssen, muß jeweils geklört werden, sonst mov 6510_STATUS,SREG #1# Flags vom add merken für 6510 nop nop ... dumm warten, bis 1µs rum ist nop nop rjmp befehlsdecoder #2# X zeigt auf nächstes 6510-Befehlsbyte Das sind 20 Zyklen für diesen Befehl. Der 6510 braucht dazu 4 Zyklen -> 64 AVR-Takte bei 16MHZ, 5 Zyklen, wenn High/Low-Byte über einer Seitengrenze liegen. Bleiben 44 AVR-Takte für Sachen, die ich hier auf die Schnelle übersehen habe. Sieht so schlecht doch nicht aus... zu 3) wenn die Wirkung eines Befehl identisch ist, also z.B. die Flag-Beeinflussung bei einem 6510 CMP der des CP/CPI des AVR enspricht, muß nicht soviel Ausnahmen behandeln. Wenn ich das gedanklich weiterspinne, sollte man einen 99,9% kopatiblem 6510 in einen Atmel bekommen, den man per Adaptersockel in einen C64 stecken können sollte... ;) Gruß aus Berlin Michael
Uhu Uhuhu wrote: > Schreib lieber den Player für einen aktuellen Prozessor neu ;-) Das wäre mir ja auch am liebsten wenn ich mit dem AVR nur die Daten zum SIDChip rüberschaufeln müsste. Leider ist in allen SID-Dateien ein eigener Player enthalten und es ist noch nicht mal immer der gleiche. Ich hätte keine Lust in jeder Sid-Datei erstmal zu schauen welcher Player drinsteckt, um dann entsprechend die Daten aufzubereiten... Lieber würde ich die Sid-Dateien so verwenden wie sie sind. Grüße Björn
> Leider ist in allen SID-Dateien ein eigener Player enthalten und es ist > noch nicht mal immer der gleiche. D.h., ein Hack, der für ein Musikstück vielleicht funktioniert, fällt mit dem nächsten jämmerlich auf die Schnauze... Da ist es wohl das Beste, wenn Du die Audiodaten aus dem Orginalkasten rausholst und auf eine PC-Soundkarte gibst, um sie in heutige Formate umzucodieren.
Uhu Uhuhu wrote: > D.h., ein Hack, der für ein Musikstück vielleicht funktioniert, fällt > mit dem nächsten jämmerlich auf die Schnauze... So isses, deswegen bilden ja auch alle Programme zun Sidabspielen für den PC einen halben C64 (6510, 6526 und 6581) nach. > > Da ist es wohl das Beste, wenn Du die Audiodaten aus dem Orginalkasten > rausholst und auf eine PC-Soundkarte gibst, um sie in heutige Formate > umzucodieren. Da wäre ja dann keinerlei Herausforderung mehr... das ist unsportlich ;) Grüße Björn
Würde eher drauf tippen, daß dieser Sport in allgemeiner Verfettung endet. Fahrrad ist gesünder...
Hallo, > Leider ist in allen SID-Dateien ein eigener Player enthalten und es ist > noch nicht mal immer der gleiche naja, das liegt einfach daran, daß es keinen SID-Player auf dem C64 gibt. Der SID wurde programmiert, der eigentlich erste brauchbare Tracker für den C64 war der SidMon von Chris Hülsbeck. Damit konnte man erstmals die SID-Eigenschaften nutzen und trotzdem mit Noten-Einträgen arbeiten. Ansonsten ist jedes Stück programmiert. So resourcensparend wie es geht, Speicher sparen, CPU-Zeit sparen. Ein guter Sound sollte ein Spiel oder ein Demo aufpeppen, nicht das Gameplay versauen oder den in Echtzeit gerenderten bunten Würfel am Drehen hindern. Ansonsten habe ich im Netz noch das gefunden... http://www.tripoint.org/kevtris/Projects/sid/index.html So, jetzt zähle ich weiter Befehle. ;) Hoffentlich habe ich noch ein C64-Intern irgendwo, muß erstmal nach Zeropage-Belegung und Vektor-Tabellen ausschau halten, ist doch schon etliche Jahre her..... Gruß aus Berlin Michael
Nun will ich mal meinen Senf dazugeben. Ich denke eine MOS6502 bzw MOS6510 (folgend nur noch als MOS bezeichnet) Emulation auf einem AVR sollte unter folgenden Umständen möglich sein: Der MOS Takt ist nicht höher als 1MHz Der AVR Takt ist ein ganzes Vielfaches des MOS Taktes Der AVR hat genug Flash (Mega64 wäre ideal) Der Emulator wird in Assembler gecoded Ich muß dazusagen das ich nie speziel auf den MOS gecoded habe. Meine Anfänger CPU war der Z80 Aber was ich in den 6502 Datenblättern gesehen habe stimmt mich zuversichtlich. Die schnellsten MOS Befehle brauchen mindestens 2 MOS Takte und haben während dessen 1 RAM zugriff. Bei 1MHz MOS-Takt und 16 MHz AVR-Takt würden das bis zu 32 AVR-Assembler Befehlen entsprechen. Der RAM Zugriff müßte in Software realisiert werden (das Hardware XRAM Interface wäre zu schnell für Busbausteine wie den SID) Die MOS haben maximal 256 Opcodes (wenn ich mich nicht täusche) Für jeden Opcode würde im AVR-Flash ein kurzes Unterprogramm stehen. In jedem dieser Unterprogramme würde gegen Ende der nächste MOS-Befehl gelesen und das dazugehörige Unterprogramm angesprungen werden. die Notwendigen Befehle wären:
1 | out PORTD,Adresshigh ;1 Takt |
2 | out PORTC,Adresslow ;1 Takt |
3 | ... |
4 | SBI PORTB,Lesebit ;2 Takte |
5 | ... |
6 | in zh,PINA ;1 Takt |
7 | ijmp ;2 Takte |
Für das Einholen und dekodieren des Befehls gehen also 7 AVR-Takte weg. Bleiben noch 25 AVR-Takte für die Ausführung des eigendlichen MOS-Befehls. Das sollte machbar sein. Bei komplizierteren Addressierungsarten kommen dann noch zusätzliche MOS-Takte dazu, so das man noch zusätzlich Zeit gewinnt. Ich weiß jetzt nicht welche Interupts beim MOS vorhaden sind und wie diese gehandhabt werden, aber um diese Taktsychron einzubinden könnte man noch ein kurzes sei/cli Fenster in den o.g. Code einbringen.
1 | out PORTD,Adresshigh ;1 Takt |
2 | out PORTC,Adresslow ;1 Takt |
3 | ... |
4 | SBI PORTB,Lesebit ;2 Takte |
5 | ... |
6 | sei ;1 Takt |
7 | (exakt hier wuerden die entsprechenden ISR angesprungen werden) |
8 | cli ;1 Takt |
9 | in zh,PINA ;1 Takt |
10 | ijmp ;2 Takte |
Dies Beispiel würde jedoch 64kword Flash brauchen, (jeder MOS-Opcode hätte 256 AVR-Befehle Platz) deshalb wäre es sinnvoll noch eine LUT für die Opcode-Unterprogramme zu verwenden. Diese könnte aus Geschwindigkeitsgründen im internen RAM stehen (512 Byte) Die Zeropage und den Stackpointer würde ich ebenfalls in das interne RAM packen. Ich denke nicht das externe Busbausteine im C64 auf die Zeropage oder den Stack zugreifen oder diesen gar verändern dürfen. (Korregiert mich wenn ich falsch liege) Alles in allem halte ich eine Emulation für möglich. Aber wie gesagt ich habe auf den MOS noch nicht programmiert, und ich finde auch keine wirklich gute Doku zu den Chips. Das was ich bisher gefunden habe sind ein paar schlecht gescannte Seiten oder PDFs von Vergleichstypen (bei deren Kompatiblität ich mir nicht sicher sein kann. Was ich gut gebrauchen könnte wäre eine Befehlsbeschreibung wie ich sie von den AVRs gewohnt bin. Damit könnte man dann planen. (OK illegale Opcodes sind dann noch so eine andere Sache) cu Hauke
Hallo, ich denke das könnet noch andere Probleme geben. Der 6502 hat eien von Neumann Architektur und das wurde auch gerne ausgenutzt. Ich sag mal Daten und Code mischen oder sogar selbstmodifizeirender Code. Das wird nicht einfach mit dem AVR das nachzubilden. Eckhard
@Eckhard Solange man den MOS-Code und die Daten in einem exteren RAM behält und diese gleich behandelt, dürfte diese Problem lößbar sein. Der nächste Opcode wird ja erst gelesen wenn der Vorherige Befehl (evt. ein schreibender RAM Zugriff) fertig ist. cu Hauke
Es gibt schon länger (2002) einen 6502 in VHDL, wurde aber seither nicht mehr gepflegt: http://www.opencores.org/projects.cgi/web/t65/overview http://www.opencores.org/cvsweb.shtml/6502vhdl/
Hier gibts noch mehr 6502 und Peripheriebausteine in VHDL oder Verilog: http://www.birdcomputer.ca/Cores/CoresToC.html
Hallo, ich habe mir das jetzt mal etwas näher angeschaut. Rahmenbedingung bleibt mal ein SID-Player mit 6581 dran. 16MHz Mega8515 oder Mega162 mit externem Ram. Experimentierumgebung: STK200 mit Mega8515 und 32k externem Ram, z.Z. 8MHz getaktet. UART für Debug mit 38400 Baud. Testpbjekt: ein SID-Player-File mit knapp 500Byte Länge im EEPROM. File wird beim AVR-Start an die Original-Adresse im externen Ram kopiert. 6510 Befehlsdekoder/Interpreter mit LockUp-Table (512Byte im Flash). Die Initialisierungsroutine des Players läuft inzwischen durch, das heißt, es werden alle benutzten Befehle dekodiert und abgearbeitet. Keine Rahmenbedingungen, Zugriffe auf IO laufen ins Leere usw. Kein Timing, nur Test, ob ein Befehl überhaupt mit der zur Verfügung stehenden AVR-Taktzahl bearbeitet werden kann. Wenn der "6510" läuft, wird nichts anderes auf dem AVR gemacht. Die - bis jetzt - ungünstigste Variante ist lda/ldx/ldy immediate mit 2 6510-Zyklen. Da bleiben als Reserve 5 AVR-Takte übrig. Das Problem dabei ist, das der 6510 da die Flags setzt und das muß bearbeitet werden. Alle 3 Zyklen-Befehle haben bis jetzt genug Reserve, auch die indirekt idizierten. Mein Hauptproblem im Moment ist, daß ich zwar diverse Zyklen auf dem AVR übrig behalte, die aber nicht sinnvoll nutzen kann, weil sie eben "abgezählt" sein müssen. Interruptlösungen scheiden meiner Meinung nach aus, 4 für IRQ-Start, 3 für den Sprung, 2 für SREG sichern und zurück und 4 für Reti sind 13 Takte, die habe ich bei 32 Takten für einen 2-Zyklen Befehl des 6510 nicht übrig. 6510 immer mit rund 1MHz gerechnet, also C64 Speed. Falls jemand Interesse hat und mitdenken/mitbasteln will, packe ich das AVR-Projekt gern mal hier rein. Gruß aus Berlin Michael
>Mein Hauptproblem im Moment ist, daß ich zwar diverse Zyklen auf dem AVR >übrig behalte, die aber nicht sinnvoll nutzen kann, weil sie eben >"abgezählt" sein müssen. kannst du dir nicht übrig gebliebene bis zu einem gewissen Wert "aufsparen" um sie für zeitintensivere Befehle zu verwenden?
Was spricht gegen Pollen des Timers in der ungenutzen Freizeit als Interrupt Ersatz ? 5 Takte sollten dazu ausreichen, das Interrupt Flag zu prüfen bzw. den Pin abzufragen, das Interrupt Enable Flag abzufragen und gegenfalls zu springen.
Hallo, @Walter: aufsparen bringt vermutlich Probleme, wenn es IO-Zugriffe zum SID oder in der CIA-Timer-Emulation gibt, da spielt dann wohl schräg... @Benedikt K.: spricht erstmal nichts dagegen, ich weiß einfach noch nicht, ob und wofür ich die Rechenzeit brauche oder gebrauchen kann. Von der CIA dürfte nur Timer/Counter genutzt werden, den kann der AVR erledigen und darf auch IRQ machen. Das wird nur insofern etwas tricky, weil ich da sozusagen mitten im 6510-Befehl stecken kann. Das IRQ-Timing des 6510 muß ich mir erstmal wieder ansehen, ist zu lange her. Da ist aber auf jeden Fall genug Zeit, 6510 PC und STATUS habe ich schneller auf dem 6510-Stack als das Original. Zugriffe auf $Dxxx, also IO, muß ich sowieso getrennt bearbeiten, wegen Bank-Switching des C64 usw. Das ist aber auch relativ unkritisch, weil daß alles 6510 Befehle mit mindestens 3, meist 4-5 Zyklen sind. Ich bastle jetzt erstmal die Befehle zusmmen, die die Mini-Routine benutzt, dann muß ich erstmal meine alten C64-Unterlagen suchen. ;) Im Netz liegt viel, leider auch viel unvollständiges oder falschen... Für den 6502 ist erstmal http://www.6502.org/tutorials/6502opcodes.html zu empfehlen. Gruß aus Berlin Michael
>@Walter: aufsparen bringt vermutlich Probleme, wenn es IO-Zugriffe zum >SID oder in der CIA-Timer-Emulation gibt, da spielt dann wohl schräg... natürlich keine msec aufsparen, aber so 1-2µsec für einzelne 6502 Befehle die du vielleicht nicht in der Taktzeit schaffst sollten doch wohl drin sein
Hallo, naja, sieht bis jetzt immernoch gut aus, geht alles ins Zeitraster. Es bkeiben eben z.B. bei lsr addr,x rund 50 AVR-Zyklen übrig, die ich Taktgenau verheizen muß. Da muß ich mir noch was ausdenken. Außerdem kommen noch 2 Dinge dazu: während gespielt wird, will ich ja nur 2 Sachen machen können: Tasten abfragen, wenn eine gedrückte Taste erkannt wird, ist sowieso Puse oder Ende für den 6510, dann will ich ja irgendwas verändern, neuen Track, Pattern-Skip oder so. Da ist Timing also egal. Andere Sache ist es, das Display zu aktualisieren, also Laufzeit oder Pattern-Nummer usw. Das muß zwischendurch passieren. Da wird es dann wohl auf eine zeichenweise Ausgabe ans Display hinauslaufen, also Zeiger auf Textbuffer und bei jedem Aufruf 1 Zeichen. Das dann in solche Befehle reingehangen mit einer Timerabfrage, damit es gleichmäßig aussieht. Dann kommt noch erleichternd hinzu, daß die Play-Routinen normalerweise in einem Timer-IRQ des C64 laufen, die werden also normalerweise nur alle 20ms aufgerufen oder imn eigenem Timer-IRQ. Dazwischen sollte der Original-C64 ja noch was nützliches machen, z.B. bewegte Grafik darstellen. Die CPU-Auslastung über die Zeit läßt also vermutlich auch noch ausreichend Rechenzeit übrig. Das kann ich aber erst abschätzen, wenn etwas mehr spielt. ;) Gruß aus Berlin Michael
Vor einiger Zeit habe ich diese angehängte Emulation im Netz gefunden; Quelle vergessen, kann sein auf AVRFreaks oder so. Der VIC20 ist ein Vorgänger vom C64, mit der gleichen CPU. Kann sein das sich etwas unterscheidet, soweit ich mich (sehr gerne btw) erinnere hatte die CPU im C64/Plus4 einen eingebauten IO-Port. Vielleicht hilft das dem einen oder anderen. Torsten
machs doch so: .org 0x100 _nop: nop nop nop nop . . . nop ret (sagen wir mal 100 stück) dann kanst du mit CALL 0x150 z.b. 50 Takte (+call + ret) "verbraten"
Michael U. wrote: > Falls jemand Interesse hat und mitdenken/mitbasteln will, packe ich das > AVR-Projekt gern mal hier rein. Jaa, hier! Grüße Björn
Hallo, @T.S.: Danke, schau ich mir mal an. Allerdings sieht die 6502cpu.asm nicht so aus, als hätte er taktgenau emuliert, ein paar Sachen scheint er auch noch nicht fertig gehabt zu haben. Vielleicht finde ich ja den Ursprung im Netz. @Läubi: so ähnlich sieht es auch aus, allerdings nur für 7...16 Takte Wartezeit. :) 7 ist Minimum damit wegen rcall + ret, 16 ist rcall + ret + 9 nop, jeweils mit eigener Sprungmarke, liest sich besser. Komplette 6510-Zyklen werden mit mehreren Aufrufen von warte_16 erledigt. Kürzere Pausen sind eben mit 1...6 NOP direkt aufgefüllt. lda/ldx/ldy habe ich so mal gestern fertig gemacht, das geht relativ schnell, viel copy/paste, sind wenig Anpassungen nötig. Ist im Moment mehr reine Fleißarbeit....... Behandeln muß ich noch die Extra-6510-Zyklen bei Pagewechsel (indirekt adressierte und bedingte Sprünge), das muß ich mir aber erst nochmal anschauen. Gruß aus Berlin Michael
Hallo, @Björn Wieck: AVR-Studio v4 Projekt, schau rein und frage, wenn es Unklarheiten gibt. Ich habe hoffentlich alles wichtige kommentiert, natürlich bis jetzt mehr für mich als für andere... Die Befehle in den Includes sind im Moment nach Alphabet geordnet, war für mich erstmal überschaubarer. Meine Referenz ist im Moment http://www.6502.org/tutorials/6502opcodes.html Gruß aus Berlin Michael
Hallo, hmmm. zu schnell gewesen... Etliche L/H-Vertauschungen in allen Befehls-Includes beseitigt, sta/stx/sty komplett. Gruß aus Berlin Michael
http://www.npsnet.com/danf/cbm/cross-development.html#Emulators da gibts u.a. einen 6502-Emulator auf ARM, mit 30MHz Takt soll er etwa 5 MHz 6502 emulieren. Ich habe noch irgendwo den 6502 Emulator für den Atari ST, der hatte auch nur 8 MHz mit dem 68000 Prozessor.
Hallo, Danke, merke ich mir auch mal. ist auch kein grundsätzliches Problem, von der Geschwindigkeit dürfte er mit einem 16MHz-AVr so etwa auf 3MHz kommen. Das wäre aber dann ein Durchschnitts-Wert, der von 6510-Befehl abhängt. Ist dann aber nicht Zyklen-genau und das will ich. Da ist 1MHz für den Original-C64-Takt drin. Gruß aus Berlin Michael
Hi Ich habe auch mal angefangen einen mos6510 Emulator zu schreiben. Ich versuche vor allen Dingen nicht nur das Timing sondern auch das externe RAM Interface ähnlich hinzubekommen. Würde gerne mitmachen. Bin Assemblercoder und neige dazu Taktzyklen zu zählen. cu Hauke
Hallo, wie meinst Du das mit dem Ram-Interface? Prinzipell könnte man den Bus sicher komplett in z.B. C64-Originalgeschwindigkeit zusammenbasteln, ich habe das Problem zumindest mit dem SID ja auch noch vor mir. Ich bin auch noch nicht so sicher, welche Probleme der Zugriff auf das externe AVR-Ram mir so beschert, die Timingdiagramme muß ich noch genauer studieren... Gruß aus Berlin Michael
@Michael Da gibt es gleich mehrere Probleme. Das AVR interface ein gemultiplexter (scheußliches denglish) Adress und Datenbus mit zusätzlichen den Steuersignalen ALE /RD /WR Das 6510 Interface ist nicht gemultiplexed, sondern verwendet getrennte Daten und Adressbusse. Der Adressbus muß zudem von außen abschaltbar (tristate) sein. Als Steuersignal gibt es nur ein einzelnes R/W Signal mit dem die Signalrichtung gesteuert wird. Weiterhin sollen Adresshigh Adresslow und R/W gleichzeitig umgeschaltet werden. (ohne Tricks unmöglich auf dem AVR) Weiterhin wird der Standartzugriff des AVR (braucht ca 3 Takte) viel zu schnell für einen SID sein. Man kann zwar reichlich Waitstates einbauen aber ich habe meine Zweifel ob diese reichen. In meinem aktuellem Ansatz verwende ich ein paar Latches zur synchronisierung, und einen zusätzlichen Port für den Datenbus. So komme ich ohne Waitstates hin, und kann zwischen der Ausgabe der Adresse und dem einlesen der Daten noch ein paar Sachen machen. Ich frickle mich zur Zeit durch die einzelnen Adressierungmodi des 6510 anhand des Befehls AND. Leider sind die Datenblätter die ich im Netz gefunden habe leicht wiedersprüchlich. Mal wird von einem zusätzlichem Maschinenzyklus bei einem Page-Wrap-Around gesprochen, mal von einem zusätzlichem Maschinenzyklus beim Dezimal Modus. Wohl gesagt bei ein und demselben Befehl und Adressierungsmodus. Sehr verwirrend. cu Hauke
Hallo, die Problematik der Geschichte mit dem Zugriff auf echte 68xx-Perpherie ist mir klar, ich habe da schlicht noch einen großen Bogen drum gemacht. Etwas TTL-Kram ist da sicher fällig (nein, keine GAL, FPGA usw.usw. ;)). Zu den Datenblättern kann ich Dir nur zustimmen, ich werde, wenn es soweit ist, wohl den C64 entstauben müssen... Ich werde jetzt erstmal den Befehlssatz soweit zuende machen, daß alles durchläuft. Dann CIA soweit wie nötig (Timer), dann den SID ranhängen. Dezimal-Flag muß ich mir sowieso noch anschauen, ob es da einen Zusatzzyklus gibt, weiß ich jetzt auch nicht. Daß es beim gleichen Befehl und Adressmode passieren kann, daß dann 2 Zyklen zusätzlich eingefügt werden, kann schon sein. Gruß aus Berlin Michael
Hallo, falls doch noch jemand reinschaut: 6502-Befehlssatz komplett drin, Stackbehandlung drin, Bedingungen und Sprungweiten-Berechnungen scheinen zu stimmen, Timing bei 16MHz Zyklengenau 6510 1MHz. Was noch fehlt: Dezimal-Flag noch nicht berücksichtigt, Zusatz-Zyklen bei Page-Crossing nicht berücksichtigt. Wie ich den SID an den ATMega mit möglichst wenig Aufwand ranhänge, ist noch etwas unklar... Vielleicht am Wochenende mal was probieren. Gruß aus Berlin Michael
Mal kurz überflogen: Bei Adressierungen zeropage+X/Y wird die Adresse ohne Carry gerechnet. SP arbeitet etwas anders als gewohnt: TOS ist leer, nach JSR ist die Returnadresse an SP+1,SP+2. Streng genommen besitzen 65xx-CPUs keine Befehle für Subtraktion, sondern für Addition des Einerkomplements. Das hat Folgen für das C Flag, es ist invers zum C-Flag des AVR. Erkennt man schon daran, dass die übliche Subtration lda var1 sec sbc var lautete.
Tip zur Laufzeitkorrektur bei page crossing: Ein BRCS PC+1 braucht 1 Takt bei C=0, 2 Takte bei C=1.
Naja wenn eh immer gewartet werden mus... haeng das ganze doch an ein Schieberegisterlatch (HC 4094 glaub ich) "reinholen" kannst das ganze auch uber ein Parralle zu Seriell Wandlerchip (HC 4021 beim NES Controller ist sowas drinn) braucht dann insgesammt am AVR nur 4 fuer den Output und 3 fuer Input musst mal gucken obs schnell genug ist das durch alles durch zu schieben, ansosnten kannst du auch 2 Datenleitungen parrallel machen dann sind es halt 5+4 Leitungen.
Also Schieberegister dürften definitiv zu langsam sein. Man hat für einen 6502 Daten Transfers 16 AVR Takte. Meines Wissens ist die höchste SPI Frequenz (als Master) Freq/2. Das heißt für die 25 Bit (16*Adress 1*R/W 8*Daten) Bräuchte man mindesterns 50 AVR Takte. Und mit mehreren Schieberegistern parallel kann man auch vergessen. Das müßte nen AVR dann in Software machen, was noch langsamer ist. Ich habe es mir zur Zeit so überlegt, daß der Adressbus über zwei Latches geleitet wird. Beide hängen an den AD0-AD7 XRAM Ausgängen. Das eine Latch wird durch das ALE Signal gesteuert. Das andere durch das WR Signal. Der Datenbus hängt an einen unabhängigen Port.
1 | mov yl,adresshigh |
2 | st y,adresslow |
3 | ... |
4 | in daten,pinc |
Spart Ports und zum zweiten ist der Adressbus über den /OE-Steuereingänge der Latches abschaltbar. cu Hauke P.S. Auf welchem AVR seid ihr das am planen? Ich code das zur Zeit (rein aus Simulationszwecken) auf einem M128
Hallo, @A.K.: Danke, korrigiere ich. Kann mich jetzt auch an die Carry-Sache erinnern, werde wohl doch alt, ist ja schon mehr als 15 Jahre her, meine C64-Zeit... ;) Adresse zeropage+x/y habe ich sogar in der Doku als Hinweis gelesen und dann ignoriert. Stackpointer-Verhalten ist schon klar, aber was mir bei Deiner Anmerkung auffiel ist, daß der wohl nach 6510-Rest auf $FF steht und nicht auf $00, wie ich im annahm. Muß ich auch korrigieren. Beim Page-Crossing habe ich einfach noch nicht zusammengesucht, wann da genau ein Zyklus eingefügt wird, der Vergleich von PC-Highbyte vor und nach der jeweiligen Aktion muß noch rein und den 6510-Zyklus einfügen, wenn nötig. @Hauke Sattler: ich habe im Moment nur einen sehr theoretischen Ansatz für die SID-Anbindung, den ihc überlege. SID-Daten an Memory-Datenport, SID Adressen an Memory-High-Adress-Port. R/W an WR, CS an einen Extra-Port-Pin. E-Clock (Phi2) per CTC (AVR-Clock/16) erzeugen und mit Pin toggle für den SID bereitstellen. Test auf Zugriff High-$D4, also SID. Ext-Mem ausschalten, Daten auf Port, Adresse R/W auf Port, jetzt E-Zustand abwarten (CTC-Pin lesen oder ähnlich) und passend vor E L/H CS setzen und nach E H/L wieder zurück. Zurücksetzen kann man die AVR-Takte zählen, das Verhältnis ist ja konstant. Problematisch ist erstmal die Syncronisation von CTC-Phase und dem setzen von /CS des SID ohne die 6510-Zyklenlänge durcheinanderzubringen. Der Rest ist relativ unkritiisch, habe ich schonmal in einem MP-Playerversuch mit 2,5" Platte und 32k Ram am Memory-Bus so gemacht. Werde ich wohl am Wochenende mal ranstecken/löten und dem SID möglichst erstmal ein paar Töne entlocken. Irgendwelche natürlich nur.... Wäre auch noch zu klären, welche 6510-Befehle überhaupt mit dem SID eigesetzt werden können, er hat ja nur Lese- oder Schreibregister. Memory-modified-Befehle wie dec adresse usw. fallen damit ja sowieso aus und müssen dann auch nicht behandelt werden. Gruß aus Berlin Michael
Hallo, @Hauke Sattler: im Moment ein Mega8515, falls mir der Flash knapp wird durch die Tabellen auch Mega162. Allerdings kann man die Befehlsroutinen stark kürzen, wenn sie erstmal "fehlerfrei" spielen, im Moment ist alles einzeln, hat den NAchteil, daß Fehler einer Befehlsgruppe in allen BEfehlen einzeln korrigiert werden müssen, hat aber den Vorteil, daß es keine versehentlichen Abhängigkeiten gibt. Gruß aus Berlin Michael
> ist ja schon mehr als 15 Jahre her Langt aber nicht zum imponieren. AIX65 ca. 1979. ;-) > Stackpointer-Verhalten ist schon klar Aber wohl nicht richtig in den AVR-Code eingeflossen. Denn ST -Z subtrahiert ja wohl vorher, nicht nacher.
Das wäre doch mal wieder ein richtiger schönes Projekt für's Wiki! Michael: hast Du nicht Lust, das dort zumindest "rudimentär" einzustellen?
Hallo, @A.K.: naja, ich meinte mehr den C64 als solchen von mir zuletzt benutzten 8-Bitter. Ansonsten: Um 1980 Eigenbau 6800 mit 1k Eprom und 1k Ram mit hangeschmiedetem "Betriebssytem" und 300Baud Tape-Interface. So, zumindest näher dran als vorher. ;)))) Stackpointer: ich meinte gelesen zu haben pre-decrement und post-increment. Das 6510-Datenblatt bei www.6502.org ist ja nicht zu lesen, eigene Unterlagen muß ich erst suchen gehen (sofern sie hoffentlich noch existieren...). Gruß aus Berlin Michael
Hatte deshalb gestern sicherheitshalber nochmal nachgesehen. 1FF vor JSR, 1FD danach, mit Daten in 0x1FE,0x1FF. Eben deshalb wird SP ja auf FF initialisiert, nicht auf 00. Richtig fies war meiner Erinnerung nach 6800. Da hat TXS/TSX entsprechend korrigiert um die Verwirrung noch zu steigern.
der 6502 legtt beim Interrupt außer der Rücksprungadresse noch das Flagregister auf den Stack, beim AVR muß man das selbst erledigen
Hallo, @A.K. ok, hab da jetzt auch noch was gefunden, den Stackzugriff baue ich also so um, das ist ja kein Problem weiter. @Christoph Db1uq: habe ich beim RTI so drin, beim Auftreten eines IRQ muß das dann natürlich auch rein. Gruß aus Berlin Michael
Aus der Funkschau habe ich damals für meinen AIM65 einen 8080-Emulator für 6502 abgetippt, der hatte genau beim Stack-In/Decrement einen Fehler. Das wirkte sich aber nur bei einem 8080-Programm aus, das irgendwelche fiesen Stackmanipulationen ausführte, da hab ich eine Weile gesucht.
Hallo, Stack habe ich erstmal korrigiert, Frage zum Zugriffen mit X/Y-Offset: wenn ich es jetzt richtig zusammengesucht habe, betrifft es alle Zeropage-Zugriffe mit X oder Y-Offset, die den Übertrag ignorieren? Wird wohl A.K. am schnellsten wissen. ;)) Zur SID-Ansteuerung habe ich im Moment folgende Idee: CTC mit 16:1 laufen lassen und E-Clock erzeugen. Beim Start der 6510-Emu den Ablauf auf die L/N oder H/L Flanke des E-Clock syncronisieren. Dann bleibt der Kram alleine syncron und man die 6581-Zugriffe auch per AVR-Takt-Abzählreim erledigen. Frage noch zu IRQ (habe noch nichts gefunden): das IRQ-Handling startet nach der H/L-Flanke am IRQ-Eingang mit dem nächsten Opcode-Fetch des 6510? Ich komme erst morgen dazu, weiterzumachen, also ist Zeit zum Überlegen. Nein, es gibt nichts zu gewinnen... ;) Gruß aus Berlin Michael
@Michael U. Schau Dir mal diese Seite an : http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2003/jpp13/website/index.html
Hallo Zusammen, dass man einen 6502 auf einem Atmega8 emulieren kann, halte ich für nicht unmöglich. Als Referenzprojekt könnte folgender Link dienen: http://www.kmit.sk/~peto/AVR/smallpmd/ Mit einem 18Mhz getakteten Atmega8515-20 wird hier ein 8080 Mikroprozessor emuliert. Der Emulator ist OpenSource und läst sich bestimmt gut auf den 6502-Code umbauen. Gruss, ajax
Entschuldigung, ihr seit ja schon fast fertig! Habe den Thread nur überflogen. Aber egal: vielleicht bringt das Projekt ja doch noch die ein oder andere Erkenntnis für eine AVR-C64.
Angehängte Dateien:
-
AVR-SID.jpg
180 KB
Hallo, Danke für alle Hinweise. Zwischenstand: der SID spielt eine Tonleiter, Ansteuerung vom Mega8515 klappt ohne Zusatzhardware, E-Clock wird mit dem 8Bit-Timer erzeugt. :-)) Zumindest kann man sich schon einen Synthi damit bauen. ;) Die Routinen zeitrichtig in die 6510-Emu einzubauen, wird wohl noch etwas tricky werden ..... Auf dem Bild mal der Schnellaufbau: ATMega8515, 74HCT573, 62256-70, 6581. Unten MAX3232 für die Debug-Ausgaben. Stromversorgung 12V Schaltnetzteil (saut in den SID rein), 7805 für die 5V. Ram ist nur für die 6510-Emu nötig, wer also nur mit dem SID spielen will, bracuht nur einen AVR und den SID. Mehr gibt es frühestens morgen abend. Gruß aus Berlin Michael
Angehängte Dateien:
-
IM001133.jpg
97 KB
So etwas ähnliches habe ich mit einem Mega16 aufgebaut. Habe mal 2 Bilder angehangen.
muß sagen das mir das projekt echt gut gefällt. egal ob mit 6510/6502-emu oder ohne ... das der sid heute noch beliebt ist und an jeden x-beliebigen prozessor gekorkt wird (avr,8051,pic ...) zeigt ja eigentlich nur das es nach wie vor noch eine große fan-gemeinde des c64-sounds gibt. find ich witzig :-) ich muß meinen 8580 auch mal rauskramen :-) gruß rene
Hallo, @Gast: wie hast Du die SID-Ansteuerung gelöst? Eigener Takt, wie es aussieht, und die beinen kleinen ICs am SID? Latch? Schieberegister? Meine momentane Lösung scheint zu klappen, der Mega muß mit 16MHz (eigentlich mit 15,760MHz für PAL) getaktet sein, der SID hängt direkt an den Ports. Für einen Schreibzyklus werden im Moment 3 6510-Zyklen, also 48 AVR-Takte. Wenn er direkt aus einem AVR-Programm genutzt wird, kommen noch maximal 16 Takte für die Syncronisation von E-Clock dazu. Ich weiß noch nicht, wieviel Optimierungspotential ich da noch finde. ;) @TheMason: naja, Spaß an der Freude eben. ;) Erinnerung an alte C64-Zeiten. Musikalisch im Sinne von Musik mit dem SID machen bin ich garnicht. Ich habe nur mal festgestellt, daß ich keine einzige C64/SID-Emu gefunden habe, die z.B. SynthSample 100% richtig wie auf dem 6581 abspielen konnte. Ein SID-Player, der mit dem Original-SID die .sid z.B. von einer SD-Karte spielt, war das Einzige, was mir so halbwegs sinnvoll erschien. ;) Wer will, kann sicher auch einen Midi-Expander draus machen, ich denke, dann reicht Mega8515, SID, Optokoppler für Midi und Strom aus. Passt dann wohl in eine Zigarettenschachtel... Mehrere SID ranhängen ist auch kein Problem, kostet nur je ein Pin für CS von SID zusätzlich. Das ist aber weniger meine Baustelle mangels musikalischer Fähigkeiten. Gruß aus Berlin Michael
@Michael, der Sid hat einen eigenen Takt beckommen. Die beiden IC´s sind 74hc595 (Schieberegister), um port´s zu sparen. Mittels Taster kann ich alle Register des Sid einstellen. Ein Sid-Player schwebt mir auch vor, aber die umsetzung ist nicht gerade leicht.
Hallo, @Gast: naja, soviele Ports braucht man für sowas meist nicht. Man muß eben in den alten Busstrukturen denken, die benutzt wurden... 8 Bit Daten -> 1 Port für SID, Ram, evtl. Display 8 Bit Low-Adresse für Ram ist der gleiche Port, muß sowieso der 573 ran. 8 Bit H-Adresse für Ram und als Low-Adresse für SID dazu als Einzel-Pins: SID_CS, SID_RW (könnte der Pin von Ram-WR benutzt werden, wenn das extMem abgeschaltet ist und man auf die Vorbelegungen des Ports aufpasst, allerdings muß ich für den "C64" sowieso 64k Ram ranhängen und dann müßte ich die SID-Adressen in Hardware ausdekodieren...). SID_E hängt am Toggle-Pin des 8Bit-Timers dran. SID_Reset braucht man nicht zwingend (PowerOn-Reset in Hardware basteln), wenn aber z.B. das Display auch Reset will, kann man einen Pin opfern. Der UART ist belegt für mich als Debug. SPI zum Programmieren und für eine SD-Karte (kommt noch ein CS dazu). Ich habe die Port-Belegungen noch nicht sonderlich optimiert, im Moment sind also noch frei: PB2...7 (SPI dabei) PD2...5 (Rest ist UART und extRam RD/WR) SD-Card an SPI, SD_CS an PB4 Display Daten an PA0 mit ran, RW an SID_RW, RS an A8, bleibt noch E von Display an PB3. PD2...5 für 4 Tasten, bleibt noch PB2 als Reserve oder Erweiterung auf 8 Tasten (2x4 Matrix). Das geht alles noch ohne Zusatz-Hardware am Mega8515. Wenn ich was übersehen habe, muß ich eben umräumen. ;) Habe gerade noch den SID-Zugriff auf 2 6510-Zyklen, also 32 AVR-Takte zusammengekürzt, nur wenn (wie im Test jetzt) die Daten aus dem Flash mit LPM geholt werden, fehlt mir ein Takt und ich muß einen 6510-Zyklus einfügen. Gruß aus Berlin Michael
@michael : der spaß anner freud steht hier doch bestimmt bei den meisten projekten im vordergrund. sonst hätte der björn bestimmt nicht sein mega-geiles retro-nokia mit wählscheibe gebaut, oder :-) oder ich meinen audio-prozessor, oder jemand anders seinen nussknacker, oder oder oder ... ;-) ist ja eigentlich auch das was beim hobby im vordergrund steht oder ? :-) die idee mit dem midi-sid gibts ja (leider) schon. aber trotzdem witzig das so viele noch den sid verbauen möchten. schade nur das es so schwierig ist das teil zu bekommen. jedenfalls bin ich mal gespannt was dieser thread noch hergibt. weiter so ! :-) gruß rene
@Michael, hast du es schon fertig ? Ich mein, kannst du schon .sid-Files abspielen ?
Besonders reizvoll fände ich es ja, wenn man den SID in einem 2ten Atmega emulieren würde. Jaja, ich weiß, die Puristen sagen jetzt: Kein Emulator hat bis jetzt den SID-Sound zufriedenstellend erzeugt, also kann es mir einem ATMEGA nur schlechter werden. Aber hier geht es ja um's Hobby: Wie wär's Atmega8, 8Bit PWM Ausgang und SID emulieren? Gruß, ajax
Hallo, @TheMason: naja, SID bekommen... Hängt eben meist ein C64 drumrum... ;) Sind aber bei ebay meist billig zu finden. Midi-SID gibt es, weiß ich. Wäre eben nur der Vorteil der Kosten (1 SID + ein ATMega und etwas Hühnerfutter) und der Spaß, die Midi-Befehle und Effekte nach eigenem ermessen zu vergeben. Ein SID, der General-Midi kann, wäre zumindest lustig. :) @Gast: nein, spielt noch nichts weiter. Der 6510-Emulator ist soweit fertig und macht wohl auch, was er soll. Der SID läßt sich ansprechen und spielt. Für die .sid-Files fehlt noch das nötige C64-Umfeld, zumindest der Standard-Timer-IRQ muß laufen, Teile der Vektortabelle müssen sinnvoll gefüllt sein und wenn die Leute genug genutzt haben, muß auch die Bankumschaltung mit allen noch unklaren Nebenwirkungen noch rein. Dazu müssen dann vermutlich die vollen 64k Ram ran, das ist aber kein Problem. Ich habe hier ein .sid-File, daß ist nur 636 Byte lang, die Play-Routine hängt sich nur zusätzlich in den C64-IRQ rein. Wenn er das Teil abspielt, ist schon viel gewonnen. Dann baue ich erstmal ein UART-Protokoll (X-Modem oder so) rein, damit ich .sid-Files direkt reinladen kann und teste weiter. @ajax: naja, das Problem sehe ich in der Komplexität der Geschichte. Der SID hat 3 Stimmen mit eigenem ADSR, Dazu die Filer, Ringmodulation und noch ein paar Sachen, die sich gegenseitig beeinflussen können. Im SID läuft das intern unabhängig parallel ab, der AVR muß es in der gleichen Zeit seriell bearbeiten... Vielleicht als Ansatz: 3 kleine AVR, je eine Stimme rauf, extern zusammenmischen, ein AVR als Steuerung und für die Abhängigkeiten. Per oder über 8Bit-Port verkoppeln. Wenn sich da rausstellt, daß es in einen passt eben "zusammenkleben". Ich stelle den aktuellen Source-baukasten nachher hier noch rein, die Anschlüsse für den SID stehen oben im definitionen.inc drin, falls jemand löten will. ;) Die Source ist so, daß er eine Tonleiter auf dem SID spielt. Gruß aus Berlin Michael Gruß aus Berlin Michael
@ajax ich glaub net das das hinhaut .... ich denke die filter zu realisieren wird das größte problem sein. man muß zwar nicht iir-filter nehmen (gibts bestimmt einfachere algorithmen), aber als samplerate sollte man wenigstens 8kHz (am besten 12-16kHz) nehmen. und da wirds dann schon etwas eng, da man intern bestimmt nicht mit 8 bit rechengenauigkeit auskommt. habe mal versucht auf einem msp430 einen monophonen synth zu basteln. ist recht eng geworden (bei 8kHz samplerate) und ich hatte nur 1 ozillator + 1 iir-filter (in asm), also noch nix mit envelopes, mehreren wellenformen, sync usw. wobei der msp ja den vorteil hat das der einen hw 16-bit mac hat. also ich denke einen sid im avr zu emulieren (egal ob puristen die nase rümpfen würden :-), cih würde es als bemerkenswert empfinden, selbst wenn das dingen nicht so klingt wie ein sid) dürfte schwieriger werden als einen 6502/6510 zu emulieren ...
Hallo, @heMason: sehe ich ähnlich mit dem SID. Ansonsten: ich habe noch 3 C64 hier, alle 3 laufen noch, einer mit Kernel-Umschaltung 8-fach. Mein Bekannter hat letztens ca. 10 C64, 5 1541-II, Datasetten bei ebay soweit ich weiß als Paket versteigert, sind für wenige Euro weggegangen. Sie wegzuwerfen (wäre die einzige Alternative gewesen...) brachten wir beide nicht übers Herz. Von meinen 3 Reserve-SID (2x 6581, 1x 8550) ist ein 6581 wohl tot, keine Spannung am Audio-Out. Wir haben vor ein paar Jahren etliche defekte C64 in Ersatzteile zerlegt, Reparatur lohnte mangels Nachfrage einfach nicht. So richtig schlechtes Gewissen habe ich bei C64 schlachten also nicht. Überleben wird sicher mein ältester 64er, alle ICs ab Werk gesockelt. :) Ist auch Testobjekt für die anderen ICs, muß ihn nur mal vorkramen. Eine FinalCartrdge-III und eine Nordic-Power habe ich noch aufgehoben, alles andere ist sowieso weg. Midi-Interface und Steinberg-Software auf Eprom-Modul ist auch weg, hatte ich von einem Musikus, für den ich mal Hals über Kopf eine Midi-Synconizer zusammenlöten mußte, weil wohl der einzige in der DDR existierende gerade woanders im Einsatz war... :) Naja, meiner lief zumindest merklich zuverlässiger als das Original, der überlebte auch Schlagzeug auf der Nachbarspur eines 4-Kanal Vostex-Taprecorders. Ich habe inzwischen die SID-Write-Routine auf 2 6510-Zyklen (32 AVR-Takte) zusammengeschrumpft, damit macht es Sinn, über die Verknüpfung mit der 6510-Emu nachzudenken... Ich hänge das Archiv mal ran, falls einer basteln will. ;) Gruß aus Berlin Michael
Hallo Michael, >@ajax: naja, das Problem sehe ich in der Komplexität der Geschichte. Der >SID hat 3 Stimmen mit eigenem ADSR, Dazu die Filer, Ringmodulation und >noch ein paar Sachen, die sich gegenseitig beeinflussen können. >Im SID läuft das intern unabhängig parallel ab, der AVR muß es in der >gleichen Zeit seriell bearbeiten... Na, dann basteln wir doch ein kleines Multitaskingsystem in den ATMEGA. Spass beiseite, nachdem so viele Leute der Meinung sind, den SID auf einem ATMEGA zu emulieren geht nicht, reizt mich die Aufgabe ja enorm. Ich glaube, dass man 3 Tongeneratoren/Rauschgeneratoren + Hüllkurvengeneratoren in einen ATMEGA8 reinkriegen kann. Die Filter passen eventuell auch noch, die würde ich aber für den Anfang mal vernachlässigen. Das Hauptproblem sehe ich im Kommunikationsinterface der beiden Atmegas. Hast Du eventuell Lust, das Interface für einen ATMEGA8-Emulator-SID anzupassen? Gruss, criha
Hallo, in der Verbindung sehe ich wenig Probleme, letztlich ist es ja immer ein Pärchen SID-Adresse und die Daten dazu. Ob jemand die 2 Leseregister benutzt, weiß ich noch nicht, scheint aber wohl nicht so. Also z.B. als 2x 8Bit per SPI rüberschieben. Würde zumindest kein Problem sein. Ich habe inzwischen die hoffentlich ;) letzten Fehler im 6510 ruasgebaut, einen provisorischen .sid-Lader geschrieben und das kurze SID-File erstaml mit ins AVR-Flash gelegt. Er lädt also nach Reset den Kram und startet auf der richigen Adresse die Init-Routine. Jetzt werde ich erstmal den 50Hz-VBLANK-IRQ einbauen und die SID-Registerzugriffe einbinden. Dann könnte er das kleine File eigentlich schon abspielen... Gruß aus Berlin Michael
Also wenn Du die Kommunikation einbauen kannst und an einem Atmega8 SID interessiert wärest: Ich werde mal innerhalb der nächsten Zeit versuchen, Teile des SID zu realisieren. Sobald ich die 3 Oszillatoren und die 3 Hüllkurven habe, werde ich mich auf die Kommunikation konzentrieren. Hier mal ein Beispiel zu meinen Tests mit einem Attiny13. ( 8Bit PWM, abfallende Hüllkurven, 3 Oszillatoren ). Gruss, Christoph
Michael U. wrote: > Ich habe inzwischen die hoffentlich ;) letzten Fehler im 6510 > ruasgebaut, einen provisorischen .sid-Lader geschrieben und das kurze > SID-File erstaml mit ins AVR-Flash gelegt. > > Er lädt also nach Reset den Kram und startet auf der richigen Adresse > die Init-Routine. Jetzt werde ich erstmal den 50Hz-VBLANK-IRQ einbauen > und die SID-Registerzugriffe einbinden. Dann könnte er das kleine File > eigentlich schon abspielen... Hallo Michael, Das ist ja wirklich unglaublich mit was für einem Ehrgeiz und einer Geschwindigkeit Du dich in die Sache reinhängst... Geil. Ich bin immer noch am Codelesen und hoffentlich verstehen und Du hast das Ding schon fast fertig. Ich habe mir mal so einige dieser SIDPLAY Routinen aus der HVSID-Collection genauer angeschaut und kann jetzt mit grosser Wahrscheinlichkeit behaupten das in diesen eigentlich nie Illegaler 6502 oder 6510 Opcode benutzt wird. Jetzt stellt sich mir die grundlegende Frage wie das Sid-File in den Emu kommt. Per RS232 würde sicherlich gehen, ist aber unpraktikabel. USB wäre natürlich der Hit, aber ich denke da mehr an Flashrom welches mit der Seriellen zu betanken wäre. Die Sids fressen ja glücklicheweise fast nichts. Soll ja evtl mal Tragbar werden. Ich muss hier mal meiner Begeisterung freien Lauf lassen und lobe hiermit 3 Kisten Kaltgetränk freier Wahl, aber unter 10% ALC an denjenigen aus der es hinbekommt den SID-File im Anhang auf Michaels Emu Klanglich störungsfrei laufenzulassen. Michael ist natürlich als Entwickler mit dabei... Die Kisten müssen aber regulär in DE auch kaufbar sein. Achso: ich Liefer nur in innerhalb DE und werde natürlich selbst liefern. Grüße Björn
Warum nehmt ihr nicht einen avr mit externem ram? also mega128 oder 8515?
Mista IKS wrote: > Warum nehmt ihr nicht einen avr mit externem ram? also mega128 oder > 8515? Lies Dir mal den Thread durch... Gruß Björn
Hallo, @Björn Wieck: Deine Begeisterung freut mich. :))) Vieles ist Baukasten und Copy-Paste, außerdem war mir Assembler schon immer sympathisch, man weiß genau, was passiert. CPUs würfeln nicht- ;) Illegal OpCodes: vorerst kein Problem, die 6510-Emu dekodiert sowieso alle 256 Kombinationen per Tabelle, alle unbekannten landen in der Debug-Ausgabe. Ich schreibe den Ram auch weitgehend mit $FF voll, so daß falsche Sprungziele sich melden. Für die SID-Files habe ich eigentlich MMC/SD-Card angedacht. ich weiß aber jetzt nicht, ob irgendwo eine spartanische ReadOnly-FAT16 möglichst in ASM rumliegt. Ram ist ja nicht das Problem, Laden und Spielen gleichzeitig geht sowieso nicht. Ich wollte zum Test erst X-Moden einbauen, allerdings habe ich gestern nichts "mundgerechtes" gefunden, daß ich nur reinhängen müßte. Deshalb ist eben jetzt erstmal das 15BB.sid fest im AVR-Flash. Dein SID-File ist erstmal eingelagert. :) Gruß aus Berlin Michael
Hallo, habe noch was zum thema Sid-Files gefunden. Vieleicht hilft es......
Weiss jemand von euch, wie die Ring-Modulation genau funktioniert? Angeblich ist es ja keine FM-Synthese. Im Datenblatt wird das nur ungefähr beschrieben. Gruss, Christoph
Hallo, zu diesen Details des SID weiß ich ertmal leider garnichts, ich werde aber über Ostern auch mal kramen... Zum Stand der Dinge: es gibt jetzt den VBlanc-Interrupt (50Hz PAL vorerst) mit dem 16Bit-Timer. Aufruf usw. sind eingebaut, ich baue gerade die Dummy-Routinen drumrum, damit der "C64" sinnvoll wartet... ;) Also Loop als Basic-Prompt-Ersatz und Interruptroutine, die aus RTI besteht. Muß erstmal die Debugumgebung irgendwie anpassen, 20ms-Timer-IRQ für den 6510 aktiv haben und Single-Step mit UART-Ausgabe zu machen, verträgt sich irgendwie nicht so ganz richtig... Ansonsten noch diverse Fehler in der 6510-Emu beseitigt, vor allem das doppelt eingebaute Status-Register mit mal hier - mal da - Benutzung der Flags bereinigt. :( Archiv wird es wohl so Karfreitag geben, wenn das Wetter schlecht ist. ;) Gruß aus Berlin Michael
@chriha ringmodulation war meine ich "nur" das du das ausgangssignal des einen oszillators mit dem eines anderen muplitplizierst (so wird jedenfalls meine ich ein ringmodulator aufgebaut) bin mir aber nicht ganz sicher ob das beim sid genau das ist (meine aber schon, da das ein feature der synthies zu der zeit gewesen ist)
nach einiger Suche habe ich schon etwas mher dazu gefunden: On the C64 SID chip, ring modulation multiplies a triangle wave with a square wave. Beitrag "6502 Emulation auf AVR ?" Dreieck mit Rechteck multiplieziert also. Müsste man eigentlich hinkriegen, oder?
Upps, Rechtschreibfehler und falscher Link. Muss langsamer schreiben und genauer lesen. Hier also der Link: http://en.wikipedia.org/wiki/Ring_modulation Interessant ist auch, dass der Begriff aus der Anordnung der Dioden in einem Diodenmischer stammen, bei dem die Kathoden alle in eine Richtung zeigen ( anders als beim Brückengleichrichter ) http://de.wikipedia.org/wiki/Ringmodulator stochri
Für die Taktzyklen der 65xx-Instruktionen könnten folgende PDFs interessant sein: http://www.bitsavers.org/pdf/mosTechnology/
Hallo Michael, was machen die Programmierfortschritte? Ich habe gerade eine URL gefunden, die für Dich interessant sein könnte: http://digilander.libero.it/ice00/tsid/tinysid2/ Kann es eventuell sein, dass die meisten SID-Programme nur Schreibzugriffe durchführen? In diesem Fall sollte man die Registerzugriffe ja einfach sampeln und abspeichern können. Das würde in den meisten Fällen ein relativ kompakter Datensatz ergeben. Z.B. in der Form -setRegisters Sound0 -Wartezeit Sound0 -setRegisters Sound1 -Wartezeit Sound1 ...... Gibt es Datenfiles für Sid-Sounds in einem ähnlichen Format? Gruss, stochri
Hallo, sieht gut aus oder auch nicht... ;) Ich habe noch etliche Fehler in der 6510-Emu gefunden und bereinigt, von Tippfehlern über Fehler im Ablauf bis zu Verständnisproblemen meinerseits. Es ist sogar relativ sicher, daß meist nur Schreibzugriffe stattfinden, einfach deshalb, weil die wichtigen SID-Register nur Schreibregister sind. Es gibt nur 4 nur-Leseregister, davon sind 2 die AD-Wandler der Paddleports (uninteressant also), eins ist der Oszillator 3 zum Zufallszahlen erzeugen (wohl auch uninteressant) und das letzte ist der Wert des Hüllkurven-Generators von Stimme 3, der könnte vielleicht genutzt worden sein. Dazu kommt noch, daß wohl 9x% Prozent der Playroutinen sich in den VBLANC-IRQ reinhängen, also mit 50Hz (PAL) oder 60Hz (NTSC) aufgerufen werden, ein paar Werte im SID setzen und dem System wieder die Kontrolle überkläßt. Man könnte also durchaus eine Tabelle zusammensamplen, die für jeden IRQ die Adressen und Daten enthält und diese alle 20ms (16,67ms) abarbeiten. Ich wüßte aber nicht, daß das bisher jemand so gemacht hätte. Ich kann auch auf Zyklen-genaues Abarbeiten des 6510 eigentlich verzichten, solange nur im IRQ gespielt wird. Im Moment mache ich aber erstmal trotzdem so weiter und suche Fehler im 6510. ;) Gruß aus Berlin Michael
@criha >Kann es eventuell sein, dass die meisten SID-Programme nur >Schreibzugriffe durchführen? kann nicht nur sein, ist sogar so. :-) der sid hat nur wenige lese-register (2 paddels, envelope 3 level und noch irgendeins) ansonsten sind alle anderen register (frequenz, wellenform, hüllkurven, filter, usw.) write only. gruß rene
Hallo Michael, >letzte ist der >Wert des Hüllkurven-Generators von Stimme 3, der könnte vielleicht >genutzt worden sein. Das Datenblatt zum SID habe ich mittlerweile ziemlich ausführlich gelesen. Genau hier hätte ich die Probleme vermutet, falls das zurücklesen des Hüllkurvengenerators für Synchronisationsprozesse genutzt würde. Mittlerweile habe ich mir mal ein kleines Testarray gebastelt, mit der ich die Registerwerte meines virtuellen Atmega-Sid beschreiben kann. Die sieht so aus: static uint8_t sound[] PROGMEM ={ // voice1 4,0x11, // set waveform 5,0xBB, // attack/decay 6,0xAD, // sustain/release // voice2 11,0x11,// set waveform 12,0xCB, // attack/decay 13,0xAD, // sustain/release // voice3 18,0x11,// set waveform 19,0xCB, // attack/decay 20,0xAD, // sustain/release // C4 1,0x11, 0,0x25, // 0.5 second 0xF0,0x00, // pause low 0xF1,0x02, // pause high } Die erste Zahl ist immer die Registeradresse, die zweite Zahl der Wert. Im Anhang der gesamte Testsound. Gruss, christoph
So hört sich der ATMEGA-SID mit 8Bit PWM-Ausgang an. Er wird mit den Registerwerten aus dem vorigen Post beschrieben. Kurz gegen Ende werden die 3 Oszillatoren mit abklingenden Hüllkurven gleichzeitig benutzt, dann gibt es Schwebungen. Am Schluss wird von Dreieck auf Sägezahn umgeschalten, das klingt dann allerdings eher wie ein Hupe... Auf einem realen SID klingt das bestimmt noch etwas runder.
>Ich habe noch etliche Fehler in der 6510-Emu gefunden und bereinigt, von >Tippfehlern über Fehler im Ablauf bis zu Verständnisproblemen >meinerseits. So geht's mir mit dem ATMEGA-SID auch. Eigentlich habe ich gedacht, ich würde das in 2-3 Tagen schaffen, aber leider tauchen immer neue Probleme auf. So langsam läuft mir ein wenig die Zeit davon, bei dem schönen Wetter ( zummindest hier im Süden) kann man ja nicht die ganze Zeit vor dem Rechner sitzen. Gruss, Christoph
Ziemlich beachtlich, bis jetzt. Bin schon gespannt auf das endgültige resultat..
Hallo NG, ich habe diese Diskussion ein bischen verfolgt. Ganz schön cool, was ihr da macht. Ich bin auch gerade dabei einen portablen SID-player zu basteln. Ich habe mir allerdings vorgestellt, das Ganze zunächst in C# zu stricken und den (original) SID dann per Parallelen Port anzusprechen. Der 6510 Emulator ist fast fertig. Kennt einer von euch ne Quelle, wo man die Addition und Subtraktion (vor allem im Dezimal-Mode) mittels ADC und SBC 100% emuliert hat? Ich bin da ziemlich detailverliebt, wenns auch unnötig ist... Wenn das dann läuft habe ich mir vorgestellt, das Ganze auf nen Atmel oder Arm zu portieren. Mal schauen. Ich tendiere allerdings eher zu nem ARM, weil ich da schon ein günstiges Entwicklerkit mit SD-Reader und LC-Display gesehen habe. Viele Grüße, Peter
>Ich habe mir allerdings vorgestellt, das Ganze zunächst in C# >zu stricken und den (original) SID dann per Parallelen Port >anzusprechen. Der 6510 Emulator ist fast fertig. Ist ja witzig, dass sisch soviele Leute für eine historischen Sounderzeugung interessieren. Den C# Code auf einen Atmega zu übertragen dürfte wohl wenig Erfolg beschieden sein. Da führt wohl nur Michaels Assembler-Emulator-Methode zum Erfolg. Bei einem 70Mhz ARM könnte ich mir das schon eher vorstellen. Meine Sound-Emulation ist bis jetzt übrigens auch noch C pur, allerdings ziemlich stark an das Timing des ATMEGA8 mit 16MHz gebunden. Aber so langsam wird es schon eng und vielleicht komme ich um ein paar Zeilen Assembler nicht herum. Christoph
>Den C# Code auf einen Atmega zu übertragen dürfte wohl wenig Erfolg >beschieden sein. Da führt wohl nur Michaels Assembler-Emulator-Methode >zum Erfolg. Bei einem 70Mhz ARM könnte ich mir das schon eher >vorstellen. Das denke ich auch. Wollte nur die Emulation zuerst mal mit einer "leichtverständlichen" Sprache umsetzen, damit ich weiß, was gemacht werden muss, und damit ich verstehe, was abläuft. Danach möchte ich das dann schon auch in Assembler umsetzen. Habe da nur schon ewig nichts mehr gemacht damit, und meine Mikrocontrollerkenntnisse sind auch noch nicht so groß. Aber ich habe ja Zeit (zumindest manchmal :-) ... Peter
Für diejenigen die es intersessiert, und behaupten emulation auf dem AVR währe nicht möglich. schaut mal hier http://www.swinkels.tvtom.pl/swinsid/
Hallo! Soweit ich das sehe gibt es Probleme beim Speichermapping. Aufgrund des direkten Zugriffs per ATMega-Speicherinterface in der Emulation kommen sich die 6502-Zeropage-Adressen $00 bis $5F (8515: Register File und I/O-Bereiche) und der 8515-Stack, der auf das Ende des internen 8515-SRAM initialisiert wird und somit den 6502-Bereich $025F bis $0060 nutzt in die Quere. Im Übrigen benötigen bei den AVRs Zugriffe auf externes RAM einen Takt mehr als Zugriffe auf internes RAM. -Lutz
Hallo SID Fans! Sehr interessant was hier gerade passiert, ich beschäftige mich selbst seit einer Weile damit nen portablen SID-Player zu bauen. Inzwischen hab ich einen Prototypen aufgebaut der .sid files von einer FAT formatierten SD Karte lädt. Das ganze ist allerdings noch alles andere als zyklengenau und optimiert, sondern mangels Zeit eher noch in der proof of concept Phase. Falls es interessiert, hier eine kleine Übersicht + Beschreibung: Hardware: - ATmega128 @ 16MHz - 64kb SRAM - 6581 R4AR SID - LM386 als Audioverstärker Software: Der 6510 Befehlsinterpreter ist komplett in C geschrieben und ist rein auf das Abspielen von .sid Musikstücken ausgelegt. Die Musikstücke bestehen im wesentlichen aus einer Init Routine und einer Play Routine, wobei die Play Routine (zumeist) im 50 Hz Takt aufgerufen wird. Genau das macht meine Software auch - beim Laden eines Songs wird einmal die Init Routine und dann per Interrupt mit 50 Hz die Play Routine "aufgerufen". D.h. emulierten Programcounter entsprechend setzen, Emulation starten, und bis zum Rücksprung von der Play Routine (welcher abgefangen wird) laufen lassen. Zur zeitlichen Genauigkeit der Emulation ist zu sagen, dass zwischen 2 Aufrufen der Play Routine theoretisch 20 ms Zeit sind um die Routine auf dem emulierten 6510 abzuarbeiten. Selbst wenn die Emulation zu langsam und nicht zyklusgenau läuft ergibt das "nur" einen zeitlichen Fehler beim Setzen der SID Register im Mikro- oder Millisekunden Bereich. Akustisch macht sich das vermutlich hauptsächlich bei Effekten bemerkbar die auf mehreren Zugriffen auf das selbe SID Register innerhalb eines Play-Durchlaufs aufbauen. Insgesamt kann ich sagen das die meisten Songs im Moment schon recht passabel bis sehr gut abgespielt werden. Trotzdem hatte ich eigentlich von Anfang eine Assembler-Optimierung (erspart vor allem das aufwändige Berechnen der Flags) und letztendlich auch zyklusgenaue Emulation geplant. Zum Testen der Emulation und einzelner Instruktionen war es übrigens auch sehr hilfreich eigene Testprogramme mit einem C64 Crossassembler zu erstellen (z.B. Relaunch64 + ACME) und diese dann auf einem funktionierenden Emulator (z.B. VICE) und dem eigenen Emulationcore zu debuggen. Das angehängte Foto zeigt den Prototyp in Aktion (den Sound kann man allerdings schlecht einfangen), man glaubt garnicht wieviele SID Songs auf eine 8MB SD Karte passen :D. Wenn sich jemand den output anhören will kann ich evlt. auch mal ein kleines mp3 aufnehmen. Philipp
Angehängte Dateien:
-
sidbox_mini2.jpg
140 KB
Sorry, Dateianhang war nach der Vorschau scheinbar weg, und lässt sich auch nicht rein-editieren. Deshalb hier noch ein Versuch. Philipp
Hallo, da Ostern war, ist bei mir nicht allzuviel passiert. Verblüffend, wer da alles bei ähnlichen Ideen und Projekten am Basteln hat... :))) @Lutz Legero: naja, ich habe mich vorerst etwas aus der Affaire gezogen: die Zeropage liegt vorerst auf 0x400, den Videoram des C64. Die Zeropagebefehle werden direkt umgeleitet, falls jemand da Zugriffe mit 16Bit-Adressierung auf die Zeropage benutzt haben sollte, falle ich im Moment auf die Schnauze. ;) Allerdings kann ich das abfangen, die Zugriffe auf 0xD400 werden ja auch schon rausgefiltert... Mit taktgenauer Emu des 6510 wird es allerdings bei den 2-Zyklen-Befehlen verdammt eng... IRQ-Handling ist drin und läuft, VBLANC-IRQ läuft, wird jeweils zum Beginn eines 6510-Befehls per Polling abgefragt und emuliert, wenn nötig, einen 6510-IRQ. D-Flag habe ich noch ganz ignoriert, ob die C-Behandlung bei SBC 100% stimmt, bin ich auch noch am Testen. Gruß aus Berlin Michael
@Björn Wieck: Hast du zu dem Driller.sid ein mp3 wie sich das korrekt anhören sollte? Hab im Moment keine einfache Möglichkeit es am C64 abzuspielen, habs aber mal auf meiner SIDBox laufen lassen. Die ersten 30 Sekunden hab ich angehängt. Die vollen ~10 Minuten (4.7MB) gibts hier: http://wwwhsse.fh-hagenberg.at/Studierende/hse03003/SIDBox_driller.mp3 Und hier noch ein kleines ~3 Minuten (1.3MB) Medley mit dem aktuellen Inhalt meiner SD Karte. Sind ziemlich viele Sachen von Danko Thomas dabei, und ein paar Klassiker. Draxish, Reactions, Introtune1, Plasticpop, Turrican Mix, Kikstart II, Katakis, Giana Sisters ... um ein paar zu nennen. Bei Giana Sisters stimmt irgendwas nicht ganz, laut SidPlayWin sollte da noch mehr zu hören sein, bei mir ist die "fehlende" Stimme nur gaanz leise zu hören. Entweder ist der Song nicht auf den 6581 ausgelegt, mein Chip hat was, oder es liegt an der Emulation. Hab den speziellen Subsong leider nie am C64 gehört. http://wwwhsse.fh-hagenberg.at/Studierende/hse03003/SIDBox_medley.mp3 Vielleicht gibt der Sound ja Motivation zum weiter Entwickeln :).
@Philipp: Ich hab kurz ne Frage zur "SIDbox_medley". Wie heißen die SIDs die an folgenden Zeitpunkten anfangen: 0:18, 0:31,0:47,1:00 und 1:11 Schonmal Danke und Gruß, SIGINT P.S.: Hey Leutz, das ist echt super, was hier abgeht. Mit euerem Talent kann es ja nicht mehr lange dauern bis ein brauchbarer SID-Player, auf Basis von ATmegas, fertig ist. Leider kenn ich mich nicht wirklich mit der Materie aus, so daß ich nicht viel beitragen kann. Ich bin aber schon richtig gespannt auf das Endergebniss und wünsche noch erfolgreiches Schaffen. abo
Hallo, was bringt der schönste SID-Sound bei miserablem Sequencing? Das Medley ist schlimmer als der Nachbarsjunge mit der ersten E-Gitarre beim Üben von 'Smoke on the water' (Kann Tage dauern, wird nur lauter statt besser...) Ein bisschen Kreativität abseits der Elektronik wäre auch gefragt. Der Kritiker
>SIDBox_driller_short.mp3
Upps, wenn ich mir das so anhöre, muss man wohl doch noch den Filter in
den Emulator einbauen.
Es wäre super, wenn man von dem Stück das zeitliche Beschreiben der
SID-Register in ein Tabelle extrahieren könnte.
Damit liese sich der Emulator prima testen.
Christoph
@sigint: 00:18 Introtune_1.sid, Danko Tomas 00:31 Censor_Introtune.sid, Danko Tomas 00:47 Jump.sid, Danko Tomas 01:00 Luft_Med_Isbit.sid, Danko Tomas 01:11 Plastic_Pop.sid, Danko Tomas (davon hat er vor ein paar Jahren auch mal nen remix als mp3 gemacht) @Kritiker: Ich weis nicht ob ich dich richtig verstehe, aber der Sinn davon war eigentlich nur mal eben den Verzeichnisinhalt durchzugehen, nicht etwas musikalisch wertvolles zu schaffen. Die Reihenfolge der FAT directory entries bestimmt übrigens der Einfachheit halber auch die Reihenfolge der Songs :). @Christoph: Einen ATmega-SID wollte ich auch schon machen um die echten SIDs beim Entwickeln zu schonen. Kannst du ein bißchen beschreiben wie du im Moment vorgehst? Benutzt du zur Ausgabe wirklich einen PWM Ausgang (hast du weiter oben geschrieben) oder inzwischen schon parallel + dac? Das extrahieren in eine Tabelle sollte eigentlich kein Problem sein, wenn ich Zeit habe schau ich mal was sich machen lässt. Philipp
>Benutzt du zur Ausgabe wirklich einen PWM Ausgang
Es wird wirklich nur der PWM-Ausgang benutzt (8Bit). Die Dynamik der
einzelnen Stimmen ist allerdings auf 256/3 begrenzt, da sich die
Spitzenamplituden ja überlagern können. Klingt aber trotzdem
einigermaßen gut ( siehe Beispiel weiter oben ). Es gibt einen
Interruptroutine, die mit 32Khz angesprungen wird. Ein neues Sample wird
allerdings nur jedes 2te Mal berechnet.
Das ganze ist eigentlich ein "wave table synthisizer", aus
Rechenzeitgründen und da das Programm in C geschrieben ist. In Assembler
könnte man die Ausgabe direkt berechnen.
Die main-Schleife läuft mit 1Khz, dort werden auch die Einhüllenden
berechnet.
Gruss,
Christoph
@Christoph: Danke für die Beschreibung. Habe mal versucht die Schreibzugriffe auf den SID in den ersten 3 Minuten von Driller.sid zu loggen. Vielleicht kannst du dir daraus die für dich relevanten Registerzugriffe rausfiltern und ein Testarray erzeugen. Hier ein kleiner Auszug der Tabelle kommentiert:
1 | #1 -> Erster Aufruf der play-routine |
2 | 00090 d404 00 -> Nach 90 Zyklen wird 0x00 auf 0xD404 geschrieben |
3 | 00094 d40b 00 |
4 | 00098 d412 00 |
5 | 00104 d418 0f |
6 | 00242 d409 e0 |
7 | 00258 d40a 02 |
8 | 00391 d410 50 |
9 | 00407 d411 0c |
10 | |
11 | #2 -> Zweiter Aufruf der play-routine |
12 | 00349 d401 07 |
13 | 00368 d400 e9 |
14 | 00391 d404 40 |
Die Adresse und Daten sind jeweils hexadezimal angegeben, der Rest dezimal. Die Zyklen beziehen sich immer auf den aktuellen Aufruf der play-routine, bei den Zyklen hab ich allerdings nicht die Sonderfälle beim Überschreiten von page-Grenze berücksicht, manche Befehle brauchen dann einen Zyklus mehr. Zwischen play-routine Aufrufen liegen jeweils 20 ms. Philipp
von der Sinnhaftigkeit des Vorhabens mal abgesehen... Aber der Denkfehler den viele hier machen ist ganz einfach: Ein 6502 ist im Endeffekt ein Clone vom Motorola 6800 (da haben sich ein paar Motorola Mitarbeiter damals selbständig gemacht) und somit ein CISC Prozessor. Dh er braucht für einen Befehl MEHRERE Taktzyklen! Der AVR braucht meist nur 1 cycle, kann also wirklich 16 MIPS (Million Instructions Per Second) abarbeiten. Ein 6502 wird mit 1MHz bei geschätzt 0.3 MIPS oder sogar darunter liegen. Pro Takt kann auf jeden Fall nur 1 Byte verarbeitet werden, und ein indirekt indizierter load verbrät sicher an die 8 Zyklen. Ein multiply wahrscheinlich um die 25 rum. Das Problem ist also wahrscheinlich weniger die Geschwindigkeit, als das exakte timing. LieGrü, strub
Hallo, @struberg: eigentlich sind 2 völlig unabhängige Probleme: eine Zyklengenaue 6502-Emu auf einem 16MHz-Avr ist hart an der Grenze des Machbaren, ohne einige Tricks sind die 2-Zyklen-Befehle des 6502 nicht Taktgenau zu emulieren. Anders beim SID-Player. Wohl 9x% der SID-Files spielen in der C64-üblichen Art: im VBLANC-IRQ wird alle 20ms die Playroutine aufgerufen und aktulisiert die nötien SID-Register. Dabei ist nichts zyklengenau nötig, es muß nur ausreichend schnelle gehen. Das macht es aber in jeder denkbaren Variante, weil der 16NHz-AVR etwa einen 3MHz 6510 emuliert. Abweichungen im 6510-Timing stören da nicht, weil die Aktukisierung der SID-Register akustisch sozusagen gleichzeitig erfolt. Dazu kommt, daß ein SID-Player auf dem AVR nicht noch die Routinen berbeiten muß, die der Original-C64 ja noch als Hauptbeschäftigung beim Musik spielen erledigen mußte. Also Init aufrufen und ok. Dann im 20ms-IRQ die Playroutine durcharbeiten und fertig. Ich schätze die CPU-Last dabei auf ca. 10-20%... Das werde ich vermutlich am Wochenende soweit haben, daß ich es genauer weiß... Ich habe mit der Zyklengenauen Emu angefangen, weil ich wissen wollte, ob es überhaupt Sinn macht. Macht es, für den SID-Player aber unnötig. Gruß aus Berlin Michael
Hallo NG, also ich bin jetzt bis auf 10 Befehle auch durch mit meinem C# Emulator. Jetzt interessiert mich aber trotzdem noch eins: Wie sieht das eigentlich hardwaretechnisch aus mit den Sidfiles, die Digi-Sounds verwenden? Wie werden die Digi-Daten an den Sid geschickt? das kann ja nicht nur jede 1/20 Sekunde sein? Ich habe mal irgendwo gelesen, dass die Samples so um die 6KHz Samplingrate hätten... MfG Peter
@Peter: Das basiert auf einem Bug des 6581, wenn die Lautstärke eines Kanals geändert wird hört man ein leichtes "Knacken" am Ausgang. Durch schnelles Ändern der Lautstärke können so kurze Samples abgespielt werden, oder spezielle Effekte erzeugt werden. Ich glaub in Martin Galways "Arkanoid" Soundtrack wurde das zum ersten Mal verwendet. Im 8580 wurde der Bug dann behoben bzw. stark reduziert. Was auch immer auf diese Art erzeugt wurde ist auf einem 8580 nurmehr sehr leise zu hören, z.B. die "Gittarrensounds" im Intro von "Grand Prix Circuit". Philipp
Hallo, Der Das Ghostbusters-Intro dürfte so eins der Ersten Sprach-Samples gewesens ein, vermute ich zumindest. Die Sachen dürfte den C64 dann aber auch komplett beschäftigt haben, in "üblichen" SID-Tunes (Games, Grafik-Demos) sollte das wohl eher selten vorkommen. Wie man das erkennt und dann handelt, wird man dann aber wohl noch entscheiden müssen. Ich sehe aber da mehr das Problem, sowas zu erkennen als darin, es sauber zu emulieren. Gruß aus Berlin Michael
Also das mit dem Kancksen und so ist mir schon bekannt. Auch dass im
neueren Sid die Effekte nur noch ganz leise zu hören sind. Aber mir
gehts mehr ums technische...
->Philipp:
Spielt Dein Digiplayer auch die Digi-Sound (wenn auch leise)?
Wenn nein: Warum ist das so?
Wenn ja: Dann ist alles OK :-)
->All:
Das würde doch bedeuten, dass der Sid über eine Sekunde verteilt ca.
6000x Infos über die Samples bekommt? Waren diese Stücke dann nicht in
nem ("Player"-)Interrupt untergebracht, der 20x/Sek aufgerufen wird?
Oder gibt es irgendeinen Baustein, der die Daten zum Sid geschickt hat?
Oder besser gefragt: war es die CPU, die die Digisound zum Sid/an die
entsprechenden Adressen schickt?
MfG
Peter
Hallo Phillip, >@Christoph: Danke für die Beschreibung. Habe mal versucht die >Schreibzugriffe auf den SID in den ersten 3 Minuten von Driller.sid zu >loggen. Vielen Dank für Deine Mühen. Gerade eben habe ich mir einen Format-Converter bebastelt, der Deine Daten in mein sound.c übersetzt. Und .... Ich bin total begeistert! Das was rauskommt, klingt tatsächlich wie der Anfang von "driller", ( glaube ich zumindest ). Eigentlich habe ich vermutet, dass irgendwas undefiniertes erzeugt wird, weil ich vielleicht nicht alle Funktionen des SID orginalgetreu nachgebildet habe und sicherlich auch noch der ein oder andere Fehler im Emulator zu finden sein wird. Aber nein, es klingt gar nicht schlecht für die 8Bit PWM. Allerdings gibt es auch eine schlechte Nachricht: Ich kriege nur die 1.te Sekunde des drillers in den SID. Eigentlich sind noch ca.3KB Flash frei, aber mit PROGMEM verbrät der Compiler scheinbar den doppelten Speicher, sodass ich nur 3000/2/2 Registerzugriffe ( RegAdr+RegWert ) abspeichern kann. Hast Du vielleicht noch einen gut klingende SID-Sound, der mit 50ms upgedated wird? Oder irgendeinen anderen gut klingenden 20ms Sound ? Gruss, Christoph
Hi, tut vielleicht nicht viel zum thema beitragen, aber der avr läuft sicher auch bei 18 oder 20mhz ich hatte einen mega128 lange zeit als i2c logger mit 20mhz stabil laufen. das würde euch evtl noch einige zyklen mehr geben, oder?
@ struberg > Ein 6502 ist im Endeffekt ein Clone vom Motorola 6800 Prinzipiell korrekt, wobei doch noch einige Sachen geändert wurden, wahrscheinlich weil Motorola MOS-Technology deswegen verklagt hat. > und ein indirekt indizierter load verbrät sicher an die 8 Zyklen. Ich glaube mehr als 6 Taktzyklen verbraucht keine 6502-Instruktion (eventuell 7 beim Seitenwechsel). > Ein multiply wahrscheinlich um die 25 rum. Ich glaube Du solltest Dir mal den Instruktionssatz anschauen, der 6502 hat keine Multiplikation ;-) Einer der ersten 8-Bitter mit Multiplikation wird wahrscheinlich der 6809 gewesen sein, kann mich aber auch irren. > Das Problem ist also wahrscheinlich weniger die Geschwindigkeit, Man sollte den Aufwand für die Dekodierung der Instruktionen und die anschließende Emulation der Arbeitsweise, ungünsigstenfalls inklusive Berechnung von Status-Flags, die sich eventuell komplett anders verhalten als das Zielsystem, nicht wirklich unterschätzen. Wenn Du mal die exakte Emulation eines 6502 z.B. mit der eines MIPS R3000 vergleichst, wirst Du merken, daß der Aufwand für den 6502 ungleich größer ist. Dadurch ist die Emulation des 6502 relativ gesehen langsamer, obwohl der R3000 nicht nur im ein vielfaches schneller getaktet ist, sondern auch noch deutlich weniger Taktzyklen pro Instruktion benötigt. > als das exakte timing. Das ist das andere Problem des 6502. Die Hardware-Systeme waren früher häufig recht gut aufeinander abgestimmt, was bei der Emulation sehr genaues Timing erfordert. Daß die Programmierer genügend Zeit hatten, aus dem System das letzte herauszuholen, macht das ganze auch nicht wirklich einfacher. @ Michael U. > Der Das Ghostbusters-Intro dürfte so eins der Ersten Sprach-Samples > gewesens ein, vermute ich zumindest. Ich dachte immer, daß Impossible Mission die erste Sprachausgabe gehabt hätte, aber ich kann mich täuschen, zumal beide Spiele 1984 veröffentlicht wurden.
Hallo Michael! Da ich bereits an einem AVR Emulator für den PC mitarbeiten durfte (http://sourceforge.net/projects/avrsimu/), weiß ich in etwa wie man das machen könnte ;) Aber du hast schon recht, der 6502 ist ein CISC und somit komplizierter zu emulieren als der gute alte MIPS-Risc mit seinen lediglich 39 Befehlen. > Ich glaube Du solltest Dir mal den Instruktionssatz anschauen, der 6502 > hat keine Multiplikation ;-) Die VC20 Zeit ist ja schon ein Weilchen her, und das letze mal hab mich in den 80ern mit den Hitachi 6301, 03 und 09 rumgeärgert - da hab ich wahrscheinlich ein bißchen was durcheinander gemischt. LieGrü, strub
Hallo, @Mark Struberg: stimmt, Impossible Mission... "Another Visitor" oder so ähnlich??? Gruß aus Berlin Michael
abo Man ist das heute wieder ein super Wetter. Da muss ich unbedingt mal ein neues Fahrrad besorgen und durch die Gegend fahren. Wird aber zeit, daß es wieder Regnet... ich kann es kaum erwarten die neusten Ergebnisse hier zu sehen. Leider ist mein PC SID-Player ne reine Katastrophe, so daß ich hier leider nicht viel beitragen kann. :-((( Viel Erfolg noch mit eueren Projekten und ... Gruß, SIGINT
Eben habe ich ein Projekt gefunden, bei dem versucht wurde, mit einem PIC einen SID-Player zu realisieren: http://tripoint.org/kevtris/Projects/sid/sidman.html Gruss, Christoph
Den Player gibts schon ziemlich lange, aber leider nicht sehr viele Infos dazu. Die Kompatibilität scheint aber beeindruckend zu sein, würde mich interessieren wie er das mit den digi-sounds genau gelöst hat. Wegen der Zugriffstabelle zum SID-Emu testen - hab schon befürchtet dass das mit dem Flash knapp wird, hast du keinen mega32 oder was größeres rumliegen :)? Wenn du mir nen Song (aus der HVSID collection) sagst kann ich dir noch mehr Tabellen machen, bzw. wenn ich mal Zeit hätten den code etwas aufzuräumen oder zumindest ein binary mit commandline parameter zu machen... Wobei der Aufbau von dem Driller.sid schon relativ simpel ist, andere Songs haben teilweise wesentlich mehr Zugriffe pro play-routinen Aufruf. Philipp
Hab gestern noch schnell was gebastelt, kurze Anleitung: sidextractor.exe filename [calls] [init] [asm] filename: PSID Datei calls: Anzahl der play-routine Aufrufe (default 3000) init: Starten bei init Adresse statt bei load Adresse (default 0) asm: Schreibt disassembly statt den SID register writes (default 0) Beispiele: sidextractor.exe demo.sid 6000 Ausführung startet bei load Adresse, 6000 play-routine Aufrufe werden ausgeführt, geloggt wird nach demo.log sidextractor.exe demo.sid 10 0 1 Ausführung startet bei load Adresse, 10 play-routinene Aufrufe werden ausgeführt, disassembly wird nach demo.dis geschrieben Vielleicht kann jemand was damit anfangen, die disassembly Funktion ist ganz lustig um mal reinzuschaun was so passiert. Philipp
Hallo Phillip, danke für das Extraktor-Programm, im Moment komme ich nicht dazu, aber werde es sobald wie möglich testen. Gruss, Christoph
Hallo, @Philipp B.: Riesen Dank für das Programm, genau das hat mir gefehlt! 2 Erkenntnisse: cauldron.sid scheint ein undankbares Testobjekt zu sein, auch Dein Programm behauptet, daß in den Zyklen immer die gleichen Daten geschrieben werden (ich hab mal bis 1000 getestet...). Selbiges macht auch meine Emu. sidplay spielt aber in dieser Zeit (sind ja immerhin 1000/50 = 20s) fleißig... Da scheint also bei mir und im sidextraktor was falsch emuliert zu werden... Boulderdash II Intro ergibt keine sinnvolle Ausgabe, das Sample aus Impossible Mission auch nicht (leere Play-loop-Angaben oder Endlos-Loop vom sidextraktor. So, ich habe jetzt ma Pink Panther genommen, die ersten 1000 Play-Aufrufe, das .sid ist mit im Archiv. Das werde ich dann wohl auch zum Testen nehmen, sollte noch ins Flash bei mir passen. Gruß aus Berlin Michael
Hallo, so, habe nun doch noch "schnell" umgebaut... Obiges Archiv spielt auf dem SID "Pink Panther" wie es scheint, sogar fehlerfrei??? Man kann sogar in SID_6581.inc den rcall debug_sid reinnehmen, ohne daß es richtig hakt, Dann werden über UART mit 38400 alle SID-Zugriffe ausgegeben. Nun muß ich wirklich nachdenken, wie ich eine SD-Karte ranhänge........ Gruß aus Berlin Michael
Hi zusammen, das passt zwar nur indirekt zum Thema, aber vielleicht findet das ja jemand interesannt: http://6502asm.com/ Vielleicht könnte man so was ähnliches mit einem Grafik-LCD auch auf einem AVR realisieren. Gruß, SIGINT
Na was ist denn aus diesem schönen Projekt geworden? Ich habe ebenfalls großes Interesse einen solchen SID-Player zu bauen.. Ich wäre für jedes Bild oder Schaltplan sehr dankbar! Auch wäre es schön zu erfahren auf welchem aktuellen Stand sich die 6502-Emulation von Michael U. befindet. Gibt es denn bereits eine neue Version des AVR-Codes? Gruß J. Sauer
SIGINT: Ich hab noch 'ne bessere Idee! Man kaufe sich einen 6502 und schließe dort über Logikbausteine ein LCD an!
Hallo, @J. Sauer: der letzte Stand war, daß sie (hoffentlich?) fehlerfrei von der Logik her ist. Beim Timing von ein paar indirekt-indizierten Befehlen fehlte mir ein Taktzyklus. Ich habe für den SID eine Version der 6510-Emu um alle Wartezeiten gekürzt und die Play-Routine in einen 50Hz Timer-IRQ reingehangen. Meine 3 Testmelodien hat er erstmal richtig abgespielt. Dann war Sommer und wundersamer Weise fand auch unser Umzug in die Reko-Wohnung mit nur wenigen Monaten Verspätung statt ;). Mittlerweile ist Herbst, meine Bastelecke ist wieder ziemlich komplett und auch der SID wird demnächst wieder ausgegraben. :-) Gruß aus Berlin Michael
Vielen Dank für die Auskunft Michael U. Es stimmt mich froh noch ein Lebenszeichen des Projektes zu sehen =).. an dem einen noch benötigten Takt solls ja (hoffentlich) nicht scheitern. Ich bin für Informationen jeglicher Hinsicht zu diesem Projekt dankbar! Weiter so und frohes Schaffen wünsche ich! Gruß J. Sauer
Hallo Zusammen, vor kurzem habe ich darüber nachgedacht, ob es nicht möglich sei, den 6502 Emulator in C zu schreiben und auf einem AVR laufen zu lassen. Natürlich gibt es jetzt den Einwand: das wird doch nich zyklusgenau! Die Frage ist: muss der Emulator wirklich zyklusgenau sein, oder reicht es aus, wenn er im Mittel genau ist? Eine Realisierung könnte dann folgendermaßen aussehen: Jeder Emulationsbefehl weiß, wie lange er dauern müsste. Bei Ausführung eines Befehls wird dann ein Zeitakkumulator mit der entsprechenden Befehlsdauer erhöht. Parallel zur Emulation läuft ein Timer im AVR. Falls die Emulation zu schnell ist ( erkennbar am Wert im Zeitakkumlator relativ zum Timer ) wird die Emulation gebremst und der AVR kann in dieser Zeit was anders rechnen. Was haltet Ihr von dieser Idee? Gruß, Christoph
christoph, so und nicht anders würde ich einen Emulator aufbauen... PC Emulatoren können gar nicht anders funktionieren.
Hallo, für bestimmte Sachen wie z.B. SID-Ansteuerung mit SID-Files, die im 50Hz-CIA-IRQ oder V-Blanc-IRQ auf dem C64 laufen, spielt es garkeine Rolle. Das sind bestimmt 50% aller SID-Files. Das ist ja mein letzter Test gewesen, solch ein File im 50Hz-Timer-IRQ des AVR und die 6510-Emu ohne Ausgleich. Die ist dann etwa 0,9-6x so schnell wie das Original, im Durchschnitt der benutzten Befehle etwa 3x. Geht für solche Files so ohne Probleme. Gruß aus Berlin Michael
Hallo, schalt mich hier auch wiedermal ein. Bei mir hat sich in letzter Zeit leider auch nichts mehr weiterentwickelt, da ich mich bis letzte Woche noch mit der Diplomarbeit/prüfung rumgeschlagen hab. Jetzt wären mal ca. 2 Wochen Zeit was zu basteln, mein nächster Plan wäre die Kompatibilität zu verbessern und evtl. Teile der Emulation in Assembler neu zu schreiben. Laden von der SD Karte funktioniert soweit eigentlich schon sehr gut, Display und Verzeichnis-Navigation kommt dann später mal ;). Grüße, Philipp
Vielleicht kommt Ihr ja mal dazu, die SID-Daten über die serielle Schnittstelle rauszu"beamen" (Protokoll: Registeradresse, Registerwert, 9600 8n1 ). Abhängig von den zu beschreibenden Registern muss man nach dem Schreiben des Registerwertes ca. 5ms warten. http://www.roboterclub-freiburg.de/atmega_sound/atmegaSID.html Zugegebenermaßen ist das etwas langsam, aber bei dem ein oder anderen SID-File könnte die Geschwindigkeit ja ausreichen. Mitlerweile gibt es sogar schon ein kleines Projekt mit dem SID-Emulator: http://www.arduino.cc/playground/Main/SID-emulator Gruß, Christoph
Hallo, @Christoph H.: Schau mal mein Posting vom 19.04.2007 21:10. Ich kann den Debug gern auf das von Dir gewünschte Format bringen. Meine Version spielt im Moment nur SID-Files, die im 50Hz-IRQ laufen. Die Werte-Paar einer Gruppe (was als Trenner zwischen den 20ms-Gruppen?) also einfach hintereinander stetzen, 20ms warten und nächsten Block. Mal schauen, ob ich das Zeug morgen mal rauskrame und ranstecke... Gruß aus Berlin Michael
Hallo Michael, >Die Werte-Paar einer Gruppe (was als Trenner zwischen den 20ms-Gruppen?) >also einfach hintereinander stetzen, 20ms warten und nächsten Block. Genau das ist es, einfach immer einen Block senden und dann die 20ms warten. Allerdings leider nur "fast". Vermutlich wird sich das ganze auf meinem SID-Emulator etwas länglich anhören. Das hat folgenden Grund: Zuerst muss die Registeradresse über die serielle Schnittstelle gesendet werden (1ms bei 9600 Baud ) und dann der Registerwert. Nach dem Senden des Registerwertes sollte man ca. 5-7 ms warten, solange brauch die Emulation, wenn eine neue Waveform in die Arrays geschrieben werden soll. Deshalb ergibt sich für das Schreiben eines Registers also ca. 6-8ms. Will man als Block 5 Register schreiben benötigt man 30-40ms. Das bremmst natürlich das Abspielen ziemlich aus, da man ja einen Block in 20ms gesendet haben sollte. Ich denke aber, daß es trotzdem ganz lustig wäre das mal auszuprobieren, auch wenn die Melodien etwas "deformiert" werden. Gruß, Christoph
Hallo Christoph, der Pink Panther aus dem Archiv vom 18.04.2007 21:43 enthält sinnvolle Daten. Der erste Block sind die Init-Daten, dann jeweils mit #x der 20ms-IRQ. Wenn da nichts drinsteht, wird nichts gemacht. Kann man ja notfalls zum Testen so, wie es ist, in einen Mega 16 packen und ein paar Zeilen drumrum, die die Adresse und die Daten rausfiltern und über den UART an Deinen "SID" schicken. Gruß aus Berlin Michael
Hallo Michael, mit dem Programm von Phillip habe ich ja schon Daten aus dem Hihg-Voltage-Archiv extrahiert, dann mit einem eigenen Programm aus den Daten eine Header-Datei erzeugt und in einen Atmega168 geladen. Das Ergebnis war das hier http://www.roboterclub-freiburg.de/atmega_sound/atmegaSID2.mp3 Es hört sich ja so an, als wenn die SID-Emulation funktioniert. Gruß, Christoph
Hallo, wollte mal fragen, ob das Projekt eigendlich ergebnisse gebracht hat, oder ist es gestorben......
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.