Hardware > Hardware (High-End)

Fastram mit PAK68/2 ...

<< < (16/46) > >>

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
--- Zitat ---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.
--- Ende Zitat ---
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?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete