VME Bus Zugriffe

[guest522]

Ich kann das nicht verstehen !?!

Naja, Du hast schon Recht. Es ist nicht wirklich schwer, aber meine Erfahrung hier ist, dass es nur sehr wenige machen würden.

Der Atari ist halt kein Amiga ..., leider !?!

 

Man müsste die Signale /SBHE und A0 für Grafikkarte per GAL verändern.
Auf dem Nova-VME-Adapter sind beide allerdings direkt mit /DS0 und /DS1 verdrahtet.

Warum /SBHE? Das wird doch schon von DS1 gesteuert. D.h. bei einem 8 bit Zugriff auf gerade Adressen sthet das auf 0.

Zur Generierung von A0 kommen A20-A23 in Frage, da nur die am GAL anliegen.

xx Ax xx xx - xx Fx xx xx  und xx 8x xx xx werden aber schon für 16 bit Zugriffe verwendet.

xx 9x xx xx generiert die 8 bit IOW bzw. IOR Signale.

A23 aktiv kommt für eine Steuerung also nicht in Frage.
Gehen wir der Einfachheit halber mal von
A23 A22 A21 A20
0      0     0      0   
aus.


SA0 = /A23*/A22*/A21*/A20 wobei man die normalen Zugriffe per DS1 ja weiter zulassen muss.

(A23*/A22*A21 + A23*A22 + A23*/A22*/A21*/A20) * DS1

==>
SA0 = /A23*/A22*/A21*/A20 * /DS1 * DS0
+ (A23*/A22*A21 + A23*A22 + A23*/A22*/A21*/A20) * DS1

Jetzt noch DTACK aufbohren:

DTACK = A23 *IOCHRDY *Qb
wird zu
DTACK = A23 *IOCHRDY *Qb
+ ( /A23*/A22*/A21*/A20  *IOCHRDY *Qb )

Was denkst Du?

[guest522]

Mist.....war zu voreilig. Es ist doch kein GAL Output mehr frei. 

[frank.lukas]

Hallo Idek,

 ein zweites Gal mit einer Adapterplatine (kann ich dir bauen!) und eine Aufteilung der Funktionen so wie beim Gal (/RW & (CS0 + CS1 + TOS)) des IDE Adapters aus der CT ...

--- Ausschnitt ---

*BOOLEAN-EQUATIONS

   TOS.E    = VCC;
   IOWR.E   = VCC;
   IORD.E   = VCC;
   G.E      = VCC;
   CS1.E    = VCC;
   CS0.E    = VCC;

  INT.E    = IRQ14;
  INT      = IRQ14;
   
   DTACK    = /A17 & /A18 & /A19 & A20 & A21 & A22 & A23
      + TOS;
   
  DTACK.E  = /IOCHRDY & AS & /A19 & A21 & A22 & A23;
        
   CS0      = /A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
   
   CS1      =  A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
   
   G        = LDS & RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23
       +      /RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
    
   IORD     = LDS &  RW & (CS0 + CS1);
        
   IOWR     = LDS & /RW & (CS0 + CS1 + TOS); % Signal TOS wegen EEPROMs %

   TOS      = ROM2
      + AS & A23 & A22 & A21 & /A20 & /A19;
---
Der Code muss für den JEDI aber angepasst werden, ich weiss nicht womit der Erzeugt wurde ...

[guest522]

Jubel.....es funktioniert.
Ich habe einfach einen Sockel auf GAL1 gelötet und da Huckepack ein zweites GAL drauf. Bilder gibts später.

Die Erkennung für ET4000 Karten klappt.
EMULATOR.PRG muss ich noch fertig umstricken. Ich bekomme die Karte aktiviert, aber bisher nur ein grünes Bild.


Nachtrag: Schwierige Nummer. Ich kann die Karte nun korrekt initialisieren, es wird aber noch nichts sichtbar gezeichnet. Prinzipiell scheint es zu funktionieren, die Treiber sind aber sehr kompliziert. Mal sehn was geht....

Nachtrag2: Erfolg! VMG läuft und stellt die Auflösungen korrekt mit seinem Streifenmuster dar.  Die Outputs auf ungerade Register sind oftmals einfach Zuweisungen der Art
*(IO_BASE + DAC_DATA) = 0x33
Das macht die Sache mühsam.

[pakman]

Warum /SBHE? Das wird doch schon von DS1 gesteuert. D.h. bei einem 8 bit Zugriff auf gerade Adressen sthet das auf 0.

Stimmt

