Fastram mit PAK68/2 ...

[Lukas Frank]

Mir widerstrebt das zwar aber ich muss Einfach das Handbuch lesen ;-)

Habe aber im Moment keine Zeit dazu ...

[czietz]

Woran genau hängt es denn bei Dir? Was spuckt PALASM statt des .JED-Files aus?

Ich habe hier auch noch ein PALASM (wobei ich meine GALs letztlich in ABEL entworfen hatte). Allerdings kann ich @joejoes U12TTRAM.PDS mit meinem PALASM nicht mal compilieren, es beschwert sich über diverse Syntax-Fehler. Die zu fixen, dazu habe ich im Moment keine Zeit. Schick mir eine PDS-Datei, die ohne Syntax-Fehler durchläuft, dann erstelle ich Dir die .JED-Fusemap daraus.

[Lukas Frank]

Hast einen Download Link zu dem ABEL Paket für Windows ?

[czietz]

Was ich nicht kapiere, ist die Bemerkung an Pin 15 (nicht als input nutzbar)

Bei einem GAL20V8 (und ein PALCE20V8 ist m.W. 100% dazu kompatibel) kann Pin 15 im sogenannten "Complex Mode" eben nicht als Eingang benutzt werden. Der "Complex Mode" ist aber nötig, damit Tristate-Ausgänge (in diesem Fall DSACKx) überhaupt möglich sind. => Ist so nicht in einem GAL20V8/PALCE20V8 abbildbar.

[czietz]

Hast einen Download Link zu dem ABEL Paket für Windows ?

Ich nutze eine DOS-Version, die es als Shareware gab. Download-Link kenne ich jetzt keinen, müsste ich auch er"google"n.

[Lukas Frank]

Dann eben mit 22V10 ...

Aber das original U12 ist doch auch ein GAL20V8 ?

DOS Version von ABEL ist doch gut.

[czietz]

Aber das original U12 ist doch auch ein GAL20V8 ?

... und verwendet Pin 15 (A0) nicht als Eingang. Erst joejoes Variation tut das und ist daher nicht mehr compilierbar.

[czietz]

Das andere Problem mit den Gleichungen aus Post #109 ist:

dsack_en =  as_20 * /cpuspace  * (tosx06 + fram);

Man muss für dsack_en dann einen eigenen Pin spendieren, wie in joejoes Post #102. Leider ist nur keiner mehr frei. Die naheliegende Variante, das zu umgehen, indem man die obige Gleichung direkt einsetzt und schreibt...

dsack0.trst = as_20 * /cpuspace  * (tosx06 + fram);
dsack1.trst = as_20 * /cpuspace  * (tosx06 + fram);

ist zum Scheitern verurteilt, weil die TRST- bzw. Output-Enable-Eingänge bei GALs nur einen Produktterm haben dürfen, also nur über "*" (UND) verknüpfte Variablen, keine über "+" (ODER) verknüpften.

[Lukas Frank]

Ginge es denn wenn man U12 original belässt für den TOS Eprom Zugriff und ruckepack obenauf ein weiteres GAL setzt mit der Logik für den Fastram Zugriff mit A24 und den Busabschluss über DSACK0/1 ...

[joejoe]

Dann kracht es beim Rom-Zugriff, da das Ende des Atari-FastRAM-Bereichs sich mit dem TOS-Bereich überlappt wg. Spiegelung an A24.

Dann arbeiten die Ausgänge der ROMs gegen die der TT-FastRAM-MMU.

Die von mir vorgeschlagene Variante in Post #109 ist als Entwurf einer 'abgespeckten + zurückgebauten Version" der *froam.pds  war als Schriitt in die richtige Richtung mit minimalem Verdrahtungsaufwand gedacht. Ob das so in ein 20V8 passen würde weiß ich tatsächlich nicht. Bin mir allerdings sehr sicher, dass die nicht abgespeckte Version, also mit den umgelegten und umgedeuteten PINs damals so funktioniert hat mit einem 22V10 GAL.
Das dsack_en war vermutlich eine "burried fuse", also ohne eigenen Anschluß.
Das sollte vermutlich eine Gatterlaufzeit generieren, was aber mittels 'Minimize On' dann doch sofort wieder zu czietz direkter Variante geführt hat. Keine Ahnung, das ist einfach viel zu lange her.

