68020 für ST?

[1ST1]

In der c't gabs in den mittleren 1990ern mal im Zusammenhang mit Cache, TAG, Dirty Bit usw, mal ein sehr guter Artikel, der das erklärt hat.

[Arne]

Ist nur die halbe Miete.
Ich schau mal die Tage in den Schaltplan der PAK68/3 wie das dort mit dem Validbit gemacht ist. Die 71S74/48S74/48S80 haben einen /RESET Eingang, womit man das evtl. lösen könnte. Ein "normales" SRAM hat das nicht und nach einem Reset könnte da Mumpelgrumpf drinstehen -> und schon kommt Müll raus.

Hab nochmal drüber nachgedacht: TagRAM (mit/ohne Komparatoren) ist ein MUSS. DirtyBit ist nice-to-have. Bringt aber wohl eh nur <3% (http://www.sdsc.edu/~hocks/pc.ram.html).

[dbsys]

btw. Das verlinkte ATARI_HQ_1.zip ist wohl nicht mehr auf dev-docs. Hat das jemand von Euch?

Ich nehme an, es handelt sich um diese CD:
JAGHQ1 New Atari HQ #1 CDROM $14.95

Zu finden hier:
http://www.myatari.com/atarijag.txt

Zitat:
"It has over 600 Mega bytes, over 8,000 files(sorry some
are zipped), schematics, source code, Jag Developer
software, tons of internal Atari software, Gerber files
for many atari PCB. Has stuff for all newer Atari
products. Lynx, Jaguar, ST, Mega STE, Falcon, ETC.
Hundreds of hours were spent collecting this data.
Know one will be able to use it all. There is just
so much on this CDROM. We put the entire source for
the sounds files for demolition man. There is work in
progress source for many games. These are not final
versions but test portions. Source from AVP, Hoverstrike,
Iron Soldier II and more. There is the encryption
software that AStari used to encrypt CDROMs. There are
letters from Atari to Software developers telling them
they are doing a great job(Fat Bobby) or telling them
they are in default on their schedule(Road Riot +)+++++++
This is an ISO9660 CDROM. Not a Jaguar CDROM. It works on
PC, MAC, ST, TT, Falcon computers with CDROM drive."

[goetz @ 3rz]

Ihr vergesst noch eine Winzigkeit: Auf der PAK 68/2 ist ein 32 Bit breites TOS-ROM, welches mit CPU-Takt läuft. Das bringt einiges, da jedes vernünftige Programm dieses für alle möglichen Sachen nutzen sollte.

Kommt stark darauf an, welche Programme und welches OS man einsetzt. Beim raytracen bringt ein schnelles TOS im ROM nichts, bei LaTeX auch kaum, beim Platine entflechten auch nicht. Und wenn man NVDI einsetzt, dann kommt das VDI aus dem RAM, nicht dem ROM. Kommt noch MagiC dazu, dann braucht es das TOS noch für ein paar wenige Zugriffe beim booten, dann ist es ungenutzt.

Aber ja, wer mit Single-TOS unterwegs ist, für den könnte das was bringen. Mir wäre ja der Hardwareaufwand dafür zu hoch, ich würd lieber viel schnelles RAM einbauen und das TOS da reinladen ...

[Arne]

Kommt stark darauf an, welche Programme und welches OS man einsetzt.

So isses!

Hab jetzt nochmal über Cache nachgedacht. Das V-Bit ist implizit im TagRAM untergebracht. Über den /RS Eingang kann man das TagRAM ausnullen. Füllt sich der Cache, dann füllt sich auch das Tag mit Werten <> Null, da dort Adressen gespeichert werden - fraglich wie z.B. die Speederkarten auf Adresse Null reagieren. Fragt die Logik das Tag, ob eine Cacheline im Datencache steht, liefert das TagRAM am MATCH Ausgang eine 1, wenn die Adresse (die <> Null ist) im Tag vorhanden ist.
Will man nun das Tag durch "normales" SRAM ersetzen, muss man:

• einen Speicherplatz für ein V-Bit je Cacheline vorsehen
• zusehen, dass im Reset alle V-Bits auf 0 oder auf 1 gesetzt werden

"Normale" SRAMs haben aber keinen RESET Eingang, ergo müsste man eine Logik basteln, die:

• auf einen /RESET angestossen wird
• den /RESET eigenmächtig auf low hält
• eine FOR Schleife über alle Adressen des nachgebildeten TagRAMs laufen lässt, die alle Datenwörter ausnullt
• und erst am Ende den /RESET wieder loslässt

[Lukas Frank]

Hatte auch damals mit PAK68/3 und PAK68/2 die Erfahrung das, dass 32bit breite TOS gegenüber dem 16bit nichts bringt ...

[Arne]

Kann das einer bestätigen oder widerlegen, was ich oben schrieb?

[guest522]

Kann das einer bestätigen oder widerlegen, was ich oben schrieb?

Im Moment nicht, sorry.....da muss ich erst mal in Ruhe drüber nachdenken. Der ganze Hardwarekram is leider ziemlich verschüttet in meiner alten Processing Unit.

[Arne]

Dann brauchst Du ein Update für Deine PU.
Mein Chef hat mir eine Beginnerschulung für FPGA/VHDL im November bewilligt. Mal sehen, was ich da an Wissen abstauben kann.

[Arne]

