Ein kleiner Computer

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#1
27.07.2014, 13:26

Hallo zusammen,

meine Gewächshausbewässerung ist ja nun fertig (wenn ich den kleinen Fehler denn finde) und es wird Zeit für ein neues Projekt.

Ich habe zwei Themen, die mich interessieren:
  • Ein kleiner autonomer, fahrender Roboter
  • Ein kleiner voll funktionsfähiger Computer

In den letzten Tagen habe ich mich intensiv mit dem Thema "Kleincomputer" auseinander gesetzt. In meiner Jugend hatte ich einen kleinen VZ200. Dieser hatte eine Z80-CPU und war viel leistungsfähiger als es das implementierte "Betriebssystem" erlaubte.

Es gibt im Netz einige Vorschläge zur Verbesserung der Leistung dieses kleinen Computers.

Nun will ich diesen Computer nicht nachbauen sondern lieber etwas mit einem AVR machen. Die Schaltpläne des VZ200 sind aber sehr hilfreich für das Verständnis des Aufbaus eines solchen Computers.

Zunächst einmal habe ich mir jetzt einen Fignition Fuze bestellt. Das ist ein AVR-basierter, kleiner Computer, der recht leistungsfähig ist. Den werde ich dann mal aufbauen um tiefer einzusteigen.

Und wenn der mal läuft, und ich verstanden habe, wie das alles zusammenhängt, dann will ich selbst auch mal einen kleinen Compi entwickeln. Ich weiß, dass das ein großes Projekt ist und ich dafür sicher viel Zeit benötigen werde. Aber es macht ja Spaß. Und meine Assemblerkenntnisse werde ich so auch erheblich erweitern können.

Näheres dann, wenn der Fignition da ist....

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#2
30.07.2014, 23:07

Hallo zusammen,

meine Tendenz bezüglich eines neuen Projekts hat sich ja schon abgezeichnet.... Ich tendiere eher zum Bau eines kleinen Computers als zum Projekt Roboter. Auch wenn der praktische Nutzen eines 8 Bit-Computers sich wohl in Grenzen hält, so ist der Lerneffekt (für mich) sicher hoch.

Mein Plan ist, einen Atmega 162 als Prozessor zu verwenden. Der Atmega162 ist einer der wenigen µC von Atmel mit einer Schnittstelle für externes RAM. 64 KB sind möglich. Zusätzlich werde ich für die Bildverarbeitung einen MC6847 Videocontroller einsetzen an den ich ein 8KB-Video-RAM (6264) anschließe. Die Verbindung zwischen VDC, RAM und µC erfolgt mit einem 74LS783 (Synchronous Adress Multiplexer).

Alle diese Teile sind aus den Anfängen der Heimcomputer und schon echt schwer zu beschaffen. Ich habe sie auf dem amerikanischen Ebay bei einem chinesischen Händler gefunden (Und natürlich bestellt).

Als Vorlage für die Schaltung werde ich diverse Referenzschaltungen aus dem Netz und die Datenblätter der Hersteller der Bausteine verwenden.

Das "Betriebssystem" des Computers wird höchst wahrscheinlich ein Basicinterpreter werden. Ich besitze ein ROM-Listing eines VZ 200/Laser 210 (Das war mein allererster Computer). Es ist für einen Z80-Prozessor geschrieben. Ich werde versuchen, es zu portieren (Z80-Assembler war mal meine Spezialität, ist aber schon 30 Jahre her *gg*).

Nunja... Soviel zum ersten Plan... Wir werden sehen, wie weit ich komme.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#3
09.08.2014, 19:03

Hallo zusammen,

inzwischen sind meine Überlegungen einen Schritt weiter.

Der VDC 6847 befindet sich noch auf dem Weg zu mir. Das Teil muss ja immerhin aus China kommen. Ebenso der SN74LS783.

Als externer Speicher für den Atmega162 und als Video-RAM kommt nun der HY62256ALP-10 Speicherchip (32K x 8Bit, also 32KB) zum Einsatz (In der Bay gefunden). Zwei davon werden insgesamt verbaut (= 64KB). Damit sind die regulären Möglichkeiten des Atmega162 ausgereizt.

Der SN74LS783 wird dafür sorgen, dass sowohl der Atmega als auch der MC6847 auf den Speicher zugreifen können. Auf diese Weise ist es möglich einen Teil des externen Speichers des Atmega vom µC aus zu beschreiben und den MC6847 das Ergebnis anzeigen zu lassen.

Natürlich fehlen zum vollständigen Computer noch etliche Komponenten. Schnittstellen zur Außenwelt wären nicht schlecht.... Tastatur, serielle Schnittstelle, vielleicht sogar soetwas wie ein Soundchip. Mal sehen....

