Fastram mit PAK68/2 ...

[Lukas Frank]

@tuxie ... ob eine Magnum TT den Bust Mode unterstützt oder nicht Interessiert ja nicht !

@czietz ... ich vermute aber mal das dass /STERM handling schon ähnlich ist und eine Magnum TT mit der PAK68/2 auch nicht funktionieren wird.

/STERM ist doch ein Ausgang der Fastramkarte. Wie muss denn das DSACK0/1 Timing aussehen damit TOS 3.06 mit einem MC68020 das Fastram erkennt ?

Geht das Überhaupt über DSACK0/1 ?

[Lukas Frank]

@tuxie ... ich brauche mal Hilfe ...

Das ist für Omikron Basic Code

PRINT PEEK($1000000)
PRINT WPEEK($1000000)
PRINT LPEEK($1000000)

jeweils ein Byte, ein 16-Bit-Wort und ein 32-Bit-Langwort vom Beginn des TT-RAMs lesen und...

POKE $1000000,0
WPOKE $1000000, 0
LPOKE $1000000, 0

schreiben ...

Wie würde das ganze für GFA Basic aussehen müssen ?

[tuxie]

Eigentlich genauso.

Poke $100000,0
Dpoke $100000,0
Lpoke $100000,0

print peek.......
print dpeek...
print lpeek.....

[Lukas Frank]

Vielen Dank ...

Ich bekomme aber Error Meldungen bei dem Schreiben Teil ?

Ich wollte morgen mal mit einen Logic Analyzer schauen wegen dem STERM Signal und der PAK68/2, deshalb brauche ich das ...

Eine schleife mit Lese Aktionen jeweils ein Byte, ein 16-bit Wort und ein 32 Langwort und das gleiche als Schleife mit Schreiben wäre vielleicht schön.

[Lukas Frank]

Habe mal gemessen ...









Der Clock_16 sieht besonders auf der PAK Kacke aus. Der Rechner läuft aber einwandfrei. Fällt vielleicht unter "wer viel misst, misst mist" ...

STERM ist eigentlich die ganze Zeit high (also low) mit ein paar Ausnahmen beim Atari TT, beim ST tut sich gar nichts ...

Wenn die Fastram Karte an der PAK68/2 steckt bootet der Rechner mit "bad CRC in Rom X), da ist die Busbelastung vielleicht zu hoch. Läuft aber einwandfrei.

[czietz]

Die Frage ist: Wenn schon der Clock nicht richtig gemessen wird, kann man dann den anderen Signale vertrauen? Wenn STERM auf der PAK tatsächlich nie "low" wird, dann gefallen der MMU ja nicht mal die Eingangssignale... Du bist Dir auch sicher, einen Zugriff auf das Fast-RAM aufgezeichnet zu haben und nicht irgendwelche anderen Lese- oder Schreibzugriffe, die immer auf dem Bus stattfinden? So sehe ich in "schreiben_pak.png" keinen einzigen Schreibzugriff, R/W ist immer high.

Was mir gerade noch auffällt: Hat der Clock 16 MHz? Dann muss Dein Logic-Analyzer mit mind 32 MS/s Sampling-Rate arbeiten (eher noch mehr), um die richtig abzutasten.

[Lukas Frank]

Ich habe mit Hilfe einer Omikron 5 Demo jeweils die beiden Code Geschichten laufen lassen und gleichzeitig den Analyzer angeworfen ...

Das mit der Sampling Rate ist ein Problem da meiner nur maximal 16MS/s machen kann.

Geht das überhaupt wenn dem TOS das Fastram nicht bekannt ist darauf zuzugreifen ?

[czietz]

Ich habe mit Hilfe einer Omikron 5 Demo jeweils die beiden Code Geschichten laufen lassen und gleichzeitig den Analyzer angeworfen ...

Aber selbst wenn Du die PEEK- und POKE-Befehle in einer Schleife laufen lässt, macht der Rechner doch noch andere RAM-Zugriffen dazwischen, die nicht aufs Fast-RAM gehen, vielleicht hundert andere Zugriffe auf jeden Fast-RAM-Zugriff. Du musst schon auf Lese- und Schreibzugriffe speziell aufs Fast-RAM triggern.

Das mit der Sampling Rate ist ein Problem da meiner nur maximal 16MS/s machen kann.

OK, dann lassen wir die Clock halt weg. Die anderen Signale sind ja zum Glück beim 68020 "langsam" genug.

Geht das überhaupt wenn dem TOS das Fastram nicht bekannt ist darauf zuzugreifen ?

Klar, das ist der CPU doch egal, ob TOS den Speicher kennt oder nicht. Du kannst ja auch auf den Speicher auf Deinen ET4000-Grafikkarten zugreifen, obwohl der beim TOS (natürlich) nicht als Alternate RAM angemeldet ist.

[czietz]

Nochwas: Warum ist CBRQ auf der PAK eigentlich dauerhaft "low"? Müsste das nicht dauerhaft "high" sein? Logic-Analyzer-Probe einfach nicht angeklemmt?

