Fastram mit PAK68/2 ...

[czietz]

Tempelmon: Lesen:

m 1000000

Schreiben:

: 1000000 ff

Ungetestet, weitere Details bitte dem Handbuch entnehmen.

[Lukas Frank]

Danke ...

Das kannte ich schon von der Mega4000 GK, ich wusste nur nicht das ich da 1000000 und dann weiter garnichts eingeben muss ;-)

[Lukas Frank]

Beim Lesen mit "m 1000000" kommt ":01000000 60"

Beim Schreiben kommt ein Bus Error ...

[Lukas Frank]

Verhindert die PAK68/2 vielleicht alles über 16MB (68000) und löst einen Buserror aus ?

[joejoe]

Da die unmodifizerten GALs der PAK/2 nach meiner Erinnerung Adresse A24 überhaupt nicht auswerten  bzw. diese erst gar nicht an den GALs anliegt, ist das eine gute Frage.

Für die PAK/2 bzw. deren (unmodifizerte) GALs liegt der Fastram-Adressbereich gespiegelt in den unteren 16MB, das sorgt also für Konflikte. Du schreibst also praktisch an Adresse 0 aufwärts,
bei Lesen liest Du Teile des Resetvektors, oder was auch immer an Adresse 0 im RAM liegt.

edit: an Adresse 0 liegt nicht der Resetvektor, sondern der Initial Stackpointer

[Lukas Frank]

Gibt es nicht Quellen zu Amiga GALs, da gab es doch die Option SRAM einzusetzen oder liegt das auch nicht über der 16MB Grenze des 68000 Bereiches ?

[czietz]

edit: an Adresse 0 liegt nicht der Resetvektor, sondern der Initial Stackpointer

Es ist plausibel, dass Franks PAK darauf zugreift, denn das Byte an Adresse 0 ist bei TOS immer 0x60; also genau der Wert, den Tempelmon dort auch liest. Beim Schreiben an Adresse 0 (statt 0x1000000) erzeugt GLUE(?) einen Bus-Error, weil die ersten 8 Bytes ja aus dem ROM kommen. Auch plausibel.

[1ST1]

Das heißt, die PAK müsste so umgebaut werden, dass wenn Adressen jenseits von 16 MB angesprochen werden, dass dann die Komponenten unterhalb von 16 MB sind, nicht angesprochen werden. Und es muss das Bus-Error-Signal, das von der GLUE kommt, verändert werden.

[1ST1]

Gibt es nicht Quellen zu Amiga GALs, da gab es doch die Option SRAM einzusetzen oder liegt das auch nicht über der 16MB Grenze des 68000 Bereiches ?

Soweit ich weiß lag dieser SRAM-Adressbereich auch unterhalb von 16 MB.

[czietz]

Das heißt, die PAK müsste so umgebaut werden, dass wenn Adressen jenseits von 16 MB angesprochen werden, dass dann die Komponenten unterhalb von 16 MB sind, nicht angesprochen werden. Und es muss das Bus-Error-Signal, das von der GLUE kommt, verändert werden.

Idee ins Blaue hinein: AS (und vielleicht UDS, LDS) nicht auf den 68000-seitigen Bus geben, wenn Fast-RAM angesprochen wird. Dann funken keine Komponenten mehr dazwischen (auch Glue nicht). Hinweis: da die Hardware auch unter $ffffxxxx erreichbar sein muss, kann man nicht einfach alle Zugriffe jenseits von 16 MiB vom ST fernhalten.

[joejoe]

Hier
http://forum.atari-home.de/index.php?topic=12916.msg207982#msg207982
hatte ich meinen kleinen Anteil an der damaligen FAST-SRAM-Option auf einer PAK/2 offengelegt.

Und ja, die für den beliebigen (8/16/32-bittigen) FastRAM-Zugriff notwendigen GAL Gleichungen stammen von den Amiga-Quellen ab. Für FASTRam auf einem ATARI, zumindest solches, welches vom TOS 3.06 eigenständig gefunden werden kann, ist eine Adresslage des FastRAMs direkt oberhalb der 16MB notwendig. TOS sucht halt standardmäßig nur dort. Sofern der FastRAM-Buffer eigenhändig angelegt wird (das macht TOS 3.06 sonst selbst) sollte eine andere Adresslage, möglicherweise auch unterhalb 16MB möglich sein. Nur ist dafür kein Platz vorhanden.
Ich hatte damals A24 in meine GAL Gleichungen intergriert (und die Leitung physikalisch hinzugefügt).