Um mal ein Gefühl für die Speicherthematik zu bekommen, habe ich heute auf meinem Steckbrett mal einen Speicherbaustein an meinen Arduino Mega2560 gehängt. Der erste Versuch ist gescheitert, beim Zweiten hat's dann funktioniert. Die nächste Version wird mit einem Atmega162 gebaut. Der Mega2560 ist für die Thematik etwas zu groß und auch zu Schade. Die Mega162 sind auch schon bestellt.

Hier mal zwei Bilder vom Testaufbau:

Der Speicherchip:
   

Der Gesamtaufbau:
   
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#4
16.08.2014, 19:58

Inzwischen habe ich mir ein paar weitere Gedankeen gemacht.

Es gilt zunächst einmal den modernen ATMega162 mit einem Video Controller von 1980 zusammenzubringen. Das ist nicht ganz so einfach.

In meinem vorigen Beitrag hatte ich ja schon einen Speicherchip an meinen Arduino Mega 2560 gehängt, um mal das Speicherinterface zu testen. Da hatte ja soweit funktioniert.

Nun ist es wieder ein "nackter" Chip, eben ein Atmega 162. Dieser hat ebenfalls ein Interface für externen Speicher und wird vom Prinzip her genau gleich behandelt wie der Mega 2560.

Die Herausforderung ist jetzt, den MC6847 mit an die Schaltung zu bekommen.

Heute habe ich mir mal die Zeit genommen, einen kleinen Schaltplan zu entwerfen. Ich habe einen ATMega162 mit 2 RAM-Bausteinen vom Typ HY62256 bestückt (32K x 8). Der 74HC573 dient als Latch und sorgt für das Multiplexing der Adressleitungen/Datenleitungen des ATMega. Mit Pin 28 des AVR (PC7 / A15) wird der Chipselect gesteuert. Ist CS high, wird RAM 1 genutzt. Für den Chipselect von RAM 2 verwende ich einen Inverter (74HC04). So ist gesichert, dass immer das richtige RAM aktiv ist.

Bis hierhin ists noch recht einfach gewesen.

Jetzt kommt der MC6847 ins Spiel. Hier wächst meine Unsichertheit umgekehrt zur Außentemperatur bei uns im Ort.

Der Takt des VDC soll gemäß seiner Spezifikation sein. Dieser Takt wird dann auch für den AVR verwendet. Das Signal /FS des VDC hänge ich an OE des 74HC573 um diesen auf Tristate zu bringen, wenn der VDC zugreifen möchte. Die Adressleitungen des VDC habe ich direkt mit denen des RAM verbunden. Allerdings habe ich DA8 bis DA12 des VDC mit A10 bis A14 des AVR verbunden um auf den oberen Adressbereich von RAM 2 zugreifen zu können. Hier bin ich sehr unsicher, ob meine theorie funktionieren kann, was mache ich an dieser Stelle mit dem Chipselect? Meine Gadankengang war, dass der VDC kein CS benötigt, er adressiert von &H0 aufwärts bis &H6800 und weil ich seine Adressleitungen um zwei Leitungen verschoben angeschlossen habe, beginnt er &H6800 Bytes unterhalb vom Ende des Adressbereichs von RAM 2 ( wenn das mal gut geht...)

Damit der VDC nur Daten bekommt, wenn der AVR nicht schreibt, habe ich in die Datenleitungen einen 74HC245 (8 bit Bustreiber) eingeschleift. Dieser nimmt das Byte entgegen und wartet darauf, dass !WE erlischt. Das Signal geht über den Inverter zum Treiber. Erst dann wird das Byte übergeben.

Das ist jetzt mal ein erster Wurf. Der besseren Übersicht halber habe ich die Leitungen im Plan unterschiedlich eingefärbt:

Grün = Adressleitungen des AVR
Blau = Datenleitungen (alle)
Gelb = Adressleitungen des VDC
Lila = Steuerleitungen (alle)
Schwarz = GND
Rot = Vcc

Der Plan ist hinsichtlich Stromversorgung und sonstigem Schnickschnack nicht vollständig. Es geht erst einmal darum, den Weg zu finden, wie AVR und VDC elektrisch in Einklang zu bringen sind.

Hier ist der Plan:
   

Beste Grüße,
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#5
25.08.2014, 14:07

Hallo zusammen,

ich habe meinen Schaltplan ein wenig modifiziert. Der vorige Plan war hinsichtlich der Adressierung nicht in Ordnung und auch die Übersichtlichkeit war nicht wirklich gegeben.

