Hallo. Über diesen Weg, möchte ich eruieren, Gedanken sammeln und am besten Gleichgesinnte begeistern für eine mögliche KIM-1 Implementierung mit einem AVR. Nun, für alle, die es bisher noch nicht wußten.. was ist ein KIM-1? KIM-1 ist ein sog. Single-Board-Computer auf 6502 Basis mit 6x7-Segment Display und 4x6 Matrixtastatur (und serieller Schnittstelle!). Das System verfügt über 1kb Ram und 2kb Rom. Das Rom enthält einen rudimentären Monitor, der unter anderem die Programmierung über die HEX Tastatur erlaubte. Zu seiner Zeit erlangt der KIM-1 eine 'weite' Verbreitung und Berühmtheit, der er einer der ersten Computer war, der 'erschwinglich' war. Es gab so einige 'Programme' für den KIM-1.. darunter auch MicroChess! Ein orig. KIM-1 dürfte heute mehr kosten als der damalige Preis (um 1977), wenn man ihn überhaupt mal zu kaufen bekommt! Es gibt aktuell einen Nachbau von Briel Computer aus den USA für 99€ als Bausatz (ich habe mir einen bestellt ;-) ). Nun, die Frage.. 6502 Emulationen auf AVR gibt es ja bereits! 7-Segment und Tastaturmatrix sollten auch kein größeres Problem sein..? Und serielle Kommunikation können heutige AVR's von zuhause aus. Sähen sich hier interessierte in der Lage und hätten Lust sich an einem solchen Projekt zu beteiligen..? Ziel wäre es, einen KIM-1 mit einem AVR nachzubauen. Ideal mit möglichst 'echtem' Feeling = 6x7-Segmentanzeige und 6x4 Matrixtastatur. Obwohl zumindest als Alternative der KIM-1 auch komplett über die serielle Schnittstelle 'bedient' werden kann.. Ich selber verfüge NICHT über die nötigen Fertigkeiten und Kenntnisse in C auf einem AVR! Ich bin mehr der Koordiniererer/Dokumentierer/Nachbauer/Tester... ;-) Als AVR sähe ich in erster Näherung einen ATmega644/1284..? EDIT: Zum Einstieg einige englische Textdokumente im ZIP Archiv.. Peter
ketzerische Frage: Wenn du sowieso nicht programmieren willst, wozu brauchst du dann einen KIM? Um so einen Nachbau zu machen, bräuchte man als allererstes die Schaltpläne vom KIM. die 6502 CPU ist eine Sache, aber die Peripherie rundherum ist eine andere Sache. Die muss ebenfalls in Software nachgebildet werden, wenn du die Originalprogramme laufen lassen willst.
Nun, da waren die 15min wohl um... Hier die Texte.. @Karl heinz: Wer sagt, das ich keine Programme FÜR den KIM-1 schreiben will? Ich bin generell fasziniert von der Anfangszeit der Computer.. also ein Retro-Freak ;-) Und dazu auch noch Minimalist.. reicht das als Begründung.. ;-) Schaltplan bekommt du hier angehangen.. ob man das aber wirklich genau so nachbilden MUSS, kann ich z.Z noch nicht abschließend sagen.. ggf. reicht es sogar, die 7-9 Monitorroutinen abzufangen und nachzubilden..? Peter
Angehängte Dateien:
-
kim-rb.gif
73 KB
Hier der Schaltplan.. Hier die Monitorroutinen:
1 | KIM SUBROUTINES |
2 | |
3 | CALL ADDRESS ACTION ARG RESULT NOTES |
4 | JSR AK 1EFE Check for - A A = 0 = Key down |
5 | key depressed A<>0 = No Key down |
6 | X & Y lost |
7 | |
8 | JSR GETKEY 1F6A Get key from - A A>15 illegal |
9 | keyboard or no key |
10 | |
11 | JSR SCANS 1F1F Display F9, FA, F9. - A, X, Y are lost |
12 | FB FA, |
13 | FB
|
14 | |
15 | JSR GETCH 1E5A Put character - A X preserved |
16 | from TTY in A Y = FF |
17 | |
18 | JSR PRTBYT 1E3B Prints A as A - A preserved |
19 | 2 Hex Char. X preserved |
20 | Y = FF |
21 | |
22 | JSR PRTPNT 1E1E Prints Contents FB, A lost |
23 | of FB & FA FA X preserved |
24 | on TTY Y = FF |
25 | |
26 | JSR OUTCH 1EA0 Print ASCII char A - Xis preserved |
27 | in A on TTY Y = FF |
28 | A = FF |
29 | |
30 | JSR OUTSP 1E9E Print a space - A = FF |
31 | X preserved |
32 | Y = FF |
Peter
Und hier das ROM inkl. 6502 Assemblerquelltext. Das kann man so auch im I-Net finden! Aber da nicht 100% das (C) klar ist, darf es nur für eigene Schulungszwecke verwendet werden! Peter
Es ist möglich eine 1MHz CPU (6502) in Echtzeit zu emulieren mit einem AVR der mit 18 MHz getaktet ist. Das wurde bei der NES Emulation bereits nachgewiesen: NES Emu: http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2009/bhp7_teg25/bhp7_teg25/index.html Ich habe mich vor einiger Zeit mit einem sehr ähnlichem Projekt beschäftigt: die Emulation einer 1541 Floppy, die technisch gesehen einem KIM-1 sehr ähnlich ist: 1541-Emul: http://t-winkler.net/dokuwiki/doku.php?id=1541-emul:start Dabei habe ich diese NES Emulation als Basis verwendet. Der KIM-1 könnte problemlos laufen. Man müsste aber die Tastatur und die 7 Segment LED Anzeige auch am AVR anhängen. Oder möchtest du das über ein Terminal emulieren?
Wenn ich mich richtig erinnere, wurde beim KIM ein Programm als Hexcode eingehackt und dann laufen gelassen. Der AVR hat den Haken, dass Programme nur aus dem Flash-ROM und nicht aus dem RAM laufen können. Wie willst Du das Problem lösen? Welcher Cassettenrecorder soll denn zur Abspeicherung verwendet werden? :-)
Es geht doch um einen Emulator... und der kann die zu interpretierenden Befehle problemlos aus dem RAM holen...
Ja, ein Mega644 hat genug RAM für einen KIM im Grundausbau. Das ROM könnte man bequem im Flash ablegen. Der Emu läuft als virtuelle CPU deren Adressraum aus AVR RAM und Flash zusammengesetzt wird. IO Zugriffe werden emuliert auf eigenen IO.
Selbst im Maximal-Ausbau würde ein KIM locker von einem 644er abgedeckt werden: 1K RAM bis maximal 5K RAM 2K ROM Der KIM hat nur einen Adressraum von 8KB der 8 mal gespiegelt ist. Die 7-Segment Anzeige gibts auch schon fertig bei myAVR: http://shop.myavr.de/index.php?sp=article.sp.php&artID=200018 Man müsste nur noch eine passende Tastatur finden. Es gibt auch KIM mit einer seriellen Schnittstelle, die könnte man auf den internen UART des Atmega umleiten. :)
Wenn es eine 6502-Emulation für den Mega644 gibt, wäre doch eine Emulation des PET 2001 bzw. des C64 für Mega644 o.ä. eine feine Sache. Weiss jemand, ob es das schon gibt?
moin hab das letztens mal für VC20 gesehen ,ob hier im Forum k.a. und es gibt diese Spiele Joysticks mit C64 emulation für ca.20€ da ist irgendein AVR verbaut. mfg
@alle: Thomas Winkler hat eine 6502 Emulation für AVR erstellt, die läuft.. ist aber für den damals gedachten Zweck (1541 Emulation) etwas zu langsam.. @Dr.PillePalle: Im sog. 64DTV Joystick mit ca. 30 C64 Programmen werkelt kein AVR, sondern ein custom progr. ASIC Chip (quasi eine fest geflashte FPGA Variante). Ich denke VC20/PET etc. in einem einzigen AVR dürfte z.Z noch nicht machbar sein.. Es gibt allerdings einige Projekte, die in eine solche Richtung (= Basic Selbstbaucomputer mit AVR) gehen.. aber keine Kompatibitität mit den genannten (Home)Computern anstreben.. Zur Zeit scheint es aber möglich zu sein, einzelne Chips solcher Computer durch eine AVR Ersatzschaltung ersetzen zu können (siehe z.B SwinSID als SID Ersatz). Wobei ich noch darauf warte, das jemand mal eine 6502/10, 6526, 6520, VIC Ersatz bastelt.. Zurück zum Thema! KIM-1 sollte machbar sein.. da (kein) Sound und keine aufwendige Bildschirmsteuerung.. Peter
Update: ich habe die NES Emulation angepasst auf das Speichermodell des KIM-1. Die NES Emulation läuft leider etwas langsamer wie ein 1MHz 6502 bei einem AVR Takt von 20MHz. Vielleicht lässt sich da noch was optimieren. Aber Geschwindigkeit ist ja nicht alles. Ich gebe die Zugriffe auf die 6530 Ports direkt auf die Atmega644 Ports aus. Damit sollte Tastatur und 7-Segment funktionieren. Ich habe mir nun 7-Segment und Printtasten bestellt. In den nächsten Wochen werde ich das mal auf einer Lochraster aufbauen und testen.
Ein 6502 müsste meiner Meinung nach in ein FPGA zu bekommen sein. Das muss man nicht mit einem AVR machen. Über eine Art Retro-Computer denke ich inzwischen auch schon verschärft nach seitdem der ATMEGA1284p im DIP-Gehäuse erhältlich ist. Mit 16kiB SRAM fängt das ja an, interessant zu werden. Lösungen für eine integrierte Alpha-Nummerischen Videoausgabe (TV und VGA) gibt es ja auch schon. Bei VGA bleiben vielleicht dann nur 15% der Rechenleistung, das sollte aber in etwa für C64-Niveau reichen. Größtes Problem ist der Basic-Interpreter. Den werde ich wohl selbst schreiben müssen. Gefunden habe ich leider noch nichts, was auch nur annähernd meinen Ideen nahe kommt. Auch wenn ich z.B. für Berechnungen auf die gcc-Bibliotheken zurückgreifen kann, bleibt da eine Menge Arbeit. Reiner "Spielkram" soll das auch gar nicht werden. Ich kann mir durchaus vorstellen, dass man wenig zeitkritische Projekte auch mit so einem Interpreter abwickeln kann. Und der Zugang zu Mikrocontrollern wäre so viel einfacher, wenn man nicht gleich zu Beginn sich mit Toolchain, Programmer und Fuses auseinander setzen muss, sondern Befehle "einfach mal so" eingeben kann und sieht, was die machen. Schaun mer mal. Zur Zeit entwerfe ich noch die Hardware. Wenn etwas dabei heraus kommt, sage ich Bescheid. ;-)
Ganz ausschließen würde ich nicht, daß der AVR eine Emulation hinbekommt, denn für einen CP/M Rechner hat es ja auch mal gereicht. http://pmd85.topindex.sk/
Ich bin überzeugt es geht, allerdings sind meine Assembler Künste am AVR sehr sehr beschränkt. Und die Kombination AVR Assembler und C im GCC habe ich auch noch nicht vollständig geblickt ...
Einen 6502 zu emulieren dürfte deutlich einfacher sein als ein 8080 - oder gar Z80. Der hat eigentlich nur drei Register (A,X,Y), weniger Adressierungsmöglichkeiten und der Stack kann nur im Bereich 0x0100 bis 0x01ff liegen, wobei der Stackpointer nur 8Bit groß ist. Ich würde wahrscheinlich eine rjmp-Tabelle mit 256 Einträgen machen, für jeden OP-Code eine eigene Routine. Die springt man dann mit einem ijmp an und gut. Ist ein bisschen Fleißarbeit, aber nicht wirklich kompliziert. Bei dem CP/M-Projekt hat man sich aus meiner Sicht zu viel Arbeit gemacht, als man die Arbeitsweise des Prozessors selbst (Laden, Verarbeiten, Speichern) im Detail nachgebaut hat. Das BIOS hätte man zudem nativ in AVR anlegen können anstatt auch hier emulierten 8080-Code zu verwenden. Dann wäre das sicher auch performanter.
Peter Sieg schrieb: > Hier der Schaltplan.. Das scheint mir aber nicht der original KIM1-Schaltplan zu sein - der hatte IIRC 8 Stück 6102 (1k x 1!) SRAMs und das Monitor-ROM fest in den 6530 drin (je 1k x 8 IIRC). Aber das wäre schon ne schöne Ergänzung zum 8080 mit CP/M im AVR :-) - vielleicht sogar mit erträglichem Aufwand zum Apple II erweiterbar... (Edit: stimmt, zum Apple II gab's ja auch schon was - http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/bcr22/final%20webpage/final.html - die Jungs sind aber nicht wirklich weit gekommen) -- Michael
Eine AVR lib die eine 6502 bei 1 MHz Taktgenau emuliert, - das wäre ein absoluter Traum. Es gäbe so viele Projekte die man darauf aufbauen könnte!
Detlev T. schrieb: > Ein 6502 müsste meiner Meinung nach in ein FPGA zu bekommen sein. Das > muss man nicht mit einem AVR machen. Ah, statt mit Kanonen willst du mit Atombomben auf Spatzen schießen?!? In einen durchschnittlichen FPGA bekommst du mehrere AVR rein, die dann auch noch besser und schneller sind. Und ein 6502 ist ein absoluter Witz für einen FPGA, da bekommst du ganze Rechner drin unter. (MINIMIG, C-One, FPGA64,Zet-Processor, etc. etc.) > Lösungen für eine integrierte Alpha-Nummerischen Videoausgabe (TV und > VGA) gibt es ja auch schon. Bei VGA bleiben vielleicht dann nur 15% der > Rechenleistung, das sollte aber in etwa für C64-Niveau reichen. Ach, C64 Niveau?!? Und was ist mit den ganzen Custom-Chips?!? (VIC,SID,VIA) Ich möchte sehen, wie du das in den 15% unter bekommst. Vieles ist mit den AVR machbar, aber nicht alles. Aber so Sätze wie "müsste gehen" oder "geht nicht" mag ich nicht leiden, wenn man sich noch garnicht praktisch mit dem Thema beschäftigt hat. Soviel von meiner Seite... Gruß, SIGINT
@SIGNINT: So ist es! Willkommen im Thread ;-) Hier noch ein paar Links: Orig. Commodore Unterlagen und Info's: http://www.commodore.ca/products/kim1/mos_kim1.htm Micro-KIM Nachbau von Briel Computer: http://www.brielcomputers.com/micro-KIM.html Tools: http://www.6502.org/tools/emu/ Von dort kann ich den Soft6502 und die von diese Seite ebenfalls verfügbaren Assember (CBA65) und Disassembler empfehlen: http://www.crbond.com/soft6502.htm Z.Zeit bin ich dabei auf Basis: http://www.piumarta.com/software/lib6502/ einem KIM-1 Emulator auf PC Basis zu implementieren, wobei ich NUR die 3 Nicht-TTY Monitorroutinen abfange und das KIM-1 Rom gar nicht verwende. Erste Testprogramme laufen schon.. Lunar Lander mußte ich ersteinmal mühsam von Fehlern bereinigen.. aber jetzt kann ich den CBA65 ASM Source in ein 1:1 bytegleiches BIN File assemblieren.. Sobald auch Lunar Lander in meinem Emulator läuft.. lade ich den Emulator hier mal hoch.. und danach mache ich mich an MicroChess.. ;-) (Das wird nur ein absolut minimalistischer Emulator werden! Und das ist so von mir auch beabsichtigt!) Peter
Sigint 112 schrieb: > Ach, C64 Niveau?!? Und was ist mit den ganzen Custom-Chips?!? > (VIC,SID,VIA) Ich möchte sehen, wie du das in den 15% unter bekommst. Oha, da fühlt sich aber jemand auf den Schlips getreten. Äh, ich wollte natürlich "Apple][ -Niveau" schreiben. ;-) Wo bitteschön habe ich behauptet, ich wolle einen kompletten C64 auf einem AVR simulieren? Ich sprach von "Rechenleistung", also wie schnell ein Basic-Interpreter da wohl vermutlich sein könnte. 15% von 25MHz machen in etwa 4MHz "effektive" Taktrate aus, das muss man mit dem 1MHz damaliger Rechner vergleichen. Ein RISC-Prozessor braucht im Mittel da vielleicht doppelt so viele Befehle, das sollte insgesamt ungefähr hinkommen. Es soll aber wie beim ZX81 auch einen "FAST-Modus" geben :-) , wo nur noch die Sync-Signale erzeugt werden. Das mit "noch nicht praktisch beschäftigt" lasse ich für mich nicht gelten. Das Pflichtenheft für die Hardware ist fertig. Der Sprachumfang des Basic praktisch auch. Das Layout ist begonnen, ich komme wohl mit 1/4 Eurokarte aus, auch ohne SMD. Immerhin 8 I/O-Pins (digital I/O oder ADC), 2 x PWM und ein Interrupt werden verfügbar und vom Basic-Interpreter aus ansprechbar sein. Die Ausführgeschwindigkeit solcher Programme liegt dann natürlich weit unter dem, was man mit einem Compiler erreichen könnte, eben auf C64-Niveau. Oder Apple ][ - Niveau. Oder PET2001-Niveau. Oder....
Die NES Geschichte verwendet eh schon eine Sprungtabelle für alle 256 OP codes. Leider ist der Rest in reinem C und zu langsam. Außerdem keine Clock Synchronisation. Der Apple-II Ansatz gefällt mir sehr, kritische Teile sind in Assembler implementiert. Leider braucht man dazu den IAR Compiler und mit AVRGCC lässt es sich nicht compilieren weil die ASM Einbindung ganz anders ist. Es gibt allein hier im Forum schon zwei Ansätze eine 6502 zu emulieren mit einem AVR die in reinem Assembler geschrieben sind. Beitrag "Re: 6502 Emulation auf AVR ?" Beitrag "Re: 6502 Emulation auf AVR ?" Kann mir jemand erklären und an einem Beispiel vorführen wie man mit AVRGCC richtig Assembler und C mischt? Ich kenne die Beschreibung: http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc Aber ich bin leider nicht in der Lage das aufgrund dieser Beschreibung umzusetzen. Mir ist das irgendwie zu komplex.
Soo.. nachdem ich mich nun einige h verweifelt versucht habe kbhit(), getch() unter Vista und Dual Core und mingw dazu zu bewegen, das zu machen, was ich möchte.. gebe ich erseinmal auf.. ich lade das ganze lib6502 emu Verzeichnis mal hoch.. evtl. weiß ja jemand weiter.. Das Problem scheint zu sein, das selbst wenn ich die taste gedrückt halte, mind. 15x keine Taste zurück kommt und erst dann mal wieder die gedrückte.. Damit läuft Lunar Lander nie.. Ach war DOS doch schön ;-) Peter
Hier ist der Link eines VC-20 nachbau mit einem Atmega 8: http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=400 Das Teil ist komplett in Assembler geschrieben und läuft 1,5 bis 2 mal so schnell wie ein 6502 mit 1MHz bei einer Atmega Taktrate von 16MHz. Das ist der Beweis das es in Assembler möglich wäre den 6502 in Echtzeit zu emulieren.
Thomas Winkler schrieb: > Hier ist der Link eines VC-20 nachbau mit einem Atmega 8: > > http://www.avrfreaks.net/index.php?module=Freaks%2... Leider etwas wenig Beschreibung bei (oder hab ich die übersehn?). Aus dem Projektfile für AVR Studio ergibt sich, dass ein ATmega 128 benutzt wurde, der laut Webseite mit 16 MHz lief. Gewundert hatte ich mich über die Screenshots des LCD, in denen 28kB BASIC-Speicher angezeigt wurde - da wird laut Projektdatei das externe SRAM-lnterface verwendet. Der LCD-Anschluß ist unter http://www.belanger.pwp.blueyonder.co.uk/Projects/ANSI%20terminal/Terminal.htm beschrieben. Fehlt zum Nachbau eigentlich nur noch die verwendete Pinbelegung des AVR, aber die sollte sich durch ein wenig Assembler lesen rausfinden lassen. Das wäre sicher ne gute Basis, auch für ne allgemeine 6502-Emulations-Library (optional wäre sicher gut, wenn es mit der GNU-Toolchain übersetzbar wäre). Leider schreibt der Autor weder auf der Webseite noch im Source etwas zu einer Lizenz für seinen Code. Aber da hilft vielleicht eine kurze Anfrage. -- Michael
(Zu spät zum editieren...) Michael Engel schrieb: > Aber da hilft vielleicht eine kurze Anfrage. Anfrage ist raus. -- Michael
Hoffentlich kommt eine Antwort. Das VC-20 Projekt liegt schon ein paar Jährchen zurück ... Wenn die 6502 Library zustande kommen sollte, - ich würde mich gern bei der Arbeit beteiligen wenn mir jemand erklärt wie man es richtig macht.
Das ging fix. Ich mag nicht direkt aus privaten Mails zitieren, daher die Zusammenfassung: Emile freut sich, dass wir den Code verwenden wollen - er meint, wir können damit tun, was wir wollen und er wäre froh, seinen Namen irgendwo dabei zu sehen (das ist IMHO selbstverständlich). Er hatte bisher nicht über eine Lizenz für den Code nachgedacht und ist sich nicht sicher, was die passendste Lizenz wäre. Aktuell tendiert er zu GPL3. Gegen GPL3 hätte ich nichts einzuwenden, was denkt ihr? Ich würde mich auch bereiterklären, das Projekt auch auf Sourceforge oder Google Code zu stellen und zu administrieren. Habe jetzt schonmal damit angefangen, den Code auf gas-Syntax umzubauen, das sollte nicht so lange dauern. Meine Idee wäre, die nicht zeitkritischen Teile in C neu zu schreiben und die restlichen Assembler-Routinen zu einer gut verwendbaren Assembler Black Box :) zu machen. -- Michael
Das wäre super und hört sich großartig an!!! Für mich wäre die Engine sehr wichtig für das KIM-1 Projekt. Wenn es wirklich Echtzeit schaffen würde, das wäre ein Traum, dann könnte ich ein aufgelassenes Projekt von mir wieder aufnehmen, das mir sehr sehr wichtig ist: 1541-Emul :: Ein Floppy 1541 Ersatz Bei diesem Projekt müsste man aber zusätzlich die 6502 Befehle mit dem AVR Takt synchronisieren. Sodass man zumindest im Schnitt taktgenau zu einer 1MHz 6502 CPU wird. Der Grund ist, zu C64 Zeiten wurde Code geschaffen der auf die Floppy 1541 geladen wird und diese um Faktor 6 bis 15 beschleunigt. Dieser Code sendet Daten zum C64 ohne Handshake, also mit ausgezählten CPU Takten. Siehst du eine Chance dass man das taktgenau hinkriegt? ==== Ich dachte an AVR Hardware Timer und an eine Tabelle der Taktzyklen für jeden 6502 Opcode. Die 6502 Engine summiert die "verbrauchten" 6502 Taktzyklen in einer uint8 Variable. So alle 10 CPU Befehle (6502 Opcodes) synchronisiert man die virtuelle CPU mit dem AVR Timer. Also man wartet einfach bis die Zeit abgelaufen ist, die eine echte 6502 CPU gebraucht hätte. Geht natürlich nur wenn die virtuelle schneller läuft. Wenn nun ein IO Befehl kommt, der ist alleinig zeitkritisch, macht man außerordentlich eine Synchronisation. So wirkt die virtuelle CPU nach "außen" hin taktgenau. Was meinst du, könnte das klappen? Man könnte damit eine komplette 1541 Floppy durch einen Atmega1284 + SD Interface ersetzen. Und es wäre der perfekte Ersatz, der sogar Benutzerprogramme wie Speeder etc. ausführen würde. Ziel wäre, das 1541-Emul an den C64 anzuschliessen als perfekten Floppy Ersatz. Es gibt ja schon so ein Projekt: SD2IEC Funktioniert großartig aber leider ohne 6502 Emulation. Daher funktioniert das SD2IEC nicht in allen Fällen dh. nicht mit jeder C64 Software.
Thomas Winkler schrieb: > Wenn es wirklich Echtzeit schaffen würde, das wäre ein Traum, dann > könnte ich ein aufgelassenes Projekt von mir wieder aufnehmen, das mir > sehr sehr wichtig ist: > > 1541-Emul :: Ein Floppy 1541 Ersatz Mir schwebt ein Apple-I und Apple-II vor... > Bei diesem Projekt müsste man aber zusätzlich die 6502 Befehle mit dem > AVR Takt synchronisieren. Sodass man zumindest im Schnitt taktgenau zu > einer 1MHz 6502 CPU wird. Ja, wir brauchen hier Zyklenexaktheit - also mehr als eine WCET (worst case execution time-Analyse). Dazu gibt es ein paar wissenschaftliche Ansätze, die ich mir mal anschaue (z.B. von Puschner/Kirner zu single-path). Gut, dass die WCET-Experten hier nebenan sitzen :-). > Der Grund ist, zu C64 Zeiten wurde Code geschaffen der auf die Floppy > 1541 geladen wird und diese um Faktor 6 bis 15 beschleunigt. > > Dieser Code sendet Daten zum C64 ohne Handshake, also mit ausgezählten > CPU Takten. > > Siehst du eine Chance dass man das taktgenau hinkriegt? Mal schaun, ich schlage mich grade noch mit gas rum und versuche, den Code mit gcc/binutils ans Laufen zu bekommen. Das ist mehr oder weniger nervige Fleißarbeit. Danach kann das Zyklen-zählen beginnen... > ==== > > Ich dachte an AVR Hardware Timer und an eine Tabelle der Taktzyklen für > jeden 6502 Opcode. > > Die 6502 Engine summiert die "verbrauchten" 6502 Taktzyklen in einer > uint8 Variable. > > So alle 10 CPU Befehle (6502 Opcodes) synchronisiert man die virtuelle > CPU mit dem AVR Timer. Also man wartet einfach bis die Zeit abgelaufen > ist, die eine echte 6502 CPU gebraucht hätte. Geht natürlich nur wenn > die virtuelle schneller läuft. Wenn die Synchronisierung nicht zu viel Zeit braucht und die "Auflösung" von 10 6502-Zyklen reicht, wäre das ein machbarer Ansatz IMHO. Wenn man den AVR-Code aber so hinbekommt, dass jeder Ausführungspfad durch den Emulationscode für eine Instruktion genauso lange dauert wie auf einem 1 MHz 6502, wäre es noch besser. > Wenn nun ein IO Befehl kommt, der ist alleinig zeitkritisch, macht man > außerordentlich eine Synchronisation. > > So wirkt die virtuelle CPU nach "außen" hin taktgenau. > > Was meinst du, könnte das klappen? Ausprobieren kann nicht schaden. Wir haben hier einen einfachen Zyklenzähler (mit ein paar Extras) für dsPIC gebaut, der AVR ist da auch nicht komplexer. > Man könnte damit eine komplette 1541 Floppy durch einen Atmega1284 + SD > Interface ersetzen. Und es wäre der perfekte Ersatz, der sogar > Benutzerprogramme wie Speeder etc. ausführen würde. > > Ziel wäre, das 1541-Emul an den C64 anzuschliessen als perfekten Floppy > Ersatz. Hm, dann brauchen wir aber noch defekte Netzteile und einen Hitzegenerator, sonst wird die 1541-Emulation nie perfekt :-). > Es gibt ja schon so ein Projekt: SD2IEC Small World - Ingo (der SD2IEC-Autor) wird hier am Lehrstuhl öfter gesehn :-). > Funktioniert großartig aber leider ohne 6502 Emulation. Daher > funktioniert das SD2IEC nicht in allen Fällen dh. nicht mit jeder C64 > Software. Ja, das Problem ist in dem Fall erstmal, dass die 8 MHz AVRs, die Ingo verwendet, sicherlich zu langsam sein werden. Mit 16 oder 20 MHz dürfte das schon anders aussehn. -- Michael
Hallo, bin derzeit auch dabei, mir eine 6510-Emulation zusammen zu tippen. Absolute Taktgenauigkeit ist für mich dabei wichtig, da mich die Idee eines C64-Nachbaus mit AVRs reizt. Dabei sind aber die 6502-Opcodes recht einfach strukturiert, sie dauern abhängig von den Speicherzugriffen. Ich löse das derzeit so, dass die jeweiligen Zugriffsroutinen entsprechende Warteschleifen haben je nach den Takten in Original. Der Prozessor gammelt dabei zwar meist nur rum, aber auf die Art könnte man ggf. sogar das Speicherinterface des 6510 an den ATmega-Ports nachbilden. Michael Engel schrieb: > Ja, das Problem ist in dem Fall erstmal, dass die 8 MHz AVRs, die Ingo > verwendet, sicherlich zu langsam sein werden. Mit 16 oder 20 MHz dürfte > das schon anders aussehn. Zumindest bei meinem Ansatz könnte es schwierig werden, alle 2-Takt-opcodes mit unter 16MHz (evtl. auch 20) zuverlässig zu verarbeiten. Bin aber mit den opcodes noch nicht durch und habe mich auch noch nicht mit den Interrupts beschäftigt, außerdem weiß ich nicht, ob meine Idee sonderlich effizient war. Mark
Das könnte ja eine art 6502 / 6510 Ersatz werden. Das wäre gut falls mal die Chips knapp werden. Nur befürchte ich, der Atmega wird das Bus Timing niemals einhalten können. Für diesen Zweck wird es wohl irgendwann Ersatzchips auf CPLD/FPGA Basis geben. Leider ist eine CPU wie die 6502 ein CPLD zu klein und ein FPGA zu gross/teuer ... Wenn du den C64 in Atmega aufbauen möchtest, komplett, nicht nur den 6510, dann spielt timing in sich ja kaum eine Rolle mehr. Es muss nur im Schnitt wieder passen. Der SID als Custom Chip ist ja schon fertig (SwinSID, Atmega88). Mit dem VIC-II wirst du wahrscheinlich an die Grenzen stoßen wegen der Sprites, Rasterinterrupts etc. Aber insgesamt wäre das sehr cool!
Die Taster sind da! Natürlich musste ich die gleich mal in eine Lochraster Platine setzen. Das hat mich veranlasst mal eine Projekt Page anzulegen: http://t-winkler.net/dokuwiki/doku.php?id=kim:kim1284
Thomas Winkler schrieb: > Nur befürchte ich, der Atmega wird das Bus Timing niemals einhalten > können. Da ich ja schon alles nach einem festen Takt ausrichte müsste ich doch eigentlich nur die OUTs und INs für den externen Speicher entsprechend dem Original ausrichten. Vielleicht sehe ich das zu einfach, aber das schlimmste, was meiner Meinung nach passieren kann, wäre, dass man auf Subroutinen und Sprungtabellen verzichten müsste. Schwieriger finde ich da den Punkt, den Prozessor von extern anzuhalten, wenn der Speicher noch anderweitig verwendet wird. Weiß aber nicht, ob das bei der 1541(meine lief übrigens nur ohne Deckel, sonst konnte sie keinen einzigen Sektor einlesen) oder dem Kim-1 eine Rolle gespielt hat. Bei einem 'Ersatz'-Chip könnte ich auch auf die Idee kommen, die 'freien' Opcodes sinnvoll zu verwenden, bspw. mit einer Multiplikation. Allerdings fehlen auch Pins am Atmega Thomas Winkler schrieb: > Mit dem VIC-II wirst du wahrscheinlich an die Grenzen stoßen wegen der > Sprites, Rasterinterrupts etc. Du sagst es, die lieben Sprites sind genau mein 'Knackpunkt', sowas wie die Eiger-Nordwand eines C64-Emulators mit ATmegas ;-). Ich meine, da sind auch andere Projekte dran gescheitert. Zumindest in Echtzeit beim Anzeigen der Zeile weiß ich noch nicht weiter. Da das Original mit >7MHz gearbeitet hat und die Sprites in Hardware gelöst waren, ist es aber vielleicht auch verrückt das mit einem ATmega versuchen zu wollen. Für Basic-Programme und Spiele ohne intensive Grafiknutzung würde es zwar reichen die im VSync vorzuberechnen, aber (sofern die Disketten noch lesbar sind) verschiedene selbstgeschriebene Demos von ganz früher halt nicht und so einige Lieblingsspiele aus der Kinderzeit könnte ich auch vergessen. Da reicht dann die Motivation oft nur für 'ne Stunde hier und da mal ;-) Mark
Nö weder bei KIM noch bei 1541 spielen Bustiming oder externe CPU Signale eine Rolle. Der KIM ist überhaupt unkritisch, solange man das Kassetten Interface nicht implementiert. Die 1541 ist auch relativ unkritisch im "Normalbetrieb". Wenn aber Programme im RAM laufen (User Code) und der Interrupt maskiert wird, dann wird es heikel. Dann sollten die IO Schreibzugriffe möglichst exakt laufen damit alle Speeder laufen. ======= Das spielt nur eine Rolle, wenn man eine 6510 ersetzen will. Ich sag mmal das bringt man einfach nicht hin: + die CPU greift nur in der Phi2 Phase auf den Bus zu, sonst ist sie hochohmig. So können zwei 6510 im Gegentakt am selben Bus arbeiten oder eben ein 6510 und ein VIC + über ein externes Signal hält die CPU an und wird hochohmig. Wenn der VIC zusätzlich Zeit am Bus braucht. + über ein Signal gibt die CPU bekannt was sie intern gerade verarbeitet Alles Dinge die im µs Bereich ablaufen und für einen Atmega vermutlich nur schwer zu schaffen sind. Andererseits läuft der Swin-SID direkt am 6510 Bus und gibt brauchbare Töne von sich. Nur Register lesen, das scheint nicht schaffbar zu sein. Aber immerhin funktioniert SID Register schreiben, da muss der Mega88 innerhalb von 300nS reagieren und das Byte vom Bus lesen. Das lässt nur sehr wenig Spielraum.
Thomas Winkler schrieb: > Die 1541 ist auch relativ unkritisch im "Normalbetrieb". Wenn aber > Programme im RAM laufen (User Code) und der Interrupt maskiert wird, > dann wird es heikel. Dann sollten die IO Schreibzugriffe möglichst exakt > laufen damit alle Speeder laufen. Die 6502-Emulation macht grade für die Speeder wohl Sinn - eine unmodifizierte 1541 hält sich ja ans Protokoll :). > Das spielt nur eine Rolle, wenn man eine 6510 ersetzen will. Ich sag > mmal das bringt man einfach nicht hin: > > + die CPU greift nur in der Phi2 Phase auf den Bus zu, sonst ist sie > hochohmig. So können zwei 6510 im Gegentakt am selben Bus arbeiten oder > eben ein 6510 und ein VIC Das erste Problem dürfte sein, ob der AVR seine Pins mit 1 MHz schalten kann - und dann auch noch jede Mege davon jede Mikrosekunde. > + über ein externes Signal hält die CPU an und wird hochohmig. Wenn der > VIC zusätzlich Zeit am Bus braucht. Das sollte sich mit Bustreiberbausteinen regeln lassen. > Alles Dinge die im µs Bereich ablaufen und für einen Atmega vermutlich > nur schwer zu schaffen sind. Einfach ist es sicher nicht - aber ohne Herausforderung wär's ja langweilig ;-). > Andererseits läuft der Swin-SID direkt am 6510 Bus und gibt brauchbare > Töne von sich. Nur Register lesen, das scheint nicht schaffbar zu sein. > Aber immerhin funktioniert SID Register schreiben, da muss der Mega88 > innerhalb von 300nS reagieren und das Byte vom Bus lesen. Das lässt nur > sehr wenig Spielraum. Ein Multi-AVR-System, von denen jeder einen Original-Chip ersetzt. Schick :-). Was XMOS mit großem Aufwand macht ("software implemented hardware"), sollte man auch einfacher hinbekommen. -- Michael
Ich habe mal einen Artikel zum Thema im Wiki unter http://www.mikrocontroller.net/articles/AVR_6502_Emulator angelegt.
Thomas Winkler schrieb: > Kann mir jemand erklären und an einem Beispiel vorführen wie man mit > AVRGCC richtig Assembler und C mischt? Ich kenne die Beschreibung: > > http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc > > Aber ich bin leider nicht in der Lage das aufgrund dieser Beschreibung > umzusetzen. Mir ist das irgendwie zu komplex. Prinzipiell ja, aber ins Blaue rein erklären bringt nix. Am besten machst du einen Tread im GCC-Forum auf und stellst dort konkrete Fragen, was dir an dem Artikel nicht klar ist oder es wird ein konkretes Beispiel vorgeführt. Den Artikel hier hab ich nur grob überflogen. AVR und 6502/10 hab ich schon in asm programmiert. So ganz klar ist mir das Projekt aber nicht, insbesondere wie das Interface zur Umgebung aussieht und wie die Taktung der 65xx genau aussieht. Wird da pro Takt/Doppeltakt nur 1 Byte gelesen? Das würde ja bedeuten, daß man nach Lesen des Opcodes auf diesem sitzt und erst wenn man mit Byte 2 bzw. 3 die Operanden gelesen hat die Auswertung machen kann. Das Hauptproblem dürfte die Zyklenexaktheit sein und die WCET einzuhalten, insbesondere bei den exotischen Adressierungen wie indirekt+indiziert, indiziert+indirekt, die ja mehrfach auf den externen Speicher zugreifen und Sachen wie BCD-Mode. Zudem muss ja auch immer das PSW mitgeführt werden. Inwieweit das schon im SREG abgebildet wird, hab ich noch nicht angeschaut; jedenfalls sehe ich nicht, wie da Inline-Assembler helfen kann. Da man harte Echtzeitanforderungen mit sehr engem Zeitrahmen hat, scheidet C+iasm recht wahrscheinlich aus und es ist Assembler angesagt. C und Assembler per Inline zu mischen ist also kaum angezeigt, sondern die Mischung wäre -- wenn überhaupt -- C und GNU-Assembler. Die Zyklenexaktheit per Timer herzustellen dürfte schwer werden, da zur Timerbedienung weitere Befehle anfallen und man eine definierte IRQ-Latenz sicherstelen muss. Zudem frisst der IRQ-Mechanismus weitere Ticks. Die Ticks zu zählen ist ne Sklavenarbeit, vor allem die Ticks bei bedingten Sprüngen wieder glatt zu ziehen...
Ich denke auch dass C und GNU-Assembler die richtige Variante ist. Wobei inline ja im Endeffekt keinen Unterschied macht, nur dass alle Quelldateien dann mit .c enden. Im Falle der 1541 muss es ja nur unter bestimmten Umständen zyklengenau sein, im Interrupt gar nie. Diese bestimmten Umstände sind auch genau definiert: + Programm im RAM + der 6502 Code setzt das IRQ Flag (SEI) + eigentlich sind nur Schreibzugriffe auf das VIA (IO) kritisch Wenn die virtuelle 6502 CPU etwas schneller läuft als die echte bei 1MHz, dann muss man nur bei IO Operationen mit dem AVR Timer synchronisieren. Damit das Protokoll am IEC Bus noch funktioniert.
Thomas Winkler schrieb: > Ich denke auch dass C und GNU-Assembler die richtige Variante ist. Wobei > inline ja im Endeffekt keinen Unterschied macht, nur dass alle > Quelldateien dann mit .c enden. Unter Inline-asm versteht man idR das Mischen von C/C++ und Asm in einer Funktion, während bei "externem" Assembler nur das C-ABI eingehalten werden muss und eine Funktion entweder in Asm oder in Hochsprache steht. Zudem sind lange Inline-Asm-Sequenzen nervig, da sie in einem String stehen und man alles quoten muss.
Der Monitor für die virtuelle 6502 Umgebung ist nun auch fast fertig. Über das Monitorprogramm kann der virtuelle KIM Speicher ausgelesen (Hexdump, Disassembler) und verändert werden. Auf diesem Wege kann man auch einfach Programme in den AVR-KIM laden (Datei Transfer) bzw. einen Speicher Dump als Datei speichern. Die virtuelle 6502 CPU kann jederzeit angehalten und gestartet werden. http://t-winkler.net/dokuwiki/doku.php?id=kim:kim1284#monitorprogramm Für den virtual KIM habe ich blaue LED Anzeigen geordert. Sieht sicher stylish aus wenn es erst mal läuft. Die Print Taster aus dem eBay kann man oben prima beschriften. Der single step Schalter bekommt eine LED, die direkt am Taster raus guckt. Der Taster bekommt eine Schalter Funktion durch die AVR Firmware.
Super! Das wird! Ab wann kann man denn 'mitfühlen' ;-) = Quelltext/HEX-Datei.. Z.Zeit braucht man ja nur einen AVR (welcher?) und Quarzbeschaltung..(bitte nicht wieder 14,xxxx MHz ;-) ) (Besser 16/20MHz) Seriell Anbindung über MAX232 oder Handykabel.. K[im] interaktiv liest ja schon 'Tastendrücke' über serielle IF - korrekt? Display gibt 7-Segment in Ascii Darstellung aus (kann ich mir z.Z nicht so richtig vorstellen.. hast du da mal ne Hardcopy?).. heißt das, das ich im interaktiven Modus auch die 7-Segmentanzeige über serielle IF 'sehe'? (Das wäre 'machbar'.. immer wenn JSR $1f1F angesprungen wird, oder nach x Zyklen..) Falls die 7-Segmentanzeige 'mehrzeilig' simuliert wird, müßte da eine ESC Sequenz zur HOME-Pos vorgeschaltet werden (VT100/52).. ist glaube ich ESC[2J o.ä. Damit könnte man den virutellen KIM-1 komplett ohne echte Matrixtastatur und 7-Segmentanzeige ersteinmal laufen lassen und bedienen.. Peter
Peter Sieg schrieb: > Super! Das wird! > > Z.Zeit braucht man ja nur einen AVR (welcher?) und > Quarzbeschaltung..(bitte nicht wieder 14,xxxx MHz ;-) ) (Besser > 16/20MHz) Zur Zeit läuft V-KIM auf meinem XS-1541 mit Mega644, einem modifizierten Olimex Prototype Board. 14,xxxx MHz ist halt ideal für RS232. ;-) Ne bei 38400 spielt der Quarz keine Rolle. Wird wohl eher 20MHz werden. > Seriell Anbindung über MAX232 oder Handykabel.. Egal, bei mir ist ne USB Bridge dran > > K[im] interaktiv liest ja schon 'Tastendrücke' über serielle IF - > korrekt? Ne, Zukunftsmusik. Zur Zeit geht nur der Terminal Monitor. Ich warte jetzt auf die 6502 lib von Michael Engel für die anderen Sachen. > Display gibt 7-Segment in Ascii Darstellung aus (kann ich mir z.Z nicht > so richtig vorstellen.. hast du da mal ne Hardcopy?).. heißt das, das > ich im > interaktiven Modus auch die 7-Segmentanzeige über serielle IF 'sehe'? Nein, die Wiederholfrequenz ist viel zu hoch beim KIM. Es werden nur Tastendrücke gesendet. Der AVR merkt wenn die virtuelle CPU ein 7-Segment anspricht und buffert das Byte. Man kann alle 6 Zeichen per Monitor Kommando anzeigen lassen
1 | |
2 | ** |
3 | * * |
4 | ** |
5 | * * |
6 | ** |
1 | |
2 | -- |
3 | ! ! |
4 | -- |
5 | ! ! |
6 | -- |
> (Das wäre 'machbar'.. immer wenn JSR $1f1F angesprungen wird, oder nach > x Zyklen..) > Falls die 7-Segmentanzeige 'mehrzeilig' simuliert wird, müßte da eine > ESC Sequenz zur HOME-Pos vorgeschaltet werden (VT100/52).. ist glaube > ich > ESC[2J o.ä. Nix mit $1f1f. Das Betriebssystem ist egal. Es funktioniert auch wenn nur ein Programm im RAM das Display ansteuert. Ich trace die Ausgabe auf den 6530 direkt ... > > Damit könnte man den virutellen KIM-1 komplett ohne echte Matrixtastatur > und > 7-Segmentanzeige ersteinmal laufen lassen und bedienen.. Nicht wirklich. Wenn man Spielereien mit den einzelnen LED der 7-Segment macht (Animation) dann kommt die serielle nicht mit. Man kann am Display ja auch nicht darstellen wenn das Display ausgeht. Ganz davon zu schweigen dass so kein KIM feeling aufkäme, so ohne LED Anzeige.
ok.. macht nichts.. mit LED+Tasten ist sowieso 'echter'.. Hier übrigens noch ein KIM-1 Emulator für den C64 ;-) http://www.floodgap.com/retrobits/kim-1/emu.html Peter
Angehängte Dateien:
-
IMG_0001.jpg
1,2 MB
Hallo, damit ihr noch etwas Futter für euren KIM habt biete ich das Das RPB Heft Herwig Feichtinger Anwendungsbeispiele Für den Mikroprozessor 6502 Für 5,-Euro incl. Versand an. Interessant ist die Rückseite, demnach hat sich Feichtinger schon 1945 mit dem 6502 beschäftigt. Email an: Jochen-Rathje (ätt) t-online.(dot) de MfG Jochen
Hallo, mir ist zwar gestern mein Arbeitsrechner kaputt gegangen, aber vorher konnte ich noch etwas weitermachen und habe den Emulator ganz grob 'fertig'. Folgendes ist dabei herausgekommen: Pur Assembler, alles komplett durchgetaktet. 25MHz-Raster, 4CK für externen Speicherzugriff reserviert(out ADDLow, out ADDHigh, out RE/WE, in/out Data), dann jeweils 21 Takte Verarbeitung. Zyklengenaue Verarbeitung der 6502-Opcodes inkl Speicherzugriff. Das Bustiming sollte ich mit etwas Arbeit auch abbilden können, müsste ja 'nur' die OUTs und INs entsprechend auseinanderziehen. Einfache Interruptroutinge für NMI und IRQ ist eingebaut. Abfangen von IO-Adressen sollte in den WRITE-Routinen möglich sein. Die unnützen Speicherzugriffe habe ich zwar gespart aber Takte dafür sind noch frei. Derzeitige Nachteile/Probleme: Dezimalmode bei ADC/SBC in 2 Takten fehlt noch, derzeit Übertaktung auf 25MHz nötig, aber die 10 Takte mehr als bei 20MHz sind derzeit bei wenigen OPcodes nötig. Ich bilde das StatusRegister original ab, was einige Takte kostet aber vermutlich nicht nötig ist. Noch keine Verarbeitung des AEC-Signals, hab auch noch keine Idee, wie ich das da rein bekomme. Illegale Ops fehlen noch. Fehlerkorrektur (ist unwahrscheinlich, dass ich mich nicht ein paar Male verzählt habe) und Testläufe sind vermutlich aufwendiger als den Code zu schreiben. Das V-Flag-Signal der 6502 fehlt auch noch. Bin da auch auf ein grundlegendes 'Problem' gestossen: die Zeropagezugriffe benötigen logisch und auch lt. dem kaum lesbaren Datenblatt bei 6502.org 3 Zyklen, indiziert 4. In den Opcodebeschreibungen lese ich aber ständig von 2 bzw. 3 Zyklen. Hab derzeit die logische Variante umgesetzt (1CK opcode, 1CK Adresse in ZP, 1CK Daten lesen). Da aber soviele Webseiten was anderes behaupten bin ich etwas verunsichert, ob die alle falsch liegen. Mark
Cool, das ging aber schnell. Bin schon gespannt wie dein Projekt weitergeht und ob da womöglich wirklich mal ein voller CPU Ersatz Chip raus schauen wird?
Mark L. schrieb: > Bin da auch auf ein grundlegendes 'Problem' gestossen: die > Zeropagezugriffe benötigen logisch und auch lt. dem kaum lesbaren > Datenblatt bei 6502.org 3 Zyklen, indiziert 4. In den > Opcodebeschreibungen lese ich aber ständig von 2 bzw. 3 Zyklen. Hab > derzeit die logische Variante umgesetzt (1CK opcode, 1CK Adresse in ZP, > 1CK Daten lesen). Da aber soviele Webseiten was anderes behaupten bin > ich etwas verunsichert, ob die alle falsch liegen. Mark, Die Befehle mit Zeropagezugriffen brauchen 3 bzw. bei ZP,X und ZP,Y 4 Zyklen. Bei den Befehlen: ASL, DEC, INC, LSR, ROL, ROR braucht es 5 bzw. bei ZP,X 6 Zyklen.
@ Norbert: Besten Dank, dann habe ich mir das schon richtig gedacht. @ Thomas: Ein voller Ersatz-Chip wird nur mit Hardwaretricksereien gehen, schätze ich mal. Was ich mir erstmal vorgenommen habe, wäre ein ATmega, der in einer ATmega-tauglichen Hardware (zumindest was den Speicher anbelangt) den Originalcode so originalgetreu wie möglich auszuführen. Ich wollte erstmal sehen, ob es überhaupt so geht, wie ich mir das dachte, jetzt kommt aber auch erstmal die Detailarbeit. Ich hätte noch zwei Fragen, zum einen, könnte ich einen 8515 auf 25MHz übertakten? Und, so wie ich mich erinnere, wäre es unüblich gewesen, die Adressen 0x0000 und 0x0001 anders, als direkt über ZP-Zugriffe anzusprechen, daher fange ich diese Adresse auch nur da ab. Weiß aber nicht, ob's nicht Programmiermethoden gab, die das absolut oder so ansprechen. Vielleicht weiß das ja jemand, der etwas mehr im 6502-Code drin ist. Mark
Im Projekt SwinSID werden AVR auf 28MHz übertaktet und es läuft sicher. Ich glaube die haben vor dem Mega88 einen 8515 verwendet. Habe keine Erfahrung damit, vielleicht geht nicht jeder AVR zum übertakten, sondern nur ein Prozentsatz, keine Ahnung. Vielleicht weiss Peter mehr darüber? Einige AVR werden jetzt von den Shops schon offiziell mit 28MHz angeboten. --- Der 6510 verwendet die ersten beiden Bytes für das interne IO (DDR, PORT). Diese beiden RAM Zellen sind definitiv unerreichbar für den 6510, egal ob man die ZP, Absolut oder indexiert anspricht.
Mark L. schrieb: > könnte ich einen 8515 auf 25MHz übertakten? Ich verwende einen ATmega168 @ 24Mhz, funktioniert seit jeher ohne Probleme. An (interner) Peripherie verwende ich allerdings nur Timer (CTC-Mode, PWM), digitale I/O, UART und EEPROM. AFAIR haben die neueren AVR nen eigenen, internen RC-Oszillarot für das EEPROM-Timing, der unabhängig von F_CPU arbeitet, was bei älteren Modellen nicht der Fall ist. Auf jeden Fall sollte die Versorgungsspannung im "normalen" Bereich sein, also saubere 5V, und der µC bei etwa Zimmertemperatur betrieben werden. Der spezifizierte Bereich, in denen der µC fehlerfrei funktioniert, dürfte einiges kleiner sein als der Bereich, in dem er fehlerfrei funktioniert, ohne daß dies spezifiziert ist.
>Der spezifizierte Bereich, in denen der µC fehlerfrei >funktioniert, dürfte einiges kleiner sein als der Bereich, in dem er >fehlerfrei funktioniert, ohne daß dies spezifiziert ist. Hä...?
Ich denke er meint, übertakten funktioniert nicht im ganzen spezifizierten Bereich. Sondern eben am besten bei Zimmertemperatur und etwas auf und ab.
Mark L. schrieb: > Und, so wie ich mich erinnere, wäre es unüblich gewesen, die > Adressen 0x0000 und 0x0001 anders, als direkt über ZP-Zugriffe > anzusprechen, daher fange ich diese Adresse auch nur da ab. Weiß aber > nicht, ob's nicht Programmiermethoden gab, die das absolut oder so > ansprechen. Vielleicht weiß das ja jemand, der etwas mehr im 6502-Code > drin ist. Mark, da die 6502 CPU (die 6510 CPU ist nur ein 'unglücklicher' Sonderfall ;-) viele Befehle mit absoluter Adressierung beinhaltet, muss ein Emulator diese auch berücksichtigen. Einfachstes Beispiel LDA: Zero Page: A5 xx (2cyc) Absolute: AD xx xx (4cyc) Absolute,X: BD xx xx (4cyc, 5cyc when page boundary is crossed) Absolute,Y: B9 xx xx (4cyc, 5cyc when page boundary is crossed) Normalerweise würde jeder Programmierer zB. auf $0000 mit A5 00 zugreifen. Ein Byte und eine Mikrosekunde gespart. Da 'früher' aber sehr viel mit selbstmodifizierendem Code gearbeitet wurde, kann auch zB. der Befehl AD 00 00 vorkommen.
Thomas Winkler schrieb: > Ich denke er meint, übertakten funktioniert nicht im ganzen > spezifizierten Bereich. Sondern eben am besten bei Zimmertemperatur und > etwas auf und ab. Nö, so war's nicht gemeint. Beim Übertakten ist man immer ausserhalb der Spezifikation. Ansonsten wär's kein Übertakten ;-)
SwinSID nutzt Atmega88PA mit 32MHz bei +5V. Beim AVR CP/M Projekt habe ich 168/88PU mit +3.3V und 30MHz stabil am laufen.. Peter
Thomas Winkler schrieb: > Der 6510 verwendet die ersten beiden Bytes für das interne IO (DDR, > PORT). Diese beiden RAM Zellen sind definitiv unerreichbar für den 6510, > egal ob man die ZP, Absolut oder indexiert anspricht. Daher muss ich ja alle Schreib- und Lesezugriffe auf diese Adresse entsprechend auf die IO-Adressen vom ATmega umleiten um den IO-Port wie im Original verwenden zu können. Ich hatte das wohl etwas unglücklich formuliert. Norbert schrieb: > Da 'früher' aber sehr viel mit selbstmodifizierendem Code gearbeitet > wurde, kann auch zB. der Befehl AD 00 00 vorkommen. Ich glaube, ich hatte gehofft, dass ich das falsch in Erinnerung hatte und mir die Fleissarbeit sparen könnte, das überall abzufangen. 30MHz hören sich ja ziemlich verlockend an, gerade da mir genau diese 5 Takte beim ADC/SBC immediate in Dezimal-Modus immer noch fehlen. Wäre ärgerlich, wenn es an den zwei Opcodes scheitern würde, bzw. ich dort einen Takt mehr brauchen würde, als das Original. Ist schon ärgerlich genug, dass ich bei allen andern OPcodes mit 20MHz hinkommen könnte, wenn diese zwei Spezialfälle nicht wären. Ich hielt das für etwas utopisch, als ich es beim SwinSID mit den 32MHz gelesen hatte, aber Versuch macht anscheinend kluch. Mark
Hallo, hab' noch etwas weiter gemacht und hab' bereits den ersten 6502-Code laufen lassen muss jetzt hauptsächlich noch Testprogramme schreiben. Ich hab mich jetzt erstmal für die folgende Variante entschieden, da ich die hier habe und erstmal kein Löten nötig ist: Atmega644, 20MHz, emuliert 6510 bei 1MHz mit Code im internen SRAM, zyklengenau(im Dezimalmodus bei ADC/SBC gemäß CMOS-6510), anhalten bei Lesezugriffen über RDY möglich, die AVR-IO-Register können mit Vorsicht verwendet werden(alle, die über LD/ST angesprochen werden können), die AVR-Interrupts lösen einen NMI aus, unter 6KBytes Codegröße, 6510-IO-Port auf beliebigem AVR-Port, neuer opcode zum verschieben der ZP (ähnlich 65C02). Da ich mich bei all den vielen Möglichkeiten, die ich ständig sehe, wenn ich mal an dem Kram arbeite, immer wieder verzettel, wollte ich mal fragen, ob und was genau ihr vielleicht für eure KIM-1 und 1541-Projekte gebrauchen könntet. Bin etwas in den Emulator vertieft, wenn ich mal Zeit habe, daher hab' ich mir das noch nicht so genau angesehen. Könnte mir aber so grob, wie ich den KIM überblicke, vorstellen, 'einfach' Anzeige per Schieberegister an den AVR, Hex-Tasten an AVR-Port, AVR-USART von 6502 aus ansprechen, KIM-ROM entsprechend anpassen und ins SRAM schreiben beim Booten. Mark
Hi Mark. Das hört sich ja schon mal super an! Diddl wird das sicher in seinem KIM-1 Prototypen einbauen, mit Matrixtastatur und 7-Segmentanzeige.. In wie weit das für sein 1541-Ersatzprojekt einsetzbar ist..? Ich sehe eine weitere Möglichkeit, eine 6510 Ersatz-CPU zu bauen, die man dann direkt in eine DIP-40 Fassung z.B in einem C64 als 6510 Ersatz einsetzen könnte (der ultimative Test!). Preislich z.Z eher uninteressant.. da sicher 6510 nicht soo oft kaputt geht und die ggf. auch noch für 5-8€ zu erwerben ist.. aber die 644 werden auch immer günstiger.. und für die Zukunft sicher ein interessanter Ersatz! Peter
Hi Peter, ich wollte erstmal eine Variante weit genug hinbekommen, um zu sehen, ob die ganzen Konzepte, die ich mir so ausgedacht habe auch funktionieren. Ist das erste Mal, dass ich mich überhaupt mit Emulation beschäftigt habe. Die jetzige Variante mit internem SRAM ist leider die einzige, die ich einfach hier habe und auch in Hardware testen kann. Durch die 2-Takt Zugriffe auf den Speicher könnte man das vermutlich noch auf 16MHz runterkürzen (bzw. 1,25MHz emulieren), die RDY-Leitung ergibt auch nur Sinn, wenn entsprechende Hardware dran kommt. Für einige Projekte ist es vielleicht gut, wenn man den AVR-IO wahlweise verwenden kann (besonders den USART) für die Kompatibilität ist es aber Mist falls Programmcode in der ZP ausgeführt werden soll. Will man das so verwenden, wie es derzeit ist, ok, will man gar keinen AVR-IO, aber internen Speicher (oder externen per XMEM) müsste ich das auch abfangen, ohne XMEM wäre eher die umgedrehte Frage, ob und inwiefern das AVR-IO verwendet werden sollte/könnte. Ist leider der Nachteil von so durchgetakteter Assemblersoftware, dass man nicht so flexibel mit Änderungen ist, aber mir ist bis heute kein Compiler begegnet, der sowas auch nur in Ansätzen hinbekommen würde. Die 6510-Hardware-Eratz-Variante schiebe ich ein Wenig von mir weg, da ich nicht so viel Erfahrung mit der Hardware habe. Ich stelle mir das zwar recht 'einfach' vor (so im Prinzip), dass ich per PLL oder sowas den Systemtakt ver-20-fache, das Phi2 über PWM erzeuge und die Adress- und Daten-Leitungen über Tri-State-Buffer bzw. -Latch mit AEC verbinde. Wenn ich dann in der Software dafür sorge, dass die Signale zeitlich innerhalb der Spezifikation (sind oft nur Min/Max-Zeiten) zur Verfügung stehen, sollte es ja eigentlich klappen. Da die reale Hardware aber meist nicht so funktioniert wie die ideale, fürchte ich da mangels Erfahrung etwas wichtiges übersehen zu haben. Hab's mir auch noch nicht ganz genau angesehen, ob ich die 'in's und 'out's in der Software soweit auseinandergezogen bekomme, wie das Bustiming es auf den ersten Blick erfordert (Viel Zeit zwischen Anlegen der Adresse und der Gültigkeit der Daten), oder ob die Adresse erst angelegt werden braucht, bevor die Leitungen aus dem Tri-State herausgehen(Wurde ja nicht überall verwendet). Wenn es so geht, könnte man allerdings jeden 20MHz-8KB-40Pin-AVR nehmen, der 644 ist nur wegen dem internen SRAM interessant. Dann könnte man auch noch so 'verrückt' sein, eine Art Extended-Modus in den Emulator einzupflegen (manche 2-Takt opcodes lassen sich in einem erledigen usw.) und die invaliden opcodes mit sinnvollen Funktionen zu belegen (bspw. MUL). Beschäftige ich mich aber wohl erst weiter mit, wenn ich die entsprechenden Teile bestelle und praktische Erfahrungen mache. Sofern er die Lagerung überstanden hat(was ich aber bezweifel) könnte ich immerhin meinen alten Brotkasten als Testsystem verwenden, würde mich eh' mal interessieren, ob 27 Jahre alte Disketten noch lesbar sind. Mark
Jup. Ich habe hier immer einen C64 aufgebaut und betriebsbereit stehen.. ;-) Diddl dürfte auch bald aus dem Urlaub wieder da sein, sodaß man am ursprünglichen Thema weiter basteln kann.. Aber langfristig hätte so eine 6502/10 Ersatz-CPU auf AVR Basis schon seine Existenzberechtigung.. und wenn auch nur um zu zeigen, das es geht! Peter
Angehängte Dateien:
-
6510HardwareEmu.png
34 KB
Hab' mir mal das Bustiming genauer angesehen und könnte mir gut vorstellen, dass es so geht (Skizze und Code):
1 | RAM_READ: |
2 | ; sync: Phi0 erreicht Vcc-0.2V |
3 | 2x nop |
4 | cbi ALE |
5 | out add_L |
6 | sbi ALE |
7 | out add_H |
8 | sbi RW |
9 | out data_DDR, input |
10 | 14x nop |
11 | in data |
12 | 2x nop |
13 | |
14 | RAM_WRITE: |
15 | ; sync: Phi0 erreicht Vcc-0.2V |
16 | 2x nop |
17 | cbi ALE |
18 | out add_L |
19 | sbi ALE |
20 | out add_H |
21 | cbi RW |
22 | out data_DDR, output |
23 | 10x nop |
24 | out data |
25 | 6x nop |
Bei den Datenleitungen bin ich mir aber nicht wirklich sicher, ob das eine gute Lösung ist, oder ob ich sie nicht über den AVR länger hochohmig schalten muss. Aber ansonsten müsste ich so alle Min/Max-Vorgaben einhalten können (mit 74HCTxx). Der Emulator sollte auch da herum passen.
Peter Sieg schrieb: > Diddl wird das sicher in seinem KIM-1 Prototypen einbauen, mit > Matrixtastatur und 7-Segmentanzeige.. Als Gehäuse eignet sich ein alter EPROM-Brenner. So ein Ding mit Hexadezimaltastatur und Display, und V.24-Schnittstelle an der Rückseite. Patrick
Angehängte Dateien:
-
blue_led.jpg
370 KB -
lochraster.jpg
370 KB -
schematic.gif
64 KB
So, der Urlaub ist zu Ende, bin wieder im Lande ... Inzwischen sind die blauen 7-Segment aus China da. Habe dieses Wochenende meine LED Theorie etwas aufgebessert und die Display am Breadboard getestet. Und ein Schaltbild gezeichnet. Es zeigt die Erweiterung für ein AVR Entwickler Board auf Lochraster. Die 100 Ohm Widerstände beziehen sich auf das von mir verwendete blaue 7-Segment Display bei 5V. Die Displays laufen mit 3,4V und ziehen 15 bis 20 mA. Für andere (rote,grüne) Displays müssen die Widerstände entsprechend angepasst werden. Der BD137 ist überdimensioniert, ich weiß. Aber habe gerade nix anderes da ...
Hallo, vielleicht hat ja jemand Lust das mal zu testen. Ich habe zwar vermutlich noch nicht alle (Tipp-)Fehler beseitigt, IRQ und NMI sind auch noch nicht richtig getestet, aber ansonsten sollte alles soweit funktionieren. Das Taktverhältnis ist 20zu1, AVR mit 20MHz ergibt 6510 mit 1MHz. Habe das auch auf dem STK500 laufen lassen und die LEDs blinken so wie sie sollen, angesprochen vom 6510er-Code aus direkt auf den AVR-IO. Ich hab' nur mal das Arbeitsverzeichnis kopiert, ist daher alles noch etwas chaotisch und voll von nutzlosen, überholten Kommentaren. Der 6510er-Code kommt in die Datei "6510CodeSeg_inc.asm" in Form von .db-Anweisungen, wird ab Adresse 0x0200 ins SRAM kopiert und dann der Code an Adresse 0x0200 ausgeführt. Der IRQ ist derzeit deaktiviert(SEI/CLI setzen nur das Flag ohne Auswirkungen), spart einen Pullup beim Testen. Einstellungen bzgl. IO-Port, Reset-, NMI- und IRQ-Vektoren und -Portpins befinden sich ganz zu Anfang der Datei "6510Emu644iRam.asm". Die RDY-Leitung ist mit active-High in Funktion, wenn's stört, sollte es genügen, die zwei Befehle im Macro "READ_RDY" durch nops zu ersetzen. Mark
Genial, da muss ich doch glatt am Weekend mein verstaubtes STK500 aus dem Keller holen! :-)
Hab' leider nicht mehr genügend Taster hier, sonst würde ich mir mal die KIM-Tasten und Display zusammenlöten. Ich habe in dem Emulator noch ein paar kleinere Fehler korrigiert sowie IRQ und NMI fertig gemacht. Ich konnte bisher nicht herausfinden, wieviele Takte es benötigt, wenn während BRK ein IRQ/NMI kommt, habe einfach mal 8 genommen. IRQ ist noch deaktiviert, damit der feste Pin nirgends dazwischen funkt. Das KIM-Rom habe ich mir auch mal angesehen, sollte eigentlich kein Problem sein, dass anzupassen auf AVR. Ich habe nur nicht ganz verstanden, was mit dem dritten Port ist, im KIM-Rom tauchen nur A+B auf, liegt der auf dem anderen IO-Baustein??
Ich habe alle Teile beisammen, aber hier hat es so schönen Schnee, das wirkt stark Projekt verögernd ... Aber immerhin habe ich nun den Lochraster Aufbau im Lochmaster geplant: http://t-winkler.net/dokuwiki/doku.php?id=kim:kim1284#prototyp Und gestern bin ich auch noch etwas zum Löten gekommen, - es wird langsam. --- @Mark L. Deine Engine ist 100% Assembler. Mit Assembler hab ich es leider nicht so. Kann ich deine Engine irgendwie aus meinem C Programm ansprechen? Kann das Assembler Teil mit Variablen arbeiten die ich in C global definiert habe? Oder verkehrtt rum, kann ich Daten ansprechen die im Assembler definiert wurden? Wenn der AVR zu schnell ist, dann wird die übrige CPU Zeit quasi "verheizt", also du hast einfach bei jedem Befehl Waits um den Vorsprung auszugleichen. Wenn jetzt der Speicher nicht so simpel ist wie beim KIM, also bei jedem fetch entschieden werden muss, welchen Speicher man zugreifen muss, dann müsste man alle Waits jedesmal anpassen? Als CPU Ersatz, mit ausschliesslich externem Speicher und IO, hat man das Problem natürlich nicht. --- Wie weit ist denn Hr. Engel mit der 6502 Engine?
Thomas Winkler schrieb: > Deine Engine ist 100% Assembler. Mit Assembler hab ich es leider nicht > so. Kann ich deine Engine irgendwie aus meinem C Programm ansprechen? > Kann das Assembler Teil mit Variablen arbeiten die ich in C global > definiert habe? Oder verkehrtt rum, kann ich Daten ansprechen die im > Assembler definiert wurden? Tut mir leid, aber ich habe von dem Zusammenspiel Hochsprache+Assembler auf AVR kaum Ahnung. Ich beschäftige mich nur wegen dem Assembler überhaupt mit AVRs um mal gerade keine 'Hoch'-Sprache nutzen zu müssen, bezweifel aber auch, dass ein Zyklentreuer Emulator ohne viel Assembler überhaupt möglich ist. Thomas Winkler schrieb: > Wenn der AVR zu schnell ist, dann wird die übrige CPU Zeit quasi > "verheizt", also du hast einfach bei jedem Befehl Waits um den Vorsprung > auszugleichen. Prinzipiell ja, es finden alle 20-AVR-Takte eine Abfrage des RDY-Pins und ggf. ein Speicherzugriff statt. Das 'einfach' hat allerdings den Großteil der Arbeit an dem Emulator ausgemacht ;-). Eigentlich ist dieser Emulator ein geschlossenes System, das einfach durchläuft und (hoffentlich) seine Arbeit fehlerfrei erledigt. Änderungen im Emulator bedeuten immer wieder neu Takte zählen, auch wenn ich das über Macros etwas vereinfacht habe. Thomas Winkler schrieb: > Wenn jetzt der Speicher nicht so simpel ist wie beim KIM, also bei jedem > fetch entschieden werden muss, welchen Speicher man zugreifen muss, dann > müsste man alle Waits jedesmal anpassen? Ich denke mal, du willst auch weitere Hardware im AVR emulieren nicht nur den Prozessor. Ich hab' vielleicht diesbezüglich ein Brett vorm Kopf, aber ich sehe auch nicht, wie es möglich sein soll, dann noch Zyklenexaktheit zu erreichen, außer man begnügt sich mit ungefähren Mittelwerten wie bspw. die Cornell-Projekte. Einen Mini-Speichermanager wollte ich noch in den freien Takten einbauen, damit auch der AVR-Flash als 6502-ROM verwendet werden kann, aber dann ist auch spätestens 'Ende der Fahnenstange' für die immediate-Opcodes (aus meiner Sicht). In den >3-6502-Takte-Opcodes ist zwar genügend Platz, aber da nicht vorhersagbar ist, wann, bzw. ob diese überhaupt auftauchen würde das wohl nur in ganz speziellen Fällen funktionieren, wenn man Hardware in dieser Zeit emuliert. Hoffe, dass sich das hier nicht zu negativ/kritisch anhört, ich suche nur nach Lösungsmöglichkeiten die ich bisher übersehen habe. Das Üble sehe ich gerade in den immediate-opcodes. Da muss in 40 AVR-Takten(@20MHz) der opcode gelesen werden(min. 9 Takte), IRQ+NMI+RDY abgefragt(min. 6 Takte), im absoluten Minimum zwei Sprünge durchgeführt (durch das dann notwendige Ausformulieren gehen keine relativen Sprünge mehr)(6 Takte), Oparand lesen, verarbeiten, Flags setzen (8+ Takte) sowie der Timer gesetzt und angesprungen werden (6+ Takte). Ist nur grob überschlagen, ich weiß nichtmal, ob das überhaupt so hinhaut, aber vielleicht hat ja jemand eine bessere Idee. Viele Grüße Mark
Deine Lösung ist super! Speziell wenn man an einen 6502 Ersatz denkt. Aber, - ja, - ich will AVR Flash als 6502 ROM verwenden! Und da fängt die Problematik an. Bei jedem Speicherzugriff des 6502 muss man prüfen ob es RAM oder ROM wird. Ja schlimmer noch, es muss auch geprüft werden ob IO gemeint ist. Aber, - mir würde eine durschnittliche Takt Synchronität leicht langen. Es muss halt an bestimmten, kritischen Stellen erfolgen. Also zb. Wenn ein IO Zugriff erfolgt. Ich bräuchte also nur eine Funktion Sync(), die vergleicht AVR Timer Zeit (Echtzeit) mit 6502 CPU Zeit (6502 Takte) und wartet gegebenfalls bis die synchron sind. Diese Funktion Sync könnte man alle 10 6502 Befehle aufrufen. und natürlich bevor kritische Befehle kommen (IO Access).
Ich hab' bisher keine Idee, wie man das alles hinbekommen könnte. RAM+ROM geht, ein, zwei oder drei IO-Adressen umleiten geht auch dazu, aber es wird schon eng, wenn dann noch bspw. ein 74145 emuliert werden soll. Für die Sync-Funktion habe ich auch noch keine Idee, wie man die kurz und genau hinbekommen könnte, die müsste ja Taktgenau mit 3 Wartetakten zurecht kommen, wie mit 500, je nach emulierten Programmcode. Und sie müsste so kurz sein, dass, wenn bspw. vor dem IO-Zugriff nur ein 2-Zyklen-Opcode steht, Opcode+Sync+IO im Takt sind. Hab mich da gestern mal mit beschäftigt, aber bisher nix brauchbares zusammenbekommen, im vorgenannten Worst-Case würde aber bisher alleine der Sync alles aus dem Takt hauen. Thomas Winkler schrieb: > Aber, - mir würde eine durschnittliche Takt Synchronität leicht langen. > Es muss halt an bestimmten, kritischen Stellen erfolgen. Also zb. Wenn > ein IO Zugriff erfolgt. Der Durchschnitt bspw. bei der NES-Emulation bezog sich ja darauf(nur grobe Zahlen, genauere standen da irgendwo auf der Seite), dass 2-Takt-Opcodes mit <1MHz emuliert werden, dafür die 7-Takter mit <4MHz und damit ein Mittel von 1,77MHz erreicht werden könnte. Eine Sync-Funktion müsste da noch Takte einsparen. Vielleicht hat ja jemand eine Idee, wie man so einen Emulator aufbauen kann, bzw., wie man in (Worst-Case) 10-15 Maschinentakten(inkl. Sprünge) eine solche Syncfunktion hinbekommt.
Mark L. schrieb: > Vielleicht hat ja jemand eine Idee, wie man so einen Emulator aufbauen > kann, bzw., wie man in (Worst-Case) 10-15 Maschinentakten(inkl. Sprünge) > eine solche Syncfunktion hinbekommt. Eine Idee habe ich schon: + Jede 6502 Funktion "weiss" wieviele 6502 Takte sie braucht. Also einfach eine Konstante in eine Register laden. + Die übergeordnete Funktion die die einzelnen OP Code Routinen aufruft addiert die 6502 Takte aus dem Register in eine Variable (VT). + Ein AVR Timer muss reserviert sein für die Sync Sache. Teiler und Counter werden auf 1MHz geeicht. Man braucht eine Funktion die quasi die vergangenen µs (RT) zurückgibt. Die Sync() Routine vergleicht nun die aufsummierte Zahl in VT mit dem Wert RT. Is VT kleiner, - Pech gehabt. Wir waren zu langsam. Ist VT größer, dann muss man VT - RT in µs warten (delay()). In jedem Fall wird der AVR Timer und VT auf null gesetzt. Die Taktik ist nun Sync() ab und zu aufzurufen und bei bedarf (critical IO). Ab und zu bedeutet: + alle 50µs + oder alle 10 6502 Befehle + oder ...
Thomas Winkler schrieb: > Is VT kleiner, - Pech gehabt. Wir waren zu langsam. Das plus kritischen IO macht die Sache irgendwie unbrauchbar aus meiner Sicht. Dann kann man auch die vorgenannte Durchschnittsmethode nehmen, wenn der IO dann eh' schon aus dem Takt ist. So, wie du es vorschlägst und auch andere Möglichkeiten habe ich gestern mal ausprobiert, aber alle dauern deutlich zu lange, um sicher zu laufen. Die Idee, die ich meinte, wäre, wie geht das in möglichst wenigen 8-bit Rechenoperationen, so bspw. einmal Plus, einmal Minus, eine Verzweigung (in C: b-=c;a+=b; If (a>d) warte;) Viel mehr Code darf das nicht sein für den Sync. Vielleicht könnte man den Watchdog missbrauchen oder irgendeine andere Funktionseinheit im AVR. Um den Timer auf 1MHz zu bekommen, müsste man das wohl mit einem Timer als externes Signal erzeugen und in einem zweiten als Eingang nehmen, 8 oder 64 als Prescaler ist da unbrauchbar. Was vielleicht auch geht wäre soweit übertakten, dass ausreichend Zeit zur Verfügung steht (so aus dem Bauch, vielleicht auf 28 oder 30MHz).
Falls euch das hilft.. beim SwinSID88 wird ein ATmega88 mit 30MHz übertaktet.. läuft stabil bei +5V. Beim AVR CP/M Projekt läuft bei mir ein 88/168 mit 30MHz sogar noch bei +3,3V.. Ergo: 30MHz bei +5V sind definitiv machbar.. Peter
Die >=20 AVR-Takte, die bei 30MHz pro Opcode mehr zur Verfügung stehen sollten für einen Sync reichen. Je nachdem, wie ich Zeit finde, probiere ich das mal aus. Hab' schon angefangen den Emulator neu zu schreiben (hab bisher mit dem Z-Register getrickst, brauche das aber für die LPMs daher ist's was mehr Arbeit). Wieviel Genauigkeit für den Sync ist eigentlich nötig? Ich versuche 100%(Abweichung =0 AVR-Takte) zu erreichen, könnte mir aber vorstellen, dass das übertrieben ist.
Nach dem Sync sollte es möglichst µs genau sein. Wenn es im Schnitt etwas langsamer oder schneller läuft ist für meine Projekte irrelevant.
Hab' mich mal für eine Variante entschieden, die bis zu 16-AVR-Takte schwankt, aber im Mittel konstant laufen sollte. Zumindest bei 30MHz sollte das gehen. Was die Verwendung von dem Code angeht sehe ich aber Schwierigkeiten. Es gibt zwar genau definierte Punkte, ab denen Code für IO eingefügt werden kann, mir ist aber kein Assembler bekannt, der Inline-C beherrscht. Am PC wüsste ich wie man das machen könnte, aber beim AVR??? Viele Grüße Mark
Inline C? Nö aber der GCC kann inline Assembler. Aber zum Mixen sollte es ja langen wenn man Assembler vom C aus aufruft. Man müsste einfach die Anzahl Takte vorgeben können. ZB.: Exec6502(50); läuft 50 µs lang. Bei Exec6502(1); läuft genau ein Assemblerbefehl, für single step. Exec6502(0); läuft unendlich, Unterbrechungen nur durch IO oder Interrupt. --------- Wenn er RAM (extern oder AVR RAM) und ROM (AVR flash) kann ist es schon ok. Für IO müsste er einfach eine Unterprogramm (RCALL) ausführen. Es müsste "nur" der Adressbereich für IO selektieren können: ZB. RAM :: 0000 - 17FF IO :: 1800 - 1BFF ROM :: FC00 - FFFF Im Falle vom KIM-1 wäre es gut die obersten drei Bit (A15, A14, A13) zu ignorieren. So dass sich RAM, ROM und IO einfach 8 mal spiegeln im Adressbereich.
Komme im Moment nicht groß dazu, weiter zu machen, aber so das Gröbste habe ich schon. Eine Ablaufsteuerung habe ich nicht vorgesehen. Bei Speicherzugriffen wird zwischen RAM und ROM unterschieden anhand einer Grenze (bspw. RAM von $0000 bis $17FF, dann ROM), außer bei ZP-Zugriffen, die ZP muss im RAM liegen. Außer bei den Opcodes wird dann zusätzlich beim RAM eine Grenze abgefragt(bspw. RAM von $0000 bis $16FF, IO von $1700 bis $17FF), ab der zur einer IO-Routine (rcall IOREAD, rcall IOWRITE) verzweigt wird. IO-Zugriffe werden synchronisiert auf den Genauen Takt innerhalb des Opcodes beim ersten Zugriff. Bspw. liest die absolute Adressierung bei 6502-Takt 4 des Opcodes den IO ein, Sync ist hier nach 3 Takten. Bei READ-Modify-WRITE-Zugriffen auf den IO wird 'nur' das READ synchronisiert, das restliche Timing(WRITE nach 2 6502-Takten) innerhalb des Opcodes muss dann die IO-Routine übernehmen. Verwenden des IO für opcodes geht nicht, auch die Möglichkeit Opcodes in der ZP auszuführen habe ich derzeit nicht vorgesehen, das könnte aber evtl. noch möglich sein. Wenn ich das Spiegeln richtig verstehe, reicht da wohl das regelmäßige ANDen des Highbyte aus, das sollte kein Problem sein. Deutlich schwieriger würde es, wenn die Bereiche RAM, IO und ROM keine aufeinander folgenden Blöcke sind. Wenn's mehr als ein paar IO-Adressen(Tastatur+7-Segment waren's, glaub ich, 4) wie beim KIM sind sollte man da auch eine schnelle Sprungtabelle einbauen. Mark
Hallo, also, sieht so aus, als wenn alles soweit läuft. Hab's aber bisher nur mal grob getestet mit dem KIM-ROM im Flash und es funktioniert so, wie es soll. Ich kann das gerne mal hochladen, so wie es ist, aber das Vorhandensein von Fehlern kann ich nicht wirklich aussschließen. Mir ist dabei noch eine 'Inkompatibilität' zu der Platine von Thomas aufgefallen: Ich habe für IRQ, NMI und RST INT0 bis INT2 verwendet, der Platinenaufbau würde aber PinChange-Interrupts verlangen. Problem eins ist das Entprellen bei diesen Leitungen, außerdem würde der PCI beim Drücken und auch beim Loslassen der Taste auslösen. Das Entprellen könnte man vielleicht lösen, indem die entsprechenden Leitungen per PWM nur mit 50Hz oder so versorgt werden, für die PCI-Verwendung fallen mir aber nur FlipFlops ein
@Mark L: Ja, bitte hänge den Code doch mal an.. Wie wird 'das System / dein Micro-KIM' bedient..? Ich hatte mir ja als Option 'gewünscht', das auch eine parallele Bedienung über seriell möglich ist.. ;-) Peter
Da ich wegen dem (C) nicht Bescheid weiß, habe ich das KIM1-ROM nicht dabei gelassen. Dieses müsste als .db-Anweisung in die Datei "k1rom_inc.asm". Zur 'Bedienung' weiß ich nicht so recht, was ich sagen soll. Es gibt ein paar Einstellmöglichkeiten im Code, aber mehr eigentlich nicht. So, wie es ist (hab die IO-Port grob umgesetzt), sollte die Schaltung von Thomas mit dem KIM-ROM eigentlich laufen (von vorgenannten Schwierigkeiten mit dem IRQ etc. abgesehen). Was eine Steuerung des Emulators angeht, kann es gut sein, dass ich das zu kompliziert sehe, aber das, was ich mir darunter vorstelle passt einfach nicht mehr auf einen AVR. Zumindest nicht so präzise, wie ich denke, dass sowas sein müsste. Ist aber vielleicht mehr die Frage, welche Art von Steuerung man wie unterbekommen könnte und wie der Emulator sich dabei verhalten soll. Bspw. könnte man den Emulator über eine Steuerleitung anhalten oder den USART-Interrupt verwenden und bei Empfang eines Bytes in eine Steuerrotuine verzweigen. Aber es wäre meistens das Timing hin und bspw. beim KIM-1 könnte man die 7-Seg.Anzeigen nicht mehr lesen, wenn der Emulator nicht durchläuft.
Die KIM-1 Geschichte wird wieder interessant. Jetzt, 2 Jahre später ist die Technik an einem ganz anderen Stand. Die ARM's sind super günstig geworden. Deshalb habe ich vor ein paar Monaten beschlossen, die ARM Welt für mich zu erschliessen. Die Entscheidung fiel auf den Cortex-M4 von ST. Der Grund ist das günstige Discovery Board um 16€. Der STM32F4 strotzt nur so vor Leistung: 168MHz, 1MB Flash, 168K SRAM, eine Unzahl von Timer und Peripherie ... Nach den ersten Gehversuchen mit dem F4 war ich restlos begeistert von dem Teil. Die Abkehr von der alten 8 bit AVR Technik fiel mir nun sehr leicht. Berauscht von der hohen Leistung des F4, habe ich mich an mein altes 1541-Emul Projekt erinnert. Kurze Tests mit der 6502 Engine haben gezeigt, dass es diesesmal nicht scheitern würde. Eine reine C Implementierung würde funktionieren. Ganz so leicht war die Umsetzung dann aber doch nicht. Viele Monate hat die Umsetzung samt Grundlagenforschung nun verschlungen. Inzwischen läuft die Floppy Emulation am F4 ziemlich gut. Natürlich wird es noch Monate dauern, bis zur Perfektion. Aber man sieht, dass die Probleme überwunden sind und es nur noch fertig gestellt werden muss. Lange Rede kurzer Sinn, - der virtuelle KIM-1 ist mittelfristig wieder im Rennen. Er wird quasi als Abfallprodukt vom 1541-Emul kommen. Alle Komponenten des KIM-1 sind auch in der Floppy 1541 drin. Man muss es nur noch auf den KIM-1 abspecken.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.