Zur Generierung von A0 kommen A20-A23 in Frage, da nur die am GAL anliegen.

Gehen wir der Einfachheit halber mal von
A23 A22 A21 A20
0      0     0      0   
aus.

Was denkst Du?

Damit wäre der MSTE aussen vor, der kann am VME-Bus nicht auf $0x.xxxx zugreifen...

Besser wäre z.B.
A23*/A22*/A21*A20*/A19  '90 bis 97 I/O-Bereich mit SA0=0, wie bisher
A23*/A22*/A21*A20* A19  '98 bis 9F I/O-Bereich mit SA0=1

Also:
SA0 =  A23*/A22*/A21*A20*A19 * /DS1 * DS0
+ (A23*/A22*A21 + A23*A22 + A23*/A22*/A21*/A20) * DS1

DTACK bleibt Original

Einziger Nachteil: Die Leitung A19 muss an das Huckepack-GAL gefädelt werden...

Gruß, Holger

[guest522]

Damit wäre der MSTE aussen vor, der kann am VME-Bus nicht auf $0x.xxxx zugreifen...

Damit hast Du natürlich Recht, aber ich werde es erst mal bei meiner Variante belassen. Es geht ja ohnehin nicht darum eine funktionierende Nova durch eine funktionierende, aber langsamere (weil Adressen angepasst werden müssen) zu ersetzen. Vielmehr möchte ich erst mal eine funktionierende Software hinbekommen. Das modifizieren der Adressen mache ich ohnehin zentral in einer outp bzw. inp Routine.
Wenn die Software stabil laufen sollte, knöpfe ich mir doch nochmal den CT60 Falcon vor. Da müssten die Adressen ja dann auch geändert werden.

[guest522]

STA_VDI ist ein größeres Ding. So ziemlich alles in Assembler und viele viele 1000 Zeilen Code. 

Könnte man das Umschalten der Datenleitungen nicht einfacher und ggfs. schneller per Hardware realisieren?
Dann müsste man nicht an den Adressen rumfummeln und könnte die Schaltung ggfs. direkt im Falcon austesten.

[guest522]

Aufgegeben hab ich noch nicht....

In der Zwischenzeit ist es mir gelungen EMULATOR so zu verändern, dass es die Ausgabe komplett auf die Nova umlenkt.
D.h. ich bekomme eine GEM Oberfläche mit kleinen Fehlern und der TT-High Auflösung in meine 1024x768 Nova Auflösung eingeblendet.  Die VDI-Ausgabe ist dann natürlich die vom TOS und deshalb relativ lahm.
Aber mein "Huckepack GAL" tut es. Die Umstellung des STA_VDI ist wirklich ein Mega-Projekt und deshalb werde ich das vermutlich nicht durchziehen. 
Als Basis für einen CT60 Test sollte das reichen.....mal sehn wann ich die Zeit dafür finde.

[tuxie]

