Junior Computer ][

Hallo Norbert,

danke nochmal für den Code. Du hattest ihn mir schon mal per PM zukommen lassen, aber für die andern ist der ja sicher auch interessant.

Bezüglich Uhren Bausteinchen bleibe ich mal bei der on board Lösung. Man benötigt ja nicht viele Bauteile. Ausserdem muss ich ja auch irgendwas auf die Platine drauf machen, sonst könnten wir ja gleich eine leere Lochrasterplatine unter den Junior schrauben .

Allerdings bin ich tatsächlich am schwanken, ob ich nicht auf einen RTC Baustein mit SPI - wie z.B. den DS1306 - zurückgreife. Dann muss ich nicht zwei verschiedene Seriell Protokolle unterstützen. Das kostet ja zum einen kostbaren Speicher für den Code und zum anderen spare ich natürlich ein paar Port-Leitungen, die ich dann wieder für was anderes (sinnloses) verballern kann.

Jedenfalls konnte ich schon mal auf den 74LS03 (NAND O.K) verzichten, den ich nur wegen der open Kollektor Verbindung zu /RAM_SEL drin hatte. Die Kombi NOR (U9B) und NAND O.K (U14A) - beide als Inverter geschaltet - ist jetzt draussen. Die hab ich einfach durch eine Diode ersetzt - Kathode am Ausgang des 2 zu 4 Decoders. Bei LOW zieht der dann auch /RAM_SEL auf LOW, bei HIGH hab ich dann auch einen offenen Ausgang.

Den Sound Chip binde ich über einen weiteren 74LS373 8fach Latch an, dann muss nicht noch ein VIA Port dran glauben.

Apropos VIA Port. Ich werde wohl Port C sowohl per Pin-Connector als auch via DB9 raus führen, dann kann man den Port auch als Joystick-Anschluss nutzen, falls wir dann doch mal irgendeine Grafikkarte basteln und das ganze für Spiele nutzbar wäre.

Zitat von NorbertJ

An anderem Ort in unserem Forum ist ein Verweis auf die Entwicklung eines funktionierenden Apple ][ mit unter anderem 6502 CPU und zwei Propeller-Chips. In angehängtem pdf ist auf Seite 3 das Schaltbild des mit einem Propeller verwirklichten Grafikteils des Apple. Ich finde diesen Ansatz sehr interessant und werde ihn bei Gelegenheit checken. Die notwendigen Dateien kann man ebenfalls downloaden.

Ich schau mir das mit dem Propeller Controller als Grafik Chip auf alle Fälle an. Platz genug wäre schon da und eine kostengünstige Grafiklösung würde mich schon echt reizen. Wenn die Grafikbibliothek im Microcontroller was taugt und ich auch keinen extra Speicher mehr anbinden muss, spart das viel Zeit und Geld. Der Propeller ist auch in einem passenden DIL Gehäuse, so dass das nicht zu neumodisch aussieht.

Heute kommt auf alle Fälle erst mal der Sound Chip dran. Der ist leider nicht in der KiCAD Bib drin, deshalb muss ich den erst noch zeichnen.

Beim DS1306 sieht es leider etwas schlechter aus. Der ist nicht bei Reichelt und Co zu bekommen. Bei anderen Quellen (eBay, etc.) kostet der Chip locker das dreifache des DS1302. Daher bleibe ich wohl bei letzteren. Ich kann da ja SCL und I/O auch mit den SPI Leitungen SCK und MOSI teilen und so zwei Port Pins sparen. Dann kann ich z.B. noch eine I2C Schnittstelle bereitstellen, die man ja immer für nette Erweiterungen (Port Expander, AD Wandler, etc.) brauchen kann.

Autsch, was für ein gruseliger Schaltplan!!! Da rollen sich mir ja die Zehennägel hoch.

Die Schaltung mit dem Propeller P8X32A scheint aber nur eine 8 Farben Grafik zu ermöglichen. Ich werde mal schauen, ob es da nicht Lösungen mit 64 Farben gibt.

Edit: Ach ja, da war ja noch das mit der RC2014 Grafikkarte. Das hattest du mir ja auch schon gesagt NorbertJ . Sorry!

Zitat von NorbertJ

Ich will ja auch nicht auf dem Propeller herumreiten, war nur eine Möglichkeit. Wenn es eine einfachere und auch später eventuell spielekompatible Lösung gibt, wäre mir das auch sehr recht.

Das hab ich keinesfalls so gesehen. Ich finde da jede Lösung spannend und hilfreich. Und der Parallax Controller ist sicherlich dafür sehr gut geeignet. Ich hab mich mit dem Propeller aber nur mal ganz kurz beschäftigt, als der damals raus kam. Ist schon ewig her (90er ? Artikel in der Elektor). Deshalb bin ich da ein echter Newbe. Ich war da eher jemand der mit Atmel oder PIC Controller gebastelt hat.

Falls du eventuell Zeit und Lust hast, ein wenig zu recherchieren, was die einzelnen Lösungen mit Propeller so können, wie man sie in bestehende Schaltungen integriert und vor allem, wie man sie dann programmiert - sprich wie bringe ich vom 6502 da was auf den Bildschirm - wäre das super. Gerade bei der RC2014 Lösung scheint mir potential da zu sein. Wenn es bei dir zeitlich nicht passt, ist das aber kein Problem.

Der Schaltplan des Apple II Nachbaus hatte mich vorher leider etwas aus der Fassung gebracht, weil der so unglaublich unübersichtlich und durcheinander ist. Texte über den Leitungsverbindungen, überlappende Widerstände, Leitungen die vom Datenbus überdeckt werden, Busleitungen die im Zickzack verlaufen... Da war mein Vertrauen in die Fähigkeiten der Grafik Unit schon leicht lädiert.

Die Auflösung und die Farbtiefe finde ich gar nicht so schlimm. Die 6502 muss das ja auch noch handeln können und es soll ja auch retro bleiben. Einen Versuch ist es auf alle Fälle wert. Bei den "echten" Grafik Chips ist halt der Hardware- und Programmieraufwand wesentlich höher. Das ich bei der uC Lösungen auch keinen Grafikspeicher mehr brauche, finde ich ebenfalls sehr attraktiv. Wenn man darauf mal irgendwann Loderunner oder Pacman spielen kann bin ich schon glücklich .

Zitat von NorbertJ

Frage: entspricht der WAIT Input beim Z80 dem RDY Input beim 6502? Dieses Signal wird in der RC2014-Grafikkarte verwendet.

Solange Wait =High ist stoppt die CPU und wartet z.B. auf langsamere Devices. Bei Low geht's weiter.

Das WAIT Signal der Grafikkarte wird, soweit ich das verstanden habe, nur genutzt um eine Synchronisation zwischen Z80 und dem Monitor zu bekommen (Stichwort flickerfreie Darstellung). Ist also jetzt nicht absolut notwendig. Ansonsten sollte WAIT dem RDY der 6502 entsprechen.

Ich hab jetzt heute Nacht mal wie das kommunale Tiefbauamt vor den Ferien, drei Baustellen auf einmal eröffnet.

1 - Grafik:

Mit dem Propeller kann ich zwar Tiles (x * y Pixelblöcke) schnell Darstellen, aber bei einzelnen Pixeln benötige ich dann doch recht viele Befehle, da ich immer ein Kommando und die Pixel-Daten schicken muss. Das scheint mir dann doch recht langsam. Der Raw Bitmap Write Befehl macht das ganze zwar etwas besser, aber Grafikbefehle wi Linien oder Kreise muss ich zu Fuß programmieren. Ausserdem beherrscht die Propeller Lösung zwar anscheinend Sprites, ich hab aber nichts über Collision Detection der Sprites gefunden. Irgendwie scheint die Sache noch nicht ganz das Gelbe vom Ei zu sein. Vielleicht also doch eine andere Lösung.

2 - Kassetten I/O:

Welches Aufzeichnungsverfahren sollte ich nehmen? Das des Original Juniors? C64 oder Apple II? Was ist ausreichend schnell und wie aufwändig ist die Programmierung? Wie sollte ich die Aufbereitung der von der Datasette kommenden Signale machen? Kommen von der Datasette bereits verstärkte und wieder digitalisierte Signale, oder sind die noch analog, wie bei einem Standardkassettenlaufwerk? Soll ich überhaupt einen Kassettenport bereitstellen? Eigentlich finde ich es ja ganz charmant und retro, aber würde den den jemand nutzen, wenn eine SD-Karte on Board ist?

3 - SD-Karte via SPI:

Hier hab ich mir die konkretesten Gedanken gemacht. Zum einen habe ich mich das erste mal wirklich mit dem Datenblatt und den Möglichkeiten der 6522 VIA auseinander gesetzt, und zum andern, wie ich das SPI Protokoll am effizientesten umsetze.

Dabei bin ich auf drei mögliche Lösungen gekommen, die ich im Anhang noch als (hoffentlich für euch lesbare) Aufzeichnungen beigelegt habe:

Möglichkeit 1: Ich erzeuge den SPI Takt von Hand durch Setzen und anschließenden Löschen eines Port Bits. Die Daten werden via SPI gleichzeitig gelesen und geschrieben. D.h. an MOSI sende ich ein Bit und an MISO empfange ich eines pro Takt. Schreiben und Lesen der einzelnen Bits mache ich wie beim Takt durch schreiben bzw. lesen eines Port Bits nach jedem vollen Taktzyklus. Das (nicht ganz richtige - das letzte Input Bit wird hier noch nicht gelesen) Programm ist im PDF skizziert. Ich bräuchte für diese Methode ca. 23 Taktzyklen, was bei 1MHz dann eine maximale Übertragungsrate von 5,3 KByte/s wäre.

Möglichkeit 2: Die VIA wird im Modus 3 Betrieben - Shift In Under CB1 Control. Hier kann ich über einen externen Takt am Anschluss CB1 Daten automatisch per Anschluss CB2 in das interne Schieberegister (SR) laden. Durch Verbinden des Port Pins PB1 - an welchem mein manuell per Programm erzeugter Takt ausgegeben wird - mit CB1 kann ich dann den im Programm mit * gekennzeichneten ROR Befehl weglassen, da meine MISO Daten dann ja automatisch in SR geladen werden. Ich muss dann nur noch nach acht Taktzyklen das SR auslesen. Durch den fehlenden ROR Befehl steigt meine Übertragungsrate auf ca. 6,1 KByte/s.

Möglichkeit 3: Hier muss ich leider eine gesamte VIA für das SPI opfern und ich brauche etwas Zusatzelektronik. Aber es lohnt sich. Für diese Methode würde ich Modus 6 der VIA wählen - Shift Out Under Phi2 Control. Hierbei wird CB1 zum Taktausgang (CLK), der das Phi2 Signal 1:1 weiterreicht und CB2 (MOSI) schiebt im Takt den Inhalt von SR an die SD-Karte raus. An CB1 schließe ich den Clock Eingang eines 74LS164 Schieberegisters (Seriell In - Parallel Out) an. Der Eingang des 74LS164 ist dann MISO. Nach 8 Takten wird automatisch von der VIA ein Interrupt erzeugt, so dass ich die empfangenen Eingangsdaten aus dem LS164 per Port A einlesen und die neuen Ausgangsdaten in das interne SR schreiben kann. Das ganze läuft dann eigentlich wie ein kleiner DMA Controller, halt nur mit einem Byte . Der Clou ist, dass ich mit voller 1MHz Taktrate lesen und schreiben kann, was dann zu 1MHz/8 gleich 125 KByte/s Übertragungsrate führen würde. Abzüglich der Zeit die zwischen drin zum Lesen und Schreiben der vollständigen Ein-/Ausgabe Bytes nötig wäre, kann man vermutlich von etwa 120KB/s ausgehen, was dann für so eine SD-Karte zumindest erträglich wäre.

So weit mal mein Gedankenmüll von heute Nacht. Ihr könnt es euch ja mal ansehen und mir Bescheid geben, was ihr davon haltet, bzw. wie ihr entscheiden würdet. Ich muss jetzt erst mal wieder an die Arbeit, sonst kann ich mir das Hobby irgendwann nicht mehr leisten

Zitat von klaly

... weil ich eben VIA - SPI gesehen habe,
da könnte man dann auch gleich einen SD-Karten Slot, bzw. Anschluss mit vorsehen, bzw. damit realisieren.
halt sowas hier :

weil sonst brauhst wieder extra 3.3V Level Shifter.

Na na na klaly , da hat wohl jemand den Thread nicht mehr ganz aufmerksam verfolgt?

Die SPI Schnittstelle soll tatsächlich ausschließlich für eine SD-Karte mit drauf und da hatte ich bei AZ-Delivery was komplettes mit Micro-SD Slot, Pegelwandler und 3,3V Regler für 1,20€ das Stück rausgesucht. Da ist selbst löten keine Option mehr.

Zitat von NorbertJ

Generelle Frage: wie stark wird die CPU eigentlich insgesamt belastet? Ich komme darauf, weil ein Freund mich vorgestern fragte: das alles soll der 6502 performant 'händeln' können? Ich kann aus eigener Erfahrung sagen, dass die KIM-1 SD-Karten-Option von corshamtech relativ performant ist, aber dort nimmt ja ein Arduino Mega dem 6502 alles ab...

Ich würde sagen, dass das eigentlich keine Frage der Auslastung ist. Die CPU macht halt so schnell wie sie kann. Da sie keinen Idle Mode kennt, muss sie ja sowieso bei jedem Takt einen Befehl ausführen und wenn es NOPs sind. Bei SPI Option 1 und 2 muss ich natürlich alles selber machen, und deshalb ist dann die Übertragung halt langsam. Bei Option 3 könnte ich ja sogar Multithreading machen, da hier die Elektronik das meiste macht und sich per IRQ dann meldet wenn sie fertig ist. In der Interrupt Routine kann ich dann schnell per Pointer einen Lese- und Schreibbuffer nutzen.

Ich hab mich vorhin wieder daran erinnert, dass die Jungs vom "Steckschwein" Projekt ja auch eine SD-Karte als Massenspeicher benutzt haben. Deshalb hab ich mir gerade deren Seite angeschaut. Und siehe da, sie machen das wie Option 2, also im VIA Mode 3 - Shift In Under CB1 Control. Da deren 65C02 aber deutlich höher getaktet war (4MHz ?) kommen die dann natürlich auf etwas bessere Übertragungsleistungen. Schnell ist das natürlich immer noch nicht. Die von mir ausgetüfftelte Version mit externem Shift Register und Taktung per Phi2 ist sicherlich das Maximum, das so erreichbar wäre. Das wäre meines Wissens jedenfalls schneller als eine Commodore 1541 Floppy.

Zitat von NorbertJ

Zu 1: Ok, vergessen wir den Propeller, vielleicht sind andere Chips nur genau für diesen Zweck besser geeignet.

Vielleicht nicht ganz vergessen, aber erst mal zurückstellen.

Zitat von NorbertJ

Zu 2: Kassetten Port wäre schön, ist aber nicht unbedingt nötig. Wir weichen ja mit SD-Karte usw. eh schon vom Original ab.

Ich glaub ich mach ihn drauf, wenn jetzt nicht alle anderen widersprechen. Bin da irgendwie altmodisch. Kassette hat so was gemütliches

Ich hab gerade gesehen, dass beim VIA Mode 6 CB1 nur den halben Phi2 Takt ausgibt. Also kommt man auf ca. 60KB/s. Ist aber immer noch ordentlich.

Zitat von klaly

Ja, sorry, so ist es wirklich.
Der Thread war mir "zu viel".

Kein Problem Klaus. Ich bin selber immer wieder erstaunt, wie viel ich hier reinschreibe. Muss das wohl etwas reduzieren, um euch da nicht zu nerven.

Zitat von NorbertJ

VideoDa schlage ich gleich mal den EF9366 Grafikprozessor vor, der in der Commodere HSG (high speed graphic) verwendet wurde.

Kennt einer den? Sind wohl rar

Hallo Norbert, den EF9366 oder EF9365 hatte ich schon vor einiger Zeit im Auge, weil die richtig gut sind und auch höhere Auflösungen können. Ich hab auch noch einen, aber die sind wirklich selten zu bekommen und dann natürlich $ch€i3 teuer.

Zitat von ThoralfAsmussen

Außerdem sollte man evtl. mal was priorisieren. D.h. nicht alle drei Wunschsachen auf einmal bauen wollen. Momentan sind ja sogar eher mehr im "Gespräch", als da wären: RealTimeClock, SD-Card Interface, Grafikkarte, Soundmodul, Kassetten-Interface.

Hallo Sebastian, den RTC hab ich ja schon drauf, der war auch immer mein Wunsch. Sound ist auch gesetzt und das SPI (Serial Peripheral Interface) für SD-Karten mache ich auch, weil kein Aufwand in der Hardware. Beim Kassetteninterface hatte ich für die Platine ja bereits den Platinenanschluss ala C64 in KiCAD designt. Um die Analogelektronik wollte ich mich aber zum Schluss kümmern, weil ich halt ein alter Digielektroniker bin.

Prinzipiell kann man für den Nachbau alles weglassen, was man nicht möchte, und kann so Bauteile sparen. Ich werde das dann zu gegebener Zeit auch in der Aufbauanleitung so kommunizieren.

Die Grafikausgabe war ja ursprünglich tatsächlich nicht für dieses Erweiterungs Board geplant. Aber da noch freier Platz vorhanden war, kann man natürlich drüber nachdenken. Beim Weglassen hab ich da aber absolut kein Problem, da ja sowieso (in ferner Zukunft) noch ein Floppy-Controller geplant ist, der dann die Grafik mit drauf haben könnte. Im Übrigen kann man bzgl. Grafikkarte natürlich immer noch am ESP32 und der FabGL Bibliothek festhalten, die ich für das ESP32 Terminal genommen habe. Die kann nämlich alles geforderte: Hohe Auflösung, hohe Farbtiefe, eigener Grafikspeicher, Linien, Rechtecke, Ovale, Sprites mit Collision Detection und und und. Einziges Manko, das ESP Modul sieht halt irgendwie wie ein Fremdkörper unter all den alten DIP Bausteinchen aus. Video

VORSCHLAG: Wir lassen die Grafikerst mal weg und über das auf der Platine befindliche Lochrasterfeld kann man dann schon mal diesbezüglich experimentieren. Bei einer Rev.2 Platine kommt dann die Grafik mit drauf.

Zitat von NorbertJ

Mich nervt das nicht. Nee, im Ernst nicht.

Zitat von ThoralfAsmussen

Ich finds auch gut.

Danke!