CT60 + Nova Falcon ISA Grafikkarten Adapter ...

[Lukas Frank]

Der Atari Falcon Nova ISA-Grafikkartenadapter der auf dem 16-Bit-Erweiterungsbus des Falcon sitzt (demselben Bus, der auch vom ct60/63 Beschleuniger belegt wird) funktioniert nicht zusammen mit einer CT60. Woran liegt das? Belegt die CT60 (CT60 TOS) den gesamten Adressraum oder gibt es ein Kommunikations Problem seitens der CT60 mit dem Falcon-Mainboard, solange der CT60 Beschleuniger aktiv ist und läuft?

Mit einem DFB1 oder einem Afterburner040 zum Beispiel läuft es ...

[Joebar]

Der Atari Falcon Nova ISA-Grafikkartenadapter der auf dem 16-Bit-Erweiterungsbus des Falcon sitzt (demselben Bus, der auch vom ct60/63 Beschleuniger belegt wird) funktioniert nicht zusammen mit einer CT60. Woran liegt das? Belegt die CT60 (CT60 TOS) den gesamten Adressraum oder gibt es ein Kommunikations Problem seitens der CT60 mit dem Falcon-Mainboard, solange der CT60 Beschleuniger aktiv ist und läuft?

Mit einem DFB1 oder einem Afterburner040 zum Beispiel läuft es ...

Dazu habe ich vor vielen Jahren einiges (auch hier) geschrieben. Zunächst hat Rodolphe immer gesagt die Software sei nicht 68060 fest. Ich habe dann lange mit Didier und Rodolphe an dem Problem gearbeitet. Didier hat besondere TOS Versionen erstellt und ich habe Treiber und GAL modifiziert. Alles ohne Erfolg.

Ergebnis: Die CT60 implementiert nur das in der Falcon Doku beschriebene "einfache" Busprotokoll, welches keine Waitstates beachtet und nach einer definierten Anzahl von Zyklen einen Buserror erzeugt. Das Signal (ich erinnere mich nicht mehr wie es heißt) welches am Erweiterungsbus die CPU zum Warten auffordert, ist bei der CT60 nicht mal verbunden.
Als die CT60 verkauft wurde, hat Rodolpe gesagt alle alten Karten würden laufen. Aber auch die Eclipse lief damals nicht. Andere Karten konnte ich nicht testen.

[Lukas Frank]

Das ist ja schonmal etwas, vielen Dank. Mal sehen was bei dem Thema noch so kommt ...

Wenn da etwas bei heraus kommt würde ich Pavel von Centuriontech mal fragen ob er das etwas machen kann? Er baut die CT60 ja noch nach aber kann bei der CT60 Firmware nichts machen vermute ich aber man weiß ja nicht?

[don_apple]

In deinem Thread auf a-f zum selben Thema gab es eine Antwort mit einem Link zu einem anderen Thread mit vielen interessanten Informationen: https://www.atari-forum.com/viewtopic.php?p=496081#p496081

https://www.atari-forum.com/viewtopic.php?t=34016

[Lukas Frank]

Habe dem Entwickler der DFB1 mal angeschrieben wegen dem CT60 Problem ...

[Joebar]

Wie auch bei den anderen Links zu lesen ist liegt es am Busprotokoll. Das Thema hat einen sehr langen Bart. Das verlinkte dhs post von mir ist von 2007!
Didier war immer bereit zu helfen, Rodolphe hat zunächst immer wieder die Software verantwortlich gemacht. Nachdem ich Monate lang versucht habe die Karten zum Laufen zu bringen habe ich die Problematik mit dem /EXPAND Signal erkannt und mit Rodolphe darüber diskutiert. Er hat es aber abgelehnt ein anderes Protokoll zu implementieren und damit war das Thema für mich erledigt. 

[badwolf]

Guten tag,

Sorry I will reply in English today as my German is 35 years old and too basic for the topic at hand.

DFB1 does also not pay any attention to the /EXPAND line. I don't know enough about the CT60 (I have never owned one) to know why this matters for it but not for DFB1. I remain slightly skepitcal about EXPAND being a problem at all and tend to agree with Rodolphe that it should have no effect really.

BUT there is one area where I can see it could. Perhaps CT60 generates its own BERR signal for the lower 16MB range rather than relying on the motherboard's 128 clock cycle timeout? [nb. from memory it's 128 cycles -- about 8 microseconds, but I may be misremembering and it may be only 4microseconds]

DFB1 does not synthesize its own bus errors apart from at the top of TT-RAM. It relies on the motherboard  to assert BERR and EXPAND is, of course, still connected to the motherboard.

Perhaps CT60 is not like this and, for some reason, Nova requires a very, very slow bus access from time to time?

BW

[Joebar]

Guten tag,

Sorry I will reply in English today as my German is 35 years old and too basic for the topic at hand.

DFB1 does also not pay any attention to the /EXPAND line. I don't know enough about the CT60 (I have never owned one) to know why this matters for it but not for DFB1. I remain slightly skepitcal about EXPAND being a problem at all and tend to agree with Rodolphe that it should have no effect really.

BUT there is one area where I can see it could. Perhaps CT60 generates its own BERR signal for the lower 16MB range rather than relying on the motherboard's 128 clock cycle timeout? [nb. from memory it's 128 cycles -- about 8 microseconds, but I may be misremembering and it may be only 4microseconds]

DFB1 does not synthesize its own bus errors apart from at the top of TT-RAM. It relies on the motherboard  to assert BERR and EXPAND is, of course, still connected to the motherboard.

Perhaps CT60 is not like this and, for some reason, Nova requires a very, very slow bus access from time to time?

BW

Hi David,

I don't recall the details since we worked on this more than 20 years ago, but as far as I remember Rodolphe was expecting expansion cards to create /DTACK within 4 cycles. Since Nova needs to honour the ISA protocol (I think I read that I/O can take up to 12 cycles), this was an issue. Nova uses a 74LS164 for timing control and we tried modifying the GAL as well as using a different LS164 output, but nothing worked. He concluded that the card (interface) is too slow and since this was also the time when CTPCI became available, he stopped looking into the issue.
Maybe someone with better hardware knowledge than me can make it work, I also don't own a CT6x anymore and only one Falcon with a DFB1. 

Wolfgang