Autor Thema: PAK68/2 Platinen Projekt ...  (Gelesen 156555 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #100 am: Fr 10.06.2016, 15:13:12 »
Yep, Hochsitz, nicht HuckePAK (man kann sich ja auch nicht an alle Kleinigkeiten erinnern).
Bei einem Freund lief das Teil aber.
« Letzte Änderung: Fr 10.06.2016, 15:48:57 von joejoe »

Offline Lukas Frank

  • Benutzer
  • Beiträge: 13.409
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: PAK68/2 Platinen Projekt ...
« Antwort #101 am: Fr 10.06.2016, 15:20:21 »
Ja sollte laufen, ich weiss auch nicht was ich damals falsch gemacht habe ...

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #102 am: Fr 10.06.2016, 15:51:29 »
Habe mir an meinem letzten Urlaubstag gleich den Hochsitz-Artikel gegönnt:
hier zwei Zitate daraus:

In älteren Rechnern, etwa im Mac II, auf Eurokarten-Computern (wie unserem c't 68020), aber vor allem auf 68000-Beschleunigerboards (wie unserer PAK68) findet sich der Prozessor 68020 als genügsames Arbeitspferd. Dort könnte er auch alt werden - würde nicht der 68030 mit seiner eingebauten PMMU (Paged Memory Management Unit, seitenorientierte Speicherverwaltungseinheit) und dem zweiten (Daten-) Cache locken. Über den Sinn eines Daten-Cache braucht man nicht zu streiten - dort vorrätiges Zahlenmaterial ist schnellstmöglich zur Stelle und muß nicht aus dem Hauptspeicher hervorgekramt werden. Je nach Software ergibt sich allein durch dieses Zwischenlagern ein Geschwindigkeitsvorteil von 15 Prozent gegenüber dem lediglich mit einem Befehls-Cache ausgerüsteten 68020. Die PMMU nützt allerdings nur in Verbindung mit entsprechender Software-Unterstützung etwas: Virtual Memory von Apples System 7 zum Beispiel macht regen Gebrauch davon
.
=> Da würde dann auch Mint davon profitieren.

Gleichlautende Prozessor-Pins sind durchverbunden, nur die 68030-spezifischen Pins müssen adäquat behandelt werden - entweder durch Pull-Ups oder durch das angeflanschte GAL.

=> Dieser Aufwand sollte für jemanden, der das alte Layout nachvollzogen hat dann ja eher kein Problem darstellen.
« Letzte Änderung: Fr 10.06.2016, 17:06:46 von joejoe »

Offline Lukas Frank

  • Benutzer
  • Beiträge: 13.409
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: PAK68/2 Platinen Projekt ...
« Antwort #103 am: Fr 10.06.2016, 16:24:47 »
Das GAL ist aber sehr wichtig bei der ganzen Sache.

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #104 am: Fr 10.06.2016, 17:06:17 »
ja, aber mit simplem Inhalt (den will ich aus rechtlichen Gründen hier nicht im direkten Zusammenhang posten, denn viel mehr Informationen gibt es im ganzen c't Artikel nicht).
Das cache -Signal wird aus der Verknüpfung von den u.a zum Datenaustausch mit dem CoPro benötigten FC0 bis FC2 und dem cacheablen RAM.-Bereich gebildet. Wenn FastRAM (also oberhalb A23) vorhanden ist, dann müssen die betroffenen Adressleitungen natürlich ebenfalls mit ins GAL einfließen.
 
Aber ich glaube, es gab auch noch eine Ergänzung zu diesm Artikel.

Offline czietz

  • Benutzer
  • Beiträge: 3.674
Re: PAK68/2 Platinen Projekt ...
« Antwort #105 am: Fr 10.06.2016, 17:52:02 »
Die GAL-Gleichungen im Artikel sind sowieso nur passend für einen Mac SE, für den Atari müssen sie neu geschrieben werden. Ist aber nicht schwer.

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #106 am: Fr 10.06.2016, 18:10:02 »
Irgendwie fehlt da dann auch das Signal um Cache zu verwerfen, wenn z.B. ein DMA-Schreibzugriff aufs RAM erfolgt ist. Wollte man nur das FastRAM chahen (auf welches sowieso nur die CPU Zugriff hat) dann könnte jegliche Adresse unterhalb 16MB als nicht cachable ins GAL eingehen.

Offline czietz

  • Benutzer
  • Beiträge: 3.674
Re: PAK68/2 Platinen Projekt ...
« Antwort #107 am: Fr 10.06.2016, 18:31:09 »
Irgendwie fehlt da dann auch das Signal um Cache zu verwerfen, wenn z.B. ein DMA-Schreibzugriff aufs RAM erfolgt ist.

Stimmt, das war mir noch nicht aufgefallen. Das ist aber auch schwierig, weil der 68030 nach meinem Verständnis gar kein Eingangssignal dafür bietet.
Invalidieren TOS-Versionen, die auf einem 68030 laufen, denn wenigstens den Cache für den entsprechenden Speicherbereich, bevor sie DMA-Zugriffe starten? Dann wären nur Programme gefährdet, die den DMA direkt programmieren, an TOS vorbei.

Wie ist das eigentlich im TT gelöst?

Zitat
Wollte man nur das FastRAM chahen (auf welches sowieso nur die CPU Zugriff hat) dann könnte jegliche Adresse unterhalb 16MB als nicht cachable ins GAL eingehen.

Das ist die sicherste Lösung, sicherlich.

Arne

  • Gast
Re: PAK68/2 Platinen Projekt ...
« Antwort #108 am: Fr 10.06.2016, 18:47:08 »
Das ist aber auch schwierig, weil der 68030 nach meinem Verständnis gar kein Eingangssignal dafür bietet.
/CIIN - in Zusammenhang mit /BR, /BG und /BGACK

Abgesehen davon läuft der SE m.W. komplett DMA-los.
« Letzte Änderung: Fr 10.06.2016, 18:49:14 von Arne »

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #109 am: Fr 10.06.2016, 18:56:54 »
ups, da war jemand schneller:
hier (aus anno 1991 !!) ein paar weitere Infos dazu.
http://www.verycomputer.com/79_e0bfb7d5de99563c_1.htm#p5

Offline czietz

  • Benutzer
  • Beiträge: 3.674
Re: PAK68/2 Platinen Projekt ...
« Antwort #110 am: Fr 10.06.2016, 19:01:17 »
/CIIN - in Zusammenhang mit /BR, /BG und /BGACK

/CIIN verhindert doch nur, dass ein vom Bus gelesenes Datenwort im Cache landet? Das ist bei IO-Zugriffen natürlich richtigerweise aktiviert, das ist auch genau das, was das GAL im Artikel macht.

Wenn ich aber nun ein Wort aus cachebarem RAM lese (/CIIN = high), landet es im Cache und zukünftige Lesezugriffe werden natürlich aus dem Cache bedient und landen nicht mehr auf dem Bus.

Wenn sich dann aber das Wort im RAM durch einen DMA-Zugriff ändert, wie teile ich der CPU per Signal mit, dass dieses Wort im Cache invalidiert werden soll? Klar, per Software geht das (Cache Control Register) aber per Hardware-Signal? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht. Eigentlich kann ich da nur wie von joejoe geschrieben den kompletten vom DMA erreichbaren RAM vorsichtshalber als nicht-cachebar markieren.

Offline czietz

  • Benutzer
  • Beiträge: 3.674
Re: PAK68/2 Platinen Projekt ...
« Antwort #111 am: Fr 10.06.2016, 19:12:14 »
Invalidieren TOS-Versionen, die auf einem 68030 laufen, denn wenigstens den Cache für den entsprechenden Speicherbereich, bevor sie DMA-Zugriffe starten? Dann wären nur Programme gefährdet, die den DMA direkt programmieren, an TOS vorbei.

Wie ist das eigentlich im TT gelöst?

Und das kann ich mir selbst beantworten mit dem TT030 Companion [1]: "any program which uses DMA directly (as opposed to making the BIOS or XBIOS calls) needs to invalidate the caches after the DMA operation completes".

Also: Es kümmert sich nicht die Hardware darum, nach DMA den Cache zu löschen. TOS auf dem TT macht es, aber Programme die eigene DMA-Zugriffe machen (z.B. Festplattentreiber) müssen sich auch selbst um den Cache kümmern. Wenn man nur nach dieser Devise entwickelte Software einsetzt, kann man allen RAM cachebar machen und das GAL wird -- wie von mir schon geschrieben -- sehr einfach.

[1] http://dev-docs.atariforge.org/files/TT030_Companion-Dev_Notes.pdf

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #112 am: Fr 10.06.2016, 19:27:53 »
Zitat
? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht
na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein. Wobei /CIIN = A24 das Thema dann recht simple löst.

Arne

  • Gast
Re: PAK68/2 Platinen Projekt ...
« Antwort #113 am: Fr 10.06.2016, 19:29:10 »
Alternativ könnte (ein gepatchtes) TOS 3.06 das CI-Bit der Pagedeskriptoren für non-cacheable Bereiche setzen. Hab mir aber die MMU nie genau angesehen.

Offline czietz

  • Benutzer
  • Beiträge: 3.674
Re: PAK68/2 Platinen Projekt ...
« Antwort #114 am: Fr 10.06.2016, 19:42:09 »
na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein.

Drücke ich mich irgendwie unverständlich aus? Es geht doch gerade darum, dass wenn ein Wort einmal im Cache ist, es kein Hardware-Signal mehr gibt, der CPU mitzuteilen, es nicht mehr zu verwenden, weil es unterdessen von DMA modifiziert wurde. Genau in diesem Fall hilft /CIIN überhaupt nicht mehr weiter, denn es hätte schon beim ersten Zugriff gesetzt sein müssen, als man evtl. noch gar nicht wusste, dass DMA später in diesen Speicheradresse schreiben würde.

Entweder muss die Software nach DMA den Cache invalidieren (wie es Atari beim TT empfiehlt und ich bereits schrieb) ...

Wobei /CIIN = A24 das Thema dann recht simple löst.

... oder man muss das komplette ST-RAM vorsorglich als nicht-cachebar markieren (wie Du vorgeschlagen hast und ich ebenfalls bereits schrieb) und halt auf die Vorteile des Caches für das ST-RAM verzichten.

Beides ist keine optimale Lösung, weil man im ersten Fall auf anständig programmierte Software angewiesen ist und im zweiten Fall Performance verschenkt, gerade das langsamere ST-RAM gar nicht zu cachen.

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #115 am: Fr 10.06.2016, 20:05:13 »
nein, Deine Worte sind klar und verständlich.
Trotzdem ist es auch richtig, dass es kein Problem geben sollte, wenn eben die Daten einer speziellen Adresse erst gar nicht im Cache landen (z.B. per /CIIN, sonst hätte Motorola sich den Pin ja auch schenken können). Allerdings wäre dann im konkreten Fall /CIIN = A24 = low, dann liefe auch jegliche "non 68030 aware soft", zumindest, was dieses "Problem" anginge.

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #116 am: Fr 10.06.2016, 20:14:01 »
Ich hoffe, ich lande damit nicht gleich in der Kategorie Raubkopierer:
Der Schaltplan des Hochsitzes:
« Letzte Änderung: Fr 10.06.2016, 20:49:02 von joejoe »

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #117 am: Fr 10.06.2016, 20:32:22 »
wie stellt man hier ein Bild ein?
In die Gallery und dann den Link drauf scheint nicht zu funktionieren?

Offline Lukas Frank

  • Benutzer
  • Beiträge: 13.409
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: PAK68/2 Platinen Projekt ...
« Antwort #118 am: Fr 10.06.2016, 20:39:35 »
-> Anhänge und andere Optionen <-   beim Schreiben ...

Offline joejoe

  • Benutzer
  • Beiträge: 231
Re: PAK68/2 Platinen Projekt ...
« Antwort #119 am: Fr 10.06.2016, 20:50:10 »
Danke