mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik KIM-1 in AVR?


Autor: Peter Sieg (petersieg)
Datum:

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Peter Sieg (petersieg)
Datum:
Angehängte Dateien:

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

Autor: Peter Sieg (petersieg)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Schaltplan..

Hier die Monitorroutinen:
                                  KIM SUBROUTINES

CALL         ADDRESS  ACTION            ARG   RESULT  NOTES
JSR AK       1EFE     Check for         -     A       A = 0 = Key down
                      key depressed                   A<>0 = No Key down
                                                      X & Y lost

JSR GETKEY   1F6A     Get key from      -     A       A>15 illegal
                      keyboard                        or no key

JSR SCANS    1F1F     Display F9, FA,   F9.   -       A, X, Y are lost
                      FB                FA,
                                        FB

JSR GETCH    1E5A     Put character     -     A       X preserved
                      from TTY in A                   Y = FF

JSR PRTBYT   1E3B     Prints A as       A     -       A preserved
                      2 Hex Char.                     X preserved
                                                      Y = FF

JSR PRTPNT   1E1E     Prints Contents   FB,           A lost
                      of FB & FA        FA            X preserved
                      on TTY                          Y = FF

JSR OUTCH    1EA0     Print ASCII char  A     -       Xis preserved
                      in A on TTY                     Y = FF
                                                      A = FF

JSR OUTSP    1E9E     Print a space     -             A = FF
                                                      X preserved
                                                      Y = FF


Peter

Autor: Peter Sieg (petersieg)
Datum:
Angehängte Dateien:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

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?

Autor: Entwickler (Gast)
Datum:

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

Autor: visitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: .,.,.,.,.,.,. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht doch um einen Emulator... und der kann die zu interpretierenden 
Befehle problemlos aus dem RAM holen...

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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


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.

:)

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blödsinn, das Teil von myAVR hängt an einem 74HC4511, der kann leider 
nur BCD darstellen ...

Autor: bongo (Gast)
Datum:

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

Autor: Dr.PillePalle (Gast)
Datum:

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

Autor: Peter Sieg (petersieg)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Detlev T. (detlevt)
Datum:

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

Autor: Joerg F. (felge1966)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Detlev T. (detlevt)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Fin... 
- die Jungs sind aber nicht wirklich weit gekommen)

-- Michael

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Sigint 112 (sigint)
Datum:

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

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

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

Autor: Detlev T. (detlevt)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Aber ich bin leider nicht in der Lage das aufgrund dieser Beschreibung 
umzusetzen. Mir ist das irgendwie zu komplex.

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

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist der Link eines VC-20 nachbau mit einem Atmega 8:

http://www.avrfreaks.net/index.php?module=Freaks%2...



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.

Autor: Michael Engel (cuby)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Zu spät zum editieren...)

Michael Engel schrieb:
> Aber da hilft vielleicht eine kurze Anfrage.

Anfrage ist raus.

-- Michael

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

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

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow! Das hört sich ja prima an!

Peter

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

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

Autor: Michael Engel (cuby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal einen Artikel zum Thema im Wiki unter 
http://www.mikrocontroller.net/articles/AVR_6502_Emulator angelegt.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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


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.

Autor: Peter Sieg (Gast)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

> (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.

Autor: Peter Sieg (Gast)
Datum:

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

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

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Norbert (Gast)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Peter (Gast)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke er meint, übertakten funktioniert nicht im ganzen 
spezifizierten Bereich. Sondern eben am besten bei Zimmertemperatur und 
etwas auf und ab.

Autor: Norbert (Gast)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Peter Sieg (Gast)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Peter Sieg (petersieg)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Peter Sieg (Gast)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab' mir mal das Bustiming genauer angesehen und könnte mir gut 
vorstellen, dass es so geht (Skizze und Code):
RAM_READ:
  ; sync: Phi0 erreicht Vcc-0.2V
  2x  nop
    cbi ALE
    out add_L
    sbi ALE
    out add_H
    sbi RW
    out data_DDR, input
  14x  nop
    in data
  2x  nop

RAM_WRITE:
  ; sync: Phi0 erreicht Vcc-0.2V
  2x  nop
    cbi ALE
    out add_L
    sbi ALE
    out add_H
    cbi RW
    out data_DDR, output
  10x  nop
    out data
  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.

Autor: Om Pf (ompf)
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:
Angehängte Dateien:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genial, da muss ich doch glatt am Weekend mein verstaubtes STK500 aus 
dem Keller holen! :-)

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

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?

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
"The first book of KIM" 1977, 176 Seiten

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Peter Sieg (Gast)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

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

Autor: Peter Sieg (petersieg)
Datum:

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

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Thomas Winkler (Firma: privat) (diddl)
Datum:

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

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.