Könnte mir denn jemand eine Nova zusammen stricken? Würde gern mit helfen aber ich finde einfach keine Zeit um mir jetzt eine zu bauen :-( Habe ja auch 2 TTs hier stehen und nen Falcon ebenfalls.

[guest522]

Könnte mir denn jemand eine Nova zusammen stricken? Würde gern mit helfen aber ich finde einfach keine Zeit um mir jetzt eine zu bauen :-( Habe ja auch 2 TTs hier stehen und nen Falcon ebenfalls.

Leider kann ich keine Platinen bauen, sonst hätt ich mir schon selbst ne Nova/Netz Kombi gebaut.

[guest522]

Es funktioniert!


Bisher nur in 2 Farben.
Mehr Farben sehen noch so aus:



Wer sehen möchte wie mein Huckepack GAL aussieht:

[pakman]

Könnte man das Umschalten der Datenleitungen nicht einfacher und ggfs. schneller per Hardware realisieren?

Geht, aber dann muss man 3 Datenbustreiber einschleifen, plus die Ansteuerung dazu.
Da ist natürlich Basteln angesagt.
Schneller wird dadurch allerdings nichts...

Soll das einmalig zum Ausprobieren sein?

Und ganz wichtig: Wie werden die Mach-Karten eigentlich von der NOVA-Soft konfiguriert: 8-Bit oder 16-Bit-Zugriffe?

Gruß, Holger

[guest522]

Und ganz wichtig: Wie werden die Mach-Karten eigentlich von der NOVA-Soft konfiguriert: 8-Bit oder 16-Bit-Zugriffe?

Die Konfiguration passiert immer über 8-bit Zugriffe.

Geht, aber dann muss man 3 Datenbustreiber einschleifen, plus die Ansteuerung dazu.
Da ist natürlich Basteln angesagt.
Schneller wird dadurch allerdings nichts...

Ja, ist zu aufwändig. Macht auch vermutlich keinen Sinn mehr, da ich ja zumindest funktionierende Auflösungen für die Nova habe. Jetzt fehlt noch die Zeit das ganze mal auf den Falcon zu portieren. Aktuell ist da keine Nova mehr drin.

Meine Versuche sind im Übrigen alle mit ner ET4000-Nova, da ich mir keine (weitere)  ATI zerschiessen möchte.  Im Falcon ist das dann ne Premiere, da es da wohl keine ET4000 Version gab.

[pakman]

Die Konfiguration passiert immer über 8-bit Zugriffe.

Missverständnis, also nochmal genauer:
Viele ISA-Karten lassen sich über ein Register programmieren, ob sie 8Bit oder 16Bit breit kommunizieren sollen. Nach einer Doku zu einem Linux-Treiber gibt es für die Mach32 anscheinend folgende Möglichkeiten:

char *transwid[]={"  auto select","  16 bit","  8 bit","  8 bit hostdata/16 bit other"};

Die Frage ist: Was sagt die Nova-Soft der Grafikkarte, will sie mit 8 oder 16 Bit?
Falls 16Bit-Zugriffe eingestellt sind, dann benutzt die Grafikkarte u.U. bereits die "richtige" Hälfte des Datenbusses für die ungeraden Adressen. Der Trick mit dem Umweg über gerade Adressen mit A0=1 geht dann in die Hose!

Und es wird noch komplizierter: Selbst wenn 16Bit vereinbart sind, kann die Karte ISA-Konform mit 8Bit antworten (wird durch /IOCS16 respektive /MCS16 von der Karte rückgemeldet). Dann ist es doch wieder die falsche Datenbus-Seite, und der Trick wird gebraucht, aber das erfährt man erst, wenn der Zugriff gerade läuft!

Deshalb also, ganz wichtig:
Welche Bus-Breite setzt die NOVA-Soft?
Und, falls 16Bit gesetzt werden: Gibt es Adressen, wo die Karte trotzdem nur mit 8Bit antwortet? Müsste man ggf. scannen.

Gruß, Holger

[guest522]

Kannst Du mir sagen wie der Zugriffsmode gesetzt wird?
Welches register?

Fakt ist, dass das Lesen ungerader Adressen ohne meinen mod in die Hose geht, was zumindest dafür spricht, dass 8 bittig geantwortet wird.

Und nochwas.....ich teste nicht mit der ATI sondern mir der ET4K

Gruß
Wolfgang

[guest522]

tataaaa...it works

Es ist immer noch etwas buggy, d.h. ich habe nicht alle Zugriffe "bereinigt", aber prinzipiell gehts nun in 2 und 16 Farben. Das reicht für die "Transplantation". Jetzt brauch ich mal 2 Tage am Stück Zeit um den Falcon anzupassen.

[wfoerster]

Hallo,
Super, ich habe das mit Interesse verfolgt. Habe ich es überlesen oder was ist das für eine Auflösung mit dem grünen Desktop? Ich frage deshalb, da ich momentan auch am 'köcheln' bin und die ST(E) Auflösungen auf einem 16:9 TFT sichtbar mache.

Viele Grüße

Wolfgang

[guest522]

Hallo,
Super, ich habe das mit Interesse verfolgt. Habe ich es überlesen oder was ist das für eine Auflösung mit dem grünen Desktop? Ich frage deshalb, da ich momentan auch am 'köcheln' bin und die ST(E) Auflösungen auf einem 16:9 TFT sichtbar mache.

Viele Grüße

Wolfgang

Das ist ne Nova ET4000 mit 1024x768x16.
Das Ganze macht natürlich nicht viel Sinn, außer dass ich mehr über die Nova lerne und hoffe durch den veränderten Zugriff die CT60 Nova evtl. zum Laufen zu bringen. 
Ausgangspunkt war mein Wunsch sowas wie nen "unified Nova" Treiber zu entwickeln. Dazu muss man aber in der Lage sein, die Karte abzufragen und die Art der Umsetzung der Originalhardware macht das unmöglich.
Anyway, jetzt habe ich nen Mörder Respekt vor den Hubers. Allein die Software ist ne Wahnsinnsleistung und ihr Geld Wert gewesen.