Diese 256Byte sind doch die gleichen wie beim MC68030, das bringt doch jede Menge an Geschwindigkeit ...

Zu dieser Aussage fand ich noch dieses zur Vorstellung des TT hier:

Da nützen leider auch die beiden internen Cache-Speicher des Prozessors (je 256 Byte) nicht sehr viel. Praxisnahe Studien an typischen Anwenderprogrammen haben jedoch gezeigt, daß ein Cache desselben Funktionsprinzips wie im 68030 erst ab etwa 32 KByte Größe einen guten Wirkungsgrad von etwa 88% erreicht. Je kleiner das Cache, desto progressiver sinkt der Wirkungsgrad. Was dem TT also fehlt, ist ein zusätzliches externes Cache von mindestens 16 KByte.

http://www.stcarchiv.de/stc1990/10_ataritt.php

[Arne]

Was mir bei Durchsicht des Mach16 Selbstbauartikels aufgefallen ist:
Nur ST-RAM bis $3FFFFF und ROM $FC0000-FEFFFF werden überhaupt gecacht. Somit fällt das komplette Alt.RAM + TOS 2.06 raus!

[joejoe]

Hatte auch damals mit PAK68/3 und PAK68/2 die Erfahrung das, dass 32bit breite TOS gegenüber dem 16bit nichts bringt ..

Tja, da das TOS 3.06  physikalisch und logisch  aber nicht in die 16bit ROM-Steckplätze der ST-Reihe passte, war es zumindest bis zum Booten eines alternativen OS ganz nützlich (oder überhaupt erforderlich, konnte man denn mit einer PAK und (gepatchtem) TOS 1.04 (also ab FCxxxx) oder TOS 2.06 ein TOS 3.06 nachladen??)

Zudem stellen die 4 ROM-Steckplätze eine geeignetet Möglichkeit dar, huckepack auf die ROMs aufgelötetes SRAM als (dann auch sehr schnelles) TT-RAM zu nutzen. Ich hatte damals meine PAK/2 mit 1MByte SRAM über den ROMs und einem modifizierten Adressdecoder-GAL gemodded. 

[1ST1]

Was bringt ein TOS 3.06 gegenüber einem 2.06 auf einem ST (selbst mit 68020/30 CPU) ?

[joejoe]

möglicherweise gar nix, dazu ist das alles zu lange her.
Aber wie sollte eine PAK/2 z.B. in einem 520ST starten? T1.04 ist nicht 68020 fest, TOS1.06 passt ebenso wie TOS 2.06 ohne Adapterkarten nicht auf das Board. Und ganz ohne ROMs bootet die Kiste nicht;)

Aber selbst wenn bereits ein TOS 2.06 eingebaut ist, sind die 32bittigen (ROM)-Sockel einer PAK/2 nicht unnütz, sondern können alternativ schnelles, 32bittiges SRAM aufnehmen. Nicht viel, wegen der beschränkten Speichergröße für 32pol. SRAMs, aber die können dann ja huckepack gelötet werden. Mit acht 128MB SRAMs erhält man dann 1MB TT-Fast-RAM, (mit korrekt dekodierten, handverdrahteten  CS-Leitungen und einer zusätzlichen R/W-Leitung).

   

[1ST1]

Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.

[Arne]

möglicherweise gar nix

Doch. Mint findet auf einem 030 mit TOS 3.06 bereits eine initialisierte PMMU vor. Und ich weiss nicht, wie Applikationen/TOS 2.06 bei einem 030 auf eine nicht initialisierte PMMU reagieren.

Aber wie sollte eine PAK/2 z.B. in einem 520ST starten? T1.04 ist nicht 68020 fest, TOS1.06 passt ebenso wie TOS 2.06 ohne Adapterkarten nicht auf das Board. Und ganz ohne ROMs bootet die Kiste nicht;)

Das geht mit zwei BootROMs ab $FC0000 in den LO-2/HI-2 (die, die an /ROM2 angeschlossen sind). Man braucht kein 2.06, um ein TOS auf der PAK "anzuschmeissen"
Die BootROMs habe ich irgendwo noch rumfliegen - denke ich.

[joejoe]

ja,klar. Hatte ich auch so, aber eben mit TOSx.06 auf der PAK.
Die Resetvectoren werden per Atari MMU immer noch aus dem Inhalt der originalen ROM-Sockel geholt.

Wenn ich den Überblick in diesem Thread nicht verloren habe, geht es aber hier auch nicht um die alte PAK/2 sondern um Überlegungen, wie ein 68020 "am besten" in eine ST Umgebung adaptiert werden könnte.

Bei solchen Überlegungen würde ich nicht auf die 32bit-ROM-Sockel zu verzichten, bloß weil der Geschwingkeitsgewinn bei ins RAM nachgeladenen OS-Teilen natürlich passe ist.

Ich wüßte eigentlich auch nicht, warum man einen 68020 statt eines 68030 nehmen sollte?
Die PAK/3 war schon toll.
 

[1ST1]

@Arne: Ich wiederhole nochmal...

Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.

[Arne]

@Arne: Ich wiederhole nochmal...

Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.

<loriot>
Ach!
</loriot>

[Arne]

Ich wüßte eigentlich auch nicht, warum man einen 68020 statt eines 68030 nehmen sollte?

Dann denk mal drüber nach!
Die Usermanuals zu 020/030 könnten hierzu dienlich sein.