Der hier beigefügte Schaltplan adressiert nun korrekt beide Bausteine. Eine grössere Änderung hat es hinsichtlich der verwendeten Speicherbausteine gegeben.

Der MC6847 (im Plan rechts) benutzt einen kompletten Speicherbaustein für sich als Video-RAM. Dieser ist deshalb, abweichend zur vorigen Version, nur 8Kb groß. Der MC6847 kann 6 KB davon verwenden, der Rest liegt brach.

Der AVR bekommt als Arbeitsspeicher 32KB verpasst, auf die er ständig zugreifen kann.

Damit der VDC etwas darstellen kann, benötigt er natürlich Informationen in seinem Video-RAM. Diese werden ihm vom AVR geliefert. Hier ist jedoch die Besonderheit. Sowohl der AVR als auch der VDC würden gemeinsam auf den Adressbus und den Datenbus zugreifen wollen, was sicher zum Chaos führt. Es ist somit unabdingbar, dass der AVR dem VDC mitteilt, dass er auf den (Video)Speicher zugreifen möchte (Schreibend oder lesend). Dazu legt der AVR ein Signal an den Pin !MS des VDC. Der AVR zwingt den Bus des VDC so auf Tristate und somit vom Adressbus und Datenbus weg.

Aktuell ist im Schaltplan davon zwar noch nix zu sehen, aber wenn man alles richtig machen will, muss nicht nur der Bus des VDC auf tristate sondern man muss auch warten, bis sich der VDC in der Austastlücke des Fernsehbildes (oder des Monitorbildes) befindet. [Der VDC ist ein Video Display Generator, der ein NTSC- oder PAL-fähiges Videosignal erzeugt]. Nur wenn sich der VDC in der Austastlücke befindet, ist gewährleistet, dass auf dem Schirm während eines Speicherzugriffs kein "Grissel" entsteht.

Um das zu erreichen ist definitiv die Arbeit mit Interrupts nötig. Gedanklich läuft das in etwa so ab:
  • Der VDC teilt dem AVR mit dem Signal !FS über INT0 mit, dass er sich in der Austastlücke befindet
  • Der AVR legt den VDC auf tristate (!MS des VDC wird auf LOW gezogen)
  • Der AVR schreibt ins Video-RAM
  • !MS kommt auf HIGH

Dafür sind bei einem mit 8MHz getakteten Atmega162 ca 20000 Takte Zeit. Um das Zeitfenster einzuhalten, würde ich den 16bit Timer benutzen. Dieser löst nach etwas weniger als 20000 Takte einen Interrupt aus, der !MS wieder freigibt.

Soweit mal zu meinen Gedanken....

   
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#6
09.09.2014, 11:55

Inzwischen ist aus der Idee ein konkretes Projekt geworden, als muss entweder der Thread woanders hin oder das Forum benötigt einen anderen Namen, denn das Thema wartet ja nicht mehr auf Umsetzung, es WIRD bereits umgesetzt.

Also... Zum aktuellen Stand des Projekts:

Die Umsetzung gestaltet sich schwieriger als erwartet. Mal abgesehen vom "Betriebssystem", zu dem ich mir noch überhaupt keine Gedanken gemacht habe, ist die Umsetzung der Hardware schon eine kleine Herausforderung.

Es handelt sich ja bei den beteiligten Bausteinen um Teile aus unterschiedlichen Epochen der Elektronik. Zum einen haben wir ja den MC6847 aus den frühen 80ern, zum Anderen den modernen Atmega162. Die beiden zusammen zu bringen ist nicht ganz einfach.

