Die Fa. VideoPak verkaufte 1982 für ihre G7000 Spielkonsole (MP 8048) das Chess-Modul C7010. Das Chess-Modul hatte eine Z80 CPU (NSC800) und kommunizierte mit dem MP 8048 mit I/O Latch-Bausteinen über den Modulschacht. Wie geht das?
Gast
#4581188
Der Z80 wurde meist über die Z80-PIO an die Peripherie angebunden. Das ist ein ebenfalls 40-pol. programmierbarer IO-Latch-Baustein von Zilog. Beschreibungen dazu gibt's im Netz haufenweise.
VideoPak ist die bezeichnung für die Modulle. Die g7000 is ein Philips gerät. https://de.wikipedia.org/wiki/Philips_G7000 Hier dann noch die das ServiceManual vom Schachmodul. http://www.videopac.org/games/chess/7010servicemanual.pdf
Zwischen dem MC8048 und dem Z80 Clone gibt es nur den Datenbus mit dem Input-Latch 74LS374 und dem Output-Latch 82PC12. Der Z80 Clone soll den MC8048 unterstützen, aber wie?
Michael B. schrieb: > unterstützen, aber wie? So, wie im richtigen Leben auch. Der 8048 ist der dümmere und langsamere der beiden, ist aber dennoch der Chef. Und er gibt seinem Mitarbeiter Aufgaben. Für den Z80 gab es einige recht gute Schachprogramme (Sargon als Beispiel), die einen Amateurspieler schon echt zum Schwitzen bringen konnten. Der 8048 übermittelt das Spielfeld und holt sich den nächsten Zug ab.
Marc D. schrieb: > Hier dann noch das ServiceManual vom Schachmodul. Danke für den Link. Georg G. schrieb: > Der 8048 übermittelt das Spielfeld und holt sich den nächsten Zug ab. Danke für die Info. Der Modul EPROM wird demnach gebraucht. Wie könnte die Kommunikation in Assembler aussehen?
Gast
#4581253
> Der 8048 übermittelt das Spielfeld und holt sich den nächsten Zug ab.
War in der Spielkonsole damals wirklich ein MCS48 als Hauptprozessor
drin? Angesichts der geballten Rechenleistung kann ich das kaum glauben.
Olaf
Olaf schrieb: > War in der Spielkonsole damals wirklich ein MCS48 als Hauptprozessor > drin? https://de.wikipedia.org/wiki/Philips_G7000
Olaf schrieb: > Angesichts der geballten Rechenleistung kann ich das kaum glauben. Die Leistungsfähigkeit dieser Steinzeit CPUs wird gern unterschätzt. Man staunt immer wieder, wie kompakt und effizient damals Assembler Programme waren. Michael B. schrieb: > Wie könnte die Kommunikation in Assembler aussehen? Was hast du vor? Warum nimmst du dir nicht die Daten aus dem Eprom und analysierst sie? Es sind nur 8kB auf der Z80 Seite und vermutlich 2kB auf der MCS48 Seite. Wenn es dir nur um dir Kommunikation geht, ist das eine Fingerübung für ein Wochenende.
Georg G. schrieb: > Warum nimmst du dir nicht die Daten aus dem Eprom und > analysierst sie? Werde mir für diese Untersuchung das Chess- und das BASIC-Modul besorgen müssen. Mich interessiert, ob im Zeitalter von UART und USB, diese Form des Datenaustausches noch Sinn hat?
Michael B. schrieb: > Georg G. schrieb: >> Warum nimmst du dir nicht die Daten aus dem Eprom und >> analysierst sie? > > Werde mir für diese Untersuchung das Chess- und das BASIC-Modul > besorgen müssen. > > Mich interessiert, ob im Zeitalter von UART und USB, diese Form > des Datenaustausches noch Sinn hat? Für mich ergibt diese Fragestellung keinen Sinn. Wenn es darum geht, zwei Steinzeit-CPU zu koppeln, die weder einen eingebauten UART noch USB haben, dann ist die direkte Kopplung der Busse [1] selbstverständlich eine sinnvolle Option. Wenn man gar nur einen Modulschacht hat und mit den darin vorhandenen Signalen auskommen muß, dann hat man doch sowieso keine Wahl? Wenn man zwei aktuelle µC miteinander kommunizieren lassen will, dann sind UART, SPI, I²C o.ä. wahrscheinlich die bessere Wahl, weil sie schlicht weniger externen Aufwand erfordern. Natürlich unter der Annahme, daß die genannten Schnittstellen auf beiden Seiten integriert sind. [1] ich interpretiere das schwammige "Z80 CPU ... kommunizierte mit dem MP 8048 mit I/O Latch-Bausteinen" mal in diesem Sinn
> wie kompakt und effizient damals Assembler Programme waren. Sind sie heute auch noch wenn man es richtig macht. Siehe die ganzen AVR-Demos, die irgendwelche Freaks geschrieben haben und aus dem Ding z.B. einen Videoprozessor machen.
Axel S. schrieb: > Für mich ergibt diese Fragestellung keinen Sinn. Danke, bin zufrieden, daß meine "sinnlose" Frage, wie erhofft, beantwortet wurde. Mein Glück ist vollkommen, wenn jemand einen Link zum Manual des BASIC-Moduls hätte.
Hier sind erste Infos zum C7420 Home Computer Modul. http://www.cyberroach.com/vidpac/vidhard/new_vid_c7420.htm
Service Manual für die G700 selber http://www.videopac.org/G7000/g7000servicemanual.pdf für das C7420 Home Computer Modul gibt es dann http://videopac.nl/forum/index.php?topic=2440.0 Anleitungen und Schaltpläne....
Marc D. schrieb: > für das C7420 Home Computer Modul > gibt es dann > http://videopac.nl/forum/index.php?topic=2440.0 > Anleitungen und Schaltpläne.... Hinter der URL verbirgt sich ja eine tolle Fundgrube, fehlt bloß noch das original Intel Datenblatt vom G7000er graphics display device Intel 8245.
Michael B. schrieb: > Intel Datenblatt vom [...] 8245. Das ist seltsamerweise nirgends zu finden. Ich habe Intel Datenbücher seit 1981. Kein Hinweis auf das Teil.
8244/8245 sind offensichtlich Custom-Designs. Vielleicht hilft das (nicht ganz vollständig): http://console5.com/techwiki/images/f/fa/8245.pdf Hier noch eine kurze Beschreibung unter Punkt 3: http://www.hardwaresecrets.com/inside-the-magnavox-odyssey2/
Eberhard H. schrieb: > Vielleicht hilft das (nicht ganz vollständig): > http://console5.com/techwiki/images/f/fa/8245.pdf Verbindlichen Dank für die Links, deren Inhalte ich schon gesehen habe. Die PDF Datei vom 8245 sieht nach einer partiellen Kopie vom original Intel Datasheet aus. Es fehlen leider die Applikationen.
Eberhard H. schrieb: > 8244/8245 sind offensichtlich Custom-Designs. Auf Intel-Vintage sind sie als Bausteine des MCS85 aufgeführt, leider ohne Datenblatt. Das spricht eher für "normale" Bausteine, die mangels Erfolg schnell wieder eingestellt wurden. Aber egal. Dein Link gibt viel Information. Ein neues Gerät wird niemand damit bauen wollen :-)
Es sind erstaunlich viele guten Informationen zusammen gekommen. Leider keine Software, die die Kopplung der beiden Prozessoren beleuchten würde.
Na, der eine Prozessor legt in dem I/O-Latch ein Byte ab und der andere liest es irgendwann aus. Der Prozessor kann lesend auf das eine und schreibend auf das andere I/O-Latch zugreifen. Bei dem anderen Prozessor ist es umgekehrt. Die I/O-Latches erscheinen in beiden Bussystem auf einer festgelegten Adresse. Das ist wie ein Briefkasten, in dem nur ein Brief (Byte) Platz hat. Schiebst Du einen neuen Brief hinein fällt der vorherige heraus, wenn er nicht schon heraus genommen wurde. D.h. irgendwie werden die Prozessoren darüber auch eine Art Handshake machen oder die Timings sind garantiert. Selbst wenn man mit einer seriellen Schnittstelle zwei Controller verbindet, ist das Prinzip das selbe: µC A legt ein Bit in seinen Ausgang. µC B liest es. Liest er es nicht rechtzeitig, ist es futsch. Bei der seriellen Schnittstelle kümmert sich Hardware darum, dass dies passiert. In Deinem System muss sich die SW in beiden Prozessoren darum kümmern, dass dies geordnet abläuft und was zu tun ist, wenn ein Fehler aufgetreten ist. Das nennt man in der Hard- als auch in der Software 'Protokoll'. Mehr kann man dazu eigentlich nicht sagen, da es wirklich absolut simpel ist. Wenn man ein einfaches Prozessorsystem aus 'diskreten' Komponenten begriffen hat, sollte dies keine Hürde mehr darstellen. Michael B. schrieb: > Leider keine Software, die die Kopplung der beiden Prozessoren > beleuchten würde. Na, der Z80 wird mit einem OUT (x),A Daten in dem einen Latch ablegen und mit IN A,(x) aus dem anderen Latch einlesen. Und der 8048 wird es ähnlich tun. Brauchst eine Beschreibung, wie man einen Brief austauscht? Gruß Jobst
Jobst M. schrieb: > Mehr kann man dazu eigentlich nicht sagen, da es wirklich absolut simpel > ist. Danke für diesen kurzen verständlichen Abriss. Ich frage mich nur, ob der Lösungsweg überhaupt diskutiert wurde?
Michael B. schrieb: > Ich frage mich nur, > ob der Lösungsweg überhaupt diskutiert wurde? ??¿? Du bist ein merkwürdiger Knabe! Wer soll darüber Diskutieren? Hier? Warum? Außer Dir ist hier allen klar, wie das Abläuft. Der Ablauf ist klar wie Kloßbrühe ... Es ist eine (2) Speicherzelle, welche im Speicherbereich beider Systeme auftaucht. Da die Adressleitungen der Z80-CPU für die Latches nicht ausgewertet werden, sondern nur die I/O-Leitung direkt mit Read und Write verknüpft werden, sind die beiden Chips über den gesamten IO-Adressraum adressierbar. Schreibend ist der 82PC12 aktiviert, lesend wird, ebenfalls auf allen Adressen, der Ausgang des 74LS374 auf den Datenbus des Z80 gelegt. Am 8048 sind die Latches am RAM-Speicher-Interface angeschlossen. Daher wird auch A7 zur Dekodierung benutzt. Es sind ja nur 128Byte RAM vorhanden. Mit P10 und P14 kann ich nicht viel anfangen, aber die werden auch noch zur Dekodierung herangezogen. Ansonsten würde ich behaupten, dass der 74LS374 im Bereich 0x80-0xFF im RAM-Bereich vom 8048 beschrieben werden kann. Der RAM endet ja auch bei 0x7F. Beim lesen aus dem 82PC12 wird noch A5 mit hinzugezogen und ist damit im Bereich 0xA0-0xBF und 0xE0-FF ansprechbar. (Ich nehme an, dass im Bereich 0x80-9F oder 0xC0-0xDF der Video-Chip nach Daten lauscht.) EDIT Neee, das ergibt keinen Sinn. Dort wird ja vor allem geschrieben ... Durch die Adressdekodierung der Konsole darfst Du Dich aber selber wühlen ... Gruß Jobst
Danke, diese technischen Details reichen mir erstmal. Die Frage nach einer Diskussion betraf die Entscheidungsträger der Firma Philips. Mein jetziges Interesse gilt der Substitution des Kassettenrecorders.
Michael B. schrieb: > Mein jetziges Interesse gilt der Substitution des Kassettenrecorders.
1 | |
Bei http://www.tote-pixel.de/pixel/372-schach-dem-g7000 ist zu lesen: "Der Intel 8048H mit seinen internen 5,91 MHz (extern 1,79) und den kümmerlichen 192 Byte (nicht KByte!) wäre von der Rechenleistung sicher in der Lage gewesen einen würdigen Schachgegner abzugeben, es fehlte aber an RAM. Eine RAM-Erweiterung in einem Modul wäre möglich gewesen, aber der Grund ist in der Harvard-Architektur des 8048 zu suchen. Dabei werden für Code (ROM) und Daten (RAM) verschiedene Datenbusse verwendet. Der Daten-Bereich kann dabei bei der 8048 maximal 256 Bytes umfassen. Man hätte also auch ein größeres RAM extern über ein Videopac anschließen können, aber nur noch vergleichsweise langsam darauf zugreifen können – was das ganze System extrem ausgebremst hätte." Meine Frage, hat man mit einem 80535 die gleichen Probleme?
Der Text ist so nicht ganz richtig. Beim MCS48 gibt es einen einheitlichen Daten und Adressbus für Code und Daten. Nur die Kontrollsignale (PSEN, RD WR) sind unterschiedlich. Man kann durchaus Code und RAM auf jeweils 64kBytes erweitern, muss dann aber besonders beim Code heftige Verrenkungen machen. Und weil es keinen 16Bit Datenpointer gibt, ist der RAM Zugriff auch umständlich. Das HSE49 Board zeigt, was alles möglich ist. Der 80535 basiert auf dem MCS51 und ist von Haus aus für 64k Code und 64k RAM gemacht.
Georg G. schrieb: > Das HSE49 Board > zeigt, was alles möglich ist. Das Manual des HSE49 Board wäre schon interessant. Georg G. schrieb: > Der 80535 basiert auf dem MCS51 und ist von Haus aus für 64k Code und > 64k RAM gemacht. Der 80535 könnte also Chess-Module mit 16 Adress-Pin wie eine Z80 CPU ansprechen?
Michael B. schrieb: > Der 80535 könnte also Chess-Module mit 16 Adress-Pin wie eine Z80 CPU > ansprechen? Dir ist schon klar, dass Z80 und 80535 verschiedene Sprachen sprechen?
Michael B. schrieb: > Das Manual des HSE49 Board wäre schon interessant. In solchen Fällen empfehle ich Dr. Gurgel oder eine Mail an Mustafa von Intel-Vintage. Aber lass dir gesagt sein, dass dir das Handbuch wenig Erleuchtung bringen wird. Die Schaltung ist schon so etwas wie der Schwarze Gürtel der Hardware. Hinzu kommt, dass Erweiterungen vorgesehen waren (sogar in der Monitor Firmware schon vorbereitet), aber nie realisiert wurden. Da fragt man sich dann ab und an "was hat der Entwickler sich da gedacht?".
Ich habe hier ein Board mit einem MC 80C535, EPROM 27C512 (64KB), Latch 74HCT573, RAM 81C52 (256 Byte) Mit diesem Board könnte ich doch die G7000er Konsole aufrüsten?
Du scheinst überhaupt nicht in die Dokumente zu schauen, die Dir zur Verfügung stehen ...
Ben B. schrieb: > Siehe die ganzen > AVR-Demos, die irgendwelche Freaks geschrieben haben und aus dem Ding > z.B. einen Videoprozessor machen. Das Thema ist zwar noch nicht dran, aber ein Link wäre nicht schlecht.
Michael B. schrieb: > Mit diesem Board könnte ich doch > die G7000er Konsole aufrüsten? Mit noch diversem Hühnerfutter dazu wird es funktionieren. Ich bezweifle aber, dass du in der Lage bist, Software für die Kombination zu schreiben. Und mit 256 Bytes RAM ist das Ding auch recht unterernährt, selbst, wenn man das XRAM im 535 noch mit einrechnet.
Georg G. schrieb: > Und mit 256 Bytes RAM ist das Ding auch recht unterernährt, > selbst, wenn man das XRAM im 535 noch mit einrechnet. Der EPROM ist gesockelt, da könnte ich doch auf einer Adapterplatine den EPROM nebst 64kB SRAM packen.
Gast
#4588013
>Der EPROM ist gesockelt, da könnte ich doch auf einer Adapterplatine den >EPROM nebst 64kB SRAM packen. Aha, und die WR-Leitung?
eprom schrieb: > Aha, und die WR-Leitung? Wird fliegend verdrahtet (Steckbrücke).
Michael B. schrieb: > EPROM nebst 64kB SRAM packen. Dir ist klar, dass bedingt durch die Architektur auch die Lesesignale für Eprom und RAM getrennt sind? Das gibt etwas mehr Fliegenfänger. Ausserdem kollidiert das RAM mit dem RAM im 81C52. Und es bleibt die Frage, wie du die Software erstellen willst.
Georg G. schrieb: > Und es bleibt die Frage, wie du die Software erstellen willst. Arbeite gerade ein Data Sheet vom SAB80515/SAB80535 durch http://www.b-kainka.de/Daten/Mikros/d80515.pdf Die Software wird mit dem einfachsten Assembler erstellt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.