Hallo liebe Forumsleute,

ich bin gerade dabei mich ein bischen tiefer in die DMD-Thematik einzuarbeiten. Davon was auf der Strecke DMD-Controller <-> DMD-Treiber (14pol Flachbandkabel) passiert habe ich schon eine gute Vorstellung, aber über die Kommunikationsstrecke CPU <-> DMD-Controller (26pol Flachbandkabel) weiß ich noch nichts.

Die Hardware ist dabei ja relativ einfach gehalten.

-> DATA[8]
-> !STROBE
-> RESET
<- OUT[8]
<- BUSY

RESET ist asynchron und bedient dirket den Reset-Controller.

Normale Kommunikation wird von der CPU angestoßen, so denke ich mir das (bitte korrigieren wenn ich falsch liege):
1. CPU legt Daten an DATA an
2. CPU gibt eine Flanke auf !STROBE
3. Strobe geht direkt in den CLK Eingang von einem D-FF, dessen Dateneingang konstant HIGH ist. Q geht also nach !STROBE auf HIGH und ist mit BUSY verbunden
4. Das heißt: BUSY wird direkt nach dem !STROBE HIGH
5. Die Controller-MCU hat jetzt Zeit, das Kommando zu verarbeiten
6. Wenn sie fertig ist, legt sie die Antwort auf OUT
7. Danach löst sie CLR auf dem D-FF aus, BUSY geht wieder auf LOW

Spannend ist jetzt: Was ist das Protokoll, das da gesprochen wird? Muss ja irgendwas in der Form sein "Lade Sprite auf ROM W, Adresse X, male auf Pixeladresse Y,Z" oder "Lösche Display" oder sowas. Ist das irgendwo dokumentiert? Mein Logikanalysator hat leiderleider zu wenig Kanäle, sonst würd ich es einfach mitsniffen.

Falls mir irgendjemand auf die Sprünge helfen kann, was die Kommunikation anbetrifft wäre ich super dankbar. Ist ja bestimmt irgendwo beschrieben.

Vielen Dank schonmal im Voraus und schönen Abend noch,
~HH

Hmmm schade, ich hätte gedacht dass es zumindest von Data East ein firmenspezifisches Dokument gibt, das ich vielleicht nur nicht gefunden habe. Dann ist Reverse Engineering gefragt

Ich schenke mir zu Weihnachten einen neuen (sigrok-kompatiblen) Logikanalysator, dann werd ich auf jeden Fall mal den Bus belauschen und kann den Dump ja auch hier reinstellen.

Aber zumindest bei Data East kann man doch jeden DMD Controller (mit den richtigen EPROMs natürlich) in jedes Gerät einbauen, oder?

Der Tipp mit PinMame ist super gut, ich werd mal reinschauen was die gemacht haben und wie die das interpretieren. Die emulieren ja direkt den 68k Code. Das heißt, da gibts dann auch irgendwo (in Software) den Bus, der mich interessiert und an der Gegenstelle lauscht der Interpreter, um Pixel zu malen. Falls ich was rausfinde, werde ich das hier posten!