|
|
10.10 PAK
PAK/68-3 - Informationen
Mit zunehmender Verbreitung der PAK/68-3 haeufen sich insbesondere
im Mausnetz Anfragen nach eine FAQ zu dieser Beschleunigerkarte. Damit
kann ich leider nicht dienen, allerdings habe ich die wichtigsten und
interessantesten postings zur PAK-3, seit den ersten Geruechten,
gesammelt und moechte sie hiermit allen Interessenten zugaenglich
machen.
Diese Sammlung entstand zunaechst aus purem Eigennutz, denn ich
habe mir die PAK-3 gleich nach der Veroeffentlichung des Projektes in
den c't's 10,11/91 und nach Erscheinen der Platine selbst aufgebaut.
Den zahlreichen 'Tips und Tricks' aus maus.sys.atari.hardware habe ich
es zu verdanken, dass ich jetzt stolzer Besitzer einer perfekt
funktionierenden 50 MHz PAK-3 incl. FPU bin, die ich nicht mehr missen
moechte.
Ich hatte es mal vor, aus diesem ganzen Sammelsurium einen besser
sortierten und lesbareren Extrakt, also eine echte FAQ, zu machen, in
die auch meine eigenen Erfahrungen mit diesem Projekt eingeflossen
waeren, aber leider fehlt mir inzwischen die Zeit hierzu. Das ist auch
der Grund dafuer, dass ich diese Sammlung jetzt veroeffentliche, denn
vielleich setzt sich ja ein anderer PAK-Fan daran.
Abbildung 1 - Pak 68k Beschleuniger
Ueberfluessige, falsche oder doppelte postings habe ich nach
Moeglichkeit nicht abgelegt, aber da ich nicht den ganzen Inhalt im
Kopf habe, kann der Text doch eine Menge Redundanz enthalten. Der aus
den beteiligten newsgroups bekannte "Rauschlevel" an nicht
verwertbaren Informationen spiegelt sich auch in dieser Sammlung
wieder.
Waehrend meiner PAK-3-Bastelei ist uebrigens das Programm
"FPU-Check" entstanden, das ich allen PAK+FPU-Besitzern
empfehle, die Probleme mit dem FPU-Betrieb haben oder vermuten, und
auch denen, die versuchen durch Tuning immer noch mehr aus dieser
Hardware herauszuholen.
* * NVDI GEM-Test V1.02 (c) 1990, 1991 by Sven & Wilfried Behne * * Betriebssystem : KAOS 1.42 vom 08.03.1991 * Referenzsystem : TOS 1.04 * CPU : M68020 * Blitter : nicht vorhanden * Textausgabe : 3565 % Linien : 991 % Rechtecke : 804 % Polygone : 869 % Kreise/Ellipsen : 1660 % Rasteroperationen : 894 % Attributfunktionen : 961 % Auskunftsfunktionen: 748 % ESCAPES : 835 % BIOS-Ausgabe : 472 % GEMDOS-Ausgabe : 2150 % AES-Objekt-Ausgabe : 2246 % Modula Dhrystone ergab: ca. 3200 (leider den exakten Wert nicht
aufgeschrieben)
Die Werte entsprechen in etwa, den Werten, die die neue PAK 68/3
schaffen wird bei 32 MHz auf einem normalen 8 MHz Atari. Die obigen
Werte (schon bei 24 MHz) verdankt die PAK dem besseren
"Datendurchsatz" auf die Hauptplatine. Obige Werte
entsprechen fast schon TT Performance! Hierzu vielleicht noch ein Wert
als Vergleich: Die Vektorisierung eines kleinen Gem-Image auf dem TT
mit Avant dauert 19 Minuten. Das Vektorisieren mit obiger
Konstellation dauerte 22 Minuten (0,86-facher TT).
Wie versprochen hier die Werte von der PAK 68/2 mit second level
Cache:
An den Timing der PAK, die der neuen PAK entspricht, wurde noch
ein wenig gefeilt. Die Werte sehen jetzt noch ein wenig besser aus,
als beim letzten posting.
Tex-Lauf mit LKurz: _2 min 38 sec_ Q-Index Version 2.1: (KAOS auf der PAK; NVDI) CPU memory : 495 register: 614 divide : 762 shifts :2628 TOS text : 778 string :4218 scroll : 331 dialog :2159 * NVDI GEM-Test V1.02 (c) 1990, 1991 by Sven & Wilfried Behne * * Betriebssystem : KAOS 1.42 vom 08.03.1991 * Referenzsystem : TOS 1.04 * CPU : M68020 * Blitter : nicht vorhanden * Textausgabe : 4001 % Linien : 1099 % Rechtecke : 1063 % Polygone : 984 % Kreise/Ellipsen : 1863 % Rasteroperationen : 1076 % Attributfunktionen : 1116 % Auskunftsfunktionen: 893 % ESCAPES : 940 % BIOS-Ausgabe : 578 % GEMDOS-Ausgabe : 2332 % AES-Objekt-Ausgabe : 3150 % Modula Dhrystone: 3944 Modula Juliamenge: 1350 sec. ...und während die Leute in Villariba noch vor ihrem
orginalen ST die Tastatur schruppen feiern die Leute in Villabacho
schon dank der Fettlöse...äh...Bitlösekraft der PAK...
:-)
GAL-Listing aus der c't
- Das Listing war für ein 22V10, bei dem Pin15 im Gegensatz
zum 20V8 als Eingang benutzt werden kann. Leider sind 22V10 recht
teuer und mit den verbreiteten Low-Cost-Brennern nicht zu
programmieren
PAK12_2d PAK 68/2: Addressdekoder SRAM Holger Zimmermann-Baedecker @ PE
Im Original ist ein 22V10 vorgesehen. Diese Gleichungen sind so geändert
worden, daß ein 20V8 verwendet werden kann. Pin16 des 20V8 so wegbiegen,
daß er an der Fassung vorbei ins Leere ragt, und mit Pin15 verbinden
(Drahtbrücke o.ä.).
09-04-92 aus P20_20.PDS zusammengestellt (war für 22V10)
10-04-92 entwanzt
17-08-92 PAK12_2a 512kB ab $D0.0000
01-10-92 PAK12_2b für 128kB (4* 32k*8)
08-04-93 PAK12_2c 512kB ab $0100.0000 (oberhalb 16MB, a24 statt a29)
11-06-93 PAK12_2d 512kb ab $E0.0000
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs3 (!cs für U8)
a19 |6 19| !cs2 (!cs für U9)
a20 |7 18| !cs2 (!cs für U10)
a21 |8 17| !cs0 (!cs für U11)
a22 |9 16| a0 (war a16, jetzt mit Pin15 verbinden)
a23 |10 15| a0x (hier liegt a0 an, aber Pin15 kann
a29 |11 14| a1 nicht als Input benutzt werden)
GND |12 13| a30
|________|
%ID
PAK12_2d
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a29
a30 a1 a0x a0 !cs0 !cs1 !cs2 !cs3 !dsack1 !dsack0 a17
%LOGIC
a0x.OE = GND;
a0.OE = GND;
cs0 = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a0 * !a1;
cs1 = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a1 * siz1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * a0 * !a1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a1 * !siz0;
'(war: !a1 * siz0)'
cs2 = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * a0 * !a1 * !siz0
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a1 * siz0 * siz1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a1 * !siz0 * !siz1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !a0 * a1;
'(war: !a0 * !a1)'
cs3 = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * a1 * siz1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * a0 * a1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * !siz0 * !siz1
+ !csp * as_20 * a23 * a22 * a21 * !a20 * !a19 * a0 * siz0 * siz1;
dsack0.OE = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19;
dsack0 = a23
+ !a23;
dsack1.OE = !csp * as_20 * a23 * a22 * a21 * !a20 * !a19;
dsack1 = a23
+ !a23;
%END
PAK12_20 Addressdekoder SRAM auf der PAK 68/2
Im Original ist ein 22V10 vorgesehen. Diese Gleichungen sind so
geändert worden, daß ein 20V8 verwendet werden kann. Pin16
des 20V8 so wegbiegen, daß er an der Fassung vorbei ins Leere
ragt, und mit Pin15 verbinden (Drahtbrücke o.ä.).
09-04-92 aus P20_20.PDS zusammengestellt (war für 22V10)
10-04-92 entwanzt
17-08-92 PAK12_2a 512kB ab $D0.0000
01-10-92 PAK12_2b für 128kB (4* 32k*8)
08-04-93 PAK12_2c 512kB ab $0100.0000 (oberhalb 16MB, a24 statt a29)
07-06-93 PAK12_2d 512kb ab $E0.0000
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17 (nicht benutzt)
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs3 (!cs für U8)
a19 |6 19| !cs2 (!cs für U9)
a20 |7 18| !cs2 (!cs für U10)
a21 |8 17| !cs0 (!cs für U11)
a22 |9 16| a0 (war a16, jetzt mit Pin15 verbinden)
a23 |10 15| a0x (hier liegt a0 an, aber Pin15 kann
(war a29) a24 |11 14| a1 nicht als Input benutzt werden)
GND |12 13| a30
|________|
%ID
PAK12_2d
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
a30 a1 a0x a0 !cs0 !cs1 !cs2 !cs3 !dsack1 !dsack0 a17
%LOGIC
a0x.OE = GND;
a0.OE = GND;
cs0 = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a0 * !a1;
cs1 = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a1 * siz1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * a0 * !a1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a1 * !siz0;
'(war: !a1 * siz0)'
cs2 = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * a0 * !a1 * !siz0
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a1 * siz0 * siz1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a1 * !siz0 * !siz1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !a0 * a1;
'(war: !a0 * !a1)'
cs3 = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * a1 * siz1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * a0 * a1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * !siz0 * !siz1
+ as_20 * !csp * a23 * a22 * a21 * !a20 * !a19 * a0 * siz0 * siz1;
dsack0.OE = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19;
dsack0 = a23
+ !a23;
dsack1.OE = as_20 * !csp * a23 * a22 * a21 * !a20 * !a19;
dsack1 = a23
+ !a23;
%END
Tja, die Gleichung in ein 20V8 brennen lassen und ausprobieren,
das war schnell getan! Und jetzt läuft also TOS 2.06. Das TOS
gerät etwa nach folgendem Schema beim Booten ins RAM:
Auf der PAK befindet sich ein freier Platz für ein
zusätzliches GAL womit z.B. die PAK und ein zusätzlicher
68000 umgeschaltet werden können (vergl. hierzu den entspr.
Artikel aus der CT Stichwort: PUK auf der PAK).
Auf der PAK hast Du die Möglichkeit mit Hilfe eines
Umschalt-GAL anstelle der PAK einen 68000er anzusprechen. Diese
Umschaltung gab es schon für die alte PAK und nennt sich PUK
(vergl. hierzu den entspr. Artikel aus der CT). Damit läuft dann
auch das Fossil Signum.
Zwei Versionen
Es soll zwei Versionen geben, PAK V20 und V30 mit 32kB Cache (oder
war es V020 & V030 ?). Variabler Takt, 3 bzw 5 GALs, Ausmaße
etwa PAK2. Geschwindigkeit > TT (die Version mit dem 68030 32 Mhz).
Der Bausatz würde sich ohne CPU und FPU etwa auf 150,- DM
belaufen.
Man nehme die aktuellen Preise für 1 * neue Platine PAK3 (so
etwa, wie der Preis der alten Platine (Angabe ohne Gewähr))
1 * 68020 oder 030 (je nach Platinenversion)
Die abgedruckten GAL-Gleichungen sind nicht identisch mit den
über Mailbox verbreiteten Files! Teilweise sind sogar Pins
vertauscht (Q1 und DSACK von U4).
Selbst wenn die richtigen Gleichungen vorhanden sind, ist es mit
der Maxon-Galprommer-Software nahezu unmöglich, daraus
funktionsfähige Jedecfiles zu machen.
Probleme gab es nach dem Zusammenbau eigentlich nur mit der
richtigen Jumpereinstellung (Was soll bloß "J11 Cache
Control... 2-3 Umschaltung über Schreibzugriff auf das ROM"
bedeuten?). Es kam zu äußerst merkwürdigen Fehlern
(vor allem beim DMA), wenn einer der Caches eingeschaltet war, die MMU
aber nicht aktiviert wurde. Deshalb unten noch die Jumperbelegung, so
wie es bei mir jetzt läuft.
Das QINDEX 1.5 (die letzte PD-Version) stürzt manchmal ab.
Dies liegt an dem Programm, nicht an der PAK! Unbedingt eine neuere
Version verwenden...
Nach anfänglichen Schwierigkeiten läuft die PAK jetzt
erstaunlich problemlos und fantastisch schnell, inzwischen mit dem
gepatchten TOS 3.06 und mit einem 36MHz Oszillator, was offenbar noch
keine Probleme macht.
Dank an Holger Zimmermann, der auch noch mitten in der Nacht
Jedec-Files verschickt und an Steffen Engel für den 3.06-Support.
Die abgedruckte Stückliste und auch der Schaltplan sind nicht
ganz vollständig, deshalb hier noch einige Korrekturen bzw.
Ergänzungen (sicher noch nicht vollständig):
- R27 existiert im Layout nicht
Pin 1 von J11 ist mit /CIOUT des Prozessors verbunden.
Und die Jumperbelegung bei meiner PAK (Änderungen
vorbehalten...):
J1 offen
Abbildung 2 - Pak 68k Beschleuniger
Ja, das geht.
Man muß für TOS 2.06 vorher nur die MMU initialisieren
wie es TOS 3.06 macht, um die virtuellen Treiber auf den ihnen
bekannten Zustand zu bringen.
Wir arbeiten an den nötigen
Patches/Zusatzprogrammen/Dokumentationen
PAK und externe ROMs
Die PAK läuft sehr wohl mit ROMs, die nicht auf der PAK
selbst sitzen. Also ganz normal: wenn eine TOS-Karte für ein 2.06
eingebaut ist, läuft die PAK damit.
TOS 3.06 gibt es unter anderem bei Hard und Soft auf 4 Eproms
25V010, soll allerdings 149.- DM kosten. Bei dem derzeitigen Preisen
für Megabit-Eproms schon fast Interessant.
Es gibt auch ein TOSPatch3.06V10 (oder so) liegt auch in der Maus
Berlin, damit kann man dann SEIN (und nicht das eines Freundes -
währe ja Betriebssystem Raubkopie!) TOS auslesen, patchen und
auch splitten. Nur das Splitten nach 4 Eproms habe ich noch nicht
hingekriegt, aber einige gute Tips aus dem Muasnetz die ich bei etwas
übriger Zeit dann ausprobieren werde.
Beim Betrieb mit TOS 2.06-Karten gab es erhebliche
Startschwierigkeiten. Liegt an der Kürze des Resetimpulses der
Beschleunigerkarte. Und hier mache ich der Herstellerfirma auch die
größten Vorwürfe, entgegen ihrer sonstigen guten
Firmenpolitik mit der heißen Nadel gestrickt zu haben. Die Karte
ist meines Erachtens NICHT ausgereift. Ein Gespräch mit Herrn
Neumann ergab, das H&N in den nächsten Wochen einen, na
nennen wir die Hardware mal Resetmanager, auf den Markt bringen
wollen, der mit den diversen Resetproblemem aufräumt und noch
einige zusätzliche Features enthalten soll.
In Geräten ohne besondere Einbauten läuft der HBS 640/28
zufriedenstellend und sicher.
Beim Betrieb mit der RAM-Erweiterung von M.Wevelsieb gibt es keine
RAM-Probleme (hier wurde die 10MB-Erweiterung in einem normalen ST
betrieben).
TOS 2.06 initialisiert die PMMU nicht. Damit ist es leider nicht
möglich, Treiber für virtuelles RAM zu benutzen. Ein
Patch-Programm für den Auto-Ordner, das die MMU-Initialisierung
nachholt, behebt dieses Manko, führt aber zu einem Problem: ein
Kaltstart führt zum Systemstillstand, da beim Löschen des
Speichers der MMU die Tabelle entzogen wird.
Desweiteren ist in TOS 2.06 keine vollständige
Unterstützung von FAST-RAM drin. Mit einem gepatchten TOS 3.06
ist dies jedoch kein Problem.
Übrigens werden die Infos zu 3.06 auf der PAK nicht in der
nächsten c't befinden, da wir lieber noch etwas länger
Erfahrung sammeln wollen. Ein Schnellschuß mit den
Betriebssystem-Patches, wie in der c't 9/92 möchte ich nicht
machen.
Ich gehe aber davon aus, daß für Heft 1/94 das ganze
komplett geklärt ist.
BTW: ich suche Interessierte, die die Patches testen. Willkommen
sind alle Besitzer von 030-Karten (PAK/3, ProVME) die auch wirklich
mitarbeiten.
Betasauger ('haben will, nie etwas melden') sind _absolut_
unerwünscht (einen freundlichen Gruß an alle meine
Betatester)
Ciao, Steffen Engel
Das ganze funktioniert so:
Die ersten 8 Bytes des ROM der Hauptplatine werden vom ST auf
Adresse 0 eingeblendet.
Diese Einblendung kann natürlich nicht die ersten Bytes der
ROMs auf der PAK einblenden.
In diesen ersten Bytes stehen der Stack-Pointer und die
Reset-Adresse, die der Prozessor zur Initialisierung anspringen soll.
Dabei gibt es zwei Möglichkeiten:
Wenn man nun auf der PAK EPROMs mit 1 MBit benutzt, so findet sich
auf E40000 keine Spiegelung des TOS, was natürlich dazu
führt, daß der Rechner nicht hochkommt.
Die PAK kann zum ersten so betrieben werden, sodaß sie der
alten PAK entspricht, d.h. man braucht (um upgraten zu können)
sich nur die neue Platine für den 68020 zu kaufen.
Wenn das einem dann auf die Dauer zu langsam wird, kann man mit
Hilfe von 4 SRAMs sowie 2 TAG-RAMs die PAK mit einem Cache ausstatten.
Wer dann, in beiden obigen Ausbaustufen zusätzlich einen Copro
braucht, dem steht auch nichts entgegen. Selbiges hängt nur vom
Geldbeutel des einzelnen ab. Wem das immer noch zu langsam ist, der
kann ja sein Mainboard auf 12 MHz hochfahren mit Hilfe der
Umbauanleitung aus der ST-Computer 9/92 bzw. 10/92. Die PAK
funktioniert einwandfrei auf 24 MHz auf einem 12 MHz Board. Ob das
auch bei der HBS so ist, mag ich bezweifeln.
Ich finde die PAK wesentlich modularer. Und wer weis, vielleicht
wird es ja noch die eine oder andere Erweiterung für dieses
wunderbar modulare System geben. :-))
c't 11/93 enthält auf Seite 222 ist der Bericht
"Doppel-PAK" Beim ersten fluechtigem Lesen ist mir jedoch
der 32Kilobyte grosse Second-Level-Cache ins Auge gefallen.
Laut Ankuendigung kommt in der naechsten Ausgabe nur noch etwas
ueber die Umschaltung 68000/68030.
Soeben haben wir hier eine PAK/3 mit 68020-32 und eine
Volksfarben-Grafikkarte laufen gehabt und es war einfach genial! Die
Geschwindigkeit bei Grafikausgabe ist sehr gut, sie liegt nur knapp
unter dem Niveau eines TT mit FastRAM.
Zum Thema Einbau: die VoFa kommt genau wie bei der alten PAK
entweder in den MegaBus oder in den Prozessorslot der PAK und es muss
noch ein Widerstand von ca. 300 Ohm (heftig, aber wahr) zwischen R/!W
des Prozessors und 5 Volt gesetzt werden. Dann funkt alles klaglos.
Der Turm in einem Mega ST bei Anschluss der VoFa per MegaBus wird
dann zwar langsam aber sicher ziemlich schwindelerregend, aber ich
glaube, da laesst sich dann auch noch was machen, wenn man ein
VoFa-Adapter mit Prozessor-Sockel verwendet.
Allerdings ist noch etwas negativ aufgefallen: Mag!X 2.0 wollte
nicht mit der VoFa und der PAK/3 gleichzeitig arbeiten. Warum, weiss
der Geier. Eine entsprechende Mail an Wilfried Behne ist natuerlich
unterwegs.
So, nun zu den Benchmarks:
GEM Bench v3.10 ½ Ofir Gal 5.8.93 ============================================ ST TOS 2.06, MiNT not present Blitter not present, NVDI 2.50 present Video Mode = 1024 * 768 * 256 Colours LineF FPU installed Run and Malloc from STRAM Reference = ST, No Blitter + FPU PAK/3 mit 68020/32 und VoFa ============================================ GEM Dialog Box: 1.640 515% VDI Text: 1.150 1165% VDI Text Effects: 2.025 1160% VDI Small Text: 0.920 1083% VDI Graphics: 3.575 724% GEM Window: 1.255 311% Integer Division: 0.775 1160% Float Math: 0.120 320% RAM Access: 0.375 841% ROM Access: 0.455 693% Blitting: 7.145 163% VDI Scroll: 11.025 119% Justified Text: 4.050 339% VDI Enquire: 0.520 510% ============================================ Average: 650% Graphics: 608% CPU: 753%
wir haben jetzt auch eine PAK3 hier und mal angefangen ein wenig
zu spielen...
Dazu nun unsere ersten Erkenntnisse:
a) Bei manchen Leuten ist ein 330Ohm Pullup an r/w nötig.
b) Mit ausgeschaltetem Cache läuft es miesest -> Cache
einschalten.
c) Wie auch schon im READ-ME erwähnt: Dran denken, beim
Bausatz bzw. der Leerplatine die Leitung von GAL B Pin 5 die im Moment
an BG liegt aufzutrennen und an BGACK zu legen.
d) Eine große Hilfe war auch der Tip von Andreas Richter @
H:
e) Anscheindend hängt es auch noch vom Betreibssystem ab :-(
Warum weiß keiner. Aber anscheinend sind die Ergebnisse mit
TOS3.06 recht gut... Kann übrigens mal einer einen Patch machen,
daß das TOS3.06 den Quarter-Screen- Buffer dynamisch anlegt? Das
Teil frißt unter 256 Farben Speicher bis zum abwinken... Bei
TOS1.04 war das noch nicht so schlimm...
f) Wenn mal GAL A (!) um folgendes erweitert:
*PINS
LG1 15,
*BOOLEAN-EQUATIONS
/lg1= /lds & uds & a23 & a22 & /a21 & a20 & /a19 & /a18 & /a17 & /a16 +
/lds & uds & a23 & a22 & /a21 & /a20;
Dann geht es um einiges besser... Natrülich muß die
Leitung von GAL B zum LG1 umgelegt werden.
Das ist nicht die 100% Lösung... Aber es ist vor allem ein
recht einfacher Patch, der sich auch schon an vorhandener Hardware
vollziehen läßt.
Wir sind an völlig anderen Gleichungen dran, welche viel mehr
synchron machen und deshalb stabiler laufen werden, aber auch
gleichzeitig mehr Waits reinhaun (Damit werden wir halt leben
müssen). Die Änderung wird jedoch so heftig sein, daß
dies dann gleich in Verbindung mit einer neuen Platine geschieht und
das kann noch ein bis zwei Monate dauern...
Gerade habe ich von mw-electronic einen Prospekt zur PAK 68/3 mit einem Leistungsvergleich zum TT und Falcon erhalten. Laut Angaben wurden nachfolgende Werte mit GEM Bench v3.10 ermittelt. ------------------------------------------------------------------------- Rechner: 1. 2. 3. 4. 5. ------------------------------------------------------------------------- GEM Dialog Box: 167% 200% 141% 168% 625% VDI Text: 115% 146% 144% 127% 1230% VDI Text Effects: 181% 229% 178% 201% 1607% VDI Small Text: 160% 208% 143% 148% 1484% VDI Graphics: 297% 360% 256% 392% 1770% GEM Window: 122% 127% 107% 157% 310% Integer Division: 582% 1168% 582% 1168% 1303% Float Math: 213% 334% 0% 427% 366% RAM Access: 453% 819% 293% 485% 956% ROM Access: 463% 779% 277% 453% 888% Blitting: 52% 72% 160% 107% 129% VDI Scroll: 103% 137% 151% 149% 290% Justified Text: 114% 132% 150% 134% 350% VDI Enquire: 213% 279% 157% 244% 610% -------------------------------------------------------------------------- Average: 231% 356% 210% 311% 851% Graphics: 152% 189% 158% 182% 840% CPU: 427% 775% 384% 633% 878% 1. PAK68/3-020 mit 68020-16MHz und 68882-16MHz 2. PAK68/3-030 mit 68030-32MHz und 68882-32MHz 3. Falcon 030 4. TT 030 5. PAK68/3-030 mit 68030-36MHz, 68882-36MHz und NVDI 2.5 Als Referenz dient in allen Fällen ein Mega ST mit Blitter und FPU in der ST-Hoch-Auflösung. Interessant wären in diesem Zusammenhang noch die
entsprechenden Werte für die Medusa und dem Eagle (sofern hier
schon ein Prototyp existiert).
Meine PAK 68/3 mit einem 68020 ist schneller als ein TT, der
ebenfalls nur mit ST-RAM ausgerüstet ist. Um allen Fragen
vorzubeugen: Die PAK ist gleich schnell zu einem TT mit ST-RAM auf
einem 8 MHz ST und vierfachen Boardtakt, also 32 MHz. Bei einem 12 MHz
Board und 48 MHz auf der PAK ist die PAK eindeutig schneller als ein
TT mit ST-RAM. Dies gilt sowohl für eine PAK mit 68020 als auch
für eine PAK mit 68030. Das ist das eine!
Wenn man aber jetzt einen TT mit Fast-RAM mit der PAK vergleicht,
dann sollte man aber auch von einer PAK mit 68030 ausgehen.
Zusätzlich sollte die PAK dann ebenfalls Fast-RAM haben. Sonst
wird der Vergleich unfair! Da das aber noch nicht spruchreif ist,
schweige ich zu diesem Vergleich! Wenn einer hier was sagen sollte,
dann sicher nicht ich, sondern in erster Linie ein fähiger Mensch
mit den Initialen S.E. oder ein noch fähigerer seiner Gattung
nämlich H.Z.!
Du mußt Dir erstmal darüber klar werden, daß die
Tatsache allein, daß ein Prozessor einen 32-Bit breiten
Adressbus hat, nicht bedeutet, daß er auch einen 32-Bit breiten
Adressraum anspricht. Ich habe gerade mal die GAL- Gleichungen der
PAK/2 überflogen, und so wie ich das sehe, hat die z.B. nur einen
Adressraum von 16 MB, d.h. 24-Bit. Damit funktioniert TOS 2.06 prima,
genauso wie mit jedem anderen Speeder-Board, daß einen
Adressraum von 16 MB hat.
Sobald es aber darüber hinaus geht, wird es kritisch! Man
werfe einen Blick auf die Exception-Vektoren und stelle fest,
daß dort z.B. für den BUS-ERROR die Adresse 0x02E010E2
steht. Huch? Aber mein TOS liegt doch im Bereich 0x00Exxxxx, oder?
Genau! Aber TOS 2.06 übergibt im obersten Byte der Adresse die
Anzahl der Bomben, die es zeichnen soll. Bei einen 16 MB-Adressraum
ist das soweit ok, aber wehe man hat mehr!
Wenn das nicht bedeutet, daß TOS 2.06 _nicht_ 32-Bit fest
ist, was bedeutet es dann?
Vergleichsliste für Rechnerbenchmarks:
Die Tests wurden mit GemBench durchgeführt, als
Referenzsystem wurde ein ST mit 8 MHz ohne Blitter und FPU angegeben.
Die Referenzauflösung ist 640 mal 400 in zwei Farben. Bei den
Farbtests ist natürlich eine andere Auflösung eingestellt,
diese ist aber (mit Ausnahme des Falcons meines Wissens nach) nicht
relevant, da GemBench ja eh in einem Fenster abläuft. Ich hoffe,
beim Zusammenfassen der Tests keine Fehler gemacht zu haben, falls
doch -> Mail an mich...
Wer meint, daß noch Rechner fehlen, kann mir ja seinen Bench
- wenns geht schon in dieses Format gebracht - schicken. Als
Referenzsystem bitte auf jeden Fall einen ST ohne FPU und Blitter
wählen, da wir sonst nichts vergleichen können! Interessant
sidn vor allem noch Grafikkarten mit anderen Treibern als NVDI. Tests
von Rechnern ohne Grafikkarte und ohne NVDI halte ich eher für
nutzlos, da sie keine Vergleiche mit Rechnern mit Karten erlauben...
Rechner mit Grafikkarte in 640*400*2 Farben: Rechner: Medusa PAK/2 PAK/2 Prozessor: 68040 68020 68020 Takt: 64 MHz 16 MHz 16 MHz Betriebssystem: TOS2.06 n.n. Magix2.0 Blitter: keiner keiner keiner VGA-Karte: ET4000 ET4000 ET4000 Treiber: NVDI2.5 NVDI2.5 NVDI2.5 Quelle: Stephan Andreas Andreas Skrodzki Fries Fries ==================================================== GEM Dialog Box: 2414% 797% 625% VDI Text: 7245% 1836% 1823% VDI Text Effects: 6911% 1482% 1464% VDI Small Text: 1993% 1038% 1022% VDI Graphics: 2490% 778% 774% GEM Window: 1087% 407% 188% Integer Division: 1913% 574% 560% Float Math: 350% 145% 142% RAM Access: 852% 213% 213% ROM Access: 852% 394% 213% Blitting: 871% 424% 419% VDI Scroll: 755% 598% 591% Justified Text: 1635% 486% 481% VDI Enquire: 3540% 229% 225% ==================================================== Average: 2330% 671% 624% Graphics: 2894% 807% 761% CPU: 991% 331% 282% Rechner mit 256 Farben: Rechner: Medusa Prozessor: 68040 Takt: 64 MHz Betriebssystem: TOS2.06 Blitter: keiner VGA-Karte: ET4000 Treiber: NVDI2.5 Quelle: Stephan Skrodzki ============================== GEM Dialog Box: 884% VDI Text: 1729% VDI Text Effects: 1966% VDI Small Text: 2693% VDI Graphics: 1042% GEM Window: 525% Integer Division: 1913% Float Math: 350% RAM Access: 852% ROM Access: 841% Blitting: 257% VDI Scroll: 155% Justified Text: 493% VDI Enquire: 3792% ============================== Average: 1249% Graphics: 1353% CPU: 989% Rechner ohne Grafikkarte, aber mit NVDI: Rechner: Medusa TT030 TT030 PAK/3 Falcon Prozessor: 68040 68030 68030 68030 68030 Takt: n.n.(50?) 32 MHz 32 Mhz 36 MHz 16 MHz Betriebssystem: TOS2.06 Magix2.0 TOS3.06 n.n. TOS4.01 Blitter: keiner n.n. n.n. n.n. ja VGA-Karte: keine keine keine keine keine Treiber: NVDI2.03 NVDI2.5 NVDI2.5 NVDI2.5 NVDI2.5 Quelle: Thorsten Michael Michael Michael Martin Floeck Thurm Thurm Thurm Bartsch ========================================================================== GEM Dialog Box: 1550% 1527% 1122% 625% 443% VDI Text: 7245% 1876% 1876% 230% 1495% VDI Text Effects: 5662% 2424% 2404% 607% 1479% VDI Small Text: 3558% 1622% 1502% 484% 1193% VDI Graphics: 2097% 1700% 1629% 770% 1006% GEM Window: 807% 576% 340% 310% 209% Integer Division: 1913% 1168% 1168% 303% 580% Float Math: 350% 427% 427% 366% 3237% RAM Access: 830% 344% 344% 956% 293% ROM Access: 830% 489% 492% 888% 277% Blitting: 890% 150% 151% 129% 203% VDI Scroll: 885% 465% 465% 290% 375% Justified Text: 1327% 455% 442% 350% 312% VDI Enquire: 2794% 596% 663% 610% 390% ========================================================================== Average: 2195% 987% 930% 851% 820% Graphics: 2681% 1139% 1059% 840% 710% CPU: 980% 607% 607% 878% 1096% Rechner ohne Grafikkarte und NVDI: Rechner: PAK/3 TT030 PAK/3 Falcon Prozessor: 68030 68030 68020 68030 Takt: 32 MHz 32 MHz 16 MHz 16 MHz Betriebssystem: n.n. n.n. n.n. n.n. Blitter: n.n. n.n. n.n. ja VGA-Karte: keine keine keine keine Treiber: keiner keiner keiner keiner Quelle: Michael Günter Michael Günter Thurm Bramsche Thurm Bramsche =============================================================== GEM Dialog Box: 200% 168% 167% 141% VDI Text: 146% 127% 115% 144% VDI Text Effects: 229% 201% 181% 178% VDI Small Text: 208% 148% 160% 143% VDI Graphics: 360% 392% 297% 256% GEM Window: 127% 157% 122% 107% Integer Division: 1168% 1168% 582% 582% Float Math: 334% 427% 213% 0% RAM Access: 819% 485% 453% 293% ROM Access: 779% 453% 463% 277% Blitting: 72% 107% 52% 160% VDI Scroll: 137% 149% 103% 151% Justified Text: 132% 134% 114% 150% VDI Enquire: 279% 244% 213% 157% =============================================================== Average: 356% 311% 231% 210% Graphics: 189% 182% 152% 158% CPU: 775% 633% 427% 384%
Wie ich schon geschrieben hatte: die FPU auf der PAK wird derzeit
leider noch mit Waitstates betrieben - warum auch immer.
Schon klar, daß Du das meintest, nur ist das Problem ganz
einfach:
-abgesehen von Blitting und Raster-Fills ist der Blitter langsamer
als die PAK
Moment mal, würde da nicht der Second-Level-Cache ganz
fürchterlich zuschlagen? Ich habe da noch zwei andere Theorien
anzubieten:
1. Das GAL für die CS-Berechnung ist zu langsam (ist zwar bei
15ns unwahrscheinlich, aber ein Versuch mit nem 12er oder 10 Gal
wäre es mir Wert (wenn ich denn ne PAK hier hätte)
2. Der Takt für die CPU wird beim TT durch ein Logikgatter
gejagt. Dadurch entstehen leichte Verzögerungen, die u.U. das
Timing zur FPU verbessern können (wenn die FPU normalerweise eine
Idee zu spät das Ergebniss liefert, so daß die CPU erst
einen Zyclus später auf das Ergebniss zugreifen kann, kann die
Verzögerung hier hilfreich sein). Man könnte Versuchen, den
Takt zwischen FPU und CPU auf der PAK zu invertieren. Da die FPU
asynchron eingebunden ist, dürfte das an der Lauffähigkeit
der PAK nichts ändern. Wohl aber am timing zwischen FPU und CPU.
Entweder wird es günstiger, oder schlechter. Da ich keine
Timingdiagramme der IC's habe, kann ich keine worst-case Betrachtung
durchführen, sondern das Ergebniss nur empirisch ermitteln, wenn
denn die PAK endlich den Weg in meinen Rechner gefunden hat!
Wie gesagt, beides sind nur Theorien. Da könnten allenfalls
die Entwickler der PAK etwas zu sagen!
Da der Schaltplan in der c't 11/93 abgedruckt ist (S.228), kann
man ja eigentlich sehen, ob die FPU memory-mapped oder per LineF
eingebunden ist:
Da ist an der FPU die Leitung /CS = Chip-Select. Diese Leitung
führt auf der SFP-004 von ATARI (soweit ich mich entsinne) an ein
paar TTL-Chips, die dafür sorgen, daß bei der Adresse
$FFFA40 und den darauffolgenden auf die Steuerregister der FPU
zugegriffen wird.
Auf der PAK ist das anders! Das /CS-Signal wird als /FPUCS
bezeichnet und in GAL 6 (U6) abgehandelt. Die GAL-Gleichung von U6
(Atari ST) ist auf S. 226 zu finden: /FPUCS geht auf LOW, wenn a19,
a18, a16 Low und a17 High ist. Außerdem muß J3 gesetzt
sein, damit die Leitung nicht über RN1(2) auf High geht.
Außerdem müssen fc1 und fc0 Low sein.
Nun zu den interressanten Sachen. Der Einbau erfolgte relativ
problemlos. Adapterplatine rein, PAK drauf und fertig. Leider reicht
der Platz fürs Netzteil dann nicht mehr. Bei einer entsprechenden
Bauweise des SCC-DIL-Adapters sollte es aber möglich sein das
Netzteil mit im Gehäuse unterzubringen. Eine Taktung von 32 MHz
verkraftete der Rechner in dem 2-3 Stunden Test ohne Bombemwürfe.
Mit 40 MHz startete er nicht mehr vernünftig durch und blieb
schon in der Bootphase hängen. Vielleicht wären durch
geringe Änderungen am Mainboard auch dieses zu beseitigen.
Vorhandener Rechner ist ein Mega STE mit Netzteil -001, 4MB Speicher,
RSVE auf MODEM 1. Bei den GEMBENCH Tests waren nur der AHDI V6.061 und
NVDI V2.5 im Speicher. Bei den TeXläufen und Modemtests habe ich
meine tägliche Konfiguration benutzt ( ca. 1 MB an Autoprogs und
ACC). Teilweise sind auch Systembremser dabei wie z.B. DCF-Time V1.2.
Ich habe anscheinend ziemlich heftige Probleme bei
Plattenzugriffen. Jedenfalls hängt sich der Rechner dauernd beim
Booten und Starten von Programmen auf, wenn die VoFa drin ist.
Außerdem kommt manchmal folgende Meldung "Ihr Ausgabemedium
nimmt keine Daten an", oder so ähnlich. Die Platte hat dann
die Diode auf Daueranzeige geschaltet und hängt, während ich
auf dem Rechner dauernd diesen Alert bekomme.
Weiß vielleicht jemand, was ich hier noch ausprobieren
könnte, um die Sache ans Laufen zu bringen? Austauschen der
Bustreiber hat nichts gebracht, weder F, noch ALS, noch HCT-Typen
bringen eine Verbesserung. Auch ein Austausch des DMA-Chips hat mich
noch nicht weitergebracht, allerdings konnte ich nur zwei verschiedene
IMP-Typen testen.
Aber ansonsten muß ich mich meinen Vorrednern
anschließen, die PAK ist einfach wahnsinnig schnell, obwohl sie
bei mir "nur" mit den originalen 32 MHz läuft. Da macht
das Arbeiten wieder richtig Spaß.
1. Ab und zu meint mein Netzteil sich verabschieden zu
müssen: Symptome: Lüfter bleibt stehen, Tastatur-LED geht
aus, Monitor wird schwarz, ich tippe auf einen Spannungszusammenbruch
der entgültigen Art ;-). Nur: Warum? Jedenfalls gibt das Netzteil
vorher kurze Pfeiftöne von sich, ein Kurzer konnte nicht gemessen
werden. Kontaktschwäche (Leerlauf)? Dann sollte ich mal das
Netzteil wechseln!
2. Die PAK rennt nicht auf 32 MHz. Weder mit der TOS
Extension-Karte von Artifex, noch mit selbsgebrannten (von PINATUBO
gesplittetem) TOS auf der PAK. Da ich ein 150 ns EPROM zwischen den
120ern habe, ist J6 auf 1-2 gejumpert!
Ab und an spinnt auch mein RSVE, aber das werde ich wohl mit einem
Abschirmkäfig (oder einem anderen Ort) beheben können! Das
ist reproduzierbar. Punkt 1 ist ein reiner Zufallsgenerator.
Ach ja, manchmal Bootet die PAK auch nicht unter 16MHz, das ist
aber seltener und durch längeres Warten zu beheben!
Jetzt mal meine aktuelle Konfig:
J1 geschlossen
Jetzt kann ich natürlich auch experimentieren, aber vielleicht hat einer ne Idee, was hier falsch läuft? Ach ja, ich habe TOS 2.06 mit ein paar Patches auf der PAK und ohne Patches auf der Artifex-Karte im Rechner. Der Proz wird etwa 40 Grad warm! Antworten vielleicht besser als PM, da sie 1. Untergehen könnten (ich habe im Moment nicht so furchtbar viel Zeit), 2. Nicht von allgemeinem Interesse sein dürften. Ich poste dann den Gewinner, dessen Idee meine PAK zu 32 MHz verhilft! Ach ja, die Bustreiber sind selbstverständlich 'F'-Typen...
Typisches Symtom: Plattenzugriffe werden quälend langsam, nach dem Zugriff bleibt die Busy-LED der Festplatte an. Abhilfe: AHDI 5.xx oder 6.xx benutzen, die laufen problemlos. Oder
auf TOS 3.06 für die PAK warten.
Mittlerweile AHDI 6.06, da der HuSHI Probleme machte (wurde
langsam, bootete gar nicht, erkannte die Platte nicht, usw.).
Allerdings brachte erst der Wechsel des DMA-Chips eine endgültige
Verbesserung, leider erst nachdem ich mir meine Bootpartition und
einige Programme hoffnungslos zersemmelt habe. Was mich nur wundert,
ist, daß sowohl VoFa als auch PAK alleine wunderbar mit dem
alten IMP-DMA-Controller arbeiten.
ICD Advantage Plus.
Das habe ich gemerkt. HuSHI lief definitiv nicht, ICD lief bei mir
nur manchmal (das kann aber auch an dem alten DMA-Chip gelegen haben)
und AHDI läuft mittlerweile super.
Typisches Symtom: Plattenzugriffe werden quälend langsam,
nach dem Zugriff bleibt die Busy-LED der Festplatte an.
Genau das ist bei mir auch anfangs mit dem AHDI vorgekommen,
zusammen mit dem Alert "Ihr Ausgabegerät empfängt keine
Daten". Beseitigung nur durch Austausch des schon mehrfach
erwähnten DMA-Chips.
Nachdem die PAK 3 seit nunmehr einigen Tagen ziemlich ordentlich
läuft (welch eine Geschwindigkeit) hat sich nun doch ein kleines
Problem herauskristalli- siert, vielleicht kann einer von Euch etwas
damit anfangen und mich auf die richtige Spur bringen:
Es kommt bei Benutzung der FPU häufiger vor, daß ein
Programm (passiert mit allen Programmen, die die FPU nutzen) mit 11
Bomben (Line F Protocol Error) abstürzt. Dasselbe Programm
läuft aber mitunter auch einwandfrei durch, es läßt
sich keine Systematik (thermische Abhängingkeit,
Softwareumgebung) feststellen.
Daten: PAK3/30 auf 32 MHz, Prozessoren sind XC68030RC50B und
XC68882RC50A. Sind bei diesen Masken Probleme bekannt? Das System
läuft z.Z. unter TOS 2.06 / MagiX! 2.0.
Ansonsten arbeitet das System absolut einwandfrei. Die FPU lief
auf der PAK2 im übrigen auch ohne Fehler mit 40 MHz.
Ersten habe ich einen Fehler im Adressdekoder GAL (V6_STC1)
gefunden. Dort wird der Bereich ab $E40000 nach $FC0000 eingeblendet
und nicht, wie es sich gehoert, der TOS-Anfang ab $E00000. Als Folge
dessen bootet meine PAK nicht mit den auf der PAK vorhandenen TOS 2.06
(512kB lang) Eproms. Zweitens scheint die PAK trotz der in der c't
12/93 beschriebenen Modifikationen nicht mit der 12MHz-Erweiterung
zusammenzulaufen. Wenn ich den L2-Cache allerdings abschalte laeuft es
einigermassen. Drittens scheint die PAK Schwierigkeiten mit 48MHz zu
haben, selbst wenn ich den L2-Cache abschalte laeuft die PAK instabil.
Insbesondere hat die PAK bei aktivierter 12MHz-Erweiterung
Schwierigkeiten.
Zu erstens wuerde es mich freuen, wenn in naechster Zeit
diesbezueglich korrigierte GAL-Jedecfiles erscheinen koennten (mit dem
LCI-Format kann ich nichts anfangen). Zu zweitens waere es schn, wenn
man mit anderen PAK-Usern mal Erfahrungen austauschen koennte. Da ich
in keinen Netzen vertreten bin, wuerde es mich freuen, wenn hier
Erfahrungsberichte, Tips etc. diesbezueglich veroeffentlich werden
koennten.
Danke fuer die Nachricht. Der zustaendige Redakteur, Carsten
Meyer, ist allerdings bis zum 3. 1. in Urlaub. Ich kann daher nur sehr
oberflaechlich antworten:
Die wichtigste Information haben Sie vergessen: In welchem Rechner
betreiben Sie die PAK, mit welchem Chipsatz (Baujahr, IMP-Chips,
Modell)?
Wir haben einige Hinweise von Atari-Anwendern, wonach die PAK
einwandfrei laeuft, aber auch Gegenteiliges in folgendem Punkt: In
aelteren 520 ST und 260 ST soll das TOS 2.06 auf der PAK nur gebootet
haben, wenn als GAL P4 ein 20-ns-Typ eingesetzt worden ist. Weder 15
ns noch 25 ns soll funktioniert haben. Das deutet wieder mal auf ein
miserables Timing-Problem hin. Zugleich scheint es mir aber ein Beleg
dafuer zu sein, dass Ihre Fehleranalyse nicht zutreffen kann. cm wird
das nach seiner Rueckkehr ueberpruefen.
Uebrigens ist der Autor der 12-MHz-Modifikation auch unter den
PAK-Anwendern, diesbezuegliche Probleme sind also sicher loesbar. Ob
sie allerdings tatsaechlich 48 MHz schafft, moechte ich bezweifeln.
Waere 24 MHz nicht auch schon ganz nett...?
Selbstverstaendlich veroeffentlichen wir eventuelle Ergaenzungen +
Berichtichtigungen in der entsprechenden Rubrik. Zur Aufnahme von
Kontakten mit "Leidensgenossen" bieten wir schon seit langem
unsere Club-Rubrik an. Bitte senden Sie uns einen entsprechend
formulierten Text, der Abdruck ist natuerlich kostenlos.
Gruss
Pak/3 Takt > 32MHz
Da in Berlin 3 Paks mit jeweils 48(CPU 50MHz), 50(CPU 33MHz mit
KK) und 56.6MHz(50 MHz) laufen, und mich einige PMs bezüglich des
Umbaus erreichten, werde ich nicht jede PM einzeln beantworten.
Alle diese Rechner laufen mit 12MHz auf dem Mainboard. Es hat sich
erwiesen, die Terminierung der Leitungen, wie sie im 12MHz Umbau
beschrieben war, zu übernehmen. Näheres kann man aus der St
Computer übernehmen. In meinem Rechner sind die 244 und 373 als F
Typen und in den anderen Rechnern als ACT. Eine allgemeingültige
Aussage, wann welcher Typ läuft, kann man nicht sagen, sondern
nur ausprobieren. Sobald die CPU schneller als 32MHz wird, läuft
die FPU mit keinem höheren Takt mehr. Es gibt 11 Bomben. Dieses
Problem wird aber wahrscheilnlich diese Woche noch gelöst. Die
Gals sind 10ns Typen, die Tags 20ns Typen von Segor und die Srams sind
12ns Typen. Roms habe ich nicht auf dem Board, da ich mit Mag!x
arbeite. Die von Robert angesprochenen Probleme bezüglich des CPU
Caches konnte ich leicht nachvollziehen und wahrscheinlich beseitigen.
Am Anfang hatte ich eine leere Partition genommen und mit Kobold,
so ca 1500 Dateien kopiert und mit Treechk verglichen. Es kam zu ca
10% Fehlern. Diese Tests liefen unter 2.06. Als ich ein PMMU Init
Programm gestartet hatte, das die entsprechenden Bereiche als nicht
"cachebar" markierte, so gab es bei mir keine DMA Probleme
mehr. Das Gleiche ist auch unter Mag!x, da dort auch die PMMU
initialisiert wird. Wenn man nun schon den 12MHz Umbau hat, so kann
mon den Takt von dem 48MHz Quarz abnehmen und über eim 74AC14 der
Pak zuführen. Weitere Einzelheiten bezüglich der FPU kommen
im laufe der Woche.
Ach je, Sysinfo bei 56.6MHz zeigt 1000% CPU Speed und bei 50MHz
immerhin noch 835%. Man kann mit arbeiten. :-) Unter Winx kann man die
Fenster in Echtzeit aufziehen, ohne das es flackert.
PAK FPU bei 56.66MHz
Wie gesagt, Cache-Rams 15ns, Tag-Rams 20ns, Epromms (noch) 120ns
KAOS 1.42, alle GALs 10ns. TTLs auf der PAK ACT541 und auf dem Board
ACT244 und ACT373. Bis hier lief die CPU schon mit 56.66 MHz! Nur eben
nicht mit der FPU. :-( Lag der CPU Takt unter 36MHz lief die FPU, egal
mit welchem Takt (56.66MHz). Mit einer anderen cs_fpu Gleichung in GAL
U6 ging es auch nicht! So, Pull-ups an D16-D31! Geht nicht! (D0-D15
sind schon, da 12MHz Board!) c't 2.Teil "Bustreiber können
dazwischenfunken." Pull-up (3k3) an FE vom ACT373 (pin 1)! 40MHz
mit FPU laufen! :-) Wer ist schuld? die MMU! Andere MMU! 56.66MHz!!
FPU läuft!!!
+---------+---------------+----------------+---------+-------------------+ | Pak-TOS | Speicher 4..7 | E00004..E00007 | läufts? |Pak-TOS bei FCxxxx | +---------+---------------+----------------+---------+-------------------+ | 2.06 | 00 FC 00 20 | 00 E0 00 30 | Ja | Ja | | 2.06 | 00 FC 00 30 | 00 E0 00 30 | Ja | Ja | | 3.06 | 00 FC 00 20 | 00 E0 00 30 | Nein | | | 3.06 | 00 FC 00 30 | 00 E0 00 30 | Ja | Nein (nach booten)| +---------+---------------+----------------+---------+-------------------+ !d e00020 e0005e !,00E00020 ORI.B #$66,D0 !, ORI.B #$BB,D0 !, ORI.B #$1E,D0 !, ORI.B #$00,D0 !,00E00030 MOVE.W #$2700,SR !, RESET !, MOVE.B #$0A,$FFFF8001.W !, LEA $000007FC.L,A7 !, CMPI.L #$FA52235F,$00FA0000.L D0 wurde !, BNE.B $00E00058 nirgendwo !, LEA $00E00058(PC),A6 benutzt !, JMP $00FA0004.L !,00E00058 MOVE.L #$00000808,D0 D0 wird beschrieben
Die Frage ist nun, warum funktioniert TOS-3.06 nicht wenn man es
an FC0020 loslaufen lässt. Das (FCxxxx) != (E0xxxx) nach dem
booten kann ja nur durch die PMMU bewirkt werden ... also wenn das
System schon läuft. Das TOS-3.06 ab FC0030 läuft beweist,
daß diese PMMU Initialisierung erst nach dem Sprung nach Ewxyz
stattfindet. Da die (einfache) Umschaltung zum 68000 davon
abhängt nun folgender Anreiz: der erste, der's versteht (und mir
erklärt) hat ein Freibier im Karlsruher Stammtisch bei mir gut.
Um das Pak-TOS bei FC0030 anstatt bei FC0020 loslaufen zu lassen
ist übrigens nicht unbedingt ein neues Eprom auf der Hauptplatine
nötig. Das Aushebeln von Pin 16-U7 genügt um aus 20 ein 30
zu machen (HeavyPatch :-) ).
In GAL U6 wird das Signal "rom" erzeugt. Dieses ist
aktiv bei Adressen im Bereich $FC0000..$FEFFFF und außerdem im
Bereich $E00000..$E7FFFF und wird indirekt (über U1) als
Chipselect für die EPROMs verwendet. Wird ein 512K großes
Betriebssystem (TOS3.06) eingesetzt, so findet sich dieses im
Adressbereich $E00000..$E7FFFF; außerdem wird die _zweite_
Hälfte des Betriebssystems, also der Teil, der ab $E40000.. zu
finden ist, bei $FC0000.. eingeblendet, da die Adreßleitung A18
beim Zugriff auf $FC0000.. High ist.
Beim Reset wird der Resetvector aus den ROMs auf der Hauptplatine
gelesen, dann wird zur Adresse $FC0020 bzw. $FC0030 verzweigt. Im TOS
3.06 befindet sich clevererweise bei der Adresse $E40030 ein
Sprungbefehl zur Adresse $E00030. Dies ist möglich, da sich dort
zufällig ein nicht benötigter Teil der Desktop-Resource
befindet, welcher (soweit ich dies verstanden habe) sowieso ins RAM
kopiert und neu initialisiert wird (??). Dieser Sprungbefehl verzweigt
dann zum richtigen Eintrittspunkt. Befindet sich im ROM auf der
Hauptplatine ein Reset-Vector $FC0020, so wird das auszuführende
Programm von Adresse $E40020 genommen, und dort steht kein
Sprungbefehl.
Der Reset bei der PAK läuft also mit TOS 1.02/1.04 auf der
Hauptplatine folgendermaßen ab:
Zugriff auf ROM Adresse im Rom (rel.) Inhalt $000004 Hauptplatine $000004 $FC0030 $FC0030 PAK $040030 JMP $E00030 $E00030 PAK $000030 TOS-Start
Endlich ist es soweit, auf der PAK werkelt jetzt das TOS 3.06 mit
den Patches aus den c't-Files.
Dazu ein paar Fragen.
Wie erkennt die PAK mit 3.06 ob ein Warm- oder Kaltstart erfolgt
ist? Wenn der Rechner läuft und dann ausgeschaltet wird muß
ich teilweise bis zu einer Minute warten bis ich ihn wieder
einschalten kann.
Denn sonst startet die PAK gleich durcht. Will heißen ohne
Speichertest und Wartezeit und überfährt damit die
Festplatte. Wenn der Rechner 'längerer Zeit' aus war kommt wie
gewohnt der Speichertest.
Mit dem TOS 2.06 (nicht auf der PAK) dagegen reicht es schon wenn
der Rechner ca. 5 Sekunden ausgeschaltet gewesen ist.
Warm- bzw. Kaltstart über die Tastatur dagegen wird
einwandfrei erkannt.
Auch läuft nach dem Einschalten der Speichertest wesentlich
schneller ab als unter 2.06. Wird der Test im Cache durchgeführt
oder ist die Routine im 3.06 einfach nur schneller?
Eine Frage über die ich schon lange nachgedacht habe, warum
wird das ROM nicht gecached?
Wenn ich das TOS (2.06) ins RAM lade läufts genauso
problemlos wie im ROM, nur eben etwas schneller da dort der Cache
aktiv ist.
Gibt's eine Möglichkeit das 3.06 im RAM zu fahren?
Leider funktioniert die automatische Overscanumschaltung nicht
obwohl in den Readme's zu Overscan von einer Unterstützung des
3.06 die Rede ist. Overscan selber läuft, nur die Umschaltung
eben nicht. Kann das an den Patches liegen oder läuft die
automatische Umschaltung beim Starten von Programmen generell nicht
mit 3.06?
Da die MMU jetzt richtig initialisiert wird sind jetzt auch ein
paar Probleme verschwunden die damit scheinbar zusammen hingen.
Mit TOS 2.06 kam beim Kopiern auf HD-Disketten gelegentlich
_während_ des Kopierens die Meldung daß die Diskette
schreibgeschützt sein. Dies und andere kleine Probleme sind jetzt
verschwunden. So laufen jetzt auch wieder die anderen
Festplattentreiber einwandfrei.
Auch CoNnect läuft, obwohls nur auf 2.06 registriert ist.
Liegt wahrscheinlich daran daß das 2.06er noch im Rechner ist
und daher die ersten 8 Bytes vom 2.06 ab Adresse 0 eingeblendet
werden.
Wenn jemand bis hierhin mitgelesen hat und zu der einen oder
anderen Frage eine Antwort hat würde mich das freuen.
Habe gerade die PAK3 auf einem MegaST2(4) zum Laufen gebracht und
bemerke so einige Effekte, die nun richtig zum Tragen kommen....
betreffs der Caches, als da wären:
interner Cache Quantum PS80 (in HUSHI bzw. SCSITOOLS eingestellt
unter Modus )
HUSHI - READ-Cache eingerichtet
2nd Level Cache der PAK3
interner Cache des 68030
z.B. wenn PMMU an und L2-Cache immer an, also nicht durch PMMU
gesteuert, dann treten folgende Effekte auf: wenn ich nun zum
erstenmal ein neues Programm starte, dann rödelt die Festplatte
sehr lange vor sich hin... (ständiges Blinken der LED) bis dann
endlich das Programm erscheint... dies ist dann beim 2ten Mal nicht
mehr der Fall... zur Zeit schreibe ich hier im Editor und die LED der
Platte ist ständig an! Wenn ich nun etwas mache und einen anderen
Zugriff auf Platte hervorrufe, dann läuft es weiter und die LED
erlischt.
beim Start von SCSITOOL wurde manchmal nur eine und manchmal beide
Platten am ACSI BUS erkannt , wenn ich den internen Prozessorcache
ausschalte, dann klappt es richtig und beide Platten werden erkannt.
Beim Booten gabs am Anfang auch ein paar Probleme, wobei ich aber
nicht einschätzen kann ob es am RESET der Platte oder des
ACSI-Busses lag oder warum der HUSHI Treiber die Meldungen welche
Laufwerke erkannt wurden einfach hinten dran schreibt und nicht mehr
nach Platte geordnet untereinander...
Wenn ich die PMMU einschalte und damit auch den Cache steuern
lasse, dann kann ich wahnsinnige Steigerung der
Zugriffsgeschwindigkeit beobachten :-))werde ich wohl erstmal so
belassen. würde mich freuen, wenn qualifizierte Antworten
kämen :-))
meine Konfig: MegaST2(4), TOS2.06CPU-Card,PAK3 mit gepatchtem TOS3.06,Overscan, RSVE HUSHI-HD-Treiber,XBOOT3.0,NVDI2.5
Michael Thomeczek @B
Das Problem liegt eigentlich am L1-Cache, wenn die MMU nicht aktiv
ist.
Du solltest _unbedingt_ TOS 3.06 benutzen und die MMU nicht per
Jumper deaktivieren. Dann sollte es keinen Ärger geben.
Die Ursache liegt übrigens im Prozessor:
Wenn WA in der Cache-Maske gesetzt ist, werden Daten bei
Schreibzugriffen unter ignorieren von ciin in's Datencache
übernommen. Ein folgender Lesezugriff auf die gleiche Adresse
wird dann aus dem Cache bedient.
Das führt zu Problemen mit HUSHI, wenn der DMA-Chip bedient
wird.
WA kann beim 030 leider nicht abgeschaltet werden.
In neueren Versionen hat HUSHI ein Workaround für das
Problem.
Bitte nicht verwechseln: es ist weder ein Fehler in HUSHI noch in
der PAK, es ist die Natur des Prozessors. Daher liegt der Fehler
einfach darin, daß man die MMU nicht korrekt anwendet (TOS 3.06
und MMU nicht disabled)
Bei einem Bekannten von mir wird die gepufferte Uhr nicht korrekt
bedient, wenn der Rechner mit TOS 3.06 auf der PAK betrieben wird.
Kann ich bestätigen, aber nur in Verbindung mit DCF_Time1.2
beim Stellen der Uhr nach dem Abklemmen der Batterie !
Also, wenn er kurz die Batterie raus hatte und seit dem nicht mehr
gestellt, dann mit TOPS2.06 booten (evt. mit PUK_GAL und normalem
68000) , dann die Uhr wieder stellen und Batterie rein, dann mit
TOS3.06 und PAK3 booten und es ist wieder alles in Butter.
Habe ich Durch Zufall gemerkt, als ich den Rechner öffnete
und mal wieder der Draht zur Batterie abriß. :-))
Entweder liegt es an DCF_TIME, falls er das benutzt, oder die
Uhrenroutine im gepatchten TOS3.06 hat noch ein Verhalten dieses
Uhrenbausteins (Batterie low) nicht berücksichtigt.
Ralf Zimmermann (DCF_TIME) und STeffen Engel (TOS_Patches) wissen
von mir davon...
evt. kann sich jemand, der die Uhr und Ihr Verhalten (laut
Datenblatt) besser kennt, mal damit beschäftigen und evt.
herausfinden, woran es liegt.
Es gibt ja Uhren, die erzeugen nach Spannungsausfall einen
zyklischen Interrupt... evt. ist das ja auch bei dieser Uhr der Fall ?
Ich habe leider kein Datenblatt von der MegaST Uhr.
Die Routinen für die Mega-Uhr sind vom Prinzip her aus dem TOS 2.06 übernommen, nur mit dem Unterschied, daß aus Platzgründen 68020-Befehle für das zusammensetzen des Datums verwendet werden. Der Zugriff auf die Uhr ist jedoch identisch.
Wenn man wieder auf KAOS (Hauptplatine) umsteigt, klappt auch
alles wieder. (Nicht immer: KAOS scheint bei einer chaotisch gesetzten
Uhr manchmal beim Booten einfach hängenzubleiben... da hift dann
meistens ein "Uhren-Reset" durch Entzug der Pufferspannung
am Chip).
Stell man nun unter KAOS die Uhr, so geht es genau so lange gut,
wie man nicht wieder auf TOS 3.06 umschaltet (auch die Pufferung beim
Ausschalten klappt).
Im Zusammenhang mit dem 10/12 MHz Projekt und der Pak haben einige
von Euch (ich auch) Schwierigkeiten mit dem Bild auf dem SM 124
bekommen. Dies äußerte sich (bei mir) wie folgt:
Beim einschalten des Computix war der linke Rand des Bildes fast
immer versetzt. - Und was rechts zu viel war wurde dann links wieder
eingeschoben. Erst nach mehrmaligem, erneutem Einschalten (wenn mann
Glück hatte) wurde ein sauberes Bild aufgebaut. (Leider verschob
sich dieses auch während der Arbeit.) Das ist natürlich
für die Hardware pures Gift. (Das Einschalten) Tja, und bei
Frequenzen >11,225MHz hatte ich immer ein "Krisseln" auf
dem Bildschirm. Und zwar in dem Bereich, der angehängt wurde.
Auch der Tip von Rober Rohlfing mit einem 100nF Kondensator
zwischen PIN 1 (XTAL0) und PIN 40 (+5V) brachte (bei mir) nur bedingt
Besserung, aber "inspirierte".
Obwohl die RAM's, die Treiber und die restlichen IC's schnell
genug waren mußte ich mit einem "langsamen" ST vorlieb
nehmen. :-( Auch diverse Versuche und Test's mit anderen Eprom-Daten
waren vergeblich.
Nun habe ich eine Lösung gefunden, die (zumindest bei mir)
den gewünschten Erfolg brachte. Mittlerweile fahre ich eine
Auflösung von 1024 X 480 (sichtbares Bild) auf einem SM 124 - mit
einem Boardtakt von 12,5MHz (50MHz Quarzoszillator) ohne
"springen" des Randes oder "krisseln" zu
beobachten. 60 MHz gingen (noch) nicht - aber ich werde es weiter
versuchen.
Vorweg möchte ich aber noch darauf hinweisen, das ich weder
Pistole noch Gewehr für (gegen) nix und niemanden übernehme.
;-)
PIN 1 (XTAL0) wurde Ursprünglich über ein Widerstand
(R144 im MEGA2 und Mega4 ST) mit 10kOhm auf Masse gezogen. Diesen
jetzt auslöten (entfernen) und erst mal zur Seite legen. (wird
noch gebraucht) In die freigewordenen Lötpunkte nun den
100nF-Kondensator einlöten. Den ausgelöteten Widerstand
werden wir nun versetzen. Er bekommt sein neues Plätzchen direkt
nebenan in die Lötpunkte die mit (R 145) bezeichnet sind. (er
kommt also zwischen (BLANK) und PIN 1 des Shifters) So, nun werden wir
noch den 2. Kondensator verbraten, falls dies noch nicht geschehen
(Tip von Robert! - siehe oben.). Er kommt zwischen PIN 1 des Shifters
(xtal0) und PIN 40 (+ 5V). Zum guten Schluß noch den
100-Öhmer zwischen PIN 1 und Pin 2 des Shifters einlöten. -
fertig
Den 100 Ohm Widerstand und den 100nF Kondensator kann man am
besten auf die Platinenrückseite verfrachten. (aber bitte
aufpassen, das keine Schlüsse entstehen können.)
So, wer es versuchen will -> bitte nochmal PM an mich.
Schließlich will ich wissen, ob's bei Euch auch zum Erfolg
führte oder jemand noch eine andere (bessere?) Lösung
gefunden hat.
Jörg Nolte
Bei mir hatte ich diesen Effekt besonders ausgeprägt, nachdem
ich mir die HBS640-36 eingebaut hatte (ich leide _nicht_ am
Manta-Syndrom !). Es trat so oft auf, daß es fast zum Auswachsen
war. Eine deutliche Verbesserung trat ein, nachdem ich einige 3u3
Folienkondensatoren als zusätzliche Stütz-C's im Rechner
eingesetzt hatte.
Diese fanden ihren Platz in der Nähe des Shifters, MMU,
DRAMS, CPU. Der Einfachheit halber wurden sie über die eh' schon
vorhandenen Stütz-C's gelötet. Im Übrigen kann ich
sagen, daß das Problem bei mir sowohl mit Original-Chipsatz als
auch mit IMP-Chips auftrat. Insgesamt habe ich so den Eindruck,
daß Atari es nicht immer ganz geschaft hat, die 5V-Versorgung
auf der Platine sauber zu halten. Seit dieser
"Ergänzung" läuft die Kiste bei mir recht ruhig.
Warum auch immer hat sich der Effekt mit zunehmender Betriebdauer der
HBS immer seltener gezeigt, so als wenn die neue Hardware ersteinmal
"einlaufen" müßte (...???). Davon einmal
abgesehen, wer alzu genervt ist, sollte sich Autoswitch-Overscan
einbauen. Die Treibersoftware dreht den Versatz wieder zurück (so
mein Eindruck). Dadurch stört die Schose eigentlich noch weniger
!
Kann es sei das der Rom-Port nicht ueber den L2-Cache laeuft ?
Der L2-Cache deckt ausschließlich den Adressbereich von 0 MB
bis 4 MB ab. Zugriffe auf den ROM-Port gehen immer am Cache vorbei.
Anders beim CPU-internen Cache, insbesondere beim 68030. Durch den
"Write allocate Mode" kommt der CPU-Cache u.U. ins Spiel.
Abhilfe durch TOS 3.06, dort wird die MMU in der CPU entsprechend
programmiert.
Jeder Zugriff der PAK auf den ROM-Port läuft genauso schnell
ab, wie mit einem 68000er. Nur die Zeit zwischen zwei Zugriffen kann
kürzer werden. Und falls Daten in den CPU-internen Cache geraten
sind (s.o.), werden diese natürlich ohne erneuten Zugriff auf den
ROM-Port aus dem Cache geholt.
Die CPU-internen Caches können über die "Enable
Bits" im CACR (Cache Control Register) ein- und ausgeschaltet
werden. Der L2-Cache kann (mit J11 auf 1-2) über das "Cache
Inhibit Bit" in der Adresstabelle in der MMU ein- und
ausgeschaltet werden (die CPU-Caches sind davon ebenfalls betroffen).
Damit sind also alle Caches per Software schaltbar.
Was das TOS nun tatsächlich macht, wenn man am
Cache-Menüpunkt herumspielt, können nur die Soft-Experten
beantworten.
Das Verzerrungsproblem unter TOS 2.06 oder TOS 3.06 im
Zusammenhang mit der PAK und/oder mit einem 12 MHz Board scheinen
mehrere Leute zu haben. Es scheint so zu sein, daß ein
bestimmter Boardtyp daran Schuld ist. Wer diese Probleme eklatant hat,
sollte mal folgendes nachschauen:
Bei einigen Mainboards geht an Pin1 des Shifters das Blank Signal.
Überprüfen kann man dies indem man testet ob Pin1 des
Shifters mit Pin 36 der GLUE Verbindung hat. Achtung: Nur bei Rechnern
mit Blank an Pin1 des Shifters den Umbau starten!
Ist dies der Fall dann sollte der Rechner wie folgt umgebaut
werden: Die Zuleitung zu Pin1 des Shifters durchtrennen. Pin1 vom
Shifter über 4,7 kOhm nach Masse. Evtl. noch einen 100nF
Kondensator nach Vcc. Von Pin21 Pin24 und Pin27 des Shifters jeweils
eine Diode Löten. Die Anode (die ohne Balken) dabei an die oben
beschriebenen Pinne. Die Kathoden der drei Dioden (die mit dem dicken
schwarzen Balken) zusammen an das Blank Signal führen. Als Dioden
empfehle ich entweder Shottky Typen (z.B. BAT5 (hier kann man den
schwarzen Balken gut erkennen )) oder normale Typen wie 1N914 oder
1N1001 oder 1N1004 oder oder oder.....
Ist dies nicht der Fall: Weis ich auch keinen Rat.
Falls der oben beschriebene Umbau hilft, wäre ich für
eine kleine PM dankbar. Falls der Umbau nicht funktioniert ebenso. Bei
zwei mir bekannten Rechnern erbrachte der Umbau den gewünschten
Erfolg. Ich würde gerne wissen ob das immer so ist.
So, ein neues GAL U4 ist fertig, zumindest die Logikgleichungen.
Es ist alles einfacher und kürzer geworden. Leider konnte ich es
in Ermangelung eines GAL-Brenners noch nicht testen, kommt aber noch.
Beim Stöbern im Listing von GAL U1 (V12_16a) fiel mir aber
etwas anderes auf: Bei einem Wortzugriff auf eine Adresse mit A1=0,
A0=0 wird stets ein 68000-Zykel initiiert, falls das nächste Wort
(A1=1, A0=0) nicht im Cache ist. Dabei spielt es keine Rolle, ob das
eigentlich gesuchte Wort (A1=0) selbst im Cache steht. Es wird zwar
durch den Zugriff dort hineingeschrieben, aber beim nächsten mal
wieder vom Mainboard geholt. Ich habe das durch ein kleines
Progrämmchen verifiziert (ich wollte den Rechner nicht
aufschrauben):
org $200000
load $200000
start: move sr,d7
or.w #$700,sr
lea $200090,a0 ; <-- Adresse
tst.l $100090
move.w #600,d1
moveq #-1,d0
loop: tst.l (a0) ; <-- Zugriffsart
dbra d0,loop
dbra d1,loop
move d7,sr
illegal
Heraus kommt folgende Tabelle (handgestoppt):
Adresse Zugriffsart Zeit Zeit-15s (== nop-schleife)
-----------------------------------------------------------
$200092 tst.l (a0) 47s 32s
$200092 tst.w (a0) 25s 10s
$200090 tst.l (a0) 25s 10s
$200090 tst.w (a0) 31s 16s
$FF8240 tst.w (a0) 31s 16s
Man sieht, daß der Wortzugriff auf $200090 trotz Cache
genauso lange braucht wie der Zugriff auf eine Adresse, die sicher
nicht gecachet wird.
Man könnte in den Gleichungen von PAL U1 Abhilfe schaffen, indem auch die Signale siz1 und siz0 mit heranzieht. Leider liegen die nicht am PAL an! Dort ist nur ein Pin frei, an dem man aber (siz0 xor siz1) anlegen kann. Erlaubt man Wortzugriffe auf ungerade Adressen, braucht man auch A0. Man könnte sich behelfen, indem man (!siz1 * siz0 + !a0 * siz1 * !siz0) an bewußtem Pin einspeist. Das muß man wohl diskret erzeugen? Hmm, es ist ja anscheinend nichts perfekt auf der Welt, nicht mal
die PAK. :-)
Mir ist noch eine andere Lösung eingefallen, die völlig
ohne Zusatzhardware auskommt. Man aktiviert im Falle (mat0 * !mat2 *
!a1) einfach DSACK1, läßt aber DSACK0 inaktiv. Dann geht
die CPU von 16 Bit breitem Speicher aus und ignoriert die andere
Datenbushälfte, führt evtl. später weitere Zugriffe auf
fehlende Operandenteile aus.
Im symmetrischen Fall (!mat0 * mat1 * a1) aktiviert man dagegen
beide und gaukelt so einen Langwortzugriff vor (obwohl die Hälfte
des Langworts falsch ist). Das hat den Vorteil, daß die CPU die
Daten dann automatisch aus dem Lo-Word liest, ansonsten (bei inaktivem
DSACK0) müßte man das Wort extern "hochkopieren",
was so mit der Hardware der PAK nicht geht. Dieser Fall wird aber
bislang schon so behandelt wie beschrieben, so daß es da keine
Probleme geben sollte.
Falls jemand damit mal experimentiert, bitte ich um eine PM, auch
wenn sie bis September unbeantwortet bleiben wird. Die Entwürfe
meiner modifizierten GAL-Listings stelle ich zur Verfügung.
Vorsicht! Es müssen lt. 68030 User's Manual immer alle
Datenbytes über die volle zurückgemeldete Datenbusbreite
gültig sein.
Grund: Der 68030 übernimmt auch die zunächst nicht
benötigten "falschen" Daten in den CPU-internen Cache.
Falls dann später ein Zugriff auf diese Adresse erfolgt, gibt es
eine Überaschung!
Der 68020 hat diese Beschränkung nicht. Wirf mal einen Blick
in die GALs U1 für die PAK/3-020 (P12_xxx).
Nachdem ich nun wieder im Lande bin und auch endlich einen
GAL-Brenner habe, kann ich berichten, wie ich bei meiner PAK durch
neue GAL-Gleichungen noch 10% Speed herausgeholt habe. Damit ist nicht
etwa die Integerdivision gemeint, sondern Sachen wie BitBlt und LKURZ.
Bislang war meine PAK, wenn alle Caches aus waren, langsamer als ein
68000 im gleichen Sockel. Das sollte sich nun geändert haben, ich
habe es aber dummerweise nicht gemessen, als der Rechner noch offen
war. :-)
Gebohrt habe ich an drei Stellen, zwei befinden sich in GAL U1 und
eine in GAL U4. Meine Rechnerkonfiguration ist ein synchroner 68020 in
einem auf 10 MHz aufgebohrten Mega-ST, die drei Modifikationen lassen
sich aber vermutlich aber sinngemäß auf andere
PAK-Konfigurationen übertragen.
Probleme hatte ich auch: Erstens ist die Optimier-Option in der
Maxon-Software offenbar im Ar***. Zweitens enthielt mein von MW
geliefertes GAL P12_16 den Inhalt von P12_32, weswegen meine Eproms
auf CS-Steuerung gejumpert waren. Meine auf P12_16 basierenden
Modifikationen konnten also nicht laufen. Drittens waren dsack0 und
dsack1 im ursprünglichen GAL-Listing verwechselt, was dort aber
egal war. Viertens hatte ich natürlich noch meine eigenen Fehler
eingebaut. :-)
Es ist wahrscheinlich am geschicktesten, wenn ich die
Änderungen hier einmal kurz beschreibe und die Listings in die
beiden Folgemails packe.
(1) GAL U1: Man kann !cyc_00 minimal beschleunigen, was den
Automaten in U4 evtl. um einen CLK8-Zyklus beschleunigt, was
Ram-Zugriffe (über die MCU im ST) evtl. um drei weitere
CLK8-Zyklen beschleunigt.
(2) GAL U1: Bislang wurden Zugriffe auf ein Wort an einer
Langwortadresse nicht aus dem Cache bedient, wenn das Folgewort nicht
im Cache war. Das Problem läßt sich in den Gleichungen
leicht lösen, nur treten dabei zwei Probleme auf: zum einen kann
dsack1 nicht auf die Matrix zurückgeführt werden, zum
anderen braucht dsack1 mehr Zeilen als vorhanden sind. Ich habe das
Problem durch Zuhilfenahme eines unbenutzten Ausgangs gelöst.
68030-User aufgepaßt: der andere Fall (Zugriff auf
Langwortadresse+2) läßt sich nur beim 68020 so lösen,
wie es in P12_16 gemacht wird.
(3) GAL U4: Hier war die Statemachine doch sehr konfus (mit
pathologischen Zustandsübergängen) und hat beim Schreiben,
glaube ich, sogar einen CLK8-Zyklus zuviel verbraucht, was die MCU im
Atari mit drei weiteren bestraft. Der neue Automat ist
ästhetischer und jeweils einen CLK8-Zyklus schneller.
Noch schnell ein paar Benchmarks: Dhrystone 1.1 meldet maximal
5165 und LKURZ.TEX wird in 2'29" übersetzt, was in der
LKURZ-Liste dem TT im Fastram entspricht.
PS: Übrigens bietet Pollin-Elektronik in der neuesten
Sonderliste wieder 68020-16 für 28 Mark an, da kommt meiner auch
her.
PAK 68/3, GAL 1: CPU-Clk State Machine für 68020 mit 16 MHz 22-09-94 V12_16 Martin Rogge @ KI neu: Es werden halbvolle Cachelines korrekt behandelt. ___ ___ | \/ | 16m = CLK |1 24| VCC mat2 |2 23| mat0 16m |3 22| !dsack1 a1 |4 21| !dsack0 !as_00 |5 20| !cyc_00 !tclr |6 19| !sterm !wr |7 18| !as_22 !as_20 |8 17| !doe !prom |9 16| !as_21 !csp19 |10 15| !roe !dsack00 |11 14| !dram GND |12 13| !OE auf VCC |________| %ID P12_16mr %TYP GAL20V8A %PINS CLK mat2 16m a1 !as_00 !tclr !wr !as_20 !prom !csp19 g1p11 !OE !dram !roe !as_21 !doe !as_22 !dsack11 !cyc_00 !dsack0 !dsack1 mat0 %LOGIC as_21.OE = VCC; as_21 = as_20 * 16m + as_21 * !16m + as_20 * as_21; as_22 = as_20 * as_21 * !16m + as_22 * !16m + as_20 * as_22; doe = as_20 * !as_00 * dram * !tclr * !wr * as_22 * mat0 * mat2 + as_20 * !as_00 * dram * !tclr * !wr * as_22 * mat0 * !a1 + as_20 * !as_00 * dram * !tclr * !wr * as_22 * mat2 * a1; !cyc_00 = !as_21 * !as_20 + csp19 + !as_00 * dram * !tclr * !wr * mat0 * mat2 + !as_00 * dram * !tclr * !wr * mat0 * !a1 + !as_00 * dram * !tclr * !wr * mat2 * a1 + prom * !wr; dsack0.OE = as_21 * !cyc_00 * !csp19; dsack0 = as_20 * dram * !tclr * !wr * 16m * mat0 * mat2 + as_20 * dram * !tclr * !wr * 16m * mat2 * a1 + as_20 * prom * !wr * 16m + as_20 * dram * !tclr * !wr * dsack0 * mat0 * mat2 + as_20 * dram * !tclr * !wr * dsack0 * mat2 * a1 + as_20 * prom * !wr * dsack0; dsack1.OE = as_21 * !cyc_00 * !csp19; dsack1 = as_20 * dram * !tclr * !wr * dsack11 * mat0 * mat2 + as_20 * dram * !tclr * !wr * dsack11 * mat0 * !a1 + as_20 * dram * !tclr * !wr * dsack11 * mat2 * a1 + as_20 * prom * !wr * dsack11; dsack11 = as_20 * dram * !tclr * !wr * 16m * mat0 * mat2 + as_20 * dram * !tclr * !wr * 16m * mat0 * !a1 + as_20 * dram * !tclr * !wr * 16m * mat2 * a1 + as_20 * prom * !wr * 16m + as_20 * dram * !tclr * !wr * dsack11 + as_20 * prom * !wr * dsack11; roe = as_20 * prom * !wr * !OE; %END PAK 68/3, GAL U4: State Machine 1 für 68000 Businterface, 16 MHz 22-09-94 V4_16 Martin Rogge @ KI ___ ___ | \/ | clk16 |1 24| VCC clk8 |2 23| !dtack !from |3 22| !uds !cyc_00 |4 21| !lds rd |5 20| q1 e2 |6 19| !as_00 e1 |7 18| !vma siz1 |8 17| q0 !as_20 |9 16| !dsack1 !word |10 15| !dsack a0 |11 14| siz0 GND |12 13| !OE |________| %ID P4_16mr %TYP GAL20V8A %PINS CLK clk8 !from !cyc_00 rd e2 e1 siz1 !as_20 !word a0 !OE siz0 !dsack !dsack1 q0 !vma !as_00 q1 !lds !uds !dtack %LOGIC uds <- !uds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * rd * word + !uds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * !a0 + uds * !dsack1 * !q0 * as_20 + uds * dsack1 * !q1 * as_20 + uds * !q1 * q0 * as_20; lds <- !lds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * rd * word + !lds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * a0 + !lds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * !siz0 + !lds * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 * siz1 + lds * !dsack1 * !q0 * as_20 + lds * dsack1 * !q1 * as_20 + lds * !q1 * q0 * as_20; as_00 <- !as_00 * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 + as_00 * !dsack1 * !q0 * as_20 + as_00 * dsack1 * !q1 * as_20 + as_00 * !q1 * q0 * as_20; dsack1 <- as_00 * !dsack1 * !q1 * !q0 * as_20 * !clk8 * rd * dtack + as_00 * !dsack1 * !q1 * !q0 * as_20 * !clk8 * rd * vma * !e1 * e2 + dsack1 * !q1 * !q0 * as_20 + as_00 * !q1 * q0 * as_20 + as_00 * dsack1 * q1 * q0 * as_20; q1 <- !as_00 * !dsack1 * !q1 * !q0 * as_20 * clk8 * cyc_00 + as_00 * !dsack1 * !q1 * q0 * as_20; q0 <- as_00 * !dsack1 * !q1 * !q0 * as_20 * !clk8 * !rd * dtack + as_00 * !dsack1 * !q1 * !q0 * as_20 * !clk8 * !rd * vma * !e1 * e2 + as_00 * !q1 * q0 * as_20 as_00 * dsack1 * !q1 * !q0 * as_20; vma <- !clk8 * !e1 * !e2 + vma * !e2 + vma * !e1 + vma * clk8; dsack.OE = VCC; dsack = as_20 * dsack1; %END
Für Leute, die immer noch Schwierigkeiten haben bei dem Betrieb mit der PAK bei 50 MHz und zwar mit oder ohne Pufferplatine, denen kann geholfen werden. Hierzu müssen einige Änderungen im ST durchgeführt
werden:
1. Brennen eines GALs mit folgendem Inhalt:
OE_1 Neugenerierung des Output-Enable der 373er beim RAM im ST Robert Rohlfing
02-09-94 erster Entwurf
26-09-94 Pinänderung für Lötlösung ohne Platine
___ ___
| \/ |
!oe |1 20| VCC
|2 19| !oe_neu
|3 18| hold
|4 17|
|5 16|
|6 15|
|7 14|
|8 13|
|9 12|
GND |10 11| latch
|________|
%ID
OE_1
%TYP
GAL16V8A
%PINS
!oe nc nc nc nc nc nc nc nc
latch nc nc nc nc nc nc hold !oe_neu
%LOGIC
oe_neu = oe * !latch * !hold
+ oe * latch * hold;
hold = oe * latch
+ oe * !latch * hold;
%END
2. Die beiden 74373er im ST sind ausfindig zu machen, die zu den
RAMs gehen. Bei Mega-ST sind das U33 und U36, beim 260-ST und 520-ST
sind das U22 und U23, beim 1040-ST sind es U57 und U58.
3. Die beiden Pin1 der 373er sind aus dem Mainboard zu entfernen.
4. Vom GAL sind Pin 1 und Pin 19 nach oben zu biegen.
5. Pin 2 bis 9 des GALs sowie Pin 12 bis 18 sind zu kürzen
oder zu entfernen.
6. Pin 1, 10 und 11 des GALs sind mit den gleichen Pins eines der
beiden 373er auf dem Board zu verbinden (Das GAL oben auf einen der
373 löten).
7. An Pin 1 des GALs kommt der ehemalige Pin 1 der 373, also das
Signal vom Board.
9. Pin 18 vom GAL bleibt unbeschaltet.
Ich habe mir die obengenannte Grafikkarte mal in meinen Rechner eingebaut. Zusätzlich werkelt noch eine PAK68/3-30 mit 36 MHz vor sich
hin.
Nun habe ich mit UMG4000 mir meine Auflösungen
zusammengestellt und ein NVDIVGA.INF abgespeichert. Klappte alles
hervorragend.
Also NVDI-ET4000 V2.51 installiert, NVDIVGA.INF in den Autoordner
kopiert und einen Reset ausgeführt. Dann erschien auf dem
VGA-Moni die Auswahlbox für die diversen Auflösungen. Die
Aufösung kann man noch wählen, aber wehe man klickt auf den
OK-Button, dann erscheinen erst 2, dann 4 und zum guten Schluß
11 Bomben auf dem SM124.
Einen 330 Ohm Widerstand habe ich schon zwischen VCC und R/W. Eine Diode zwischen A23 und BGACK reduzierte die Bombenanzahl auf
drei.
Und das Ändern der Taktfrequenz auf 32 MHz änderte
nichts an der Bombenstimmung.
Bevor Jemand fragt, nein es ist nichts im Autoordner und es ist kein ACC installiert. Hat da jemand schon eine Lösung? Ich glaube nicht, das das
Problem von der Software kommt.
Der L1-Cache wird aktiv, wenn folgende Bedingungen _alle_
erfüllt sind:
Der L2-Cache wird aktiv, wenn folgende Bedingungen _alle_
erfüllt sind:
Wie willst Du da den Cache-Status hardwaremäßig
eindeutig erkennen? Man könnte vielleicht mit etwas Zusatzlogik
so eine Art Cache-Lichtorgel bauen, die um so heller flackert, je
heftiger die PAK im Cache wühlt. Hatte nicht Silicon Graphics mal
so was an ihren bunten Maschinen?
Am Samstag haben leider einige Käufer der FastRAmKarte keine
*Einbauanleitung* bekommen können, am Sonntag gab es die dazu. Um
Problemen vorzubeugen hier ein paar Sachen, die man beachten solle,
wenn man die FRAK einbaut.
- Auf der PAK sind 4 zusätzliche Verbindungen nach CON1
herzustellen.
- Das GAL U6 auf der PAK gegen ein Neues tauschen, es wurde mit
der FRAK geliefert.
- Auf der PAK muß für U1 das GAL U13_50 Verwendung
finden, auch bei 32MHz-Betrieb.
- TOS 3.06 muß vorhanden sein, nur das erkennt das FastRAM.
- Beim Aufstecken der FRAK auf die PAK aufpassen, daß _alle_
Pins unverletzt bleiben.
Vier zusätzliche Verbindungen auf der *PAK* per
Fädeldraht herstellen:
Erfahrungen mit der PAK und der Pufferplatine
Hardware: 1040STF-Mainboard (8 MHz Systemtakt), PAK3/30-40MHz, 4
MB RAM, c't-IDE-Interface mit SEAGATE 3122A, ICD Adscsi+ mit SEAGATE
4702N, HD-Modul,MegaClock,RSVE und *Pufferplatine* ;-)
Nach dem Einbau der Pufferplatine hatte ich zuerst Probleme mit
dem DMA-Transfer; meine SCSI-Platte wurde bei 32 MHz überhaupt
nicht oder nicht vollständig erkannt. Problemlösung:
Verringerung des Resetwiderstands auf 560 Ohm. Seither keine Probleme
mehr (zur Zeit bis 40 MHz getestet).
Ohne Pufferplatine hatte ich Probleme mit dem c't-IDE-Interface.
Bei 32 MHz beendeten sich alle getesteten Original-Harddisk-Treiber
(AHDI, HDDRIVER, HUSHIJR, interner Treiber der DISKUS-Demo) mit einem
Busfehler. Erst vonmir gepatchte Versionen liefen ohne weitere
Probleme. Seit dem Einbau der Pufferplatine laufen alle genannten
Treiber selbst bei 40 MHz einwandfrei.
Ein weiteres Kapitel zum Thema "Die PAK und die Uhr":
Vor dem Einbau der Pufferplatine konnte ich meine MegaClock nicht
benutzen, da bei jedem Neustart die Uhr ins Jahr 2026 sprang. Nach dem
Einbau habe ich bisher keine Probleme mehr. Allerdings hatte ich
zwischenzeitlich auch einmal mit einem 68000er und TOS 2.06 die Uhr
korrekt gestellt. Was auch immer die Ursache für den Fehler war,
jetzt ist er beseitigt.
Da ich meinen 68030-33 mit 40 MHz übertakte, würde ich
ihm gerne einen Kühlkörper verpassen. Gibt es welche in
passender Größe ? Wie sind die Erfahrungen, was hat sich
bewährt ?
Hast Du den Zettel "Hinweise zur neuen Platinenversion
PAK/3-030A" nicht bekommen?
OK, dann hier:
*Hinweise zur neuen Platinenversion PAK/3-030A*
Die neue Platinenversion erkennen Sie an dem Aufdruck PAK/3-030A
links unten auf der Lötseite. Folgende Neuerungen und
Änderungen sind bei diesem Layout in Bezug auf die erste PAK68/3
gemacht worden:
- Neuer Widerstand R9 = 33 Ohm; muß unbedingt bestückt
werden.
- Zwei zusätzliche Massepunkte und ein VCC-Anschluß am
Platinenrand neben dem 68000er-Sockel.
- Neuer Jumper J12; dient nur zu Testzwecken und braucht nicht
bestückt zu werden.
- Das GAL zur Prozessorumschaltung ist bereits vollständig
angeschlossen worden und braucht nun nicht mehr gefädelt zu
werden. Allerdings hat sich die GAL-Belegung geändert, deshalb
heißt die neue Version nun P3A_PUK.
- Unter dem Quarzoszillator U23 läßt sich nun von der
Lötseite her optional ein 74F00 einsetzen. Dieser dient der
Pufferung des Takts, da sich gezeigt hat, daß die
Quarzoszillatoren in der Regel bei 50 MHz kein ausreichend starkes und
sauberes Taktsignal mehr liefern, was sich besonders bei
gleichzeitiger FPU-Benutzung störend bemerkbar machen kann. Wenn
Sie diese Taktpufferung einsetzen wollen, so sollten Sie die
Taktleitung auch entsprechend terminieren. Insgesamt müssen Sie
dazu folgendes beachten:
1. 74F00 von der Lötseite bestücken.
Wollen Sie die Quarzpufferung nicht einsetzen, so müssen Sie
die neue Lötbrücke auf der Lötseite zwischen R47 und
dem Oszillator mit reichlich Lötzinn schließen.
*Achtung:* Sollten Sie die FASTRAM-Karte (FRAK30) einsetzen, so
dürfen Sie die Taktpufferung auf der PAK nicht benutzen (der Takt
wird dann auf der FASTRAM-Karte erzeugt und auch dort direkt
gepuffert), oder Sie müssen nachträglich Pin 6 des 74F00
durchtrennen.
Ich habe sofort R9 bestückt und die PAK eingesetzt. Lief auf Anhieb (40 MHz). Dann den 50 MHz Quarz rein, keine Probleme. Läuft absolut stabil. Ich benutze weder eine Pufferplatine, noch die Taktpufferung. Auch die Stromversorgung läuft nur über den Prozessorsockel. Dafür sind bei mir alle Komponenten (GALs: 12 ns, Cache-RAMs: 15 ns) schneller als in der Stückliste angegeben. Die Prozessoren sind 50 MHz Typen und werden noch nicht mal besonders heiß. Scheinbar bringt das mehr als alles andere. An der Busterminierung habe ich nichts geändert, die Treiber hatte ich allerdings vorher schon gegen F-Typen ausgetauscht. Was vielleicht noch wichtig ist: Bei mir ist der 8 MHz Takt, der von der MMU kommt, mit einem 74F08 gepuffert. Außerdem sind bei mir R23 - R27 auf der PAK durch ein Versehen 2k2 Ohm Widerstände.
Und noch etwas: Das TOS 2.06 meines Rechners (Mega 2) steckt bei mir auf einem H&N MultiBoard (auf der PAK steckt natürlich TOS 3.06). Daran angeschlossen ist außerdem eine ET4000-Karte, auf der ich im Moment eine Auflösung von 1024 mal 768 bei 256 Farben fahre. Das ganze auf einem 17" Monitor mit NVDI ET4000 und MagX :-). Zusätzliches RAM habe ich auf dem MultiBoard im Moment leider noch nicht.
Hinweise zum Betrieb der PAK/3 mit 40MHz und 50 MHz
Achtung:
Aus der Einbauanleitung FRAK30:
J1: ohne Funktion
Copyright © Robert Schaffner (doit@doitarchive.de) Letzte Aktualisierung am 23. Mai 2004 |
|
|
