Die Probleme könnten auch mit anderen Zorro-Karten auftreten. Kennzeichnend ist,
dass die Karten mit einer A3630 funktionieren, mit einer A3640 jedoch nicht.
Grund kann der Datenmultiplexer und die
MMU sein.
Zorro-Karten ohne AutoConfig werden durch das Aktivieren der MMU durch SetPatch
nicht mehr ansprechbar.
Ursache:
Der 68040 handhabt Byte- und Word-Buszugriffe anders als der 68030. Ein
Designfehler der Videomaster-Karte führt dann zum Fehler.
Der 040 verfügt im Gegensatz zum 030 über kein "Dynamic Bus Sizing", d.h. es werden immer 32-Bit-Zugriffe durchgeführt. Anschließend werden die entsprechenden Bits vom 32-Bit-Datenbus im internen Datenmultiplexer weitergeleitet, je nach Datenbreite (Byte, Word, Langwort entsprechend den SIZ1/SIZ0) und Adresse (A1/A0). So befinden sich die 8 Bits eines Bytezugriffs auf einer Adresse $xxxxxx00 in den Bits 31..24 des Datenbusses.
Auf der A3640 wird die Buslogik des 030 durch eine Datenbus-Multiplexermatrix nachgebildet (U214-U222), gesteuert von PALs (U207 - output enable, U208 - latch enable). Allerdings ist diese Nachbildung nicht vollständig identisch zur Funktion des 030.
Problem:
Das Layout der Videomaster-Zorro-Interfaces ist nicht für Byteadressierung geeignet.
Die Datenschnittstelle der Videomaster-Steuerkarte ist an ED[7:0] geschaltet.
Der Zorro-II-Bus ist ein 16-Bit-Bus (und sollte auch so programmiert werden).
Bei einem Byte-Schreibzugriff auf die Basisadresse $00EF0000 liegt das Datenbyte
beim 030 an allen 4 Bytes des 32-Bit-Busses gleichzeitig an [1].
Bridgette multiplext D[31:16] auf ED[15:0], sodass auf dem Expansion-Datenbus
ED[15:8] sowie ED[7:0] das Datenbyte gelesen werden kann.
Der 040 gibt die 8-Bit eines Bytezugriffs auf $00EF0000 auf D040[31:24] aus
[2]. Diese können bedingt durch den Aufbau des Datenmultiplexers auf der
A3640 nur auf D[31:24] geschaltet werden. Bridgette multiplext D[31:16] auf
ED[15:0], sodass auf dem Expansion-Datenbus ED[15:8] das Datenbyte und auf
ED[7:0] ungültige Daten liegen. Die Daten kommen also nicht auf ED[7:0] an.
Lösung:
Die Videomaster-Software verwendet zum Schreiben eines Expansion-Datenbytes den
Befehl move.b d0,(a0), Opcode $1080. Dieser schlägt wie erwähnt fehl. Abhilfe
kann dadurch erfolgen, dass stattdessen ein Word-Zugriff verwendet wird: move.w
d0,(a0), Opcode $3080.
Das Lesen eines Expansion-Datenbytes funktioniert deswegen, da Bytezugriffe in der VM-Software auf ungerade Adressen erfolgen: move.b 1(a0),d0. Scheinbar ist dem Programmierer aufgefallen, dass sich der Lesezugriff anders als der Schreibzugriff verhält und hat es so hingebogen, dass er zumindest auf dem 030 funktioniert...
Patch:
Die Programme "Videomaster" und "StartUp" sind PowerPacker-gepackt, müssen also
vor dem patchen entpackt werden.
Ersetzt werden alle $1080-Opcodes durch $3080, bis auf den letzten, dieser führt keinen Expansionzugriff durch.
Das gepatchte Programm sollte so auch weiterhin auf allen anderen CPUs laufen.
Als hervorragendes Werkzeug hat sich dazu Enforcer geeignet.
[1] User Manual MC68030, Table 7-5
[2] User Manual MC68040, Table 7-1
Ursache 1:
Wenn eine MMU vorhanden ist legt SetPatch MMU-Tabellen an. Da die
Videomaster-Karte kein AutoConfig unterstützt und vom System so nicht
automatisch erkannt wird, ist auch der Adressbereich $00EFxxxx durch die MMU
umgeleitet. So kann kein Zugriff auf die IO-Adressen des Expansion-Slots
erfolgen.
Abhilfemöglichkeiten:
Ursache 2:
Die Videomaster-Software ist in GFA-Basic programmiert. Das generierte Programm
enthält selbstmodifizierenden Code, der mit aktiviertem Daten-Cache zum Absturz
führt. Zu beachten ist wieder, dass vor dem Patchen die Programme
PowerPacker-entpackt werden.
Abhilfe:
Der Datenmultiplexer soll die geänderte Datenbusbelegung bei Word- und Byte-Zugriffen des 040 zum 030 korrigieren. Die Verschaltmatrix ist aus 9 Octal-Transceivern (74FCT543T) aufgebaut
Im Internet habe ich Schaltpläne der A3640 gefunden. In Dave Haynies fehlen ein paar Beschriftungen, insbesondere die des Datenmultiplexers. Die Beschriftung von "U212" ist falsch, sie lautet U222.
In den Schaltplänen von Oztronics ist die Busbeschriftung des Datenmultiplexers nicht korrekt.
| IC | Pin | Name | Pin | Name | Funktion | ||
|---|---|---|---|---|---|---|---|
| U214 | 1 | LEBUS0 | 2 | OEBUS0 | D040[31:24] - D[31:24] | ||
| U215 | 1 | LEBUS1 | 2 | OEBUS1 | D040[23:16] - D[31:24] | ||
| U216 | 1 | LEBUS2 | 2 | OEBUS2 | D040[23:16] - D[23:16] | ||
| U217 | 1 | LEBUS3 | 2 | OEBUS3 | D040[15:8] - D[31:24] | ||
| U221 | 1 | LEBUS4 | 2 | OEBUS4 | D040[7:0] - D[7:0] | ||
| U220 | 1 | LEBUS5 | 2 | OEBUS5 | D040[7:0] - D[23:16] | ||
| U219 | 1 | LEBUS6 | 2 | OEBUS6 | D040[7:0] - D[31:24] | ||
| U218 | 1 | LEBUS7 | 2 | OEBUS7 | D040[15:8] - D[15:8] | ||
| U222 | 13 | /DMACOE | 2 | PUP4 | D040[23:16] - D[7:0] |
Aus der Verschaltmatrix ist ersichtlich, dass der Datenbus der A3640 nicht 100% zum 030 nachgebildet wird. Vgl. [1] und [2]
Die PAL-Gleichungen für OEBUS sind in den Dave Haynie Archives zu finden.
Bei der Programmierung einer derartigen Zorro-Interface-Karte ist darauf zu achten, dass 16-Bit-Zugriffe verwendet werden - Byte-Zugriffe müssen auf ungerade Adressen erfolgen.
Über Adresse 0x00EF0xx0 und 0x00EF0xx2 ist der PCD8584 erreichbar. Es kann gelesen
und geschrieben werden. Ein Zugriff auf Adresse 0x00EF0xx2 adressiert das S1 control/status-Register des I2C-Controllers (AD1 ist mit A0 verbunden). Sein Reset-Eingang ist über Bit0 der Adresse
0x00EF1xxx steuerbar. Sein Takt wird aus den 7MHz des CDAC abgeleitet.
PCD8584 und PCF8584 dürften weitestgehend
gleich sein. Ich habe leider kein Datenblatt zum PCD8584 gefunden, nur ein
Application Note.
In diesem Register werden 8 Bits zur Steuerung gespeichert. Bit 0 und Bit 1 sind die Reset-Eingänge der I2C-Controller. Bit 2, 3 und 4 gehen an die Schnittstelle. Nur beschreibbar.
Dem Platinenaufdruck nach ist der Sockel für einen PCF8584, also einen zweiten I2C-Controller. Er ist über Adresse 0x00EF3xx0 und 0x00EF3xx2 erreichbar. Es kann gelesen und geschrieben werden. Er stellt einen unabhängigen, zweiten I2C-Bus bereit.
Sein Reset-Eingang ist über Bit1 der Adresse 0x00EF1xxx steuerbar. Der Reset
wird z.B. ausgelöst durch:
move.w #0,$00ef1000 ; /RES auf low
move.w #3,$00ef1000 ; /RES beider PCx8584 auf high
Sein Takt wird aus den 7MHz des CDAC abgeleitet.
Dem Platinenaufdruck nach sind die Sockel für SN74LS374-Latche vorgesehen. Über Adresse 0x00EF2xxx kann aus dem VM ein 16-Bit-Wert gelesen werden. Da das LE von U17 und U18 auf E7M liegt, ist über diese Adresse immer der aktuelle Port-Zustand lesbar. Nur lesbar.
Computer-Entwicklungs-Labor Mühlenhoff
Meitnerstraße 4
3000 Hannover 61
Telefon 0511 / 573679
Telefax 0511 / 563267
Computer und Video Mühlenhoff
Leipzigerstraße 6
3000 Hannover-Wettbergen