Eine Herausforderung sind zum Beispiel die elektrischen Eigenschaften. Der MC6847 ist in für die 80er typischer TTL-Logik aufgebaut. Zu der Zeit war der High-Pegel irgendwo bei größer 2 Volt, während der Low-Pegel unter 0,8 Volt lag (http://de.wikipedia.org/wiki/Transistor-...stor-Logik). Typisch wäre >2,4 Volt für High, kleiner als 0,4 Volt für Low.

Die heutigen CMOS-Bausteine (und der Atmega ist ein CMOS-Baustein) haben da andere Spannungen: Bei ca 1 Volt haben wir schon einen High-Pegel. Und auch das ist nicht sicher, denn die Pegel hängen von der Betriebsspannung ab. Ein Atmega162 funktioniert bereits ab 1,8 Volt, wenn die Oszillator-Frequenz entsprechend niedrig ist.

Also gut, hier gibt es ein paar kleine Hürden. Die Betriebsspannung meiner Schaltung beträgt 5 Volt. Schon deshalb, weil ein TTL-Baustein nur 5 Volt verträgt. Ein CMOS-Baustein verträgt auch schonmal 15 Volt. Ein AVR allerdings nicht, da ist bei 5,5 Volt schluß. Er verzeiht einem aber geringfügig zu hohe Spannungen.

Eine weitere Herausforderung in der Schaltung ist das Timing. Der MC6847 muss mit 3.579545 MHz betrieben werden. Diese Frequenz ist die Color Burst Frequenz. Sie ist exakt auf einen klassischen Fernseher ausgelegt (ich glaube NTSC). Ein AVR arbeitet typischerweise mit einer höheren Frequenz. Und die ist in diesem Fall auch erforderlich, da der MC6847 ständig auf den Speicher zugreift um ein Bild aufzubauen. Der AVR darf, um eine störungsfreie Bildschirmwiedergabe zu gewährleisten, nur in der Austastlücke (das sind 24 Zeilen am Fernseher, die NICHT sichtbar sind) auf den Speicher zugreifen. Diese Austastlücke ist 2,4 ms groß. Das reicht bei einer Betriebsfrequenz des AVR von 6 MHz für 14.400 Prozessortakte. Je schneller der AVR ist, desto mehr Zeit bleibt für den Speichezugriff.

Ein weiteres Thema ist, dass die beiden Bausteine sich beim Zugriff auf den Adressbus nicht in die Quere kommen dürfen. Es darf also immer nur EINER von beiden auf den Speicher zugreifen. Sonst gibts Chaos auf dem Adressbus und Müll in der Bildschirmausgabe. Hier ist die grösste Herausforderung. Das Timing ist das A und O bei dieser Schaltung.

Das Timing wird mit einer Interruptsteuerung erreicht, welcher jeweils auf den "Willen" vom MC6847 reagiert. Ich habe die Schaltung auf dem Steckbrett aufgebaut und kämpfe derzeit mit dem Timing sowie krassen Bildstörungen. Außerdem funktioniert der Speicherzugriff noch nicht sauber.

Dennoch wollte ich Euch mal über den aktuellen Stand informieren. Vielleicht ist dieses doch etwas komplexere Projekt ja auch mal interessant für Euch :-)

Den aktuellen Schaltplan habe ich wieder beigefügt (Nicht vollständig und nicht voll funktionsfähig!!!)

Beste Grüße

Uni


   
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#7
31.01.2015, 20:32

Hier mal noch ein schneller Status zum Projekt:

Die im vorigen Beitrag vorgestellte Version hat nicht funktioniert. Es gab immer wieder Probleme mit dem Timing zwischen AtMega, Speicher und MC6847. Ich war nicht in der Lage, das korrekte Timing zu programmieren. Ich habe mir aufgrund dessen sogar einen Logic Analyzer zugelegt um die Signale auswerten zu können. Habs trotzdem (erstmal) nicht hinbekommen.

In meiner aktuellen Version gibt es nun erstmal nur einen Speicherbaustein. Dieser hat auch nur noch 8KB. Ein Bild bekomme ich auf den Monitor (einfacher gefüllter Bildschirm, ist aber auch keine Kunst denn das macht der MC6847 ja selbst).
Das Programm für den AtMega muss ich noch schreiben. Mal sehen, wann ich Lust habe, es zu starten :-)

Grüße
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#8
08.02.2015, 13:12

Aktueller Status:

Ich habe das Breadboard erstmal abgeräumt. So wie es aufgebaut war, hat es nicht funktioniert. Außerdem habe ich im Assembler die Timer meines Atmega162 nicht im Griff. Da muss ich erstmal ein wenig Zeit investieren um das alles zu verstehen.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#9
16.02.2015, 18:38

Kaum ist ne Woche rum, gibt's auch schon einen neuen Status :-)

Ich habe das Schaltungsdesign ein wenig abgeändert und den Speicher erstmal auf einen Baustein reduziert. Das macht sich mit Sicherheit auf meinem Breadboard positiv bemerkbar!
Jetzt kommt als Nächstes der Aufbau auf dem Board. Außerdem muss ich die Verstärkerschaltung für Videosignal verbessern. In meinen Versuchsschaltungen zuvor war das Bild eher grottig.

Ich werde das "Videomodul" jetzt mit einem MC1372 und entsprechender Beschaltung aufbauen. Damit sollte ein klares und sogar farbiges Bild möglich sein.

Weitere Berichte folgen.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 735
Registriert seit: Apr 2014
Bewertung: 5
#10
18.02.2015, 13:15

Ein neuer Versuch startet:

[Bild: 977c8e90b27848d542da72c0891fcba8.jpg]

Berichte über den aktuellen Stand sowie der schaltplan folgen.



<{ gesendet mit tapatalk }>
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste