atari-home.de - Foren
Hardware => Hardware (High-End) => Thema gestartet von: Lukas Frank am Mi 18.01.2017, 19:16:11
-
Um mal zu probieren ob Atari TT Fastram auch mit der PAK68/2 mit MC68020 CPU funktioniert möchte ich mit Hilfe von Drähten eine original Atari 4/16MB Fastram Karte zusammen mit der PAK68/2 zum Laufen bringen. Auf der PAK68/2 ist ein gepachtes Atari TT TOS 3.06.
Problem sind vielleicht folgende Signale die der MC68020 nicht hat ...
- XCBACK
- XCBRQ
- XPOR
- STERM
STERM kann ich ansteuern über zwei 1N4148 Dioden jeweils zusammen über beide Anoden an den XSTM Anschluss der Fastramkarte. Die Kathoden jeweils einzeln auf DSACK0 und DSACK1 der MC68020 CPU.
XPOR ist das Reset Signal.
XCBACK ist vom MC68030 Cache Bus Acknowledge.
XCBRQ sollte CBREQ vom MC68030 sein, ebenfalls Cache Steuerung.
XCBACK und XCBRQ würde ich über jeweils einen 1k Pulllup entweder dauernd high oder über Jumper low auf GND legen.
Diese Cache Steuerung der original Atari Fastram Karte hat eine Magnum TT nicht, andere Fastramkarten warscheinlich auch nicht.
Wer hat Ideen oder Ratschläge für mich ?
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12815;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12817;image)
Der Schaltplan ist von der 4MB Karte, die MCU ist aber die Gleiche ...
-
Wenn ich das richtig sehe sind diese Signale für den Burst Modus Notwendig die a die Karte eh nicht kann und B du theoretisch nicht brauchst. ggf. die Eingänge einen definierten wert geben (inaktiv).
-
Burst wollte ich eh abschalten auf der Fastram Karte wegen dem MC68020 ...
Ist halt die Frage ob das Eingänge an der TTMCU sind ?
-
müßte man mal im Datenblatt zur CPU schauen, da die Leitungen ja zur CPU gehen.
-
CBACK in ein Eingang an der CPU, kommt also von der Fastramkarte und kann daher egal sein ...
CBREQ ist ein Ausgang an der CPU und müsste das auf der Fastram Karte auf high legen.
Beides ist low Aktiv ...
-
Sehe gerade das CBREQ über W3 auf der Fastramkarte auf high liegt bei Jumperstellung Burst Off und dann auch garnicht mehr benötigt wird.
-
Im Englischen Forum ist die Meinung das es mit den Dioden nicht funktionieren kann.
STERM ist ein Ausgang auf der Fastramkarte. Und wenn STERM high ist sollten DSACK0 und 1 gesetzt werden. Aber STERM ist doch low aktiv ...
Sollte ich besser zum Beispiel ein 16V8 GAL nehmen ?
-
Im Englischen Forum ist die Meinung das es mit den Dioden nicht funktionieren kann.
Es ist nicht die Meinung im englischen Forum, sondern eine Meinung eines Foren-Nutzers, die auch zum Teil schon wieder revidiert ist: "Diode can probably work".
STERM ist ein Ausgang auf der Fastramkarte. Und wenn STERM high ist sollten DSACK0 und 1 gesetzt werden. Aber STERM ist doch low aktiv ...
Irgendwas verstehe ich gerade falsch: Ist es nicht so, dass wenn /STERM low ist ("asserted" = aktiv), dann auch /DSACK0 und /DSACK1 low werden müssen?
Sollte ich besser zum Beispiel ein 16V8 GAL nehmen ?
Ich habe Dir im englischen Forum bereits Little Logic vorgeschlagen.
-
PS: Mit Little Logic ist die Schaltung genau die, die ich für mein Projekt "SCSI-Initiator-ID für ICD AdSCSI plus" entworfen habe: http://www.chzsoft.de/site/site/assets/files/1041/anleitung-icdfix.pdf (http://www.chzsoft.de/site/site/assets/files/1041/anleitung-icdfix.pdf). /SEL ist dann Dein /STERM, /D6 und /DP sind Dein /DSACK0 und /DSACK1.
-
Vielen Dank für die Unterstützung ...
Ich muss noch auf die Atari Fastramkarte aus England warten um das dann umzusetzen.
-
Ich warte noch auf die Fastram Karte und habe schon mal angefangen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12833;image)
Bin mal gespannt ob das funktioniert.
-
Fertig gelötet ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12835;image)
Der Rechner bootet ganz normal mit dem Drahtverhau und der Fastramkarte.
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12837;image)
Funktioniert aber nicht. Wäre ja auch zu schön gewesen ...
-
Was ist denn mit "CBACK" und "CBRQ" ?
CBRQ ist ja über den Burstmode off Jumper getrennt und liegt an der MMU auf GND.
STERM geht von der Fastramkarte gemeinsam auf zwei Kathoden von 1N4148 Dioden und die beiden Anoden jeweils auf DSACK0 und 1 der CPU.
Alle Steuersignale wie AS, DS, FC0 bis 2, SIZ0 und 1 und so weiter gehen direkt auf die entsprechenden CPU Anschlüsse.
Clock ist der 16Mhz Takt der MC68020 CPU.
-
Was funktioniert nicht? wird das Fastram nicht erkannt? hast du mal die YAART von Czietz drübergejagt? die neue version kann doch auch nicht eingeblendeten Speicher testen?
-
Mach doch mal eins,
Nimm GFA Basic, und mach ein kleines Testprogramm
a=random(65535)
dpoke $1000000,a
if dpeek($1000000) = a then
print "Speicherkarte ist ansprechbar"
endif
Wenn die Karte ansprechbar ist, dann sollte etwas passieren. Wenn zwei Bomben kommen dann ist sie nicht ansprechbar.
Frage ? Hast du SRAMS da 4 Stück ?
-
CBRQ ist ja über den Burstmode off Jumper getrennt und liegt an der MMU auf GND.
Warum eigentlich GND? Damit signalisierst Du nach meinem Verständnis der MMU doch einen Burst-Zugriff, den der 68020 gar nicht kann.
-
Habe mal den Burst Jumper geändert, der war falsch ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12839;image)
Der Plan ist ja von der 4MB only Atari Fastramkarte, die 4/16MB Karte von Atari ist etwas anders aber hat die gleiche MMU.
Das mit dem Basic Programm ist doch sinnlos weil TOS 3.06 welches auf der PAK68/2 werkelt beim Speichertest in der Bootphase das Fastram erkennen sollte genau wie bei einer PAK68/3 und FRAK Fastram Karte oder dem Atari TT ...
Die 16Mhz sind ja der Bustakt im Atari TT und die CPU läuft mit 32Mhz. Der Bustakt beim ST wären ja dann die 8Mhz, keine Ahnung ?
-
Gerade mal durchgepiept, der Anschluss CBRQ der MMU liegt bei Jumper Stellung "Burst Mode off" auf VCC.
War also Blödsinn mit GND ...
-
Das mit dem Basic Programm ist doch sinnlos weil TOS 3.06 welches auf der PAK68/2 werkelt beim Speichertest in der Bootphase das Fastram erkennen sollte
Nein, weil Du damit genau einen Zugriff auf den Speicher machst und nicht viele, wie TOS. Die Prüfung ob das jetzt klappt oder nicht (und zusätzlich, was dpeek($1000000) denn zurückgibt, wenn nicht) liefert evtl. weitere Hinweise, was schief läuft.
Auch kannst Du das Basic-Programm immer und immer wieder ablaufen lassen und mit dem Logic-Analyzer (zur Not: Oszilloskop) gucken, was Du Busleitungen beim Speicherzugriff machen. Ich denke nicht, dass wir das auf der Ferne debuggen können, dafür ist die Vielfalt an möglichen Fehler einfach zu groß.
-
Habe mir GFA Basic besorgt aber kann kein Programm erzeugen, bin zu blöd dazu ...
@tuxie .. wenn es geht mache mir doch bitte ein Programm daraus.
-
Den text kannst du so wie es ist übernehme, wenn ich mich nicht vertippt habe sollte das schon funktionieren.
Gibt eigentlich drei möglichkeiten
1. Du erhälst zwei Bomben da die TT-Ram karte den Zugriff nicht Quittiert
2. Es Funktioniert und das was geschrieben wurde konnte wieder gelesen werden
3. Es kommt kein Fehler aber du erhälst kein Ergebnis, da die Karte die Anfrag zwar Quittiert aber der zurückgelesenen wert mit dem geschriebenen nicht übereinstimmt
-
Das hilft mir nicht weiter ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12842;image)
-
Einfach GFABASIC öffnen
das File laden
und dann auf run klicken ?
Mußt du doch nicht Kompilieren
-
GFA starten "test.gfa" laden und auf run klicken ...
... manchmal kommt "Karte ist ansprechbar, und gibt güldige Werte zurück" mit der Box "Procedure nicht gefunden" und manchmal kommt einfach nur die Box "Programmende".
-
Hm, also wie schaut es mit der Spannungsversorgung aus ? Dicke Kabel zur Karte gelegt ? Ganz wichtig ist Masse.
-
Die Versorgung ist in Ordnung meine ich, die kommt vom Erweiterungsstecker hinter der Floppy beim Mega ST und zusätzlich noch GND von der 020 CPU ...
-
Versorgung ist extrem wichtig. Richtig dicke Kabel nehmen, haben auf der Prototypenplatine noch extra Versorgung legen müssen da es nicht gereicht hatte. Ansonsten nochmal genau schauen das alles richtig Kontakt gibt
-
Was Holger Zimmermann mir geschrieben hat macht die Sache mit verstärkten Stromversorgungsleitungen hinfällig ...
Das wird so nicht funktionieren, die Signale haben unterschiedliches Zeitverhalten.
DSACK0,1 wird von der CPU mit der fallenden Taktflanke eingelesen.
Falls aktiv, wird der Buszyklus mit der nächsten fallenden Taktflanke beendet, also einen
weiteren ganzen Taktzyklus nach DSACK.
STERM wird von einem 68030 mit der steigenden Taktflanke eingelesen.
Falls aktiv, wird der Buszyklus mit der nächsten fallenden Taktflanke beendet, also einen
halben Taktzyklus nach STERM.
Damit das funktionieren kann, hätte das beim Design der RAM-Karte berücksichtigt werden müssen!
-
Bedeutet das jetzt dass Fastram in Verbindung mit einem MC68020 nicht möglich ist ?
Also mit den TT Fastramkarten die es so gibt ...
Kann man das Timing von STERM und DSACK0/1 nicht irgendwie angleichen ?
-
Also ich würde sagen mit Fastramkarten für den 68030 nicht. Aber Frag doch mal Holger an ob er nicht die Firmware für unsere Storm anpassen würde. Vielleicht ist es ja gar nicht soein großer aufwand. Eine Testkarte könnte man ja schon zur Verfügung stellen
-
Habe mal gefragt ...
-
Kann man das Timing von STERM und DSACK0/1 nicht irgendwie angleichen ?
Tja, wenn man wüsste, wie die TT FMCU intern funktioniert, insbesondere nach welchen Bedingungen bzw. zu welchen Zeitpunkten sie STERM setzt (low) und wieder rücksetzt (high)... Würde aber auch dann vermutlich in Gefrickel enden.
-
Ich vermute doch stark genau so wie bei der Magnum TT und liegen die Quellen ja offen ...
-
Nicht bei unserer Storm, die sind nicht offen...
-
Hier mal die Magnum TT JED Quelldateien ...
-
Ja, aber ich halte es für unwahrscheinlich, dass Uwe Schneider exakt die Logik nachgebaut hat, die in Ataris TT FMCU steckt. Also helfen die Quellen leider nicht weiter, das Timing von /STERM zu verstehen und ob man /STERM doch irgendwie für den 68020 nutzen kann.
-
Meine Annahme war halt das der MC68030 /STERM in Bezug auf seinen Taktclock in einem bestimmten Timing erwartet und sich alle Atari TT Fastram Karten danach richten müssen. Und so alle gleich /STERM bedienen ???????
-
Die Magnum unterstützt kein burst, die Leitungen sind soweit ich mich aus dem Magnum Thread erinnert gar nicht angeschlossen
-
Das ist nicht richtig ...
-> http://www.uweschneider.de/Download.php
Die beiden Signale zur Cache Steuerung CBRQ und CBACK liegen zwar auf der VG Leiste sind aber am MACH210 nicht belegt.
/STERM wird bedient von der Magnum TT.
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12866;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=12868;image)
;PALASM Design Description
;---------------------------------- Declaration Segment ------------
TITLE TT-RAM Steuerung mit Burst Mode fuer FastPage RAM's
PATTERN
REVISION 1.15
AUTHOR Uwe Schneider
COMPANY
DATE 10.12.98
CHIP _ttram MACH210
;---------------------------------- PIN Declarations ---------------
; Inputs
PIN 35 CLK16 ; INPUT
PIN 42 RW ; INPUT
PIN 6 AS ; INPUT
PIN 41 SIZ0 ; INPUT
PIN 7 SIZ1 ; INPUT
PIN 43 A0 ; INPUT
PIN 37 A1 ; INPUT
PIN 3 FC0 ; INPUT
PIN 4 FC1 ; INPUT
PIN 17 A31
PIN 16 A30
PIN 18 A29
PIN 10 A28
PIN 8 A27
PIN 5 A26
PIN 2 A25
PIN 40 A24
PIN 33 PD0_0
PIN 32 PD1_0
PIN 29 PD0_1
PIN 31 PD1_1
PIN 36 0WS
; Outputs
PIN 39 STerm COMB ; OUTPUT
PIN 38 Row COMB
PIN 27 RAS_1B REG ; OUTPUT
PIN 24 RAS_1A REG ; OUTPUT
PIN 26 RAS_0B REG ; OUTPUT
PIN 25 RAS_0A REG ; OUTPUT
PIN 19 CAS_UU COMB ; OUTPUT
PIN 14 CAS_UM COMB ; OUTPUT
PIN 21 CAS_LM COMB ; OUTPUT
PIN 20 CAS_LL COMB ; OUTPUT
PIN 30 WE_1 COMB ; OUTPUT
PIN 28 WE_0 COMB ; OUTPUT
-
Meine Annahme war halt das der MC68030 /STERM in Bezug auf seinen Taktclock in einem bestimmten Timing erwartet und sich alle Atari TT Fastram Karten danach richten müssen. Und so alle gleich /STERM bedienen ???????
Nein, nur weil beide Karten mit dem 68030 funktionieren, heißt es nicht, dass beide /STERM gleich erzeugen.
-
@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 ?
-
@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 ?
-
Eigentlich genauso.
Poke $100000,0
Dpoke $100000,0
Lpoke $100000,0
print peek.......
print dpeek...
print lpeek.....
-
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.
-
Habe mal gemessen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13110;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13112;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13114;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13116;image)
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.
-
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.
-
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 ?
-
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.
-
Nochwas: Warum ist CBRQ auf der PAK eigentlich dauerhaft "low"? Müsste das nicht dauerhaft "high" sein? Logic-Analyzer-Probe einfach nicht angeklemmt?
-
CBRQ ist nicht angeschlossen da nicht vorhanden auf der PAK68/2, sollte ich das Signal auf high legen ?
-
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.
-
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 ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13119;image)
-
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.
-
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 ...
-
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...
-
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 ...
-
Macht das doch in einem Maschinensprache-Monitor, das ist unmittelbarer. Bugaboo oder so. Basic hat viel Overhead.
-
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?
-
Alles an Omikron bis 3.03 läuft nicht auf dem 020 und stützt ab beim Start. Anbei die 5er Demo ...
-
Ich könnte ja TEMPLMON nehmen aber weiß nicht was ich eintippen soll ...
-
Tempelmon: Lesen:
m 1000000
Schreiben:
: 1000000 ff
Ungetestet, weitere Details bitte dem Handbuch entnehmen.
-
Danke ...
Das kannte ich schon von der Mega4000 GK, ich wusste nur nicht das ich da 1000000 und dann weiter garnichts eingeben muss ;-)
-
Beim Lesen mit "m 1000000" kommt ":01000000 60"
Beim Schreiben kommt ein Bus Error ...
-
Verhindert die PAK68/2 vielleicht alles über 16MB (68000) und löst einen Buserror aus ?
-
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
-
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 ?
-
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.
-
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.
-
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.
-
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.
-
Hier
http://forum.atari-home.de/index.php?topic=12916.msg207982#msg207982 (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.
-
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 ...
-
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?
-
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
-
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 ?
-
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 ...
-
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.
-
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.
-
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 ?
-
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?
-
Vielen Dank für deine Hilfe ...
Ich schaue mir das an wenn ich etwas Luft habe.
-
Ich glaube ich gebe auf. Habe mir das alles mal näher angeschaut auch die Magnum TT Quelldatei zum MACH210 wegen STERM und das ist alles zu hoch für mich, da bin ich viel blöd zu ...
-
Na, wo Du Dir doch schon soviel Arbeit gemacht hast, würde ich nicht gleich (ganz) aufgeben.
Falls die PAK/2 nicht Deine einzige ist, hilft ev. erstmal beiseite legen und auf Ideen warten?
Obwohl ich eigentlich auch ganz andere Dinge zu tun hätte, läßt mich dieses Thema aus historischen Gründen nicht los.
Wie tuxie schon andeutete wäre ein (erster) Schritt zu FAstRAM mit der PAK/2 der Einsatz von SRAM in den ROM-Sockeln, huckepack unter den ROMs. Für einen Test reichen da 4 SRAMS z.B. http://www.ebay.de/itm/GD21761-AS6C1008-55PCN-Alliance-Memory-Sram-1-MB-2-7-V-bis-5-5-V-128Kx8-Pdip32-/132063200808?hash=item1ebf948628:g:uMgAAOSwT6pVzX7M (http://www.ebay.de/itm/GD21761-AS6C1008-55PCN-Alliance-Memory-Sram-1-MB-2-7-V-bis-5-5-V-128Kx8-Pdip32-/132063200808?hash=item1ebf948628:g:uMgAAOSwT6pVzX7M)
und meine GALs. Das ergibt läppische 512MB FastRAM (entspricht also nur dem gesamt verfügbaren Speicher in einem 520ST ;). Das Ganze läßt sich reversibel auf der PAK/2 verbauen. Wenn das dann klappt, hast Du zumindest die saubere Trenung von 32Bit FastRAM zu 16bit ST-Bus und kannst mit der Logik weitermachen (dann eher vereinfachen, da bei einer externen FastRAM-Karte die ganze Dekodierlogik wegfällt).
.
-
Da fällt mir ein, Du könntest ja zur Probe einfach mal meine GALs in Deinem Aufbau nutzen, ohne SRAMs. Das dann da die /DSACK-Signale für den FastRAM-Bereich gleich von dem PAK-GAL erzeugt werden, könnte ja eher hilfreich sein. (STERM wäre im ersten Schritt unbeschaltet.
-
Na, wo Du Dir doch schon soviel Arbeit gemacht hast, würde ich nicht gleich (ganz) aufgeben.
Falls die PAK/2 nicht Deine einzige ist, hilft ev. erstmal beiseite legen und auf Ideen warten?
Obwohl ich eigentlich auch ganz andere Dinge zu tun hätte, läßt mich dieses Thema aus historischen Gründen nicht los.
Wie tuxie schon andeutete wäre ein (erster) Schritt zu FAstRAM mit der PAK/2 der Einsatz von SRAM in den ROM-Sockeln, huckepack unter den ROMs. Für einen Test reichen da 4 SRAMS z.B. http://www.ebay.de/itm/GD21761-AS6C1008-55PCN-Alliance-Memory-Sram-1-MB-2-7-V-bis-5-5-V-128Kx8-Pdip32-/132063200808?hash=item1ebf948628:g:uMgAAOSwT6pVzX7M (http://www.ebay.de/itm/GD21761-AS6C1008-55PCN-Alliance-Memory-Sram-1-MB-2-7-V-bis-5-5-V-128Kx8-Pdip32-/132063200808?hash=item1ebf948628:g:uMgAAOSwT6pVzX7M)
und meine GALs. Das ergibt läppische 512MB FastRAM (entspricht also nur dem gesamt verfügbaren Speicher in einem 520ST ;).
Das mit den 512 MB darfst du gerne noch mal deiner Großmutter erzählen.
-
Das mit deinem GAL ohne SRAM kann ich gerne mal aufbauen. Die knapp 8,- Euro für ein SRAM von 4 für die Katz ist nicht so schön ...
Wie müsste dein GAL denn aussehen ohne die ChipSelekt Signale cs8 bis 11 die ich ja nicht brauche ...
;PALASM Design Description
;
; (c) M.Vlkel GK _Computer Freiburg
;
; Address Decoder fr On Board Speicher FAST-RAM
;
;
; Fr ATARI ST 0100 0000-0107 FFFF TT-Fast-Ram
; 4.11.93
; 08.07.94 neue Version
;------------------------------------------------------------------------
;---------------------------------- Declaration Segment ------------
TITLE 68020-16 PAK
PATTERN P20-20 = U12_ram
REVISION 1
AUTHOR Manfred Vlkel gendert J.Reinecke c't 10/92 AMIGA-Muster
COMPANY GK Computer
DATE 06/01/91
CHIP _p20_20n PALCE22V10
;---------------------------------- PIN Declarations ---------------
PIN 1 /as_20 COMBINATORIAL ; INPUT
PIN 2 /cpuspace COMBINATORIAL ; INPUT
PIN 3 siz0 COMBINATORIAL ; INPUT
PIN 4 siz1 COMBINATORIAL ; INPUT
PIN 5..10 a[18..23] COMBINATORIAL ; INPUT
PIN 11 a[29] COMBINATORIAL ; INPUT
PIN 12 GND
PIN 13 a[24] COMBINATORIAL ; INPUT !!!! VORHER: a[30] !!!
PIN 14 a1 COMBINATORIAL ; INPUT
PIN 15 a0 COMBINATORIAL ; INPUT
PIN 16 bank_0 COMBINATORIAL ; OUTPUT !!!! VORHER: a[16] !!!!
PIN 17 /cs11 COMBINATORIAL ; OUTPUT
PIN 18 /cs10 COMBINATORIAL ; OUTPUT
PIN 19 /cs9 COMBINATORIAL ; OUTPUT
PIN 20 /cs8 COMBINATORIAL ; OUTPUT
PIN 21 /dsack1 COMBINATORIAL ; OUTPUT
PIN 22 /dsack0 COMBINATORIAL ; OUTPUT
PIN 23 bank_1 COMBINATORIAL ; OUTPUT !!!! VORHER: a[17] !!!!
PIN 24 VCC
; die PINs bank_0, bank_1 werden mit den nun abgebogenen PINs CE2 (PIN 30)
; der statischen RAMs verbunden, bank_0 geht an die unteren, bank_1 an die
; oberen 512 kB (alle RAMs einer Bank miteinander verbinden)
string uucs '( /a0 * /a1 ) '
string umcs '( /a1*siz1 + a0*/a1 + /a1*/siz0 )'
string lmcs '( a0*/a1*/siz0 + /a1*siz0*siz1 + /a1*/siz0*/siz1 + /a0*a1 )'
string llcs '( a1*siz1 + a0*a1 + /siz0*/siz1 + a0*siz0*siz1 )'
string fram '( a[24] * /a[23] * /a[22] * /a[21] * /a[20] )'; 1 MB
string romE0 '(/a[24] * a[23] * a[22] * a[20] * /a[20] )'; E0
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cs11 = as_20 * /cpuspace * uucs;
cs10 = as_20 * /cpuspace * umcs;
cs9 = as_20 * /cpuspace * lmcs;
cs8 = as_20 * /cpuspace * llcs;
bank_1 = /a[19] * fram;
bank_0 = a[19] * fram;
dsack0.trst = as_20 * /cpuspace * fram
dsack1.trst = as_20 * /cpuspace * fram
dsack0 = as_20 ;
dsack1 = as_20 ;
Und reicht nur A24 für die 16MB auf der Fastramkarte aus? Und ist der Buserror damit Geschichte beim Zugriff auf das Fastram oberhalb der ersten 16MB?
STERM ist ja nur ein Ausgang auf der Fastramkarte. Möglichkeit eins wäre STERM auf einen Eingang vom GAL zu führen und damit DSACK0 und 1 zu erzeugen um dem Buszugriff abzuschliessen. Oder STERM ausser acht zu lassen und den Busabschluss ausschliesslich im GAL zu erzeugen.
-
Das mit den 512 MB darfst du gerne noch mal deiner Großmutter erzählen.
Ich denke da hat er sich vertippt und meint 512K. ;)
-
Bei Kessler haben die 512kBx8 DIL32 SRAM für 5,69 Euro ...
- 628512-LP55 SRAM = AS6C4008-55PCN -
-
Ergibt - ohne das mit meiner seligen Großmama zu diskutieren ; - immerhin 2 MegaByte FastRAM bei einer Lage. Ist natürlich immer noch weit von den 16MB DRAM Deiner TT-Karte entfernt, sollte aber mindestens genausoschnell sein (und z.B. für NVDI viel bringen). Es gibt (gab?) auch noch die schmalen Cache-SRAMS mit nur 15ns Zugriffszeit. Ob es die größer 1MBit gab, keine Ahnung.
Aber nochmal zu Erinnerung:
Wenn das SRAM nicht anstelle des ROMs eingesetzt wird, brauchst Du ein GAL zusätzlich.
Falls ROMRAM oder die anderen Tools auch ein gepatchetes TOS 3.06 ins ST-RAM laden können kann das ROM in den 32bit Fassungen der PAK direkt durch das SRAM ersetzt werden und es braucht kein Doppelstock-GAL.
Ich vermute allerdings stark, dass auch U6 (P20_22) mit A24 versorgt werden muss (und das das auch bisher die Funktion Deine FastRAM-Variante torpediert). In Deinen Quellen zu U6 steht ja****************************************************************
P20_22.PDS 1779
****************************************************************
;PALASM Design Description
;
; ATARI ST
;
; Address Decoder fr FPU , schnellen ROM Zugriff
; Buserror, CPUSPACE, ...
;
; Jumper 2 : System ROM auf PAK
; 3 : deaktivert PAK Mem , erlaubt die verwendung von
; A24 - A31 als TAG Bits in mancher Software
; ( z.B. Tempus 2.0 )
; 4 : deaktiviert FPU d.h. erzeugt buserror
;
;---------------------------------- Declaration Segment ------------
TITLE PAK 68020-16
PATTERN p20_22
REVISION 1
AUTHOR M.V”lkel
COMPANY GK Computer
DATE 08/10/91
CHIP _p20_22 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 17 /csfpu COMBINATORIAL ; OUTPUT
PIN 18 /cpuspace COMBINATORIAL ; OUTPUT
PIN 19 /cycle_00 COMBINATORIAL ; OUTPUT
PIN 20 /romsel COMBINATORIAL ; OUTPUT
PIN 21 /berr_20 COMBINATORIAL ; OUTPUT
PIN 22 /berr_00 ; INPUT
PIN 23 /as_20 ; INPUT
PIN 11 /jp2 ; INPUT
PIN 15 /jp3 ; INPUT
PIN 16 /jp4 ; INPUT
PIN 1..8 a[16..23] ; INPUT
PIN 9 a29 ; INPUT
PIN 10 a30 ; INPUT
PIN 13 fc0 ; INPUT
PIN 14 fc1 ; INPUT
; ROM Adressen :
; sysrom = Systemrom ATARI FC0000 - FCFFFF
; addmem = " E00000 - EFFFFF
STRING adrFC 'a[23] * a[22] * a[21] * a[20] * a[19] * a[18] '
STRING sysrom '(adrFC * (/a[17]*/a[16] + /a[17]*a[16] + a[17]*/a[16] ))'
STRING addmem '( a[23] * a[22] * a[21] * /a[20] )'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cycle_00 =/( a30 * /a29 * /JP3
+ sysrom * jp2
+ addmem
+ fc0 * fc1 * /a[16] * a[17] * /a[18] * /a[19] ; fpu
)
romsel = /JP2 * sysrom
csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ;
cpuspace = fc0 * fc1 ;
;---------------------------------------------------------------------
; Buserror wird erzeugt bei |
; |
; Buserror vom 68000 System |
; FPU Select wenn JP4 gesteckt d.h. keine FPU im System |
; (erlaubt Software Emulation der Line F Befehle) |
; Breakpoint ACK cycle ( braucht 68851 PMMU ) |
; Access Level fetch " " " |
;---------------------------------------------------------------------
berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * a[16]
);
;----------------------------------- Simulation Segment ------------
SIMULATION
;-------------------------------------------------------------------
Statt a30 oder a29 sollte dann A24 ans GAL gelegt werden und weiterhin die GAL-Gleichungen passend um A24 erweitert werden.
Insbesondere cycle_00 kann so nur zu einem Doppel-Zugriff auf das FastRAM und das ST-Ram führen; das kann so nicht funktionieren.
Ich weiß nicht, ob U6 in meiner im andern Thread geposteten Variante dabei war, falls nicht suche ich nochmal danach.
-
U6 ist nicht drin, habe es bisher auch nicht gefunden.
Leider hatte ich damals vor dem Verkauf meiner gepatchten PAK auf ebay keine Bilder beiseite gelegt, daher kann ich nur aus dem Gedächnis (schwach, siehe den halben Gigayte-ST) wiedergeben.
-
So, hier nun die fehlenden Dateien für U6 mit A24 an JP2.
Mit viel Glück hilft Dir allein der Einsatz dieser Version von U6, um Deine Atari-TT-Fastram-Karte doch noch zum Laufen zu bewegen.
edit:
mit JP2 gesteckt = low anstelle A24 ergibt sich die "normale Funktion"
-
Mit deiner Version von U6 bootet der Rechner nicht mehr, wahrscheinlich weil das TOS 3.06 auf der PAK ist. Man müsste die Quelldatei so ändern das JP4 (FPU disable / GAL Pin 16) für A24 genutzt wird ...
-
Ist Jumper 3 gesteckt?
-
Darf nicht gesteckt sein, da dann per
cycle_00 = /( fpu
+ fastram
+ rom_E0
+ (rom_FC * JP3)
)
der Zugriff auf den ST-BUS = cycle_00 unterbleibt.
-
Ja bootet jetzt aber er zählt nur 3968kB ST Ram. Und damit der Rechner gebootet hat musste ich erst nach dem Einschalten den Reset Knopf drücken. Tempelmon gibt zurück beim Lesen "m 1000000" !:01000000 und hängt sich auf. Beim schreiben hängt er sich auch auf aber es kommt kein Buserror mehr ...
-
Brauche ich zusätzlich jetzt auch P20_22 ?
-
A24 ist auch an die GAL-Seite von JP2 angeschloßen?
-
Brauche ich zusätzlich jetzt auch P20_22 ?
Nein, "mein" U6 ersetzt das ja.
Du brauchst eher in U12 <=> P20_24 (damit bin schon damals immer ins Scheudern gekommen) eine passende DSACKx-Zeile.
templemon hängt sich nun vermutlich auf, weil der Zyklus beim FastRAM-Zugriff nicht terminiert wird.
Hier würde also etwas wie:
dsack0.trst = as_20
dsack1.trst = as_20
dsack0 = as_20 ;
dsack1 = as_20 ;
helfen.
Das ist nur ein schlechtes Beispiel, da hier alle 32bit Zugriffe (as_20) direkt quititert werden, und auch nur komplette Longwordzugriffe korrekt bedient werden
Hier könnte mein U12 weiterhelfen, da dort ja ein korrektes chip-select (für Deine FAstRAMKArte unnötig, schadet aber auch erstmal nicht) und DSACK0/1 erzeugt wird.
Wie das mit den ROMs dann läuft weiß ich nicht mehr ganz genau, kann sein dass das GAL nur mit dauerhaftem /CS für die ROMs arbeitet und die Datenausgänge nur per /OE freigibt. Das ist schneller und spart die /CS Leitung.
-
Ich dachte U12 bleibt und dein GAL kommt ruckepack oben drauf ?
-
Das kommt ganz darauf an.
Im Vollausbau (ROMS und SRAMS in den vier 32Pin-DIL Sockel gestapelt gibt ein 22V10 die benötigte Anzahl der /CS nicht her, daher die doppelstöckige Variante.
Wenn Du nur 4 SRAMs in die Sockel steckst, dann geht das auch mit _einem_ passenden GAL.
Dann muß das TOS dann in eine externe Tos-Card oder so (ev. ins RAM??). Das ergfibt dann allerdings einen 68000er Tower. Falls Tos 2.06 per se mit FastRAM und der PAK/2 umgehen kann (weiß ich nicht mehr soi genau) braucht es kein 3.06 auf der PAK (was aber die schnellste Variante wäre).
Ich hatte die c't-IDE-Karte mit integriertem TOS x.06 unter der PAK/2.
+Wie sieht denn Dein Aufbau aus?
-
Habe nur einen Mega ST4 mit TOS 1.04 auf dem Board. Könnte aber EmuTOS drauf machen. Eine TOS 2.06 Karte habe ich nicht.
Habe ein gepatchtes PAK68/3 TOS 3.06 auf der PAK da ich davon ausgebe das TOS 2.06 mit Fastram nicht umgehen kann.
Ich könnte mir auch bei Kessler die 512kB SRAMs kaufen aber ist dieses BANK0 und BANK1 nicht für insgesamt 8 SRAMs also im Falle der 512er 2MB in BANK0 und weitere 4 Stk. in BANK1 also insgesamt dann 4MB Fastram ?
-
Alles mit "ja" zu beantworten.
Da TOS 3.06 beim Start das FastRam auch auf Spiegelungen (an nicht ausdekodierten Adressleitungen ) etc. testet, also tatsächlich Schreib- und Lese-Zugriffe tätigt, reicht eine minimale Dekodierung des FastRAM, hier nur mit A24. Der Buserror beim FastRAM-Zugriff oberhalb 1 MB Fastram, wie von mir in U6 eingefügt, ist eigentlich überflüssig/ unnötig, bzw. bei Deinem 16MB Atari-TT-FastRAM hinderlich. Aber das kann dann ja in einem weiteren Schritt geändert werden.
Wenn Du nun nur eine Bank SRAMs einsetzt, bemerkt TOS 3.06 das, und bindet auch nur die eine Bank ein.
Ich kenne EMUTOS (noch) nicht, bin lange 'raus aus dem Thema.
Das originale U12 erzeugt nur /DSACK0 und /DSACK1 für 32bittigen ROM-Zugriff; 8 und 16bitige FastRAM Zugriffe werden falsch beendet, das funktioniert nicht. Hier kommt die Dekodierung nach "AMIGA-Muster" aus 1992 ins Spiel.
Für das TT-FastRAM müsste die STERM_nach DSACK-Dioden-Lösung her, oder eine weitere Verarbeitung von /STERM im GAL. Damit gehen dann auch nur 32bit-Zugriffe korrekt.
Macht aber ev. nix, da das Tos 3.06 auf das TTFastRam offenbar (siehe /STERM) nur 32bittig zugreift?!
Wenn Du weiterhin die TTFastRAM-Karte testen möchtest und eine Zyklus-Terminierung realisieren willst, dann muss etwas her wie oben beschrieben, oder besser mit A24 (s. U12_froam.pds/jed aus dem alten Thread). Ein erster Test könnte auch sein, in Deinem U12case ( a[24..16] ) begin
#h0E0..#h0EF:
begin
cs11 = as_20 * /cpuspace
cs10 = as_20 * /cpuspace
cs9 = as_20 * /cpuspace
cs8 = as_20 * /cpuspace
end
otherwise
case ( a[24..16] ) begin
#h100..#h1FF:
begin
cs11 = as_20 * /cpuspace
cs10 = as_20 * /cpuspace
cs9 = as_20 * /cpuspace
cs8 = as_20 * /cpuspace
end
otherwise
begin
cs11 = gnd
cs10 = gnd
cs9 = gnd
cs8 = gnd
end
end
dsack0.trst = cs11
dsack1.trst = cs11
dsack0 = as_20 ;
dsack1 = as_20 ;
Edit: das ist Quatsch so! reicht allenfalls als Denkanstoß :-[
Also auch nur 32bit /DSACKx.
Ob das so übersetzt werden kann .. keine Ahnung, ich hatte eben damals die korrekte Variante mit /siz0 und /siz1 verwendet.
Da das Kessler RAM ja viermal soviel RAM hat wie die von mir verendeten SRAMs muss auch das Pin-Out und die BANK-Logic überprüft werden.
-
Das hier war die "letzte" Variante von U12:
;PALASM Design Description
;
; (c) M.V”lkel GK _Computer Freiburg
;
; Address Decoder fr On Board Speicher FAST-RAM
;
;
; Fr ATARI ST 0100 0000-0107 FFFF TT-Fast-Ram
; 4.11.93
; rom_bank
; 5.9.94
; 12.12.94 JP3 entfernt, ram_1 auf PIN 23 gelegt
; 03.03.95
; Version fr TOS X.06 Autoboot mit TOS X.06-Anfang auf Mainboard
; Resetvektoren zeigen auf E0 0000.
;------------------------------------------------------------------------
;---------------------------------- Declaration Segment ------------
TITLE FROAM
PATTERN P20-20 = U12_FASTRAM
REVISION 1
AUTHOR Manfred V”lkel ge„ndert J.Reinecke c't 10/92 AMIGA-Muster
COMPANY GK Computer
DATE 06/01/91
CHIP _p20_20n PALCE22V10
;---------------------------------- PIN Declarations ---------------
PIN 1 /as_20 COMBINATORIAL ; INPUT
PIN 2 /cpuspace COMBINATORIAL ; INPUT
PIN 3 siz0 COMBINATORIAL ; INPUT
PIN 4 siz1 COMBINATORIAL ; INPUT
PIN 5 a[24] COMBINATORIAL ; INPUT !!!! VORHER: a[18] !!!!!
PIN 6..10 a[19..23] COMBINATORIAL ; INPUT
PIN 11 a1 COMBINATORIAL ; INPUT !!!! VORHER: a[29] !!!
PIN 12 GND
PIN 13 a0 COMBINATORIAL ; INPUT !!!! VORHER: a[30] !!!
PIN 14 /rom COMBINATORIAL ; OUTPUT !!!! VORHER: a1 !!!!
PIN 15 ram_0 COMBINATORIAL ; OUTPUT !!!! VORHER: a0 !!!!
PIN 16 rw COMBINATORIAL ; INPUT !!!! VORHER a[16] !!!!
PIN 17 /cs11 COMBINATORIAL ; OUTPUT
PIN 18 /cs10 COMBINATORIAL ; OUTPUT
PIN 19 /cs9 COMBINATORIAL ; OUTPUT
PIN 20 /cs8 COMBINATORIAL ; OUTPUT
PIN 21 dsack_en COMBINATORIAL ; OUTPUT !!!! VORHER: /dsack1 !!!!
PIN 22 /dsack0 COMBINATORIAL ; OUTPUT
PIN 23 ram_1 COMBINATORIAL ; OUTPUT !!!! VORHER: a[17] !!!!
PIN 24 VCC
; die PINs ram_0, ram_1 werden mit den nun abgebogenen PINs CE2 (PIN 30)
; der statischen RAMs verbunden, ram_0 geht an die unteren, ram_1 an die
; oberen 512 kB (alle RAMs einer Bank am PIN 30 miteinander verbinden)
; /rom geht an /OE (PIN 22) der EPROMS, /CE (PIN 20) der EPROMs im Sockel
; auf GND -> schneller Lesezugriff m”glich
; /dsack1 (alter Pin 21) im Adaptersockel wird durch Schottkydiode mit
; /dsack0 (PIN 22) verbunden (Kathode an PIN 22); PIN 21 GAL wird umgebogen
; bleibt unbelegt (notwendig fr ODER-Verknpfung in /dsack0)
; rw (PIN 16 GAL) wird mit R/W verbunden; notwendig fr 68030 Caches
string uucs '( /a0 * /a1 ) '
string umcs '( /a1*siz1 + a0*/a1 + /a1*/siz0 )'
string lmcs '( a0*/a1*/siz0 + /a1*siz0*siz1 + /a1*/siz0*/siz1 + /a0*a1 )'
string llcs '( a1*siz1 + a0*a1 + /siz0*/siz1 + a0*siz0*siz1 )'
string fram '( a[24] * /a[23] * /a[22] * /a[21] * /a[20] )'; 1 MB
string tosx06 '( /a[24] * a[23] * a[22] * a[21] * /a[20] )'; 0E0000 - 0EFFFF
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cs11 = as_20 * /cpuspace * (uucs + rw);
cs10 = as_20 * /cpuspace * (umcs + rw);
cs9 = as_20 * /cpuspace * (lmcs + rw);
cs8 = as_20 * /cpuspace * (llcs + rw);
ram_0 = /a[19] * fram;
ram_1 = a[19] * fram;
rom = as_20 * /cpuspace * tosx06;
dsack_en = as_20 * /cpuspace * (rom + fram);
dsack0.trst = dsack_en;
dsack0 = as_20;
Es ist dringend ein 22V10 notwendig, ein 20V8 hat nicht genug "Power".
Die Umbelegungen im PIN-OUT waren notwendig, um ausreichend Ausgänge frei zu schaufeln, indem iNPUT-Signale, welche ursprünglich an (im 22V10) potentiellen Ausgängen verdrahtet waren auf dedizierte INPUT-Pin verlegt wurden. Hier nicht benötigte Eingänge wurden umbelegt.
Der Text im PDS sollte weitere Fragen klären.
Ich hatte mir Türmchen aus Sockeln und GALs mit aufgelöteten Sockeln gebaut, um die Verdrahtung in weitrenen, modifizierten Zwischensockeln variabel gestalten zu können und keine GAL-Pins hin- (für die PAK) und her (zum Programmieren) biegen zu müssen.
Als Starter-ROMs "unten" auf dem ST hatte ich zwei 256kB-ROMs mit den entsprechenden (unmodifizierten) unteren HI-/LO-Teilen von TOS 2.06. Das ist zwar allein nicht lauffähig, startet dann aber ab nach E0...
Gruß und viel Erfolg
joe
EDIT: es war das gepatchte 3.06
-
und noch das jedec-file:
btw. wie übersetzt Du die PDS-Files?
Die hier verwendete Schreibweise funktioniert nur mit PALASM, nicht mit den ATARI GAL-Assemblern (die mir damals bekannt waren)
-
Wenn Du keine SRAMs einsetzt, reichen die Ausgänge eines 20V8 ev. auch. Dann musst Du auch die vielen Umbelegungen nicht durchführen, und könntest Dir dennoch das DSACK0/1 erzeugen.
Sehe eben, dass meine Ausführungen zu den 8-/16-/32-bit Zugriffen im Zusammenhang mit den DSACKs immer noch genauso falsch sind, wie von czietz im alten Thread schon angemerkt. Die Dekodierung der /CS per siz0/1 ist wichtig.
siehe auch mein U12. ;) 8)
-
Ich hatte mal PALASM unter DOSBOX installiert aber komme damit nicht zurecht. Muss mal Google bemühen und nach einem Handbuch suchen ...
Ich würde lieber JEDI auf dem Atari nutzen aber der kann soweit ich weiß keine 22V10 und ich weiß nicht ob ich es hin bekomme die PDS Quellen in JEDI umzusetzen.
-
Okay,
wichtig ist bei den PALASM Quellen, dass die Polarität (positive oder negative Logik) eines INPUT oder OUTPUT in der PIN-Deklaration festgelegt wird.
Der Text auf der linken Seite der Gleichungen legt nur den Zustand fest (TRUE / FALSE), unabhängig, ob positive oder negative Logik verwendet wird. Das war bei den ATARI PAL/GAL-Assemblern anders!
Als Beispiel:
cycle_00 in U6 ist in den PIN-Definitionen als negative Logik definiert (WAHR bei Low),gekennzeichnet durch den Negations-Strich "/"
Wenn nun in denLogik-Gleichungen auf der linken Seite cycle_00 steht, dann ist der Ausgang WAHR (= low, siehe PIN-Definition!) wenn die rechte Seite WAHR wird.
Für Jedi muss das dann alles _passend_ umgestellt werden.
Nur zur Info, falls das jemand nicht weiß, und sich wundert warum es mit PASASM oder Jedi vice versa nicht so einfach klappt.
Gruß
joe
-
TOS 2.06 läuft wunderbar mit der PAK 68/2. Aber TOS 2.06 sucht nicht nach TT-RAM.
-
TOS 2.06 läuft wunderbar mit der PAK 68/2. Aber TOS 2.06 sucht nicht nach TT-RAM.
Ein wenig OT .
Hat ja niemand behauptet TOS 2.06 liefe nicht auf PAK, wegen dem Fastram nutze ich wie schon gesagt TOS 3.06 von der PAK68/3 ...
-
Habe zur Zeit auch kein PALASM installiert;
anbei ein U12.PDS wie ich es mir für Deine Atari-FastramKarte vorstelle:
Für ein 20V8 und mit a[24] anstelle von a[29]
;PALASM Design Description
;
; (c) M.Völkel GK _Computer Freiburg
;
; Address Decoder für On Board Speicher EPROM und DSACK0/1 ATARI-TT-FastRAM
;
;
; Für ATARI ST E00000-EFFFFF für TOS030
; und DSACK0/1 im Bereich 100 0000 bis 1FF FFFF = 16MByte ATARI-TT-FastRAM
;
;------------------------------------------------------------------------
;---------------------------------- Declaration Segment ------------
TITLE 68020-16 PAK
PATTERN P20-24
REVISION 1
AUTHOR Manfred Völkel, modified J.Reinecke 03/2017
COMPANY GK Computer
DATE 06/01/91
CHIP _p20_24 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 1 /as_20 COMBINATORIAL ; INPUT
PIN 2 /cpuspace COMBINATORIAL ; INPUT
PIN 3 siz0 COMBINATORIAL ; INPUT
PIN 4 siz1 COMBINATORIAL ; INPUT
PIN 5..10 a[18..23] COMBINATORIAL ; INPUT
PIN 11 a[24] COMBINATORIAL ; INPUT (war a[29])
PIN 12 GND ; INPUT
PIN 13 a[30] COMBINATORIAL ; INPUT
PIN 14 a1 COMBINATORIAL ; INPUT
PIN 15 a0 COMBINATORIAL ; INPUT
PIN 16 a[16] COMBINATORIAL ; INPUT
PIN 17 /cs11 COMBINATORIAL ; OUTPUT
PIN 18 /cs10 COMBINATORIAL ; OUTPUT
PIN 19 /cs9 COMBINATORIAL ; OUTPUT
PIN 20 /cs8 COMBINATORIAL ; OUTPUT
PIN 21 /dsack1 COMBINATORIAL ; OUTPUT
PIN 22 /dsack0 COMBINATORIAL ; OUTPUT
PIN 23 a[17] COMBINATORIAL ; INPUT
PIN 24 VCC ;
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
string uucs '( /a0 * /a1 ) '
string umcs '( /a1*siz1 + a0*/a1 + /a1*/siz0 )'
string lmcs '( a0*/a1*/siz0 + /a1*siz0*siz1 + /a1*/siz0*/siz1 + /a0*a1 )'
string llcs '( a1*siz1 + a0*a1 + /siz0*/siz1 + a0*siz0*siz1 )'
string fram '( a[24])' ; 16 MB
string tosx06 '( /a[24] * a[23] * a[22] * a[21] * /a[20] )'; 0E0000 - 0EFFFF
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cs11 = as_20 * /cpuspace * uucs * tosx06;
cs10 = as_20 * /cpuspace * umcs * tosx06;
cs9 = as_20 * /cpuspace * lmcs * tosx06;
cs8 = as_20 * /cpuspace * llcs * tosx06;
dsack_en = as_20 * /cpuspace * (tosx06 + fram);
dsack0.trst = dsack_en;
dsack1.trst = dsack_en;
dsack0 = as_20;
dsack1 = as_20;
-
Ich komme nicht klar ...
--- U12_24.LCI (JEDI) ---
U12_24 Addressdekoder fr TOS 2.06 ROMs auf der PAK 68/2 fr Atari ST
08-03-93 U12_24 aus P20_24 recompiliert, GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| a30
|________|
%ID
U12_24
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
a30 a1 a16 a0 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack0.OE = cs11;
dsack0 = as_20;
dsack1.OE = cs11;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
------------------------------------
Wie baue ich jetzt FRAM da ein und was ist mit uucs, umcs, lmcs, llcs ?
------------------------------------
;PALASM Design Description
;
; (c) M.Völkel GK _Computer Freiburg
;
; Address Decoder für On Board Speicher EPROM und DSACK0/1 ATARI-TT-FastRAM
;
;
; Für ATARI ST E00000-EFFFFF für TOS030
; und DSACK0/1 im Bereich 100 0000 bis 1FF FFFF = 16MByte ATARI-TT-FastRAM
;
;------------------------------------------------------------------------
;---------------------------------- Declaration Segment ------------
TITLE 68020-16 PAK
PATTERN P20-24
REVISION 1
AUTHOR Manfred Völkel, modified J.Reinecke 03/2017
COMPANY GK Computer
DATE 06/01/91
CHIP _p20_24 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 1 /as_20 COMBINATORIAL ; INPUT
PIN 2 /cpuspace COMBINATORIAL ; INPUT
PIN 3 siz0 COMBINATORIAL ; INPUT
PIN 4 siz1 COMBINATORIAL ; INPUT
PIN 5..10 a[18..23] COMBINATORIAL ; INPUT
PIN 11 a[24] COMBINATORIAL ; INPUT (war a[29])
PIN 12 GND ; INPUT
PIN 13 a[30] COMBINATORIAL ; INPUT
PIN 14 a1 COMBINATORIAL ; INPUT
PIN 15 a0 COMBINATORIAL ; INPUT
PIN 16 a[16] COMBINATORIAL ; INPUT
PIN 17 /cs11 COMBINATORIAL ; OUTPUT
PIN 18 /cs10 COMBINATORIAL ; OUTPUT
PIN 19 /cs9 COMBINATORIAL ; OUTPUT
PIN 20 /cs8 COMBINATORIAL ; OUTPUT
PIN 21 /dsack1 COMBINATORIAL ; OUTPUT
PIN 22 /dsack0 COMBINATORIAL ; OUTPUT
PIN 23 a[17] COMBINATORIAL ; INPUT
PIN 24 VCC ;
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
string uucs '( /a0 * /a1 ) '
string umcs '( /a1*siz1 + a0*/a1 + /a1*/siz0 )'
string lmcs '( a0*/a1*/siz0 + /a1*siz0*siz1 + /a1*/siz0*/siz1 + /a0*a1 )'
string llcs '( a1*siz1 + a0*a1 + /siz0*/siz1 + a0*siz0*siz1 )'
string fram '( a[24])' ; 16 MB
string tosx06 '( /a[24] * a[23] * a[22] * a[21] * /a[20] )'; 0E0000 - 0EFFFF
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cs11 = as_20 * /cpuspace * uucs * tosx06;
cs10 = as_20 * /cpuspace * umcs * tosx06;
cs9 = as_20 * /cpuspace * lmcs * tosx06;
cs8 = as_20 * /cpuspace * llcs * tosx06;
dsack_en = as_20 * /cpuspace * (tosx06 + fram);
dsack0.trst = dsack_en;
dsack1.trst = dsack_en;
dsack0 = as_20;
dsack1 = as_20;
-
Die Strings 'uucs','FastRAM' etc. werden von PALASM beim Compilieren einfach erweitert, sobald der Compiler auf einen solchen String stößt.
Das konnte JEDI glaube ich nicht. Also einfach per copy und paste in die GAL-Gleichungen einfügen.
'uucs' etc, also die steuerung der byte/word/longword Zugriffe ist ohne SRAM für den einfachen Test mit Deiner TT-FastrAM-Karte aber gar nicht nötigt, das macht ja alles die FastRAM-MMU:
Damit FastRAM von normalem RAM bzw. ST-Adressbereich unterschieden werden kann, ist A24 nötig, und bei 16MB Fastram auch schon ausreichend, für eine vollständige Dekodierung der 16MB FastRAM (16 MByte = A0 bis A23)
Die DSACKs kannst Du entweder hier (in U12) auch für die TT-FastRAM-Karte erzeugen, oder machst das per STERM irgendwie extern.
Eine eigene Variante von U12 für Deine FAstRAM-Karte ist nur notwendig, damit A24 auch für die ROM Dekodierung ausgewertet werden kann. Ansonsten überlappen sich ROM bei 0x0E0++ und das Ende Deines FastRAMS bei 0x1E0++.
Meine letzte U12-Variante mit SRAM ist eine gemeinsame Lösung für SRAM im FastRAM-Bereich und ROM in den vier Sockeln mit dann nur einem GAL, Muss dann aber ein 22V10 sein und einige Signale müssen umgelegt werden, damit alles in ein GAL passt.
Das ist aber für die TT-FastRAM-Version nicht nötig.
Der mindesten Fortschritt, den ich damit erwarte ist, dass Templemon sich nicht mehr aufhängt, dann /DSACKs beim Zugriff aufs FastRAM kommen sollten.
Ob die Daten trotz des eigentlich von der TT-FastRAM-Karte erwarteten synchronen Zugriffs auch korrekt gelesen und geschrieben werden können, steht auf einem anderen Blatt.
Das wäre dann der nächste Schritt.
Was ich nicht kapiere, ist die Bemerkung an Pin 15 (nicht als input nutzbar)
Woher kommt das? ist das originale U12 auch schon ein 22V10? und das (Pin 15 = Input) geht nur mit einem 22V10?
-
Ich versuche heute Abend mal DOSBOX unter Windows 7, auf dem Mac komme ich mit der Tastatur nicht klar ...
-
Unter Windows will es nicht klappen. Da ist irgendwas mit den config Dateien von PALASM nicht in Ordnung, keine Ahnung ...
Unter macOS geht es jetzt aber, ich nutze einfach ein zusätzliches PC USB Keyboard wegen der Tastaturbelegung.
Aber ich kann kein JED erzeugen, bin zu doof. Muss mich wohl erst durch das Handbuch lesen ...
-
Ich habe leider auch keine lauffähige PALASM-Installation zur Hand.
-
Läuft ja, ich bin nur du Dumm dafür ...
In JEDI umsetzen bekomme ich nicht hin also muss ich mich durch PALASM kämpfen. Bis dahin geht nichts weiter ...
-
Welchen Weg verfolgst Du denn eigentlich zur Zeit?
Ein GAL für U12 mit A24 plus die /DSACKs für Deine AtariTT-FastRAM-Karte?
Hast Du eine funktionierende JEDI-Quelle für U12 mit TOS 3.06 in den PAK-Sockeln?
Ich hatte damals immer Zugriff auf PALASM und ALLPROG-Programmer; daher habe ich leider keine Ahnung von JEDI und Atari-GAL-Programmier-Geräten.
Woran hakt es denn (bei JEDI) konkret?
Poste doch mal Deinen aktuellen Stand.
-
Ich schau mal das ich es dir für jedi heute Abend umsetze, ich hoffe ich schaffe es Zeitmässig
-
In #110 ist das JEDI LCI, ist aber auch nicht von mir. Soweit ich weiss kann JEDI nur 16V8 und 20V8, keine 22V10 und kann keine Klammern im Code verarbeiten. Man muss alles einzeln auflösen ...
PALASM ist schon gut, ich muss das nur verstehen. Wenn ich dein p20_24.pds kompilieren will kommt immer das kein Device definiert sei. Ich weiss aber nicht wo ich das angeben sollte ?
-
Huh, das ist im letzten Jahrtausend programmiert ;)
Dunkel kann ich mich an eine Auswahl per Cursor aus der Liste der von PALASM unterstützten PALs erinnern. GALs waren schon damals zu neu für PALASM bzw. kamen von einem anderen Hersteller??.
Die Auswahl von PALCE20V8 bzw. PALCE22V10 hat allerdings zum entsprechenden GAL kompatiblem JEDEC-File geführt.
Ich muss 'mal die alte XP-Kiste hervorholen & anwerfen, da hatte ich die letzte lauffähige Version von PALASM drauf.
-
Mir widerstrebt das zwar aber ich muss Einfach das Handbuch lesen ;-)
Habe aber im Moment keine Zeit dazu ...
-
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.
-
Hast einen Download Link zu dem ABEL Paket für Windows ?
-
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.
-
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.
-
Dann eben mit 22V10 ...
Aber das original U12 ist doch auch ein GAL20V8 ?
DOS Version von ABEL ist doch gut.
-
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.
-
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.
-
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 ...
-
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?
-
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: compiliert denn die 'eierlegende Wollmichsau' aus post #102?
Ja, zur Variante aus Post #102:
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
-
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.
-
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 !
-
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.
-
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!
-
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.
-
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 ...
-
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.
-
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 ...
-
Ja genau, auf meinem alten 520STM waren es 10k, für größere Stabilität mit den diverse Erweiterungen im Verbund mit den 373+244?? Paaren auch gern auf 3k3 oder 4k7 getauscht.
Also sollte der PullUp an JP2 auf der PAK/2 auch nicht stören.
-
etwas off topic:
wenn ich mir die Probleme mit dem IDE-GAL und JEDI so ansehe, schlage ich vor, Du arbeitest Dich ein wenig in PALASM ein. Das ist kostenlos und hat bei mir auch noch unter W7 funktioniert (vermutlich), unter XP ganz sicher. Die c't-GAL Quellen aus diesen Jahren waren doch meist mit PALASM erstellt.
Zur Not muss eben ein W98 im VMWare-Player her, oder so.
-
Die gesamten Files der Pak sind mit Jedi gemacht, selbst Holger Zimmermann arbeitet auch jetzt noch damit. Das hier wirklich ein Jedi Bug vorliegt, ganz ehrlich würde ich ausschliessen.... würde da eher auf Denkfehler tippen...
-
Na dann...
-
Die gesamten Files der Pak sind mit Jedi gemacht, selbst Holger Zimmermann arbeitet auch jetzt noch damit. Das hier wirklich ein Jedi Bug vorliegt, ganz ehrlich würde ich ausschliessen.... würde da eher auf Denkfehler tippen...
Guck Dir mal http://forum.atari-home.de/index.php?topic=12775.msg215678#msg215678 an, wo JEDI offenbar ohne jegliche Warnung eine Gleichung einfach nicht synthetisiert. Wenn das kein Bug ist, was dann? Vor allem, wenn man penibel auf die Reihenfolge der Gleichungen achten muss, weil man sonst falsche JEDEC-Files erhält, dann ist das zumindest fehlerträchtig.
EDIT: OK, es ist der Kommentar "% Signal TOS wegen EEPROMs %", der JEDI im o.g. Beispiel verwirrt. Nimmt man ihn weg, wird das File korrekt assembliert. Das Kommentarzeichen laut JEDI-Hilfe ist auch ' und nicht %, aber dennoch würde ich immer noch einen Syntax-Error in der Zeile mit Kommentar erwarten. Oder zumindest eine Fehlermeldung, wenn dem vermeintlichen Input /TOS plötzlich ein Ausgabewert zugewiesen wird.
-
Ja bootet jetzt aber er zählt nur 3968kB ST Ram. Und damit der Rechner gebootet hat musste ich erst nach dem Einschalten den Reset Knopf drücken. Tempelmon gibt zurück beim Lesen "m 1000000" !:01000000 und hängt sich auf. Beim schreiben hängt er sich auch auf aber es kommt kein Buserror mehr ...
@joejoe ... wie in Beitrag #94 beschrieben bootet der Rechner ja mit deinem U6 und A24, es funktioniert aber nicht richtig da DSACK0/1 fehlen. U12 kann ich ja nicht ersetzen da sonst kein booten von dem TOS 3.06 auf der PAK mehr möglich ist ...
-
Dann bleiben nur zwei (3) Ansätze, um hier weiterzukommen.
1. Du änderst Deine JEDI-Gleichungen für U12 derart, dass A24 sowohl in die TOS-Select Gleichungen (A24 = 0), wie auch in den DSACK-Term eingeht (für das zusätzliche Fastram wenn A24 = 1).
2. Möglichkeit: meine 22V10 Variante mit den dort beschriebenen Umbelegungen.
Das geht, wie schon gesagt, auch mit einem / mehreren Zwischensockel(n).
(3) Die /STERM Variante mit zwei Schottky-Dioden, wie von Dir ganz am Anfang bereits versucht.
Nur muss hier ebenfalls das GAL aus Möglichkeit 1 zumindest mit A24 versorgt werden, damit das TOS eben nur bei A24 = 0 aktiv wird.
-
Ist das Problem mit U12 nicht das wenn ich A24 mit einbeziehe ich eine andere Adresse weglassen muss weil keine Pins mehr frei sind und damit das booten von dem TOS auf der PAK nicht mehr funktioniert ...
Kann man die Funktion von U12 auf zwei 20V8 GALs aufteilen ?
-
An U12 liegen die (auch für Fastram) vermutlich nie weiter relevanten Adressleitungen A29 und A30.
Die brauchte es damals für den Amiga.
Vermutlich wurden die in den ATARI GALs auch nie verwendet (musst Du 'mal nachsehen).
Einen dieser Eingänge mit A24 verbunden, diesen Eingang zusätzlich in die TOS-Gleichung für die PAK-ROMs mit aufgenommen ( für 0x0EXX..) und mit AS_20 + /cpuspace + (TOS + FRAM) die DSACKs für den FAstRAM-Bereich erzeugen.
Der zweite nicht benötigte Eingang (A29 oder A30) könnte dann als Eingang für das STREM der ATRAI-TT-FastRAM-Karte dienen.
Solange Du tatsächlich keine SRAMS aufs Byte genau ausdekodieren musst (weil gar nicht vorhanden) entfällt auch der /SIZx-Anteil für den FASTRAM-Bereich, das macht ja (hoffentlich) die TT-FASTRAM-MMU).
Hätte ich noch einen ST und 'ne PAK/2 würde ich ja den Aufwand selbst treiben, denn die TT-FASTRAM-Karten kosten ja nicht mehr die Welt. Dein Ansatz ist nicht uninteressant!
-
Habe dir eine PM geschrieben ...
Ich stelle dir gerne meine Sachen zur Verfügung.
-
Danke,
mein letzter Satz war allerdings eher nostalgisch verklärt.
Es hat schon seine Gründe, dass ich außer einer alten Falcon-Baustelle und einigen PoFos keine Atari Hardware mehr besitze, und mich (zur Zeit) auf Dinge konzentriere, die mehr als nostalgischen Wert haben. Wobei ich diesen Wert durchaus hoch einschätze.
Mir fehlt schlicht die Zeit, alle meine Interessen mit meinem "wirklichen Leben" unter einen Hut zu bringen. Sollte sich mein Traum vom entspannten Vor-Ruhestand einmal verwirklichen, komme ich gern auf Dein Angebot zurück. Allerdings vermute ich, dass Du dieses Problem dann schon lange selbst gelöst hast.
-
Habe gerade mal mit JEDI das U12_21.JED erzeugt und läuft. Da bleiben A19 und A30 frei und size0 und 1 sowie A0 und A1 werden ja wohl auch nicht benutzt ...
------------------
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a29 |11 14| a1
GND |12 13| a30
|________|
%ID
U12_21
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a29
a30 a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack0.OE = cs11;
dsack0 = as_20;
dsack1.OE = cs11;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
-
Ich würde dann A29 = Pin11 = sicher ein Eingang an einem 20V8 umbennen auf A24,
und dann in alle csx-Terme (da steht überall dasselbe drin, da ROM, d.h. es gibt nur Lese-Zugriffe auf diesen Bereich, da verwirft die CPU, was sie nicht braucht) in jeder Zeile !24 ergänzen.
Also folgendermaßen:
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
Dann muss natürlich A24 auch an Pin 11 hängen ;)
Damit sollte der ROM Zugriff (A24 = low) sauber vom FASTRAM-Zugriff (A24 = high) getrennt sein.
-
EDIT: das folgende ist falsch!
Wenn dann A19 zu /STERM umdefiniert wird.
In Jedi durch:
%PINS
!as_20 !csp siz0 siz1 a18 !sterm a20 a21 a22 a23 a24
a30 a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
EDIT Ende
und dann noch:
dsack0.OE = cs11 + sterm;
dsack0 = as_20;
dsack1.OE = cs11 + sterm;
dsack1 = as_20;
Dann _könnte_ alles laufen.
Ich hoffe, ich habe nichts übersehen.
-
Nicht a19 (wird ja in den ROM-Gleichungen genutzut), sondern A30
Also so:
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
!sterm a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
dann noch
sterm.oe = GND
da das ein Eingang wird.
-
Oder ohne /sterm:
%ID
U12_21
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
a30 a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack0.OE = cs11
+ a24 * !csp ;
dsack0 = as_20;
dsack1.OE = cs11
+ a24 * !csp;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
Bin mir allerdings nicht sicher, ob die /DSACK-Terme so compilieren.
Vermutlich ist für das dsackx.OE noch ein Zwischenschritt nötig, so wie von czietz in Post #127 näher erläutert.
-
Also so ohne STERM ...
-----------------
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| sterm
|________|
%ID
U12_21
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
!sterm a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack0.OE = cs11 + a24 * !csp;
dsack0 = as_20;
dsack1.OE = cs11 + a24 * !csp;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
sterm.OE = GND;
%END
-
... mit STERM
------------------
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| sterm
|________|
%ID
U12_21
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
!sterm a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack0.OE = cs11 + sterm;
dsack0 = as_20;
dsack1.OE = cs11 + sterm;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
sterm.OE = GND;
%END
-
ja, aber wird das übersetzt?
Den Umweg über einen zusätzlichen (sonst nicht angeschlossenen) Pin musste ich aus den in Post #127 von czietz genannten Gründen ja auch schon '94 in meiner 22V10 single-GAL Variante "froam.pds" gehen.
Sihe Post #102.
Die dortige Lösung mit einer Schottky-Diode für das zweite DSACK ist hier nicht nötig, da es mit der ehemaligen a30-Leitung ja noch eine in den Logik-Gleichungen nicht benötigten Knoten gibt.
Dieser Pin darf dann natürlich n icht mit a30 verbunden bleiben und hängt dann "in der Luft".
-
Klappt nicht ...
Fehler: 'Oder' in einer OE-Zuweisung.
File NICHT erfolgreich gescannt!
Error C:\ALT\JEDI.045\U12_STER.LCI 35: 'cs11' als Signal gefunden.
-
Dann also so, ohne STERM, mit Umweg über dsack_en, um indirekt die ODER-Verknüpfung für TOS-ROM ODER FASTRAM für die /DASCKx Erzeugung zu erhalten.
dsack_en ist ein (ansonsten nicht benutzter) Ausgang, wird nur GAL-intern genutzt..
-----------------
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13|dsack_en
|________|
%ID
U12_21
%TYP
GAL20V8A
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
dsack_en a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack_en = cs11 + a24 * !csp;
dsack0.OE = dsack_en;
dsack0 = as_20;
dsack1.OE = dsack_en;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
-
Ich habe null Ahnung wwie ich das einbauen sollte ?
So vielleicht ...
----------
dsack_en = cs11 + a24 * !csp;
dsack0.OE = dsack_en;
dsack0 = as_20;
dsack1.OE = dsack_en;
dsack1 = as_20;
-
Ähm,
genauso hatte ich es doch im vorherigen Post angegeben :)
Da ich nie mit JEDI gearbeitet habe, kann ich leider immer noch keine Garantie geben, ob das so nun sauber übersetzt wird. Die Probleme mit dem OE-Term sind natürlich generell vorhanden, und dem Aufbau des GALS geschuldet. Das hat nichts mit JEDI zutun.
Ich habe daher im Post #160 versucht Deine Quelle aus Post #151 entsprechend zu ändern, um die DSACKs auch für den Fastram-Bereich zu erzeugen, und A24 auch in die ROM-CS aufzunehmen.
Zunächst ohne STERM-Eingang.
Quasi die Light-Version meines "Single-GAL FROAM:PDS".
Was nun alles in eine JEDI-Quelle gehört, weiß ich auch nicht. Ich vermute das GAL-Pinout wird erst beim Übersetzen erzeugt?
An Pin 11 wird A24 angeschlossen (PIN steckt dann nicht im sockel) und PIN 13 hängt ebenfalls frei in der Luft, denn im Sockel liegt ja noch A30 an.
Wenn damit der ST sauber läuft, kannst Du zurück an den Anfang und Schreib-/Lese-Versuche auf das FastRAM starten. Funktioniert das dann nicht, kann STERM an einen weiteren Eingang gelegt werden und die dsack_en Gleichung passend erweitert werden. Wie Du ja schon richtig bemerkt hast, sind für den ROM Zugriff weder die SIZ-Eingänge, noch A0 nd A1 notwendig, da wäre also noch "Platz" für weitere Eingänge.
Viel Erfolg!
-
Ähm,
genauso hatte ich es doch im vorherigen Post angegeben :)
Ich bekomme nichts mehr mit, sorry !
JEDI wirft wieder einen Error : Error C:\ALT\JEDI.045\U12_OHNE.LCI 35: 'dsack_en' ist kein Ausgang!
Datei "C:\ALT\JEDI.045\U12_OHNE.LCI" gelesen.
LOG-Datei von JEDI, Version 0.45
JEDI ist ein Shareware-Programm von
Ralf Zimmermann
___ ___
| \/ |
!as_20 |1 24| VCC
!csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0
a24 |11 14| a1
GND |12 13| dsack_en
|________|
'dsack_en' ist kein Ausgang!
File NICHT erfolgreich gescannt!
-
JEDI hat Recht, Pin 13 bei einem GAL20V8 ist halt nun mal ein reiner Eingang.
-
Bei Pin13 = A0 und Pin15 = DSACK_EN merkert JEDI wegen A0.
Bei Pin13 = nc merkert JEDI auch ...
Datei "C:\ALT\JEDI.045\U12_OHN2.LCI" gelesen.
LOG-Datei von JEDI, Version 0.45
JEDI ist ein Shareware-Programm von
Ralf Zimmermann
http://Ralf.Zimmermann.com/
___ ___
| \/ |
!as_20 |1 24| VCC
!csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| dsack_en
a24 |11 14| a1
GND |12 13|
|________|
' OLMC 0:
dsack0.OE = dsack_en;
dsack0 = as_20;
' OLMC 1:
dsack1.OE = dsack_en;
dsack1 = as_20;
' OLMC 2:
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 3:
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 4:
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 5:
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 7:
dsack_en = cs11
+ a24 * !csp;
----------------------------------------------------------------------
Error: Es konnte kein GAL-Modus gefunden werden!
Mode 'combinational' nicht realisierbar, weil ein Ausgang den 'tristate'-Mode bentigt.
Mode 'registered' nicht realisierbar, Signal 'as_20' wird nicht rckgekoppelt!
Mode 'tristate' nicht realisierbar, Signal 'dsack_en' wird nicht rckgekoppelt!
GAL-Logik NICHT erfolgreich aufgearbeitet!
-
Hatari ist ja schnell installiert. JEDI runterladen zusammen mit QED oder einem anderem Editor -> http://ralfzimmermann.de/files/jedi/jedi_045.lzh
-
Bei Pin13 = A0 und Pin15 = DSACK_EN merkert JEDI wegen A0.
Ja, der Grund steht da ja sogar korrekt:
Error: Es konnte kein GAL-Modus gefunden werden!
Mode 'combinational' nicht realisierbar, weil ein Ausgang den 'tristate'-Mode bentigt.
Mode 'registered' nicht realisierbar, Signal 'as_20' wird nicht rckgekoppelt!
Mode 'tristate' nicht realisierbar, Signal 'dsack_en' wird nicht rckgekoppelt!
GAL-Logik NICHT erfolgreich aufgearbeitet!
Das ist übrigens keine Einschränkung von JEDI sondern des GALs. So ein GAL ist -- anders als modernere CPLDs -- halt nicht 100% flexibel, was die Wahl der Pins angeht. Je nach Modus sind manche Pins fix einer bestimmten Funktion zugeordnet oder es fehlt ihnen ein Feature. Lässt sich alles im Datenblatt nachlesen.
-
Konkret: Pin 15 ist für DSACK_EN auch eine schlechte Wahl, weil das im "Complex-Mode" (der hier nötig ist, um die Tristate-Ausgänge zu realisieren) ein reiner Ausgang ist, ohne Rückkopplung in die Produkttermmatrix. Genau wie es in der Fehlermeldung steht.
-
Vielen Dank für die Hinweise ...
Wenn ich morgen etwas Zeit habe baue ich das mal um und schaue mir auch das Datenblatt an.
-
Okay,
Sorry für den Wink in die falsche Richtung (den falschen Pin).
Ziel war, es mit minimalen Hardware-Änderungen und einem 20V8 umzusetzen.
So einfach geht es also nicht.
Auszug am dem 20V8 Datenblatt von Lattice:
In the Complex mode, macrocells are configured as output only or
I/O functions.
Architecture configurations available in this mode are similar to the
common 20L8 and 20P8 devices with programmable polarity in
each macrocell.
Up to six I/Os are possible in this mode. Dedicated inputs or outputs
can be implemented as subsets of the I/O function. The two outer
most macrocells (pins 15 & 22) do not have input capability. Designs requiring eight I/Os can be implemented in the Registered mode.
All macrocells have seven product terms per output. One product
term is used for programmable output enable control. Pins 1 and
13 are always available as data inputs into the AND array.
Die Pins 13, 15, 22 und 23 scheiden also aus.
Bleibt Pin 16, welcher auf der PAK/2 mit A16 verbunden ist.
A16 und A17 werden - nach meinem Verständnis- in den TOS-Gleichungen nur für den Bereich 0xFCxxxx benötigt. Wird kein TOS kleiner 2.0x in der PAK/2 verwendet (geht das überhaupt?) ist dieser Bereich allenfalls für den Systemstart nötig, sofern in den "unteren" ROMs noch TOS 1.0x steckt.
Daher mein Vorschlag in die Sockel des ST nur EPROMs mit dem Anfang von TOS 3.0x zu brennen.
(Falsche Größe und Adresslage ist egal, da es nur um den System-Start geht und der InitialStackCounter bei dieser Herangehensweise eben automatisch auf den richtigen 0xExxxx-Bereich zeigt, Die CPU springt also direkt in den ROM-Bereich von TOS 3.06.
Ohne TOS auf der PAK/2 oder eine TOS-Card geht dann natürlich nix.)
A16 und A17 wären dann frei und könnten als interner Ausgang für DASCK_EN herhalten.
Alternativ kannst Du Dir aber auch einen Huckepack-Sockel auf U12 löten, mit einem weiteren Sockel durch Entfernen der unerwünschten Pins die Verbindungen zu den bereits funktionell belegten Ausgängen des dann unteren GALs trennen, und bist dann in der Auswahl der Pins für den Complex-Mode im dann beinahe leeren "oberen" GAL frei. Kannst dsack_en dann also z.B. auf Pin 16 legen,
A24 muss aber trotzdem ans untere GAL gelegt werden und das GAL auch den korrketen Inhalt haben, damit die DSACKs der beiden GALs sich nicht ins Gehege kommen.
EDIT:
Die Huckepack-Variante hat allerdings auch noch den Charme, dass der Umweg über dsack_en dann gar nicht mehr notwendig ist!
Durch das zweite GAL ergibt sich dann ein dsackx.OE nur für den FASTRAM-Bereich ohne! zusätzliche ODER - Verknüpfung. Die DSACKs für den ROM-.Bereich (mit A24) macht das "untere" GAL. Für den FASTRAM-Bereich ist nur das das "obere" GAL zuständig (ebenfalls mit A24)
Die ODER-Verknüpfung der beiden Bereiche wird durch den impiziten "open collector mode" an diesen Pins per Output-enable ( .OE) erreicht.
Das scheint tatsächlich die einfachste Lösung zu sein. ohne weitere Hardware-Änderungen ausser A24,
-
Wenn Du aus Deiner Quelle aus Post #156 die ODER-Verknüpfung für die DSACKs entfernst (also nach ursprünglichem Muster ohne dsack_en)
dsackx.OE = cs11;
und den Rest so läßt (A24 an Pin 11), dann sollte das korrekt übersetzt werden können.
Es fehlen dann noch die DSACKs für den FastRAM-Bereich.
Ganz ohne zweites GAL könnte dann die Dioden-Lösung mit /Sterm, wie von Dir ja schon einmal ganz am Anfnag versucht, zum Erfolg führen
.
Die anderen Hindernisse in U6 und U12 sollten dann ausgeräumt sein.
-
Ich denke das mit dem U12 20V8 geht nicht, habe ein wenig probiert. Ein 22V10 würde gehen aber da ist das Problem das ich mit PALASM nicht arbeiten kann. JEDI kann keine 22V10 meine ich ...
-
Laut Anleitung kann JEDI doch 22V10 aber es klappt nicht ...
--------------
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
plus 16MB Fastram ohne STERM
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| a17
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| dsack_en
|________|
%ID
U12_21
%TYP
GAL22V10
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
dsack_en a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 a17
%LOGIC
dsack_en = cs11 + a24 * !csp;
dsack0.OE = dsack_en;
dsack0 = as_20;
dsack1.OE = dsack_en;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
dsack.OE = GND;
%END
-
Bin einfach zu Blöd dazu !
Jetzt geht es ...
-------
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
plus 16MB Fastram ohne STERM
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| dsack_en
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| a17
|________|
%ID
U12_21
%TYP
GAL22V10
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
a17 a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 dsack_en
%LOGIC
dsack_en = cs11 + a24 * !csp;
dsack0.OE = dsack_en;
dsack0 = as_20;
dsack1.OE = dsack_en;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
--- log ---
Datei "C:\ALT\JEDI.045\U12_OHNE.LCI" gelesen.
LOG-Datei von JEDI, Version 0.45
JEDI ist ein Shareware-Programm von
Ralf Zimmermann
http://Ralf.Zimmermann.com/
___ ___
| \/ |
!as_20 |1 24| VCC
!csp |2 23| dsack_en
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0
a24 |11 14| a1
GND |12 13| a17
|________|
' OLMC 0:
dsack_en = cs11
+ a24 * !csp;
' OLMC 1:
dsack0.OE = dsack_en;
dsack0 = as_20;
' OLMC 2:
dsack1.OE = dsack_en;
dsack1 = as_20;
' OLMC 3:
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 4:
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 5:
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
' OLMC 6:
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
----------------------------------------------------------------------
----------------------------------------------------------------------
Assemblier-Vorgang erfolgreich beendet
----------------------------------------------------------------------
-
@joejoe ... oder fehlt da noch was ?
z.B. das ...
dsack.OE = GND;
-
Nö!
Schön das das nun funzt.
Hast Du es schon mit dem FastRAM ausprobiert?
Wenn bei einem möglichen Ausgangs-Pin eine .OE Zeile angegeben wird, dann gibt die zugehörige Gleichung an, unter welchen Bedingungen der Ausgang aktiv wird (wie der Name ja schon sagt).
a0.OE = GND; (GND auch im Sinne von "0"= "FALSE") besagt, dass der Augang nie aktiv wird und somit gern per Rückkopplung als Eingang verwendet werden kann.
Entsprechend gilt: " .OE = VCC " <=> Der Pin ist dauernd aktiv (als Ausgang).
Für a1 und a 16 würde ich eigentlich auch solch einen Term erwarten, aber das kann sich JEDI vermutlich auch selbst denken. Vermutlich können die Terme für a0 und a16 auch weg gelassen werden. Es sei denn, es ist nötig, um die GAL Betriebsarten für den Compiler eindeutig festzulegen.
Warum a0 nicht als Input nutzbar sein soll (siehe Quelltext), aber tatsächlich a0 dort angeschloißen ist, kann uns wohl nur ein Fachmann erklären. Mit den SRAMs (wo a0 und a1 in Kombi mit siz0 und siz1 unbedingt nötig sind) hat es ja auch funktioniert.
-
Die nächste Woche ist keine Zeit aber dann ...
Ich brauche aber neben U12 modifiziert noch das U6 mit A24, oder ?
-
Ja, ohne die modifizierten U6 und U12 jeweils mit A24 geht bezüglich Fastram oberhalb 16MB nichts.
In U6 wird ja festgelegt, wohin und wie der Zugriff erfolgt (16-bit in den ST-Bereich oder 32-bit auf bzw parallel zur PAK/2) und ob es Bus-Errors gibt.
U12 mit A24 sorgt dafür, dass sich das TOS nicht oberhalb der 16MByte angesprochen fühlt und ggf. für die Data Strobe ACKnowleges.
-
Hatte heute etwas Zeit und habe mal die GALs gebrannt und den Adapter Sockel für U12 gelötet um nicht am GAL rumbiegen und löten zu müssen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13353.0;attach=13451;image)
Aber der Rechner ist tot so. An J2 liegt A24 und J3 ist offen ...
-
Ich habe nicht mehr die Übersicht, welche Versionen von U6 und U12 Du nun im Test hast.
Poste doch bitte 'mal den jeweils aktuellen Stand.
Soweit ich das jetzt aus den älteren Posts nachvollziehen kann, läuft der Rechner mit einem U6 mit zusätzlichem A24-Pin (an J2) und normalem U12, TOS in den PAK/2 Sockeln und ohne gestecktes FASTRAM?
Stimmt das soweit?
"Frohe (Bastel-) Ostern" im Übrigen!
-
U12_21 Addressdekoder fr TOS 2.06 oder 1.04 ROMs auf der PAK 68/2 fr Atari ST
plus 16MB Fastram ohne STERM
Recompilierte JEDEC-Datei. Erzeugt mit MGP 16/20 Version 2.0
Datei: U12_21 Datum: 14.03.1993 19:35:16
14-03-93 U12_21 Aus P20_21.JED -> U12_21.JED recompiliert.
11-06-93 U12_21 GAL-ID hinzu
___ ___
| \/ |
!as_20 |1 24| VCC
(cpuspace) !csp |2 23| dsack_en
siz0 |3 22| !dsack0
siz1 |4 21| !dsack1
a18 |5 20| !cs8
a19 |6 19| !cs9
a20 |7 18| !cs10
a21 |8 17| !cs11
a22 |9 16| a16
a23 |10 15| a0 (nicht als Input nutzbar)
a24 |11 14| a1
GND |12 13| a17
|________|
%ID
U12_21
%TYP
GAL22V10
%PINS
!as_20 !csp siz0 siz1 a18 a19 a20 a21 a22 a23 a24
a17 a1 a0 a16 !cs11 !cs10 !cs9 !cs8 !dsack1 !dsack0 dsack_en
%LOGIC
dsack_en = cs11 + a24 * !csp;
dsack0.OE = dsack_en;
dsack0 = as_20;
dsack1.OE = dsack_en;
dsack1 = as_20;
cs8.OE = VCC;
cs8 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs9.OE = VCC;
cs9 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs10.OE = VCC;
cs10 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
cs11.OE = VCC;
cs11 = !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a16
+ !csp * as_20 * !a24 * a23 * a22 * a21 * a19 * a18 * !a17
+ !csp * as_20 * !a24 * a23 * a22 * a21 * !a20;
a16.OE = GND;
a0.OE = GND;
%END
;
; ATARI ST
;
; Address Decoder fr FPU , schnellen ROM Zugriff
; Buserror, CPUSPACE, ...
;
; nderung : neue Adresslage Sysrom = TOS 2.06 auf Mainboard
; : JP2 und JP3 neue Funktion: JP2 = A24,
; JP3 Lage des ROM
; Jumper 2 : hier A24 anschliessen, bzw. auf "low" legen <=> J2 gesteckt
; Jumper 3 : JP3 = ROM auf PAK, wenn JP3 gesteckt
; Jumper 4 : deaktiviert FPU d.h. erzeugt Buserror
; - 24.11.93 A24 fr sysrom auswerten
; - 25.11.93 A24 fr fastram auswerten
; - 08.07.94 JP3 = Lage des ROM
;---------------------------------- Declaration Segment ------------
TITLE PAK 68020-16
PATTERN U6test
REVISION 1
AUTHOR M.Vlkel / J. Reinecke
COMPANY GK Computer
DATE 08/10/91
CHIP _p20_22 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 17 /csfpu COMBINATORIAL ; OUTPUT
PIN 18 /cpuspace COMBINATORIAL ; OUTPUT
PIN 19 /cycle_00 COMBINATORIAL ; OUTPUT
PIN 20 /romsel COMBINATORIAL ; OUTPUT
PIN 21 /berr_20 COMBINATORIAL ; OUTPUT
PIN 22 /berr_00 ; INPUT
PIN 23 /as_20 ; INPUT
PIN 11 a[24] ; INPUT
PIN 15 /JP3 ; INPUT
PIN 16 /JP4 ; INPUT
PIN 1..8 a[16..23] ; INPUT
PIN 9 a[29] ; INPUT
PIN 10 a[30] ; INPUT
PIN 13 fc0 ; INPUT
PIN 14 fc1 ; INPUT
; ROM + RAM Adressen :
; romE0 = Systemrom TOS x.06 bei 00E0 0000 - 00EF FFFF
; romFC = Systemrom TOS 1.0x bei 00FC 0000 - 00FC FFFF
; fastram = 1 MByte bei 0100 0000 - 010F FFFF
STRING rom_E0 '( /a[24] * a[23] * a[22] * a[21] * /a[20] )'
STRING rom_FC '( /a[24] * a[23] * a[22] * a[21] * a[20] * a[19] * a[18]
* /a[17] * /a[16])'
STRING fastram '( a[24] * /a[23] * /a[22] * /a[21] * /a[20] )'
STRING fpu '( fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] )'
STRING vofamem '( /a[24] * a[23] * a[22] * /a[21] * /a[20] * /a[19])'
STRING vofareg '( /a[24] * a[23] * a[22] * /a[21] * a[20] * /a[19] * /a[18] * /a[17])'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cycle_00 = /( fpu
+ fastram
+ rom_E0
+ (rom_FC * JP3)
)
romsel = GND;(vofareg + vofamem); /* 16 MHZ Zugriffe auf Mainboard-ROM */
csfpu = fpu * /JP4 ;
cpuspace = fc0 * fc1 ;
;---------------------------------------------------------------------
; Buserror wird erzeugt bei |
; |
; Buserror vom 68000 System |
; FPU Select wenn JP4 gesteckt d.h. keine FPU im System |
; (erlaubt Software Emulation der Line F Befehle) |
; FASTRAM > 1 MByte |
;---------------------------------------------------------------------
berr_20 = as_20 *
( berr_00
+ fpu * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17]
+ /a[30] * /a[29] * a[24] * ( a[20] + a[21] + a[22] + a[23])
)
;----------------------------------- Simulation Segment ------------
SIMULATION
Bei dem U6 habe ich das fertige JED genommen da ich mit PALASM nicht arbeiten kann. Bei dem Adapter Sockel von U12 hat der Pin 11 keinen Kontakt zum Board und der Pin geht an A24. Pin 23 ist frei und unbelegt da DSACK_EN und der Pin 23 vom Board geht auf Pin 13 vom GAL 22V10 der Anschluss A17. Ansonsten alles 1:1 durchverbunden. Das 22V10 hat 10ns weil die bei Kessler nur die haben und ich hatte nur noch 25ns aber das hat wohl nichts zu bedeuten ...
Der letzte Stand war das die Karte mit U6 (A24) lief, mit dem original U12 und TOS 3.06 auf der Karte sowie TOS 1.04 auf dem Mainboard so wie es sein sollte.
-
Okay, wenn Du das Jedec aus post #90 nutzt, dann gehört der folgende Quelltext dazu:
;
; ATARI ST
;
; Address Decoder fr FPU , schnellen ROM Zugriff
; Buserror, CPUSPACE, ...
;
; Žnderung : neue Adresslage Sysrom = TOS 2.06 auf Mainboard
; : JP2 und JP3 neue Funktion: JP2 = A24,
; JP3 Lage des ROM
; Jumper 2 : hier A24 anschliessen, bzw. auf "low" legen <=> J2 gesteckt
; Jumper 3 : JP3 = ROM auf PAK, wenn JP3 gesteckt
; Jumper 4 : deaktiviert FPU d.h. erzeugt Buserror
; - 24.11.93 A24 fr sysrom auswerten
; - 25.11.93 A24 fr fastram auswerten
; - 08.07.94 JP3 = Lage des ROM
;---------------------------------- Declaration Segment ------------
TITLE PAK 68020-16
PATTERN U6test
REVISION 1
AUTHOR M.V”lkel / J. Reinecke
COMPANY GK Computer
DATE 08/10/91
CHIP _p20_22 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 17 /csfpu COMBINATORIAL ; OUTPUT
PIN 18 /cpuspace COMBINATORIAL ; OUTPUT
PIN 19 /cycle_00 COMBINATORIAL ; OUTPUT
PIN 20 /romsel COMBINATORIAL ; OUTPUT
PIN 21 /berr_20 COMBINATORIAL ; OUTPUT
PIN 22 /berr_00 ; INPUT
PIN 23 /as_20 ; INPUT
PIN 11 a[24] ; INPUT
PIN 15 /JP3 ; INPUT
PIN 16 /JP4 ; INPUT
PIN 1..8 a[16..23] ; INPUT
PIN 9 a[29] ; INPUT
PIN 10 a[30] ; INPUT
PIN 13 fc0 ; INPUT
PIN 14 fc1 ; INPUT
; ROM + RAM Adressen :
; romE0 = Systemrom TOS x.06 bei 00E0 0000 - 00EF FFFF
; romFC = Systemrom TOS 1.0x bei 00FC 0000 - 00FC FFFF
; fastram = 1 MByte bei 0100 0000 - 010F FFFF
STRING rom_E0 '( /a[24] * a[23] * a[22] * a[21] * /a[20] )'
STRING rom_FC '( /a[24] * a[23] * a[22] * a[21] * a[20] * a[19] * a[18]
* /a[17] * /a[16])'
STRING fastram '( a[24] * /a[23] * /a[22] * /a[21] * /a[20] )'
STRING fpu '( fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] )'
STRING vofamem '( /a[24] * a[23] * a[22] * /a[21] * /a[20] * /a[19])'
STRING vofareg '( /a[24] * a[23] * a[22] * /a[21] * a[20] * /a[19] * /a[18] * /a[17])'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cycle_00 = /( fpu
+ fastram
+ rom_E0
+ (rom_FC * JP3)
)
romsel = GND;(vofareg + vofamem); /* 16 MHZ Zugriffe auf Mainboard-ROM */
csfpu = fpu * /JP4 ;
cpuspace = fc0 * fc1 ;
;---------------------------------------------------------------------
; Buserror wird erzeugt bei |
; |
; Buserror vom 68000 System |
; FPU Select wenn JP4 gesteckt d.h. keine FPU im System |
; (erlaubt Software Emulation der Line F Befehle) |
; FASTRAM > 1 MByte |
;---------------------------------------------------------------------
berr_20 = as_20 *
( berr_00
+ fpu * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17]
+ /a[30] * /a[29] * a[24] * ( a[20] + a[21] + a[22] + a[23])
)
;----------------------------------- Simulation Segment ------------
SIMULATION
siehe Zip aus Post #90.
Das hat allerdings offenbar noch weitere Spezialitäten inkludiert.
Laut (meinem) damaligen Text entscheidet J3 nun darüber, welches TOS gestartet wird.
;
Änderung : neue Adresslage Sysrom = TOS 2.06 auf Mainboard
; : JP2 und JP3 neue Funktion: JP2 = A24,
; JP3 Lage des ROM
; Jumper 2 : hier A24 anschliessen, bzw. auf "low" legen <=> J2 gesteckt
; Jumper 3 : JP3 = ROM auf PAK, wenn JP3 gesteckt
; Jumper 4 : deaktiviert FPU d.h. erzeugt Buserror
; - 24.11.93 A24 fr sysrom auswerten
; - 25.11.93 A24 fr fastram auswerten
; - 08.07.94 JP3 = Lage des ROM
Demnach muss also JP3 gesteckt sein.
EDIT
Im Original deaktiviert J3 das PAK/2-ROM, das ist also ein bedeutender Unterschied. Du schriebst, J3 wäre offen. Stecke den doch bitte 'mal
/EDIT
Was mich bei der Sache etwas irritiert ist die erste Anmerkung:
Änderung : neue Adresslage Sysrom = TOS 2.06 auf Mainboard
Das kann aber eigentlich nicht bedeuten, dass eine zusätzlich TOS-Card unter der PAK/2 steckt, denn dann würde ja ein Zugriff auf den ST-Adressbereich, entsprechend cycle_00 0 aktiv, eben gerade im Bereich rom_E0 deaktiviert durch den folgende Code:
cycle_00 = /( fpu
+ fastram
+ rom_E0
+ (rom_FC * JP3)
)
,
Also soll diese Anmerkung _vermutlich_ (ist aus dem letzen Jahrtausend) enfach bedeuten, dass die ersten acht Byte der ROMs in den Mainboard-ROM-Sockeln den passenden (den gleichen) Inhalt wie das TOS auf der PAK/2 haben sollte.
Damit würde die MMU/GLUE bei einem Reset die richtigen Werte für einen Durchstart auf das TOS auf der PAK/2 vorfinden.
Eine TOS-Card würde das natürlich auch leisten, die wäre dann aber nur kurz nach dem Reset aktiv und danach durch U6 per cycle_00 deaktiviert.
-
Ich kann morgen noch mal für ein paar Stunden etwas machen ...
Ich kann nur TOS 1.04 oder eben EmuTOS in der 192kB Version auf das Mainboard stecken. Ich habe keine TOS 2.06 Erweiterung da. In ein paar Wochen habe ich wieder eine MonSTer, damit wäre das kein Problem. Ich kann auch mal versuchen dein U6 mit A24 im JEDI umzusetzen.
Für mein Verständnis brauche ich ja das TT TOS 3.06 auf der PAK68/2 wegen dem Fastram. TOS 2.06 unterstützt das nicht sondern nur Alternate Ram zwischen 4 und 14 (16) MB was auch durch Software beim Betriebssystem angemeldet werden muss.
-
Hallo Frank,
ich hätte ein IDE Interface mit 4Tos Flash Umschalter da, schaue mal in der Biete Rubrik, da habe ich sie angeboten.
-
Habe ich schon gesehen aber das macht keinen Sinn da ich unbedingt das TOS 3.06 auf der PAK brauche, denke ich ...
-
TOS 1.04 müsste eigentlich gehen, es hat zumindestens den gleichen Resetvektor wie 2.06. Meine PAK 68/2 startet so auch.
-
Ich komme nicht zurecht !
Wie soll ich denn A24 einarbeiten wegen dem JEDI ...
U6_22 PAK 68/2: Adressdekoder U6 fr Atari ST
jp1: CPU Cache on: disable *off: enable
jp2: ROMs *on: auf der PAK off: auf Mainboard 5 Clk
jp3: Addressraum *on: 24 Bit off: 32 Bit (mit a29, a30)
jp4: FPU auf der PAK on: disable *off: enable
jp5: FPU Clock on: eigener Oszillator *off: -
jp6: FPU Clock *on: CPU Clock off: -
BKPT: as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * !a16
MMU : as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * a16
FPU : as_20 * fc1 * fc0 * !a19 * !a18 * a17 * !a16
IACK: as_20 * fc1 * fc0 * a19 * a18 * a17 * a16
12-06-93 U6_22 aus P20_22.JED recompiliert, GAL-ID hinzu
___ ___
| \/ |
a16 |1 24| VCC
a17 |2 23| !as_20
a18 |3 22| !berr_00
a19 |4 21| !berr_20
a20 |5 20| !romsel
a21 |6 19| !cycle_00
a22 |7 18| !cpuspace
a23 |8 17| !csfpu
a29 |9 16| !jp4
a30 |10 15| !jp3
a24 |11 14| fc1
GND |12 13| fc0
|________|
%ID
U6_22
%TYP
GAL20V8A
%PINS
a16 a17 a18 a19 a20 a21 a22 a23 a29 a30 a24
fc0 fc1 !jp3 !jp4 !csfpu !cpuspace !cycle_00 !romsel
!berr_20 !berr_00 !as_20
%LOGIC
berr_20 = as_20 * fc1 * fc0 * !a19 * !a18 * !a17 'PMMU, BKPT
+ as_20 * fc1 * fc0 * !a19 * !a18 * !a16 * jp4 'keine FPU
+ as_20 * berr_00;
romsel = a23 * a22 * a21 * a20 * a19 * a18 * !a17 * !jp2 'TOS 1.04
+ a23 * a22 * a21 * a20 * a19 * a18 * !a16 * !jp2; 'TOS 1.04
!cycle_00 = a23 * a22 * a21 * !a20 '$E00000 bis $EFFFFF
+ fc1 * fc0 * !a19 * !a18 * a17 * !a16 'FPU
+ a23 * a22 * a21 * a19 * a18 * !a17 * jp2 'TOS 1.04
+ a23 * a22 * a21 * a19 * a18 * !a16 * jp2 'TOS 1.04
+ a30 * !a29 * !jp3;
cpuspace = fc1 * fc0;
csfpu = fc1 * fc0 * !a19 * !a18 * a17 * !a16 * !jp4; 'FPU
%END
-
Wenn Du Dir Dein eigenes U6 zusammenstellst, kannst Du den J3 Kram ja wieder entfernen:
Wichtig für Zugriffe oberhalb 16MB, also dann wenn cycle_00 nicht aktiv wird, ist ja nur folgender Teil , (ganz ohne JP3)
cycle_00 = /( fpu
+ fastram
+ rom_E0
)
Wobei die Platzhalter "fpu" etc. für Jedi vermutlich jeweils direkt durch:
rom_E0 => /a[24] * a[23] * a[22] * a[21] * /a[20]
fastram => a[24] * /a[23] * /a[22] * /a[21] * /a[20]
fpu => fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16]
ersetzt werden müssen.
Die letzte Zeile im BussError-Term fliegt dann auch hinaus.
berr_20 = as_20 *
( berr_00
+ fpu * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17]
; + /a[30] * /a[29] * a[24] * ( a[20] + a[21] + a[22] + a[23]) <= macht nur bei 1MByte FAstRAM Sinn
)
Die hat bei meinem damaligen 1MByte-Fast(S)RAM einen Buserror ausgelöst, wenn auf Bereiche oberhalb dieser 1MByte zugeriffen wurde.
Das war nötig, oder zumindestens förderlich, um den FastRAM-Test des TOS 3.06 bereits nach 1 MByte abbrechen zu lassen. Da damals in U12 nur A24 ausgewertet wurde haben sich diese 1MByte FASTRAM immer wieder gespiegelt.
Deine 16MByte TT-FASTRAM-Karte nutzt ja alle Adressen bis A23.
Läuft denn Dein U12 mit dem originalen U6 korrekt?
Die zusätzliche Adresse A24 stört ja nicht, wenn diese korrekt in die Terme eingebaut ist.
-
Ups, da war ich jetzt zu langsam, muss Deine Frage noch lesen.
-
Bei romsel hatte ich in Erinnerung, dass das nur (in einem weiteren GAL) für schnelleren ROM-Zuigriff auf dem Mainboard sorgen kann. Wenn von dort nur die Resetvektoren kommen, dürfte die Beschleunigung eher vernachlässigbar sein.
Daher hatte ich romsel deaktiviert (romsel = GND in PALASM-Syntax)
Wenn ich die Jedi-Syntax richtig verstehe, dann wäre romsel bei gestecktem J2 im Bereich FCxxxx aktiv:
romsel = a23 * a22 * a21 * a20 * a19 * a18 * !a17 * !jp2 'TOS 1.04
+ a23 * a22 * a21 * a20 * a19 * a18 * !a16 * !jp2; 'TOS 1.04
An J2 hängt nun aber A24, also eine völlig andere Funktion.
romsel muss also dauerhaft deaktiviert werden (romsel = GND?? bzw. entsprechendes in JEDI-Syntax)
!cycle_00 wird um a24 erweitert, wo es nötig ist:
!cycle_00 = !a24 * a23 * a22 * a21 * !a20 '$0E00000 bis $0EFFFFF
+ fc1 * fc0 * !a19 * !a18 * a17 * !a16 'FPU
+ !a24 * a23 * a22 * a21 * a19 * a18 * !a17 'TOS 1.04
+ !a24 * a23 * a22 * a21 * a19 * a18 * !a16 'TOS 1.04
+ a30 * !a2
-
romsel kann, schnelle EPROMs auf dem Mainboard vorausgesetzt, natürlich auch dauerhaft im FC-Rom-Bereich aktiviert werden:
romsel = !a24 *a23 * a22 * a21 * a20 * a19 * a18 * !a17 'TOS 1.04
+ !a24 * a23 * a22 * a21 * a20 * a19 * a18 * !a16; 'TOS 1.04
Da JP2 ja quasi durch A24 ersetzt wurde, ist die resultierende Logik zufällig idenisch zum Original.
Es liest und versteht sich nur besser, wenn im Quelltext JP2 durch a24 ersetzt wird.
-
Grundsätzlich sind die Änderungen in beiden GALS (U6 und U12) notwendig, um auf FastRAM oberhalb der 16MByte ST-Adressraum zugreifen zu können, wo auch immer das dann angeschlossen ist.
Der ST sollte aber zunächst ganz normal funktionieren (auch mit PAK/2), wenn nur eines der GALs gesteckt bzw. angeschloßen ist (jeweils mit A24 ), und das jeweils andere dem "Normal"-Zustand entspricht.
Damit ließe sich ein eventueller Fehler zunächst weiter einkreisen, wenn schon das nicht funktioniert.
-
Ich wollte schon wieder aufgeben ...
Habe den zweiten vor dem ersten Schritt gemacht und wollte die MAgnum TT PALASM Quellen nach ISPLever von Lattice umsetzen für einem Umbau von MACH210 auf M4A5 MACH Baustein um das STERM Signal durch DSACK0/1 zu ersetzen für die PAK68/2. Aber das hat natürlich nicht geklappt weil meine Fähigkeiten dazu nicht ausreichen. Glücklicherweise hat Holger Zimmermann der den Magnum TT auf M4A5 Umbau schon gemacht hat mir seine ABEL Quelldatei geschickt. Der Vorteil beim M4A5 ist das er via JTAG Kabel programmiert werden kann in der Schaltung. Ich habe mir aus England eine Magnum TT besorgt für den Umbau oder ich mache ein neues Layout für den M4A5 und lasse mir eine Platine machen.
Das neue GAL U12 ist ja schon in JEDI umgesetzt. Es fehlt jetzt noch das GAL U6 mit dem JEDI umzusetzen. Dann kam es weiter gehen ...
Auf den Bildern ist das Layout von neogain zu sehen wie die fertige Karte mal aussehen könnte und die umgebaute Magnum von Holger.
-
Ieh ... das Layout is ja aus'm Eagle-Autorouter ;)
Ziemlich riesige Platine.
-
Habe mir mir (mit einiger Mühe, unter VirtualBox lief es schlecht bis gar nicht) ein lauffähiges PALASM für DOSBox unter W10 zusammengestellt,
und dann damit für U6 ein JED für einen FASTRAM-Bereich von 16MB (A24 = 1) erstellt.
Ausgehend vom originalen U6_22.pds sind hier nur die minimal notwendigen Änderungen drin, d.h. A24 wird zusätzlich mit ausgewertet.
Ich hoffe, das hilft weiter.
-
Ups, hatte noch einen Fehler drin.Habe daher den Anhang aus Post #195 gelöscht.
Hier nun die berichtigte Version:
EDIT: Auch hier hatte ich einen leider sehr kapitalen Fehler drin, lösche daher den Anhang.
-
Gerade mal probiert und geht nicht. Mit dem neuen U6 ist der Rechner tot ...
-
Oh weh,
mein Ansatz das 'mal eben ausgehend vom Original neu aufzusetzen hat leider dazu geführt, dass ich den PAK/2 internen ROM-Zugriff auf die 4 PAK-ROMs versehentlich 'rausgeschmissen habe.
Das heißt im Original etwas verwirrend addmem.
Habe dieses nun wieder eingesetzet und in romE0 umgenannt.
Sorry, mein Fehler.
Tut mir leid, dass das so nur ein völliger Misserfolg werden konnte und Du damit unnötige Arbeit hattest.
Hier nun die (nochmals überdachte) Variante mit ROM auf der PAK.
-
Der Rechner ist auch mit dem neuen GAL tot ...
Vielleicht sollte man anders an die Sache ran gehen und zwar erstmal das GAL ohne A24 original lassen und die Jumper JP2, 3 sowie 4 raus nehmen, sodass die nicht mehr gebraucht werden und die drei Eingänge am GAL frei für A24, A25 und A26 sind. Für mehr als 16MB eventuell. Man müsste das GAL so ändern das JP2 intern ohne den JP2 Eingang am GAL immer gesetzt ist und JP3 immer offen sowie JP4 für die FPU das diese immer vorhanden sein muss. Und wenn das dann so läuft A24 und eventuell andere Adressen mit einbauen ...
Das GAL U12 kann und braucht man doch gar nicht verändern, oder? Sonst funktioniert doch das TOS auf der PAK nicht mehr. DSACK0 und 1 kommen doch gesondert von der geänderten Magnum TT anstatt STERM ...
-
Ein verändertes U12 wird selbstverständlich gebraucht, sobald ide FASTRAM-KArte gesteckt ist, da andernfalls, wenn A24 für die /CSx der PAK-ROMs nicht ausgewertet wird, eben diese ROMs mit dem TT-FASTRAM in Konflikt geraten.
Die TT-FASTRAM MMU wertet alle Adressleitungen korrekt aus, der PAK/2 muss das, zumindest für A24 beigebracht werden.
Richtig ist, dass als erste Voraussetzung, ohne gesteckte TT-FASTRAM-Erweiterung, der Rechner auch mit nur jeweils einen der beiden zu ändernder GALS korrekt starten und laufen muß, sofern A24 jeweils korrekt angeschlosen ist.
Damit läßt sich die Fehlersuche auf U6 bzw. U12 beschränken.
Der zweite Schritt wären dann beide GALs gemeinsam ohne FASTRAM aber beide mit A24 versorgt.
Nur dann, wenn bis hierher alles normal läuft, besteht eine Wahrscheinlichkeit, dass es auch mit TT- FASTRAM-Karte klappt.
-
Ich habe nur U6_A24 eingesetzt und U12 war original ...
-
Und was passiert, wenn Du U6_A24 steckst und den Eingang A24 des GALs per JP2 dauerhaft auf low (gesteckt) ziehst?
A24 von der CPU darf dann natürlich nicht angeschloßen sein.
-
Habe mal mit JEDI etwas probiert und hat im ersten Versuch direkt geklappt ...
U6_22 PAK 68/2: Adressdekoder U6 fr Atari ST
jp1: CPU Cache on: disable *off: enable
jp2: ROMs *on: auf der PAK off: auf Mainboard 5 Clk
jp3: Addressraum *on: 24 Bit off: 32 Bit (mit a29, a30)
jp4: FPU auf der PAK on: disable *off: enable
jp5: FPU Clock on: eigener Oszillator *off: -
jp6: FPU Clock *on: CPU Clock off: -
BKPT: as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * !a16
MMU : as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * a16
FPU : as_20 * fc1 * fc0 * !a19 * !a18 * a17 * !a16
IACK: as_20 * fc1 * fc0 * a19 * a18 * a17 * a16
12-06-93 U6_22 aus P20_22.JED recompiliert, GAL-ID hinzu
___ ___
| \/ |
a16 |1 24| VCC
a17 |2 23| !as_20
a18 |3 22| !berr_00
a19 |4 21| !berr_20
a20 |5 20| !romsel
a21 |6 19| !cycle_00
a22 |7 18| !cpuspace
a23 |8 17| !csfpu
a29 |9 16| !jp4
a30 |10 15| !jp3
!jp2 |11 14| fc1
GND |12 13| fc0
|________|
%ID
U6_22
%TYP
GAL20V8A
%PINS
a16 a17 a18 a19 a20 a21 a22 a23 a29 a30 !jp2
fc0 fc1 !jp3 !jp4 !csfpu !cpuspace !cycle_00 !romsel
!berr_20 !berr_00 !as_20
%LOGIC
berr_20 = as_20 * fc1 * fc0 * !a19 * !a18 * !a17 'PMMU, BKPT
+ as_20 * berr_00;
romsel = a23 * a22 * a21 * a20 * a19 * a18 * !a17; 'TOS 2.06
!cycle_00 = a23 * a22 * a21 * !a20 '$E00000 bis $EFFFFF
+ fc1 * fc0 * !a19 * !a18 * a17 * !a16 'FPU
+ a23 * a22 * a21 * a19 * a18 * !a17 'TOS 2.06
+ a30 * !a29;
cpuspace = fc1 * fc0;
csfpu = fc1 * fc0 * !a19 * !a18 * a17 * !a16; 'FPU
%END
Jetzt müssten die Eingänge am GAL für JP2, JP3 sowie JP4 frei sein.
Wie baue ich denn jetzt A24 ein ?
-
Und ein damit programmiertes GAL funktioniert ohne Probleme?
Schicke mir / poste doch bitte auch das unveränderte Original, also mit J2,J3,J4.
zumindest J4 sollte doch drinnen bleiben; im ersten Schritt würde ich auch J3 drin lassen.
Du brauchst nur A24 um das FASTRAM sauber vom ST-Adressraum zu trennen.
Also A24 in der PIN Definition statt !jp2,
-
Hier das original JEDI Files von U6 ...
U6_22 PAK 68/2: Adressdekoder U6 fr Atari ST
jp1: CPU Cache on: disable *off: enable
jp2: ROMs *on: auf der PAK off: auf Mainboard 5 Clk
jp3: Addressraum *on: 24 Bit off: 32 Bit (mit a29, a30)
jp4: FPU auf der PAK on: disable *off: enable
jp5: FPU Clock on: eigener Oszillator *off: -
jp6: FPU Clock *on: CPU Clock off: -
BKPT: as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * !a16
MMU : as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * a16
FPU : as_20 * fc1 * fc0 * !a19 * !a18 * a17 * !a16
IACK: as_20 * fc1 * fc0 * a19 * a18 * a17 * a16
12-06-93 U6_22 aus P20_22.JED recompiliert, GAL-ID hinzu
___ ___
| \/ |
a16 |1 24| VCC
a17 |2 23| !as_20
a18 |3 22| !berr_00
a19 |4 21| !berr_20
a20 |5 20| !romsel
a21 |6 19| !cycle_00
a22 |7 18| !cpuspace
a23 |8 17| !csfpu
a29 |9 16| !jp4
a30 |10 15| !jp3
!jp2 |11 14| fc1
GND |12 13| fc0
|________|
%ID
U6_22
%TYP
GAL20V8A
%PINS
a16 a17 a18 a19 a20 a21 a22 a23 a29 a30 !jp2
fc0 fc1 !jp3 !jp4 !csfpu !cpuspace !cycle_00 !romsel
!berr_20 !berr_00 !as_20
%LOGIC
berr_20 = as_20 * fc1 * fc0 * !a19 * !a18 * !a17 'PMMU, BKPT
+ as_20 * fc1 * fc0 * !a19 * !a18 * !a16 * jp4 'keine FPU
+ as_20 * berr_00;
romsel = a23 * a22 * a21 * a20 * a19 * a18 * !a17 * !jp2 'TOS 1.04
+ a23 * a22 * a21 * a20 * a19 * a18 * !a16 * !jp2; 'TOS 1.04
!cycle_00 = a23 * a22 * a21 * !a20 '$E00000 bis $EFFFFF
+ fc1 * fc0 * !a19 * !a18 * a17 * !a16 'FPU
+ a23 * a22 * a21 * a19 * a18 * !a17 * jp2 'TOS 1.04
+ a23 * a22 * a21 * a19 * a18 * !a16 * jp2 'TOS 1.04
+ a30 * !a29 * !jp3;
cpuspace = fc1 * fc0;
csfpu = fc1 * fc0 * !a19 * !a18 * a17 * !a16 * !jp4; 'FPU
%END
Das TOS 1.04 mit A17 ist wohl für TOS 2.06 auf der PAK und mit A16 TOs 1.04 (KAOS) auf dem Mainboard !?!
Ja funktioniert Wunderbar. Ich würde gerne alle Jumper weglassen. Kommt eh nur ausschliesslich das 32-birt breite TOS 2.06/3.06 auf der PAK68/2 in frage. Also ist der Jumper sinnlos. JP3 ist doch ebenfalls sinnlos da ein 32bit Adressraum wegen des Fastrams wünschenswert ist. Und JP4 braucht auch nicht sein da auch der Atari TT nicht läuft und bombt wenn die FPU fehlt ...
So hätte man drei Eingänge am GAL frei für A24 und zwei weitere Adressen um eventuell mehr als 16MB Fastram nutzen zu können ...
-
Okay, habe da zwar so ein paar Zweifel ob der Kommentare (Tos 2.06 neben einer Zeile, die nicht den gesammten E0-EF-Bereich dekodiert, Beschreibungen für Jumper, welche überhaupt nicht an dem GAL anliegen, bei romsel dieselbe Zeile mit TOS 2.06 wie im Original für TOS1.04, etc.) aber wenn es denn so geht :)
Hier aufbauend auf Deiner Version mein Vorschlag, wie a24 dort hinein gehören sollte.
Die Ungereimtheiten habe ich drin gelassen.
jp2: ROMs *on: auf der PAK off: auf Mainboard 5 Clk
jp3: Addressraum *on: 24 Bit off: 32 Bit (mit a29, a30)
jp4: FPU auf der PAK on: disable *off: enable
jp5: FPU Clock on: eigener Oszillator *off: -
jp6: FPU Clock *on: CPU Clock off: -
BKPT: as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * !a16
MMU : as_20 * fc1 * fc0 * !a19 * !a18 * !a17 * a16
FPU : as_20 * fc1 * fc0 * !a19 * !a18 * a17 * !a16
IACK: as_20 * fc1 * fc0 * a19 * a18 * a17 * a16
12-06-93 U6_22 aus P20_22.JED recompiliert, GAL-ID hinzu
___ ___
| \/ |
a16 |1 24| VCC
a17 |2 23| !as_20
a18 |3 22| !berr_00
a19 |4 21| !berr_20
a20 |5 20| !romsel
a21 |6 19| !cycle_00
a22 |7 18| !cpuspace
a23 |8 17| !csfpu
a29 |9 16| !jp4
a30 |10 15| !jp3
a24 |11 14| fc1
GND |12 13| fc0
|________|
%ID
U6_22
%TYP
GAL20V8A
%PINS
a16 a17 a18 a19 a20 a21 a22 a23 a29 a30 a24
fc0 fc1 !jp3 !jp4 !csfpu !cpuspace !cycle_00 !romsel
!berr_20 !berr_00 !as_20
%LOGIC
berr_20 = as_20 * fc1 * fc0 * !a19 * !a18 * !a17 'PMMU, BKPT
+ as_20 * berr_00;
romsel = !a24 * a23 * a22 * a21 * a20 * a19 * a18 * !a17; 'TOS 2.06
!cycle_00 = !a24 * a23 * a22 * a21 * !a20 '$E00000 bis $EFFFFF
+ fc1 * fc0 * !a19 * !a18 * a17 * !a16 'FPU
+ !a24 * a23 * a22 * a21 * a19 * a18 * !a17 'TOS 2.06
+ a24; ' FASTRAM
cpuspace = fc1 * fc0;
csfpu = fc1 * fc0 * !a19 * !a18 * a17 * !a16; 'FPU
%END
Da ich nie mit Jedi gearbeitet habe wundert mich die Redundanz der PIN Definitionen einmal als Pictogramm und dann über die %PINS Directive.
Aber das ist dann eben mein Problem ;)
romsel selektiert nach meiner Erinnerung mitnichten den ROM-Bereich auf der Hauptplatine, sondern steuert den Zugriff dergestalt, dass bei aktivem ROM-Zugriff (signalisiert per romsel) in einem weiteren GAL ein verkürzter 68000-BUS-Zyklus getriggert wird.
Da Du das TOS auf dem Mainboard aber nur für die ersten paar Zugriffe nutzt ist der Nutzen minimal.
-
Bevor ich weiter mache möchte ich erstmal die drei Jumper Eingänge am GAL U6 frei haben, sprich keinerlei Jumper mehr an U6.
JP2 = TOS auf dem Mainboard oder auf der PAK brauche ich nicht, soll fest auf TOS auf der PAK sein.
JP3 = Adressraum 24bit oder 32bit braucht es ebenfalls nicht, soll fest auf 32bit stehen
JP4 = FPU ja/nein, braucht nicht. FPU muss/soll immer vorhanden sein genau wie beim Atari TT der bombt ohne FPU.
Die Funktion von JP2 soll jetzt fest gesetzt sein.
JP3 soll offen sein (32bit) und JP4 soll offen sein (FPU vorhanden).
Problem ist das ich mit PALASM nicht arbeiten kann. Bin zu blöd dazu, für die Bedienung. JEDI geht da schon eher. Ich habe jetzt PALASM lauffähig unter OSX und der DOSBOX. Brauche jemanden der mir die Bedienung in groben Zügen erklären kann ...?
--- original U6 PDS -----
****************************************************************
P20_22.PDS 1779
****************************************************************
;PALASM Design Description
;
; ATARI ST
;
; Address Decoder fr FPU , schnellen ROM Zugriff
; Buserror, CPUSPACE, ...
;
; Jumper 2 : System ROM auf PAK
; 3 : deaktivert PAK Mem , erlaubt die verwendung von
; A24 - A31 als TAG Bits in mancher Software
; ( z.B. Tempus 2.0 )
; 4 : deaktiviert FPU d.h. erzeugt buserror
;
;---------------------------------- Declaration Segment ------------
TITLE PAK 68020-16
PATTERN p20_22
REVISION 1
AUTHOR M.Vlkel
COMPANY GK Computer
DATE 08/10/91
CHIP _p20_22 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 17 /csfpu COMBINATORIAL ; OUTPUT
PIN 18 /cpuspace COMBINATORIAL ; OUTPUT
PIN 19 /cycle_00 COMBINATORIAL ; OUTPUT
PIN 20 /romsel COMBINATORIAL ; OUTPUT
PIN 21 /berr_20 COMBINATORIAL ; OUTPUT
PIN 22 /berr_00 ; INPUT
PIN 23 /as_20 ; INPUT
PIN 11 /jp2 ; INPUT
PIN 15 /jp3 ; INPUT
PIN 16 /jp4 ; INPUT
PIN 1..8 a[16..23] ; INPUT
PIN 9 a29 ; INPUT
PIN 10 a30 ; INPUT
PIN 13 fc0 ; INPUT
PIN 14 fc1 ; INPUT
; ROM Adressen :
; sysrom = Systemrom ATARI FC0000 - FCFFFF
; addmem = " E00000 - EFFFFF
STRING adrFC 'a[23] * a[22] * a[21] * a[20] * a[19] * a[18] '
STRING sysrom '(adrFC * (/a[17]*/a[16] + /a[17]*a[16] + a[17]*/a[16] ))'
STRING addmem '( a[23] * a[22] * a[21] * /a[20] )'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cycle_00 =/( a30 * /a29 * /JP3
+ sysrom * jp2
+ addmem
+ fc0 * fc1 * /a[16] * a[17] * /a[18] * /a[19] ; fpu
)
romsel = /JP2 * sysrom
csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ;
cpuspace = fc0 * fc1 ;
;---------------------------------------------------------------------
; Buserror wird erzeugt bei |
; |
; Buserror vom 68000 System |
; FPU Select wenn JP4 gesteckt d.h. keine FPU im System |
; (erlaubt Software Emulation der Line F Befehle) |
; Breakpoint ACK cycle ( braucht 68851 PMMU ) |
; Access Level fetch " " " |
;---------------------------------------------------------------------
berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * a[16]
);
;----------------------------------- Simulation Segment ------------
SIMULATION
;-------------------------------------------------------------------
--- Jumper loses U6 1.Versuch -----
****************************************************************
P20_22.PDS 1779
****************************************************************
;PALASM Design Description
;
; ATARI ST
;
; Address Decoder fr FPU , schnellen ROM Zugriff
; Buserror, CPUSPACE, ...
;
; Jumper 2 : System ROM auf PAK
; 3 : deaktivert PAK Mem , erlaubt die verwendung von
; A24 - A31 als TAG Bits in mancher Software
; ( z.B. Tempus 2.0 )
; 4 : deaktiviert FPU d.h. erzeugt buserror
;
;---------------------------------- Declaration Segment ------------
TITLE PAK 68020-16
PATTERN p20_22
REVISION 1
AUTHOR M.Vlkel
COMPANY GK Computer
DATE 08/10/91
CHIP _p20_22 PALCE20V8
;---------------------------------- PIN Declarations ---------------
PIN 17 /csfpu COMBINATORIAL ; OUTPUT
PIN 18 /cpuspace COMBINATORIAL ; OUTPUT
PIN 19 /cycle_00 COMBINATORIAL ; OUTPUT
PIN 20 /romsel COMBINATORIAL ; OUTPUT
PIN 21 /berr_20 COMBINATORIAL ; OUTPUT
PIN 22 /berr_00 ; INPUT
PIN 23 /as_20 ; INPUT
PIN 11 /jp2 ; INPUT
PIN 15 /jp3 ; INPUT
PIN 16 /jp4 ; INPUT
PIN 1..8 a[16..23] ; INPUT
PIN 9 a29 ; INPUT
PIN 10 a30 ; INPUT
PIN 13 fc0 ; INPUT
PIN 14 fc1 ; INPUT
; ROM Adressen :
; sysrom = Systemrom ATARI FC0000 - FCFFFF
; addmem = " E00000 - EFFFFF
STRING adrFC 'a[23] * a[22] * a[21] * a[20] * a[19] * a[18] '
STRING sysrom '(adrFC * (/a[17]*/a[16] + /a[17]*a[16] + a[17]*/a[16] ))'
STRING addmem '( a[23] * a[22] * a[21] * /a[20] )'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
MINIMIZE_ON
cycle_00 =/( a30 * /a29
+ sysrom
+ addmem
+ fc0 * fc1 * /a[16] * a[17] * /a[18] * /a[19] ; fpu
)
romsel = sysrom
csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] ;
cpuspace = fc0 * fc1 ;
;---------------------------------------------------------------------
; Buserror wird erzeugt bei |
; |
; Buserror vom 68000 System |
; FPU Select wenn JP4 gesteckt d.h. keine FPU im System |
; (erlaubt Software Emulation der Line F Befehle) |
; Breakpoint ACK cycle ( braucht 68851 PMMU ) |
; Access Level fetch " " " |
;---------------------------------------------------------------------
berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * a[16]
);
;----------------------------------- Simulation Segment ------------
SIMULATION
;-------------------------------------------------------------------
@joejoe ... bitte ein JED aus der Version ohne Jumper erzeugen zum Testen.
An alle die Ahnung haben, sind die Gleichungen so richtig oder habe ich Fehler gemacht ?
-
Leichtes Kopfschütteln ;)
Wenn es denn irgendwann einmal läuft, dann kannst Du Dir ja über eine weitergehende Verwendung
der derzeit von den Jumpern belegten GaL Eingängen Gedanken machen.
Ich würde das alles aussen vor lassen, und NUR mit A24 anfangen.
Um Dir weiter zu helfen habe ich ja schon (mehrmals) versucht JEDI-Quellcode zu texten.
Deine Version ohne alle JP in den GAL-Gleichungen, welche ja nach Deiner Aussage den ST korrekt mit PAK/2 laufen läßt, war die Grundlage für meine Version mit zusätzlich A24.
Meine kleinen Meckereien kannst Du ja gern beiseite lassen.
Wenn nun nur A24 hinzu kommt, muß zunächst auch nur die Gleichung ergänzt werden, welche
in U6 für die Umschaltung auf ST-Adressbereich oder PAK/2-32bit Adressbereich zuständig ist, also cycle_00.
Hast Du denn meinen Vorschlag für U6 (basierend auf Deinem Original) mal mit JEDI übersetzt und ausprobiert ?
Auch mit gesetzem JP2 , was ja gleichbedeutend mit A24 dauerhaft "0" wäre?
Das sollte dann genauso funktionieren wie Dein U6, da a24 für den Zugriff auf den ST-Bereich immer "0" sein muss.
Mit entferntem J2 (a24 = "1", per Pullup am GAL) dürfte der ST dann nicht booten.
Wenn das alles klappt, dann würde ich a24 an den GAL-Eingang 11, ehemals JP2, anschließen.
Deine Bitte mit dem PALASM Durchlauf werde ich dann in Kürze erfüllen.
EDIT:
Da wir damit genau genommen keinen einzigen Schritt weiter wären, lasse ich den PALASM-Lauf mit dieser Quelle erstmal aus. Das bringt nichts, s. nächsten Post.
/edit
Gruß Jörg
-
Du kannst nicht einfach alle Vorkommen von JPx und /JPx entfernen, Du musst die Gleichungen schon anpassen, je nachdem ob der Jumper als gesetzt oder als nicht gesetzt angenommen werden soll:
Für einen Jumper "JPx" der gesetzt sein soll, lass alle Produkte stehen die "JPx" enthalten und entferne alle, die "/JPx" enthalten. Für einen Jumper der nicht gesetzt sein soll, genau umgekehrt: Produkte mit "JPx" entfernen, mit "/JPx" stehen lassen.
Beispiel: Aus ...
berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * a[16]
);... wird -- Zitat "JP4 soll offen sein":
berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] * a[16]
);
-
Da war czietz schneller.
-
Die Jumper JP3 und JP4 stören doch erstmal nicht, laß sie doch einfach wie gewünscht gesteckt.
Da in Deiner JEDI Variante (die funktioniert) auch alle JP in den Gleichungen entfernt waren, könnte es _zufällig_ auch mit dieser Version klappen, sauber ist das natürlich nicht, den Erklärungen von Christian ist nichts hinzuzufügen.
JP3 hat eine Doppel-Rolle: zum Einen definiert er in cycle_00 die physikalische Lage des TOS (Mainboard oder PAK/2), zum Anderen sorgt der Ausgang romsel bei TOS auf dem Mainboard für einen 5-Takte Zyklus beim Zugriff auf den ST-Bereich, wenn aktiv.
Das bringt Dir erstmal gar nichts, und benötigt auch schnelle TOS-ROMs auf dem Mainboard,
Ich würde den Ausgang romsel daher "totlegen", also romsel = GND; in der Gleichung (k.A. ob das auch in JEDI so geht?)
Dann hast Du keine Beschleunigung beim Zugriff auf die Mainboard-ROMs, bringt Dir mit TOS auf der PAK/2 ja auch nichts.
btw. über diesen Ausgang kann man auch den Zugriff z.B. auf die VoFa beschleunigen, aber das ist ein anders Thema.
Edit:
Mein Vorschlag wäre folgender: Teste doch bitte, ob der ST mit U6, erzeugt aus meiner JEDI-Quelle aus Post#206 ,wie in Post #208 beschrieben, mit gestecktem JP2 läuft. Also ohne die fliegende A24-Leitung.
Das wäre der erste Schritt aus meiner Sicht.
/Edit
Viel Erfolg!
-
Zum Thema PALASM in der Dosbox:
Ich habe mir einfach das PALASM_C -Zip von dieser Website
http://www.s100computers.com/My%20System%20Pages/ISA%20to%20S100%20Bus/Intro%20To%20GALs.htm (http://www.s100computers.com/My%20System%20Pages/ISA%20to%20S100%20Bus/Intro%20To%20GALs.htm)
in ein Verzeichnis entpackt und dieses dann passend in Dosbox gemounted.
Wichtig ist es, den PATH innerhalb von Dosbox um das Palasm_C\ExE Unterverzeichnis zu erweitern und das SET PALASM= Path zum Palasm-Ordner (aus Sicht von DosBox) zu ergänzen in der Dosbox Konfig. Ohne den Pfad oder die SET Directive wird kein JEDEC erzeugt, selbst wenn die Quelle geparst werden kann.
Aus Copyright-Gründen ist hier wie in den anderen freien PALASM-Quellen kein Editor "ED.exe" im EXE Unterverzeichnis vorhanden. Aber das ist kein Problem.
Ich ediere die Quellen z.B: mit Notepad++ parallel auf Windows-Ebene und wähle dann das Quellenverszeichnis und das *.pds in Palasm aus (bestätigen mit F10) und starte einfach den Übersetzungsvorgang zwei Menu-Einträge weiter rechts (auch mit F10).
Gab es keine Fehler im Palasm, steht dann das *.jed unter Windows zur Verfügung.
-
Kleiner Einwurf am Rande:
Bist Du Dir denn auch ganz sicher, dass die fliegende Leitung auch tatsächlich A24 trägt?
Eine Verwechslung könnte ja erklären, warum es nicht klappt.
-
Ich würde sagen man bleibt besser bei PALASM und lässt JEDI fallen. Ich kann ja nicht beurteilen ob die JEDI Übersetzungen alle richtig sind. Habe nochmal A24 überprüft und das stimmt. Mit dem letzten U6_A24_neu aus dem PALASM ist der Rechner tot.
Ist es nicht viel besser anstatt JP2 den JP4 für die FPU wegzulassen ?
Also anstatt csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ; dann das csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] ; und anstatt berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * JP4
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] ;PMMU, BKPT
); dann berr_20 = as_20 * ( berr_00
+ fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16]
+ fc0 * fc1 * /a[19] * /a[18] * /a[17] ;PMMU, BKPT
);
... oder ?
-
Ich zitiere mich mal selbst: "Du kannst nicht einfach alle Vorkommen von JPx und /JPx entfernen, Du musst die Gleichungen schon anpassen, je nachdem ob der Jumper als gesetzt oder als nicht gesetzt angenommen werden soll."
-
JP4 für die FPU soll ja nicht gesetzt sein also über den 4,7k Pullup auf High. Weiss ja nicht wie man den JP4 entfernt, muss doch möglich sein oder nicht ?
Anstatt JP4 = VCC zu schreiben geht ja wohl nicht ?
-
JP4 für die FPU soll ja nicht gesetzt sein also über den 4,7k Pullup auf High. Weiss ja nicht wie man den JP4 entfernt, muss doch möglich sein oder nicht ?
Klar, ich habe es schon mehrmals erklärt. Zitat: "Für einen Jumper 'JPx' der gesetzt sein soll, lass alle Produkte stehen die 'JPx' enthalten und entferne alle, die '/JPx' enthalten. Für einen Jumper der nicht gesetzt sein soll, genau umgekehrt: Produkte mit 'JPx' entfernen, mit '/JPx' stehen lassen."
Abstraktes Beispiel: Wenn da steht...
X = A * B * C * JP4
Y = D * E * F * /JP4 + G
... und der Jumper soll quasi dauerhaft gesetzt sein, dann mach daraus
X = A * B * C
Y = G
Anstatt JP4 = VCC zu schreiben geht ja wohl nicht ?
Weiß ich nicht. Probier es aus, ob der Assembler das akzeptiert (und dann wegoptimiert).
-
Hast Du denn meinen Vorschlag, A24 an U6 dauerhaft per Jumper auf low zu setzen (mit dem U6_A24-GAL natürlich) einmal ausprobiert?
Das wäre sozusagen "Hardware SingleStep"
-
Wie man hier sieht kann ich das nicht !
Ich gebe auf, das muss jemand machen der Ahnung hat oder auch nicht und weiss was er da tut ...
@joejoe ... um A24 auf low zu legen muss ich löten, bisher ist alles Steckbar.
-
Zum Verständnis: Stell es Dir einmal als Gleichungen im mathematischen Sinne vor. Auch wenn das nicht ganz korrekt ist, schließlich haben wir in Realität im GAL logische Und- und Oder-Verknüpfungen, keine Multiplikationen und Additionen, werden damit die Anpassungen verständlich.
Wenn z.B. JP4 dauerhaft gesetzt sein soll, dann wird (aufgrund der Schaltung) JP4=1 und aus "X = A * B * C * JP4" wird "X = A * B * C * 1", was sich zu "X = A * B * C" vereinfachen lässt. /JP4 (sprich Nicht-JP4) wird bei dauerhaft gesetztem Jumper zu "Nicht-1" also /JP4=0. Somit wird aus "Y = D * E * F * /JP4 + G" also "Y = D * E * F * 0 + G", nach Vereinfachung also "Y = G".
-
Warum denn löten, wenn A24 auf Pin 11 liegt, also anstelle von /JP2, dann hast Du dort doch den Jumper. Wenn Du A24 von der CPU nicht steckbar auf dem Jumper hast, sondern fest angelötet, dann musst Du natürlich löten (1 Pin- kein Ding, oder?).
Der Charme die zusätzlichen Signale per Jumper bzw. Pfostenfeld Buchsenstecker wie, z.B.mit einer passend abschnittenen HDD-LED-Leitung vom PC, liegt ja in dem schnell möglichen Umbau.
-
JP4 ist in der Pin-Definition der Palasm-Quelle durch /JP4 als low-aktiv definiert.
Heißt in diesem Fall, wenn der Eingang mit GND verbunden ist, dann ist der boolsche Wert der Variable JP4 in den GAL Gleichungen "wahr" = "1".
Wird der reale Jumper am GAL Eingang /JP4 entfernt, dann wechselt der boolsche Wert auf "nicht wahr" = "0".
In den GAL-Gleichungen wird immer mit den logischen Bool-Werten gearbeitet, unabhängig, in welcher Logik (low-aktiv oder high-aktiv) der PIN definiert wurde. Das kann dann schon etwas verwirren. Und bei JEDI ist das - glaube ich- anders?
Alternativ könnten aber auch alle low-aktiven Eingänge in der GAL-Quelle ohne Negation definiert werden, dann entsprechen die logischen Werte in jeder Zeile der GAL-Gleichungen den physikalischen Spannungspegeln.
Nur muss dann für die gleiche Funktion der Ausgang entsprechend negiert werden.
Das muss jede Person selbst entscheiden, welche Variante logischer erscheint.
-
Mein eingekürztes GAL läuft aber wenn ich A24 hinzufüge funktioniert es nicht mehr. Habe keine Ahnung woran es liegt ...
Auch das GAL von joejoe mit A24 funktioniert ja nicht.
-
Habe beim Artikel suchen folgendes gefunden:
Bequemer aufUmwegen
Daten von PALAM4 für den GalProg aufbereitet
Ein Artikel aus der ct 2/92 Seite 158
Vielleicht hilft das etwas...
-
Schaue ich mir an, ich habe die 1990-2008 DVD ...
-
Das Thema ist erledigt für mich. Ich bin nicht in der Lage das umzusetzen. Falls jemand meint das ganze erfolgreich zu Ende zu bringen dem könnte ich den Atari Mega ST4, PAK68/2 und Magnum TT gerne zur Verfügung stellen.