atari-home.de - Foren
Allgemeines => Atari - Talk => Thema gestartet von: guest522 am So 18.10.2015, 23:28:53
-
Da ja einige auf nen 68020 scharf sind.....haben wir das übersehen?
http://www.labibleatari.fr/pages/Sommaire_en_ligne_Bible_Atari.html
Komplettes Projekt inkl. GALS
-
Kannst knicken dat Dingen.
Kein L2 Cache. Den Mini-L1 hat ein Komilitone mal als verlängerte Prefetchqueue bezeichnet. Hat er recht.
rpineau aus atari-forum.com hat wenigstens einen Slot für Alt-RAM geplant.
-
Ohne L2-Cache, das heißt das Ding entspricht der PAK68/2. Diese habe ich und finde die eigentlich ganz Ok. Der damit ausgestattete ST ist so schnell wie ein Falcon 030, wenn man vom DSP absieht.
-
Diese 256Byte sind doch die gleichen wie beim MC68030, das bringt doch jede Menge an Geschwindigkeit ...
In dem Projekt läuft die CPU mit 8Mhz, ist zwar nicht so doll aber hätte trotzdem gerne so eine 020er in meinem Mega ST.
(http://fr.meric.free.fr/Articles/Classes/booster020/tutoassemblage/DSC_0026.JPG)
-
Schade, sah nett aus....mir ist die Karte bisher noch nicht aufgefallen.
Wenn man das jetzt mit dem 68000-16MHz Cache Projekt aus der ST-Computer durchwürfelt, hat man doch alles was man braucht. Geschüttelt, nicht gerührt! ;)
Leider hat die ST-Computer Karte bei mir nie stabil funktioniert und ich habe keine Lust nochmal Wochen damit zu verbringen. ::)
-
PAK68/2 hatte ich auch mal, als die Platinen raus kamen. War maßlos enttäuscht von der Performance und habe sie dann ohne Wertverlust verkloppt.
Die 256 Byte L1 I-Cache scheinen nur deswegen etwas zu bringen, weil die Leute:
- auf einem >8MHz getakteten 020/030 testen
- übliche Benchmarks nehmen, die womöglich so kleine Codeschleifen nutzen, dass sie in die 256Byte reinpassen
Mit "Real-World" hat das nix zu tun. Man nehme einfach mal z.B. ScooterPCB auf einem 020/030 und einem Standard ST, lasse per Autorouter eine Platine routen und messe die Zeit.
Bei L2 kommt man leider immer wieder auf das Thema Tag-RAMs zu sprechen. Ich habe mir sogar mal dieses Buch http://www.amazon.de/Memory-Morgan-Kaufmann-Computer-Architecture/dp/0123229804/ref=sr_1_1?ie=UTF8&qid=1445244270&sr=8-1&keywords=0123229804 (http://www.amazon.de/Memory-Morgan-Kaufmann-Computer-Architecture/dp/0123229804/ref=sr_1_1?ie=UTF8&qid=1445244270&sr=8-1&keywords=0123229804) gebraucht aus den USA kommen lassen, da der Klappentext schreibt, der Autor beschreibe einen L2 Cache für 020. Tja, Scheibenhonig: der nutzt auch wieder IDT 71S74!
Es scheint aber auch ohne die Tag RAMs zu gehen:
die Hypercache030 von Pro-VME besitzt keine dedizierten TagRAMs (mit eingebauten Komparatoren).
Da sind nur acht 8Kx8 SRAMs drauf. Frag mich, wie die das machen.
(http://www2.pic-upload.de/thumb/28619397/HC030.jpg) (http://www.pic-upload.de/view-28619397/HC030.jpg.html)
Ist jemand in Amigakreisen unterwegs und kennt dort einige Speeder genauer diesbezüglich?
-
Wenn man das jetzt mit dem 68000-16MHz Cache Projekt aus der ST-Computer durchwürfelt, hat man doch alles was man braucht
Ja, nennt sich PAK68/3-020 und wurde 1993 veröffentlicht ;D
Von der hab ich sogar noch eine Leerplatine hier in der Schublade.
-
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.
-
Ich finde das wäre auf jedenfall eine Lowcost Variante. so wie es aussieht läuft die Karte 1:1 auf dem ST bus, scheint nur ein GAL drauf zu sitzen der die FPU und den Cache Steuert. Wenn man das ganze jetzt noch mit paar anderen dingen Kompiniert hätte man eine Schöne Karte. Der vorteil, Tos2.06 unterstützt die 68020 CPU und zur Not machts auch EmuTOS.
-
DAs GAL hat mit der FPU nichts zu tun, das mit einer FPU geht ab 020 von Haus aus. Die beiden 16V8 GALs sind für die Bussteuerung 68020<->68000 ...
-
Dann halt so, ist ja wurscht, fakt ist das nur ein GAL drauf ist und damit der Aufwand nicht so sehr groß sein wird.
-
Wäre wirklich interessant wie das mit dem Cache ohne TAG-Chache-Rams gemacht wird.
Ich habe hier massig Cache-Rams und einige 68EC020.
-
ich meine irgendwo in diesem Thread (http://www.atari-forum.com/viewtopic.php?t=27088&start=175) was darüber gelsen zu haben
-
ich meine irgendwo in diesem Thread (http://www.atari-forum.com/viewtopic.php?t=27088&start=175) was darüber gelsen zu haben
Dort steht aber:
It also require TAG Ram (IDT7174S-35 or equivalent) and add 2x 8bit 8K SRAM (or one 16bit if we can find one) .. this takes more space than 2 of the SRAM chip we plan to put on the card (or the expansion).
Mit letzteren beiden SRAMs meint er aber Alt.RAM. Evtl ist der expansion connector sogar TT-RAM kompatibel von der Belegung. Ich meine, dass es eine 96pol. VG Federleiste ist.
-
Ne, was ich meine ist, dass er irgendwo in diesem Thread davon redet das tag-ram mit Komparatoren nachzubilden. Ich finde blos die Stelle nicht mehr.
-
Es gab in den 90ern 386/486er Boards ohne TAG-RAM, oder wo man das nachrüsten konnte. Also es geht auch ohne, aber die Boards legten mit TAG RAM nochmal in der Performance beinahe merklich zu.
-
Es gab in den 90ern 386/486er Boards ohne TAG-RAM, oder wo man das nachrüsten konnte. Also es geht auch ohne, aber die Boards legten mit TAG RAM nochmal in der Performance beinahe merklich zu.
Sicher, dass Du das nicht verwechselst mit dem sog. Dirty-Bit SRAM? Das war IIRC dafür notwendig, um einen WT Cache auf WB umzustellen - was etwas Performance bringen kann.
-
Ne, was ich meine ist, dass er irgendwo in diesem Thread davon redet das tag-ram mit Komparatoren nachzubilden. Ich finde blos die Stelle nicht mehr.
gefunden (http://www.atari-forum.com/viewtopic.php?f=15&t=27088&p=263142&hilit=tag#p263142)
-
Ne, was ich meine ist, dass er irgendwo in diesem Thread davon redet das tag-ram mit Komparatoren nachzubilden. Ich finde blos die Stelle nicht mehr.
gefunden (http://www.atari-forum.com/viewtopic.php?f=15&t=27088&p=263142&hilit=tag#p263142)
Ich glaube ich verstehs langsam.
-
Ne, was ich meine ist, dass er irgendwo in diesem Thread davon redet das tag-ram mit Komparatoren nachzubilden. Ich finde blos die Stelle nicht mehr.
gefunden (http://www.atari-forum.com/viewtopic.php?f=15&t=27088&p=263142&hilit=tag#p263142)
Ich glaube ich verstehs langsam.
Dann erklär bitte mal. ;D
btw. Das verlinkte ATARI_HQ_1.zip ist wohl nicht mehr auf dev-docs. Hat das jemand von Euch?
-
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.
-
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 (http://www.sdsc.edu/~hocks/pc.ram.html)).
-
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."
-
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 ...
-
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
-
Hatte auch damals mit PAK68/3 und PAK68/2 die Erfahrung das, dass 32bit breite TOS gegenüber dem 16bit nichts bringt ...
-
Kann das einer bestätigen oder widerlegen, was ich oben schrieb?
-
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. ::)
-
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.
-
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 (http://www.stcarchiv.de/stc1990/10_ataritt.php)
-
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!
-
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.
-
Was bringt ein TOS 3.06 gegenüber einem 2.06 auf einem ST (selbst mit 68020/30 CPU) ?
-
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).
-
Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.
-
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.
-
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.
-
@Arne: Ich wiederhole nochmal...
Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.
-
@Arne: Ich wiederhole nochmal...
Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.
<loriot>
Ach!
</loriot>
-
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.
-
@Arne: Ich wiederhole nochmal...
Die PAK 68/2 hat 4 Sockel drauf, für ein 32 Bit breites TOS 2.06.
<loriot>
Ach!
</loriot>
Und warum machst du dir dann Beiträgelang Gedanken über alternative Bootroms und andere Methoden, um den Rechner aus dem Sumpf zu holen? TOS 2.06 drauf und gut ists, Kiste rennt.
-
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.
Kannst du uns Unerleuchtete, die die ~700 Seiten dazu noch nicht memoriert haben, an der Weisheit teilhaben lassen? Ich wüßte ja auch gerne, warum man einen 68020 statt 68030 nehmen würde. Denn der 030 hat a) nochmal separaten Cache und ist b) leichter in höheren Taktfrequenzen verfügbar. Von so Kleinigkeiten wie Burst Mode und so mal abgesehen.