[Lukas Frank]

CBRQ ist nicht angeschlossen da nicht vorhanden auf der PAK68/2, sollte ich das Signal auf high legen ?

[czietz]

Du schriebst mal

Gerade mal durchgepiept, der Anschluss CBRQ der MMU liegt bei Jumper Stellung "Burst Mode off" auf VCC.

Daher war ich schon davon ausgegangen, dass CBRQ an der MMU "high" ist. Sollte es hingegen dauerhaft "low" sein, wäre die MMU sicherlich verwirrt.

[Lukas Frank]

Verwirrung ...

Ist aber alles richtig und zwar wird CBRQ an der TTMCU auf der Fastram Karte per Jumper auf +5V gelegt. und die Verbindung zum Fastram Karten 96pol. Stecker ist dann keine Verbindung mehr vorhanden. Die Drähte zum Analyzer sind an der 96pol. Steckerverbindung angelötet ...

[czietz]

OK, gut, dann nächster Schritt: Triggern tatsächlich auf Fast-RAM-Zugriffe.

Die Saleae-Software kann auch komplexere Triggerbedingungen. Ich würde probieren zu triggern gleichzeitig auf:

- Fallende Flanke /AS (eine Adresse wurde angelegt) und
- A24 = 1 (Fast-RAM-Zugriff) und
- FC1 = 0 (Datenzugriff, damit Dir keine "CPU Space Cycles", z.B. Interrupt Acknowledge dazwischen kommen).

Eine Aufzeichnungsdauer von einigen Mikrosekunden reicht.

Dann sollten wirklich nur noch die Datenzugriffe aufs Fast-RAM übrig bleiben.

[Lukas Frank]

Wenn ich nur 8 Kanäle nutze geht die Samplerate bis 32MS/s.


Ich bin jetzt total überfordert ...

Ich glaube da kommt nichts Sinnvolles bei rum. Wenn ich den Trigger ausser bei AS auch bei den FC Signalen setze wartet der Analyzer auf einen Trigger der nicht kommt und er nimmt dann natürlich nichts auf.

Problem ist auch ich weiß nie wann ich auf Start beim Analyzer klicken soll. Der Testrechner hat nur ein Diskettenlaufwerk und wenn ich den Basiccode starte werkelt erst das Diskettenlaufwerk und ein paar Sekunden später wird der Bildschirm weiss und ich klicke etwas vorher auf Aufnahme. Die Aufnahme Zeit muss so natürlich minimal 10 Sekunden betragen ...

[czietz]

Problem ist auch ich weiß nie wann ich auf Start beim Analyzer klicken soll. Der Testrechner hat nur ein Diskettenlaufwerk und wenn ich den Basiccode starte werkelt erst das Diskettenlaufwerk

Ich dachte eher daran, den Befehl im Omikron-Interpreter einzutippen und dann beim Analyzer auf Start und beim ST auf Return zu drücken.

Vielleicht mag jemand anderes 68k-kundiges prüfen, ob die Triggerbedingung richtig ist, die ich Dir genannt habe...

[Lukas Frank]

Ich dachte eher daran, den Befehl im Omikron-Interpreter einzutippen und dann beim Analyzer auf Start und beim ST auf Return zu drücken.

Ja so dachte ich ja auch aber wenn ich auf Start klicke beim Omikron 5 dauert es einige Zeit bis sich etwas tut. Und Ehrlich gesagt kann ich nicht abschätzen wann die Befehle abgearbeitet werden. So muss ich mehrere Aufnehmen und weiss dann nicht was davon die Abfolge der Befehle wieder spiegelt.

Wenn man die Befehlszeilen so erweitern könnte das ich ein lauffähiges Programm erzeugen könnte bei dem sowas wie ein runterzählen oder das eine Schaltfläche hätte ...

[1ST1]

Macht das doch in einem Maschinensprache-Monitor, das ist unmittelbarer. Bugaboo oder so. Basic hat viel Overhead.

[czietz]

Ja so dachte ich ja auch aber wenn ich auf Start klicke beim Omikron 5 dauert es einige Zeit bis sich etwas tut.

Hm? Mein Omikron-Basic-Interpreter v.3.irgendwas hat eine Konsole, auf der Befehle sofort ausgeführt werden, wenn ich Return drücke. Nix mit "auf Start klicken".

Macht das doch in einem Maschinensprache-Monitor, das ist unmittelbarer. Bugaboo oder so. Basic hat viel Overhead.

Das ist sicherlich die bessere Lösung, aber ich habe die Befehle für Bugaboo, Tempelmon und Co. nicht im Kopf? Du zufällig?

[Lukas Frank]

Alles an Omikron bis 3.03 läuft nicht auf dem 020 und stützt ab beim Start. Anbei die 5er Demo ...

[Lukas Frank]

Ich könnte ja TEMPLMON nehmen aber weiß nicht was ich eintippen soll ...