Edit: czietz hat es, mal wieder, auf den Punkt gebracht, der Umweg war nötig um die Einschränkung bzgl. des Produkterms zu Umgehen, daher auch der zusätzliche Einsatz der Diode, wie im Post #102 beschrieben, damit ein, dann nicht verbundener, Pin für das dsack_en frei wurtde.
Die begrabene Sicherung kann ruhen, das war Quatsch, Sorry.

@czietz: compiliert denn die 'eierlegende Wollmichsau' aus post #102?

[joejoe]

Dann wäre doch eine Variante ideal, wie von czietz angrissen, mit der dasck_en -Lösung aus post #102 und einer zusätzlichen Diode, um /DSACK0 und /DSACK1^aus nur einem Augang zu gewinnen.
Das wäre die Variante mit dem geringsten Aufwand an zusätzlicher Verdrahtung, nur A24 und die Diode.

[czietz]

@czietz: compiliert denn die 'eierlegende Wollmichsau' aus post #102?

Ja, zur Variante aus Post #102:

Code: [Auswählen]

The JEDEC is stored in ===>post102.JED

 %%  PAL ASSEMBLER  %% Maximum memory allocated was: 17064 bytes.

 %%  PAL ASSEMBLER  %% File Processed Successfully.  File: post102.pds.
 %%  PAL ASSEMBLER  %% ERROR count: 0  WARNING count: 0

[joejoe]

okay, das wäre dann ja auch eine Basis.
Auch ohne SRAMs, wenn diese weggelassen werden, stört in dieser Variante dann ja nur der auf 1MByte beschränkte /DSACK-Bereich. Für einen Test mit der FastRAM-Karte sicher ausreichend.
Im Vergleich zum Verhau zum TTRAM-Steckverbinder wäre selbst der Umverdrahtungsaufwand vertretbar.
Ein 20V8 frei nach Post #109 mit originalen PINout plus A24 plus DSACK_en und DSACK-Diode wäre die einfachste Variante, müsste dann nur nochmal compiliert werden.

[Lukas Frank]

Habe das PALASM Handbuch mal überflogen und ich verstehe nur Bahnhof und finde nicht was ich suche z.B. wie man ein Device vorgibt z.B. für ein GAL20V8 ein PAL20V8 ...

Das ist nichts für mich. Ich kann nur fertige JED Dateien in GALs brennen und das ganze Ausprobieren, mehr nicht !

[Lukas Frank]

Habe mal das "fastram.jed" in ein 22V10 gebrannt und U12 damit ersetzt. So bootet der Rechner überhaupt nicht mehr oder muss das doch ruckepack auf das alte U12 ?

Hatte auch etwas Zeit und habe für das Mainboard 6Stk. EmuTOS 0.97 Bausteine gebrannt und auf der PAK ganz ohne U12, Jumper J2 = off und ohne Eprom in den PAK Sockeln bootet der Rechner überhaupt nicht !

Mit 68000 anstatt der PAK ist alles in Ordnung.

[joejoe]

Wie schon in Post #90 beschrieben, ist Grundvoraussetzung für Deine weiteren Experimente, das der Zugriff zum ST-Adressbereich vom FAstRAM-Bereich getrennt wird.
Hast Du das dann auch in den nachfolgenden Tests bereits so berücksichtigt ?

Falls nicht:
 
Die Trennung zum ST-Adressberecih erfolgt bei minimaler Dekodierung (also bis maximal 16MB FastRAM) allein durch A24, also muss auch A24 wie in Antwort #90 beschrieben an GAL U6 angelegt werden. Das Jedec-File für diese gepatchte U6-Variante hängt an Antwort #90.
Ohne diese Änderung kann das alles gar nicht gehen. Das war mir im alten Tread nicht mehr richtig in Erinnerung, daher ist dort U6 nicht mit enthalten gewesen.

