www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 6502 Emulation auf AVR ?


Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht nicht. Dafür ist der AVR zu langsam und hat zu wenig Speicher.

Autor: Marvin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael sowas gibt es schon (für parallel port und auch mit controller, 
vlt nicht avr)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Marvin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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...

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde eher drauf tippen, daß dieser Sport in allgemeiner Verfettung 
endet. Fahrrad ist gesünder...

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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



Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
out PORTD,Adresshigh                            ;1 Takt
out PORTC,Adresslow                             ;1 Takt
...
SBI PORTB,Lesebit                               ;2 Takte
...
in zh,PINA                                      ;1 Takt
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.
out PORTD,Adresshigh                            ;1 Takt
out PORTC,Adresslow                             ;1 Takt
...
SBI PORTB,Lesebit                               ;2 Takte
...
sei                                             ;1 Takt
(exakt hier wuerden die entsprechenden ISR angesprungen werden)
cli                                             ;1 Takt
in zh,PINA                                      ;1 Takt
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

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: pluto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist vieleicht ganz Interessant.....
http://www.binkino.de/ecbm64DTV4.htm

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibts noch mehr 6502 und Peripheriebausteine in VHDL oder Verilog:
http://www.birdcomputer.ca/Cores/CoresToC.html

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"


Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hmmm. zu schnell gewesen...

Etliche L/H-Vertauschungen in allen Befehls-Includes beseitigt, 
sta/stx/sty komplett.

Gruß aus Berlin
Michael

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.npsnet.com/danf/cbm/cross-development.h...
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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tip zur Laufzeitkorrektur bei page crossing: Ein
  BRCS PC+1
braucht 1 Takt bei C=0, 2 Takte bei C=1.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

mov yl,adresshigh
st y,adresslow
...
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der 6502 legtt beim Interrupt außer der Rücksprungadresse noch das 
Flagregister auf den Stack, beim AVR muß man das selbst erledigen

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

IRQ ist Pegel, nicht Flanke.

Autor: GeraldB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael U.

Schau Dir mal diese Seite an : 
http://instruct1.cit.cornell.edu/courses/ee476/Fin...

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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




Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So etwas ähnliches habe ich mit einem Mega16 aufgebaut. Habe mal 2 
Bilder angehangen.

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und das Zweite....

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael, hast du es schon fertig ? Ich mein, kannst du schon .sid-Files 
abspielen ?

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ...

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@michael

wir betätigen uns als c64-schlächter *ggg

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: criha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn Wieck (bwieck)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mista IKS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum nehmt ihr nicht einen avr mit externem ram? also mega128 oder 
8515?

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe noch was zum thema Sid-Files gefunden. Vieleicht hilft 
es......

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Taktzyklen der 65xx-Instruktionen könnten folgende PDFs 
interessant sein:
http://www.bitsavers.org/pdf/mosTechnology/

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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



Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: criha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: criha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ziemlich beachtlich, bis jetzt. Bin schon gespannt auf das endgültige 
resultat..

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: criha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: nuno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor:        L² (nightstalker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, Dateianhang war nach der Vorschau scheinbar weg, und lässt sich 
auch nicht rein-editieren. Deshalb hier noch ein Versuch.

Philipp

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Philipp B. (razor_blade)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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/hse0300...

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/hse0300...

Vielleicht gibt der Sound ja Motivation zum weiter Entwickeln :).

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jetzt Beethoven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Philipp B. (razor_blade)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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


Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Philipp B. (razor_blade)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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             -> Erster Aufruf der play-routine
00090 d404 00  -> Nach 90 Zyklen wird 0x00 auf 0xD404 geschrieben
00094 d40b 00
00098 d412 00
00104 d418 0f
00242 d409 e0
00258 d40a 02
00391 d410 50
00407 d411 0c

#2             -> Zweiter Aufruf der play-routine
00349 d401 07
00368 d400 e9
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

Autor: struberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Mark Struberg (struberg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Mark Struberg:

stimmt, Impossible Mission... "Another Visitor" oder so ähnlich???

Gruß aus Berlin
Michael

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"There's another visitor - stay a while - stay forever!" :)

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Phillip,

danke für das Extraktor-Programm, im Moment komme ich nicht dazu, aber 
werde es sobald wie möglich testen.

Gruss,
Christoph

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: J. Sauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SIGINT: Ich hab noch 'ne bessere Idee! Man kaufe sich einen 6502 und 
schließe dort über Logikbausteine ein LCD an!

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: J. Sauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
christoph, so und nicht anders würde ich einen Emulator aufbauen... PC 
Emulatoren können gar nicht anders funktionieren.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp B. (razor_blade)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/at...

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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/at...

Es hört sich ja so an, als wenn die SID-Emulation funktioniert.

Gruß,
Christoph

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, wollte mal fragen, ob das Projekt eigendlich ergebnisse gebracht 
hat, oder ist es gestorben......

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.