Im verlinkten Beitrag sind die Quellen angehängt.

[Lukas Frank]

Danke joejoe ...

Also ich kann das ganze nicht umsetzen. Die GAL Gleichungen müssten jetzt so angeglichen werden das man eine Fastramkarte aus dem Atari TT ansprechen kann ...

[joejoe]

Meine GAL Gleichungen waren für ein _ZUSÄTZLICHES_ GAL, welches huckepack  auf einen anderen (U12??) sitzt, einige der notwendigen Signale stammen vom unteren GAL (PINs sind dort angelötet, andere waren frei verdrahtet).

Dein (der) Bus-Error wird vermutlich Folge eines nicht erzeugten /DSACK Signals sein.

Das sollte ja von der TT-FastRAM-Logik auf der Karte kommen, sofern es sich angesprochen fühlt.
Ev. fehlen doch ein paar Signale?

[Lukas Frank]

Eine Fastram Karte aus dem Atari TT hat nur die 32 Daten und Adresssignale sowie ...

Clock 16Mhz
CBACK (Cache Steuerung *)
CBRQ (Cache Steuerung *)
STERM
SIZE1
SIZE0
DS
R/W
AS
FC2
FC1
FC0

... sonst nichts weiter, GND und Versorgungsspannung natürlich noch.

* Kann man weglassen

[tuxie]

Werkelst du jetzt immer noch mit einer TT-Ram karte ? Wenn ja dann hat Holger dir doch schon die Antwort gegeben. Alternativ kann man den Mach210 umprogrammieren da die Quellen ja offen sind. So das das DTACK Signal richtig übernommen wird. Daher kommt auch dein Buserror, da die CPU das DTACK Signal der Frak nicht lesen kann erzeugt sie einen Buserror. Oder hast du dir eine SRAM Karte zusammengebaut ?

[Lukas Frank]

Hallo tuxie, das verstehe ich jetzt nicht so ganz ...

Holger hat mir nur gesagt man sollte das über DSACK1 und 0 am 020er machen und später das, dass Timing mit STERM nicht klappen kann von der TT Fastramkarte. Meine ich oder habe ich da etwas nicht mitbekommen ?

Mit SRAM habe ich nichts im Sinn da ich minimal 16MB Fastram haben möchte und so große nur in 3,3V Technik verfügbar sind und das ist mir zu kompliziert.

Ich möchte gerne eine normale Atari TT Fastramkarte an der PAK68/2 betreiben und wenn möglich eine angepasste wenn das jemand machen kann ...

[joejoe]

EIne Atari FastRamKarte wird scheinbar per synchronous bus cycle betrieben, da ich ausser STERM keine Signalleitung sehe, welche den BusZugriff ordnungsgemäß beenden könnte Hier ein Zitat aus dem Handbuch zum 68030