A24 wird also anstelle des Jumpers angeschlossen.
Das geht auch ganz elegant mit einem Stück einreihiger Pfostenfeldbuchsenleiste.
Soll die "alte Funktion"  (also ohne A24 Auswertung) laufen, wird stattdessen der Jumper gesteckt.
Für das GAL sieht das dann aus, als wäre A24 immer low = ST-Adressbereich.

Schritt eins wäre also U6 brennen und ersetzen und den Jumper (welcher steht im PDS-File) stecken.
U12 ist Deine Variante, die TOS-ROMs stecken auf der PAK.
Dann sollte der ST mit der PAK/2 ganz normal laufen.

Für Fastram kann dann Fastram.jed als huckepack GAL auf U12 kommen.
Sofern die ROMs auf der PAK gesteckt sind  muss aber auch das untere U12 GAL mit A24 und passendem Inhalt versorgt werden.
Am einfachsten wäre es daher, auf der PAK zunächst auf ROM zu verzichten.
Also wie von Dir schon angefangen auch ganz ohne U12.
Was dafür (aktuell) genau nötig / möglich ist, übersteigt im Moment meine Kenntnisse.

Z.B. ein TOS 2.06 auf einer TOS-Card sollte den ST mit der PAK/2 dann aber laufen lassen.
TOS 2.06 erkennt zwar von sich aus kein FastRAM, behindert es aber auch nicht
Ob es wg. des 68020 gepatcht werden muß, weiß ich nicht mehr.

Wenn der ST mit PAK/2, TOS 2.06 "unten" im ST-Bereich und leeren ROM-Sockeln auf der PAK/2 und ohne U12 läuft, könnte im zweiten Schritt mit meiner Fastram-Variante ohne Umverdrahtungen ausser A2, also der "Fastram.jed" in U12, der Templemon Test rudimentär funktionieren.

Auch ohne Deine TT-RAM-Karte, da das fastram GAL U12 ja die DSACKs liefert.
Es kommt also kein Bus-Error (die Daten sind dann natürlich Müll, ohne FastRAM) .

Mit Deiner TT-FastRAM-Karte und den DSACKS aus dem GAL könnte dann der Zugriff auf den (im GAL ausdekodierten) FastRAM-Bereich funktionieren, sofern das Timing zufällig zum STERM-Timing passt. Wenn nicht, geht es dann da weiter.

Weiter viel Erfolg!

[joejoe]

JP2 = off entspricht A24 (aus Sicht des GALS) = dauerhaft high, da sind Pullups am GAL!
Klar das da nichts geht.
Mit JP2 => gesteckt = A24 dauerhaft low asu Sicht des GALs sollte weiterführen.
 

[Lukas Frank]

Ich hatte U6 mit A24 ja schon drin. Ich löte mal den 4,7k Pullup raus und schaue mir das nächste Woche noch mal an wenn ich ein paar Stunden am Stück Zeit finde ...

[joejoe]

Für einen Test, ob das mit dem U6-GAL funktioniert, ist der PullUP völlig irrelevant.
Im Zustand JP2 = gesteckt wird der PullUP ja gegen GND kurzgeschloßen.
Also ist aus Sicht des GALs A24 = low, und die alte Funktionalität ist gegeben, wenn nicht ist da etwas faul.
Ich bezweifele auch, ob der Pullup (dann auch an A24) im zukünftigen Betrieb schaden würde.
Bei meiner SRAM-Lösung hängt da nicht weiter viel dran, ob die TT-FastRAM-Karte eigene PullUPs am 32-Bit Adressbus hat, welche dann in Kombi mit dem PullUp auf der PAK parallel zu niederohmig sein könnten, weiß ich nicht.
Ein Test wie oben beschireben muss erstmal funktiuonieren. Ich hatte an der PAK-Platine nie etwas geändert. sondern ggf. modifizierte Zwischensockel eingesetzt.     

[Lukas Frank]

Die Atari und auch andere Fastramkarten haben keinerlei Pullups an den Daten oder Adressleitungen.

Die Adressleitungen A1 bis A23 haben ja auf den Atari Mainboard Pullups (4,7 oder 10k, weiss ich jetzt nicht genau!) und A0 auf der PAK, A24 bis A32 haben nichts ...