7.2.10 Synchronous Operation with STERM
The MC68030 supports synchronous bus cycles terminated with STERM.
These cycles, for 32-bit ports only, are similar to cycles terminated with
DSACKx. The main difference is that STERM can be asserted (and data can
be transferred) earlier than for a cycle terminated with DSACKx, causing the
processor to perform a minimum access time transfer in two clock periods.
However, wait cycles can be inserted by delaying the assertion of STERM
appropriately.
Using STERM instead of DSACKx in any bus cycle makes the cycle synchronous. Any bus cycle is synchronous if:
1. Neither DSACKx nor AVEC is recognized during the cycle.
2. The port size is 32 bits.
3. Synchronous input setup and hold time requirements (specifications
#60 and #61) for STERM are met.
Burst mode operation requires the use of STERM to terminate each of its
cycles. The first cycle of any burst transfer must be a synchronous cycle as
described in the preceding paragraph. The exact timing of this cycle is controlled by the assertion of STERM, and wait cycles can be inserted as necessary. However, the minimum cycle time is two clocks. If a burst operation
is initiated and allowed to terminate normally, the second, third, and fourth
cycles latch data on successive falling edges of the clock at a minimum.
Again, the exact timing for these subsequent cycles is controlled bythe timing
of STERM for each of these cycles, and wait cycles can be inserted as necessary.
MOTOROLA MC68030USER'SMANUAL 7-29
m7
Although the synchronous input signals (STERM, CIIN, and CBACK) must be
stable for the appropriate setup and hold times relative to every rising edge
of the clock during which AS is asserted, the assertion or negation of CBACK
and CIIN is internally latched on the rising edge of the clock for which STERM
is asserted in a synchronous cycle.
The STERM signal can be generated from the address bus and function code
value and does not need to be qualified with the AS signal. If STERM is
asserted and no cycle is in progress (even if the cycle has begun, ECS is
asserted and then the cycle is aborted), STERM is ignored by the MC68030.
Similarly, CBACK can be asserted independently of the assertion of CBREQ.
If a cache burst is not requested, the assertion of CBACK is ignored.
The assertion of CIIN is ignored when the appropriate cache is not enabled
or when cache inhibit out (CLOUT) is asserted. It is also ignored during write
cycles or translation table searches.
NOTE
STERM and DSACKx should n e v e r be asserted during the same bus
cycle.

Ein 68020 oder gar der 68000 des Zielrechners hat keine STERM Leitung, also muss der Zyklus anderweitig terminiert werden. Also die per DSACKx. Hier kommen nun die Antworten von Holger und Christian ins Spiel, hast Du czietz litttlelogic wie vorgeschlagen integriert?
Habe mir das nicht weiter durchgelesen, gehe davon aus, dass damit das frühe STERM-Signal verzögert, oder ev. besser verlängert werden kann, damit die 68020 CPU ein für sie korrektes DSACK-Timing erhält.

[joejoe]

Da all das das TT-FastRam-interne Timing natürlich nicht beeinflußt, stellt sich dann aber noch die Frage, ob die RAM-Daten dann auch noch lange genug stabil vorliegen/anliegen um korrekt von der 68020 CPU gelesen zu werden. Die TTFAstRAM MCU ist ja offenbar schnell unterwegs, ev. ist der DRAM-Zugriff auf der FAstRAM-Karte schon beendet, wenn die 68020 CPU bereit für das Erkennen des DSACK ist?
Das meinte Holger ev. mit "das hätte bei der Konstruktion der (Atari-)FastRAM-Karte bereits berücksichtigt werden müssen" ?.

Das heißt natürlich nicht, dass Dein Vorhaben per se zum Scheitern verurteilt wäre; ev. ist es ja doch ganz einfach.

Ich wünsch' Dir viel Erfolg.

[Lukas Frank]

Aber ist es nicht so dass alles nicht funktionieren kann da die PAK68/2 bei Zugriffen oberhalb/über den ersten 16MB einen Bus Error auslöst. Das wäre doch das erste was man ändern müsste, oder nicht ?

[joejoe]

Ein BUS-Error wird im ST automatisch (vom GLUE? oder der MMU? oder doch von der CPU?) ausgelöst, wenn nach 64 Takten kein /DSACKx oder gleichwertiges Bus-Zyklus-Terminierungssignal erkannt wurde.
Das ist ein OpenCollektor-Signal, kann also von verschiedenen Einheiten aktiviert werden.

Die ST Hardware sollte von einem Zugriff oberhalb 16MB durch die normale PAK/2 -Logik verschont bleiben (GAL-Listings studieren). Sofern keine Logik-Gleichung oberhalb der 16MB sofort einen Bus-Error auslöst, steht einem Bus Zugriff mit gesetzem A24 nichts im Weg. Ein Zugriff ins Fastram muss natürlcih auch korrekt beendet werden. Im Zweifel durch zusätzliche Logik, welche die Zugriffe direkt quittiert, egal was die Atari-FastRAMKarte mit /STERM signalisiert, oder ausgefuchst unter Berücksichtigung von STERM. Wenn Du aber die 0x60 im FastRAM liest, ist der Adressbereich oberhalb der 16MB noch gespiegelt und es findet (auch) ein Zugriff auf die unteren 16MB statt.-> GAL Listings studieren.

edit: Im Zweifel ist einfach A24 falsch verdrahtet?