atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Do 12.05.2016, 16:53:01
-
Das Layout für eine PAK68/2 ist fertig von neogain. Dieser Thread dient an erster Stelle dazu mal zu sehen wie groß das Interesse an einer Platine ist. Die Bauteile gibt es alle bei Kessler. Der Preis incl. Porto wird innerhalb Deutschlands 32,- Euro betragen.
Wenn genügend Leute zusammen kommen werden die ersten 5 Platinen hergestellt und ich baue mal eine auf um zu sehen ob alles einwandfrei ist. Dann geht es ans bezahlen und ich verschicke dann die Sachen. Im Anschluss daran kann ich immer 10 Platinen herstellen lassen, das ist zwar ein wenig Teuer weil auch jedes Mal DHL Porto und Zollgebühren dazu kommen aber ansonsten ist mir das zu viel Geld.
Ich schreibe auch noch Heise an und versuche diesen Manfred Vlkel oder Völkel (GK Computer) ausfindig zu machen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11203;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11205;image)
-
Nur ein Tip, ist günstig mit sehr hoher Qualität, Prototypenplatinen für 25$ je 10Stück.
http://dirtypcbs.com
Haben sehr gute Erfahrung damit gemacht und die Qualität ist echt Top.
-
Ich melde mal Interesse an.
-
Ich würde auf jeden Fall auch eine, evtl. zwei nehmen.
-
Danke fürs Engagement! Da würde ich gerne 2 nehmen.
-
Hallo Frank,
ich nehme auch 2 Stück.
Viele Grüße
Martin
-
OK, ist gut das was gemacht wird.
Aber leicht Ketzerische Frage: wäre eine kompaktere Platine nicht Zeitgemässer?
Habe leider zur Zeit genug selber andere Projekte am laufen, von daher kann ich das leider nicht übernehmen.
Frage: habe ich das richtig verstanden das bei der PAK ein TOS zwingend auf der PAK vorhanden sein muss oder geht auch ein TOS nur auf dem Motherboard? (Klar, das wäre nur 16-Bit Zugriff und damit langsamer.)
-
OK, ist gut das was gemacht wird.
Aber leicht Ketzerische Frage: wäre eine kompaktere Platine nicht Zeitgemässer?
Habe leider zur Zeit genug selber andere Projekte am laufen, von daher kann ich das leider nicht übernehmen.
Frage: habe ich das richtig verstanden das bei der PAK ein TOS zwingend auf der PAK vorhanden sein muss oder geht auch ein TOS nur auf dem Motherboard? (Klar, das wäre nur 16-Bit Zugriff und damit langsamer.)
Ketzerisch ist die Frage nicht. Natürlich wäre es kompakter alles in SMD zu fertigen. Aber diese hier sollte möglichst originalgetreu dem Layout der c't entsprechen um "Böse" Überraschungen zu vermeiden. Man kann es aber immer noch auf SMD umbasteln und evtl. für die Roms einen großen Chip nehmen, der die 4 Roms dann ersetzt. Erstmal das hier, dann kann man immer noch schauen. Ob man jetzt unbedingt das TOS auf der Pak haben muss, kann ich dir nicht sagen. Normalerweise läuft es mit Kaos oder 2.06, bloß für das gepatchte TT Tos müssen die Zusatz Roms mit drauf. Außerdem ist diese auch für Amiga, Macs interessant. Diese Pak68/2 deckt einiges ab und ist universell.
-
Man müsste die GALs in einem Baustein zusammen fassen und eventuell zwei 16bit breite EEproms nutzen für das TOS oder Flash. Meine PAK68/2 läuft hier mit der MonSTer ohne TOS auf der PAK nur wenn KAOS im Flash der MonSTer aktiviert ist. Mit TOS 2.06 auf dem Mainboard läuft die Karte nicht. Sprich es ist zwingend ein TOS 1.04 oder kleiner notwendig und TOS 2.06 auf der PAK 32-bit breit. Eine Magnum ST geht auch nur mit dem TOS 2.06 auf der PAK.
-
Habe mal unter TOS 2.06 einige Testprogramme laufen lassen um einen Eindruck zu bekommen ...
-
Hast du das mit der ET4000 getestet oder ohne?
-
Alles ohne irgendetwas ...
Ich habe keinen Blitter in meinem Mega ST.
Die Tests über die Grafikkarten sind aber alle gut so bei/um die 150% mit dem Nova Treibern.
-
Das Layout für eine PAK68/2 ist fertig von neogain. Dieser Thread dient an erster Stelle dazu mal zu sehen wie groß das Interesse an einer Platine ist. Die Bauteile gibt es alle bei Kessler. Der Preis incl. Porto wird wahrscheinlich innerhalb Deutschlands 38,- Euro betragen.
Wenn genügend Leute zusammen kommen werden die ersten 5 Platinen hergestellt und ich baue mal eine auf um zu sehen ob alles einwandfrei ist. Dann geht es ans bezahlen und ich verschicke dann die Sachen. Im Anschluss daran kann ich immer 10 Platinen herstellen lassen, das ist zwar ein wenig Teuer weil auch jedes Mal DHL Porto und Zollgebühren dazu kommen aber ansonsten ist mir das zu viel Geld.
Ich wäre auch an 1 bis 2 Stück interessiert. Sollte ja auch auf meinen 1040STFM Maschinen laufen, oder? Sind Sockel zum Durchschleifen des Prozessors vorgesehen? Auf dem Foto sieht's jedenfalls so aus... Die Platine müsste bei mir noch die MonSTer und eine Speichererweiterung huckepack nehmen.
Viele Grüsse,
Mich
-
Die Pak läuft auf der 1040er-Platine. Aber in ein 1040er Gehäuse bekommst du das nicht rein.
-
Ich würde ja vorschlagen, lasst noch etwas Zeit. Das board könnte man schon redesignen doch wenn man das macht sollte man es so machen das man die Karte erweitern kann. Und aus heutiger Sicht bekommt man die Karte viel kleiner hin und damit Preiswerter. Da gehört z.b. dringend Fastram drauf. Ich weiß auch wer das Realisieren kann. Ich werde mit ihm mal darüber quatschen ob man die Pak3-030 nicht neu auflegen kann. Aber ich halte euch von eurem Tatendrang nicht ab.
-
Die PAK68/2 läuft bei mir mit der MonSTer wenn auf der MonSTer TOS 1.04 oder wie in meinem Fall KAOS aktiv ist und TOS 2.06 natürlich auf der PAK.
Ich habe Holger schon gefragt wegen Fastram mit dem MC68020 ...
kann man eigentlich echtes Fastram wie im Atari TT an einen MC68020 anbinden ?
Ja, geht.
wegen FRAK mit der 020 PAK und damals ging es nicht mit dem Atari TT TOS auf der 020 PAK
Die FRAK war nur für den synchronen Buszyklus mit /STERM ausgelegt.
Beim 68020 gibt es das nicht, man müsste das mit asynchronen Buszyklen mit /DSACK1,2 machen.
Braucht einen Taktzyklus mehr, und Burst gibt es auch nicht, aber ansonsten geht alles.
Ich habe aber nicht das Wissen das umzusetzen und ich weiss nicht ob Holger das machen würde ?
Ich nehme weiterhin mal an das man ein TOS 3.06 zusammen mit dem Fastram braucht und dann wird die MonSTer nicht mehr laufen ...
Was ich daran gut finde ist das es etwas neues wäre ...
Das mit der PAK68/3-030 und einer Magnum TT auf einer Platine ist ausser dem Layout ja kein Problem. Aber so eine Platine wird Teuer da minimum 4 fach Layer und groß ...
-
Aktuell arbeiten wir ja an dem TT-Ram TT-IDE Projekt und wenn dies Fertig ist dann können wir weitersehen (IDE läuft schon). Ich könnte mir vorstellen eine 68030 Karte mit TT-Ram Connector der Kompatibel ist. Darauf könnte man dann TT-Ram Karten stecken und natürlich auch das IDE Interface. Ideen haben wir viele, aber ich denke was als nächstes kommt werden wir im Juni in Hannover besprechen.
-
Alles auf einer großen Karte finde ich aber besser. IDE gibt es für die kleinen Atari genug das braucht da nicht mit drauf finde ich. Alan hat ja auch noch eine Dual IDE Karte ...
-
wie du schon sagtest, die Karte wird dann zu teuer
-
Aber Fastram ist schon ein Muss ...
Ich finde eine große Karte besser als dieses Türmchenbauen und zusammen stecken. So eine Magnum TT braucht ja jetzt auch nicht allzu viel Platz.
-
Hast du das mit der ET4000 getestet oder ohne?
... alles mit den NOVA Treibern unter 1024x768 und 256 Farben.
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11227;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11229;image)
-
Wow!
-
Die c´t hat geantwortet ...
Hallo, Herr Lukas,
solange Sie diese nicht öffentlich kommerziell vermarkten, habe ich damit kein Problem.
Viel Spaß dabei, mit freundlichen Grüßen, Detlef Grell, c't
Am 13.05.2016 um 10:14 schrieb Frank Lukas:
Ihre Mitteilung in einem Satz: c´t Projekt 90 Jahre PAK68/2 Platinen
Projekt ...
Ihre ausführliche Mitteilung: Hallo, im Rahmen eines privaten Atari
ST Retro Forums möchten wir gerne Platinen zum c´t Projekt PAK68/2
aus den 90 Jahren wahrscheinlich in einer 10 oder 20 Stück Auflage
herstellen lassen. Meine Frage ist nun ob von Ihrer Seite etwas
dagegen spricht ?
Mit freundlichen Grüßen
-
Die Benchmarkwerte sind klasse in der Auflösung! Dazu noch das offizielle OK der ct´ rundet das Projekt ab. Von mir dazu auf jeden Fall: Daumen hoch!
-
Das board könnte man schon redesignen doch wenn man das macht sollte man es so machen das man die Karte erweitern kann.
Hier gab es schon recht viele Ansätze etwas zu machen und jedes Mal wurde nichts draus. Das wird zerredet und jeder will das so machen wie er möchte.
Zum Beispiel ist es ja nicht ohne Fastram zum MC68020 hinzuzufügen. Für mich ist das zu kompliziert da DSACK1 und 2 mehrere Funktionen gleichzeitig haben. Da müssten mal Vorschläge kommen wie man die STERM Steuerung durch eine DSACK mit Waitstates ersetzen kann und den MACH210 der Magnum TT entsprechend anpassen ...
Ich will etwas machen ...
Und das beschränkt sich zur Zeit im Neuauflegen schon erprobter alter Erweiterungen. Eine PAK68/3 mit Multilayer und Magnum TT auf einen Board schreit förmlich nach einen Pool in dem etwas Geld wäre um Prototypen Platinen fertigen zu lassen. Für einen alleine ist sowas zu Teuer ...
-
Es gibt einige Leute hier im Forum die sowas machen könnten, gibt auch Leute die machen einfach eigenentwicklungen obwohl man gemeinsam beginnt. So das die so schon recht wenige Menpower die Arbeit doppelt machen. Wie ich schon gesagt habe, wenn wir unser Projekt fertig haben TT-RAM IDE geht das nächste los.
-
Die Leute die an einer PAK interesse haben sollten vielleicht darüber nachdenken sich einen Preiswerten Prommer aus China zu besorgen. Ich nutze einen G540 USB Universal Programmer für knapp 40,- Euro unter Windows 7. Für GAls und Eproms einwandfrei.
Mit dem rommix.ttp aus dem Pinatubo Paket von Michael Schwingen kann man sich die vier 27C512 Eproms selber aufteilen ...
# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 TOS-2.06-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)
# Puffergre setzen
bufsize 256k
# Directory setzen
chdir e:\pinatu24\rommix\
load tos206.img 0 256k all -> 0 all
save ee.u11 64k <- 0 ee
save oe.u10 64k <- 0 oe
save eo.u9 64k <- 0 eo
save oo.u8 64k <- 0 oo
-
Kannst du nicht passende Chips programmieren und der Platine beilegen? Dass sich jeder so ein Gerät zulegt ist doch Unsinn!
-
Ja na klar kann ich das machen ...
-
NemBench Test mit der PAK68/2 16Mhz-020_CPU/20Mhz-FPU mit MonSTer und 8MB Alternate Ram. Die 100% Vergleichswerte sind ein Atari Falcon.
NemBench v2.1 - precision CPU/FPU profiler.
Integer multiply (16bit) -> 0.615 Mips (~100%)
Integer divide (16bit) -> 0.363 Mips (~100%)
Linear (stalled) integer -> 7.992 Mips (~100%)
Interleaved (piped) integer -> 7.992 Mips (~100%)
Float multiply (64bit) -> 0.293 MegaFlops (~110%)
Float divide (64bit) -> 0.193 MegaFlops (~111%)
Linear (stalled) float -> 0.512 MegaFlops (~96%)
Interleaved (piped) float -> 0.507 MegaFlops (~95%)
16bit read (100% hit) -> 3.151 MByte/sec (~40%)
16bit write (100% hit) -> 4.000 MByte/sec (~66%)
32bit read (100% hit) -> 3.493 MByte/sec (~22%)
32bit write (100% hit) -> 4.051 MByte/sec (~60%)
Linear 32bit read (ST-Ram) -> 2.619 MByte/sec (~49%)
Linear 32bit write (ST-Ram) -> 3.898 MByte/sec (~60%)
Linear 32bit copy (ST-Ram) -> 1.959 MByte/sec (~60%)
Linear 32bit read (FastRAM) -> 3.480 MByte/sec (~65%)
Linear 32bit write (FastRAM) -> 3.915 MByte/sec (~60%)
Linear 32bit copy (FastRAM) -> 1.952 MByte/sec (~60%)
-
NemBench Test mit der PAK68/2 16Mhz-020_CPU/20Mhz-FPU mit MonSTer und 8MB Alternate Ram. Die 100% Vergleichswerte sind ein Atari Falcon.
Sehr ordentlich, toll! Läuft die MonSTer mit 16 MHz RAM-Takt oder mit 8? Im MegaSTE läuft sie ja wohl mit 16, drum frag ich ...
-
Ich habe einen Atari Mega ST ohne E. Zum Mega STE kann ich nichts sagen. Ich hatte mal einen Mega STE damals mit PAK68/3 und FRAK. Wenn der Mega STE mit 8Mhz lief gab es keine Probleme. Damit das im MSTE ging gab es aber erhöhten Anpassaufwand. Genau so ist es wahrscheinlich auf mit der PAK68/2. Die PAK68/2 verdoppelt ja den 8Mhz Mainboard Bus Takt und läuft nicht asynchron wie eine PAK68/3
-
So die Platinen sind gerade gekommen. Bestelle jetzt bei Kessler die Teile um eine mal aufzubauen und wenn alles klappt können die Interessenten die bekommen von mir ...
Habe die Preise ein wenig angepasst.
Für Leute die nicht selber löten wollen kann ich auch alles komplett fertig und getestet anbieten ...
-
So die restlichen Teile von Kessler kamen heute morgen und die Karte ist jetzt fertig aufgebaut. Läuft allerdings nicht, der Rechner stellt sich tot. Heute habe ich da keine Lust mehr drauf, werde morgen auf Fehlersuche gehen. Ich hoffe das ist mit ein wenig Fädeldraht aus der Welt geschafft. Hatte noch en GAL Satz getestet und der ist in Ordnung. Mal schauen ...
-
Die Karte läuft jetzt, es waren drei Verbindungen zu den GAL Bausteinen nicht da. Aber ein größeres Problem ist das ich die FPU nichts ans funktionieren bekomme. Diverse Tools sagen es wäre keine FPU vorhanden. Alle Signale am FPU Sockel sind da. Der GAL Satz ist auch in Ordnung ebenso die FPU. Ich habe drei zum probieren. Erst hat mich der /Sense Anschluß verwirrt da der Pin auf GND liegt aber es ist in der FPU auf GND verschaltet.
Wegen der FPU brauche ich dringend Tipps zur Fehlerbehebung ...
-
Du hast doch eine funktionierende PAK68/2 zum Vergleich, richtig? Dann kannst Du nun (in mühevoller Kleinarbeit) prüfen, was anders ist. Ein Verdächtiger bei "FPU tut gar nichts" wäre ja deren Chip-Select-Leitung. Lass ein Programm laufen, dass die FPU benutzen will und guck, ob das Chip-Select auch kommt.
PS: Dumme Frage, aber die PAK haben doch einen Jumper, um die FPU zu deaktivieren. Der sitzt schon richtig?
-
Mache ich gerade mit der original PAK68/2 ...
Bin gerade bei den SIZE0 und 1, da stimmt etwas nicht an einem der GAL Bausteine. Sysinfo und GemBench sprechen ja die FPU an und zeigen auch wenn eine gefunden wird und welche Art der Anbindung. Beim FPU Test kommen 4 Bomben. CS ist in Ordnung ...
-
SIZ0 und 1 sind in Ordnung. Bin etwas durcheinander von der ganzen Messerei ...
csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ;
Schaue mal nach FC0 und 1, hatte ich aber schon und war OK meine ich ...
-
4 Bomben = Illegal Instruction. Sollte bei einem Coprozessor-Befehl ausdrücklich nicht kommen, selbst wenn der Coprozessor (also die FPU) den Befehl mit einem Fehler quittiert.
Kannst Du die Testprogramme mal unter einem Debugger (Tempelmon?) laufen lassen, damit man sieht, bei welcher Instruktion der Fehler auftritt?
-
Das kann ich mal machen ...
Wenn ich das mit der FPU in den Griff bekomme werde ich die Platinen mit aufgelöteten Sockeln da wo Fädeldraht hin kommt ausliefern. Für die Mülltonne sind die zu schade ...
-
So geschafft, die FPU läuft jetzt. Ich hatte doch die Datenleitungen nicht genau genug nachgemessen. D23 fehlte an der FPU ...
-
Mach auf jeden Fall für eine weitere Auflage der PAK68/2 noch ein korrigiertes Platinenlayout.
-
neogain muss normal umziehen, ab Juli wahrscheinlich ...
-
Hier jetzt mal die allgemeinen Aufbauhinweise ...
Jeder sollte sich mal den/die c´t Artikel von Heise besorgen -> https://shop.heise.de/archiv/search/result?query=tausch+mit+turbo
Leserliche Schaltpläne als PDF kann ich per Anfrage via eMail verschicken ...
Die Bauteile sind so benannt wie im original von neogain, also kann man nach der original Bestückungsliste gehen. Die wichtigsten Bauteile bei Kessler sind ...
- M0204 560R (Widerstand 3mm 1%)
- M0204 1k
- M0204 4,7k
- M0204 10k
- QOS 32,000Mhz (optionaler Quarz FPU)
- PGA114 (Sockel 68020
- PLCC68Z (Sockel FPU)
- PZF64 (IC Fassung 68000)
- PZF20, PZF24, PZF14, PZF32
- TAN 10/16
- KER 22P R2,5
- VS 100N Z5U 2,5 (100nF Kondensator)
- JUMPER2,54-SW
- SA32SIL (68000 Pfostenleiste)
- STL1x50G (Jumper Pfostenleisten)
- 27C512 (Eprom 64kB 4 Stk. für TOS 2.06)
- GAL 20V8-15ns
- GAL 16V8-15ns
- MC68020RC20E (knapp 30,- Euro)
FPU -> http://www.vesalia.de/d_68882.htm
Durch die Patches wird die Platine schon mit dem FPU Sockel und den 68000 Sockeln+Pfostenleiste und 2Stk. 24pol. GAL Sockeln geliefert. Da ich in einer Versandtasche als Brief versende ist zum Schutz der 68000 Pfostenleiste ein 64pol. Sockel der wahrscheinlich beim Transport kaputt geht aber das macht nichts. Die goldene 68000 Pfostenleiste ist sehr empfindlich also Vorsicht beim Handieren damit. Später beim Einbau muss sowiesso ein Türmchen aus 64pol. IC Sockeln gebaut werden, also genügend bestellen.
Alle Bauteile werden normal auf der Bauteilseite bestückt bis auf den Kondensator für die FPU. Anbei auch zwei Bilder an denen man sich orientieren kann.
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11334;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11336;image)
Hier das Splitfile um aus dem normalen TOS 2.06 Image die vier Eprom Files für das 32-bit breite TOS für die PAK zu erzeugen. Benutzt wird das Romslit Paket aus dem Pinatubo Programm Paket. Es gibt ja auch noch das TOSPatch von Markus Heiden um Anpassungen am TOS umzusetzen ...
# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 TOS-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)
# Puffergre setzen
bufsize 256k
# Directory setzen
chdir a:\pinatu24\rommix\
load tos206.img 0 256k all -> 0 all
save ee.u11 64k <- 0 ee
save oe.u10 64k <- 0 oe
save eo.u9 64k <- 0 eo
save oo.u8 64k <- 0 oo
Wer den GAL Satz selber macht sollte beim programmieren Nullbytes = 00 setzen. Hier im Anhang sind die JED Files zu den GAL Bausteinen.
Die PAK68/2 läuft wunderbar zusammen mit der MonSTer Erweiterung von Alan. Auf der MonSTer muss nur ein TOS 1.04 oder KAOS TOS eingestellt sein, damit die PAK mit Ihrem TOS 2.06 booten kann. Die PAK68/2 braucht ein kleines TOS unter/gleich 1.04 auf dem Mainboard.
-
Zum Thema FastRAM auf der PAK/2. Ich hatte das damals mit einem guten Freund gemeinsam in etwa folgendermassen umgesetzt:
je zwei (oder waren es vier?) 128KByte statisches RAM (70ns) huckepack auf den EPROMs der PAK, ein weiteres GAL huckepack auf einem passenden GAL. Hier wurden die Chipselect und DTACK Signale für die zusätzlichen RAMs erzeugt. Damit das TOS 3.06 das FastRAM schon beim Booten findet, muss dieses physikalisch oberhalb der ersten 16MB liegen. Dazu kam dann eine zusätzliche Adresse ans GAL die Dekodierung kann sehr simpel bleiben, da TOS auf gespiegeltes RAM checkt und entsprechend verwaltet.
Ich habe meine damalige PAK/2damals auf ebay verkauft, vermutlich an einen von Euch? Daher wundert es mich, zum Thema FastRAM mit statischen RAMS noch nichts weiter gelesen zu haben. Bei den heutzutage verfügbaren SRAM-Größen sollte das eine _wirklich_ schnelle Alternative sein.
Gruß
Jörg
-
Das hatte ich auch im Kopf allerdings ist das viel zu wenig Fastram. Ich dachte eher in die Richtung Atari TT/PAK68/3 mit FRAK also an minimal 16MB Fastram mit der MC68020 CPU ...
Habe 2048kx8 und 8192kx8 welches eigentlich 16bit ist aber auch als 8bit SRAM laufen kann gefunden. Das ergäbe 8MB oder 32MB SRAM. Das Problem ist das sind alles 3,3V Typen, also braucht es einen Regler was kein Problem wäre aber ich weiss nicht ob es mit der 5V Logic klappt. Und der Bereich über 12MB im ST Ram muss frei bleiben für die Grafikkarte und andere Sachen. Der 020 ist ja eine 32bit CPU also sollte das Fastram wie im Atari TT liegen. Und ein Problem wäre noch das man wahrscheinlich TOS 3.06 mit den PAK Patches braucht und dann IDE nicht mehr funktioniert. Aber Holger Zimmermann hat ja das TOS schon gepatcht wegen IDE.
Man könnte eine Magnum TT anpassen. Holger Zimmermann schrieb mir das es mit DSACK0 und 1 geht, problem ist das ich alleine das nicht umsetzen kann.
-
ja, die DSACK0 und 1 Geschichte musste ich damals auch ändern im Decoder GAL für die EPROMS, das war in original PAK2 gleube ich einfach auf 32bittigen Zugriff ausgelegt. Habe mich damals an den Gleichungen für den Amiga orientiert. Wir hatten das gepatchte TOS 3.06 genutzt. Mit einer eigenen Initialisierungsroutine kann FastRAM auch unterhalb 16MB liegen, was dann das AlternateRAM wäre.
-
Wenn das im ST Ram Bereich liegt bringt es das nicht.
-
Das ist nicht ganz richtig,
Der Unterschied zu normalem ST-(D)RAM liegt in der Zugriffszeit mit 0-Wait States, da das SRAM einfach schnell genug ist. Diese Geschwindigkeit ändert sich nicht, egal ob das SRAM als Alternate-Ram (zwischen 12MB und 16MB) oder als FastRAM (oberhalb 16MB) angesprochen wird. Der Austausch zum "normalen" ST-RAM erfolgt über einen Puffer im ST-RAM, da die ST-I/O-Chips das Fast-/AlternateRam nicht selbst adressieren können.
Habe mal geschaut was es bei Reichelt so gibt:
AS-6C4008-55PCN für 5,70€ das Stück
https://www.reichelt.de/DRAM-FRAM-SRAM/AS-6C4008-55PCN/3/index.html?ACTION=3&GROUPID=2954&ARTICLE=146553 (https://www.reichelt.de/DRAM-FRAM-SRAM/AS-6C4008-55PCN/3/index.html?ACTION=3&GROUPID=2954&ARTICLE=146553)
mit 4 Bausteinen, also einer zusätzlichen Ebene über (oder unter) den EPROMS hat man dann schon 'mal 2 MB FastRAM. Z.B. in einem Mega-ST4 eingepflanzt heißt das 50% mehr RAM.
4 zusätzliche Lagen ergeben schon 8 MB FastRAM Der Vorteil liegt im recht einfachen, reversiblen Einbau in eine bestehende PAK/2.
-
Das ist richtig. Aber bei mir zum Beispiel arbeitet zusammen mit der PAK68/2 eine MonSTer mit Flash TOS und 8MB Alternate Ram plus Dual IDE und ein VOFA ET4000 Grafikkarten Adapter. Was mir da fehlt wäre echtes Fastram oberhalb der 68k ST Ram Grenze, je mehr desto besser. Genau so wie im Atari TT möglich, da sind mit einer Magnum TT 256MB Fastram möglich ...
-
Okay, die MonSTer kannte ich noch nicht,
...aber das ist ja beinahe derselbe Ansatz, nur das hier mangels fehlender Adressleitung (war's A20?) einer 68000-CPU eben nur Alternate-Ram bei (vermutlich) 8MHz und 16Bit Zugriff möglich sind. SRAM auf der PAK/2 würde 16MHz und 32-bittigen Zugriff bedeuten (natürlich nur bei Longword-Zugriffen) das bringt schon ein wenig Speed.
Aber das sollte auch nur ein kleiner Hinweis sein.
Gruß Jörg
-
Hier geht's aber ein bisschen durcheinander.
Also, richtig ist: Der 68000er hat nur einen 16-Bit-Datenbus, folglich sind alle Zugriffe natürlich maximal 16 Bit breit. Wenn die CPU nur bei 8 MHz läuft, sind die Zugriffe (selbst ohne Waitstates) natürlich auch nicht schneller. Die Anzahl der Adressleitungen, beim 68000er nur A23-A1, hat nichts mit 8 MHz oder 16 Bit zu tun, bestimmt aber die mögliche Lage des RAMs im Adressraum, mehr als 16 MiB kann der 68000er halt nicht adressieren. (Die Adressleitung A20 ist übrigens eher beim PC relevant...)
Ein 68020er hat einen vollen 32-Bit-Datenbus und einen Adressbus, der theoretisch 4 GiB adressieren kann. Somit kann dort -- wie auch im TT -- (Fast-)RAM oberhalb von 16 MiB eingebaut werden, auf den dann allerdings nur von der CPU (dafür aber 32-bittig und mit CPU-Takt) zugegriffen werden kann, nicht von der Peripherie.
-
Danke für die Korrektur der Adressleitung ;)
Was sonst "falsch" an meinen Aussagen gewesen sein sollte, kann ich nicht nachvollziehen. Deine Aussage trifft es ebenfalls: Es gibt durchaus einen nennenswerten Geschwindigkeitsvorteil von Fast (oder auch Alternate-) RAM auf einer PAK (32-bit, voller CPU-Takt) gegenüber AlternateRam am ST-Bus (16bit, 8MHz).
Auf einer PAK ist es relativ simpel SRAM im DIP32-Gehäuse zusätzlich zu integrieren, ohne zusätzliche FRAK oder ähnliches. Mehr wollte ich nicht sagen. 8)
>edit> Da hier von einem Re-Design der alten PAK/2 die Rede ist, wäre es durchaus naheliegend, den Turmbau mit gestapelten RAM/ROM Bausteinen, wie ich ihn beschrieben habe, durch zusätzliche (SMD-) Sockel auf der "neuen PAK/2" vor zusehen. Die Glue-Logic ist eher simple.
-
So kleines Fastram ist uninteressant ...
Magnum TT Quell MACH210 Datei (musste ich Einkürzen wegen der 10000 Zeichen)->
NODE ? Div[0] REG
NODE ? Div[1] REG
NODE ? Div[2] REG
NODE ? Div[3] REG
NODE ? Div[4] REG
NODE ? Div[5] REG
NODE ? Div[6] REG
NODE ? Div[7] REG
NODE ? StrRef REG
NODE ? StartHidden REG
NODE ? C_AS REG
NODE ? ClearRef REG
NODE ? DoCAS COMB
NODE ? RightAdr COMB
NODE ? UmDel1 COMB
NODE ? UmDel2 COMB
NODE ? MemStart REG
NODE ? R95 REG
NODE ? StartRefresh REG
NODE ? STermBankOK COMB
NODE ? STermInt REG
NODE ? STerm1 COMB
NODE ? R103 REG
NODE ? Bank_0A COMB
NODE ? Bank_1A COMB
NODE ? Bank_0B COMB
NODE ? Bank_1B COMB
NODE ? DelCAS COMB
NODE ? DelCAS2 COMB
;----------------------------------- Group Statements --------------
;group mach_seg_d Div[6..0]
;----------------------------------- Diverse Gleichungen -----------
String BankOK '(Bank_0A + Bank_0B + Bank_1A + Bank_1B)'
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
; ******* Bank Decodierung
Bank_0A = A24 * /A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31
+ /A24 * /A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
+ /A24 * /A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD1_0
+ A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
+ A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD1_0
Bank_0B = /A24 * A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * /PD1_0
+ /A24 * /A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
+ A24 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
+ A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
Bank_1A = /A24 * /A25 * A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * PD1_1
+ /A24 * /A25 * A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * /PD0_1 * PD1_0 * /PD1_1
+ A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * PD1_1
+ A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * /PD0_1 * PD1_0 * /PD1_1
+ /A24 * /A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD0_1 * /PD1_0 * /PD1_1
+ A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD0_1 * /PD1_0 * /PD1_1
+ A24 * /A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD1_0
+ A24 * /A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD1_0 * /PD1_1
+ A24 * /A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD0_1 * /PD1_0
+ A24 * A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * /PD1_0 * /PD1_1
+ A24 * A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * /PD0_1 * /PD1_0 * PD1_1
+ /A24 * A25 * /A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * /PD0_1 * PD1_0 * PD1_1
Bank_1B = /A24 * /A25 * /A26 * /A27 * A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * PD1_1
+ A24 * A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * PD1_1
+ A25 * A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * PD1_1
+ /A24 * A25 * /A26 * A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * PD1_0 * /PD1_1
+ /A24 * A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * /PD0_0 * PD0_1 * /PD1_0 * /PD1_1
+ /A24 * /A25 * A26 * /A27 * /A28 * /A29 * /A30 * /A31 * PD0_0 * PD0_1 * /PD1_0 * /PD1_1
; ******* Refresh Counter
Div[0] := /ClearRef* /Div[0]
Div[1] := /ClearRef* /Div[0]* Div[1]
+ /ClearRef* Div[0]* /Div[1]
Div[2] := /ClearRef* Div[2]* /Div[1]
+ /ClearRef* Div[2]* /Div[0]
+ /ClearRef* /Div[2]* Div[1]* Div[0]
Div[3] := /ClearRef* Div[3]* /Div[2]
+ /ClearRef* Div[3]* /Div[1]
+ /ClearRef* Div[3]* /Div[0]
+ /ClearRef* /Div[3]* Div[2]* Div[1]* Div[0]
Div[4].T := ClearRef* Div[4]
+ /ClearRef* Div[3]* Div[2]* Div[1]* Div[0]
Div[5].T := ClearRef* Div[5]
+ /ClearRef* Div[4]* Div[3]* Div[2]* Div[1]* Div[0]
Div[6].T := ClearRef* Div[6]
+ /ClearRef* Div[5]* Div[4]* Div[3]* Div[2]* Div[1]* Div[0]
Div[7].T := ClearRef* Div[7]
+ /ClearRef* Div[6]* Div[5]* Div[4]* Div[3]* Div[2]* Div[1]* Div[0]
StrRef := /ClearRef* StrRef
+ /ClearRef* Div[7]* Div[6]* Div[5]* Div[4]
StartHidden := /ClearRef* StartHidden
+ /ClearRef* AS* Div[7]
R103 := /ClearRef* R103
+ /ClearRef* /AS* /RightAdr* StartHidden
+ /ClearRef* /AS* /BankOK* StartHidden
StartRefresh := R103
+ StrRef
+ /AS* StartHidden* /(RightAdr * BankOK)
R95 := StartRefresh* ClearRef* /MemStart
ClearRef := /R95* /MemStart* StartRefresh
;******* CAS Selection
/CAS_UU = MemStart* /AS* DoCAS* (RW
+ /A1* /A0)
+ /R95* /MemStart* ClearRef* StartRefresh
/CAS_UM = MemStart* /AS* DoCAS* ( RW
+ /A1* SIZ1
+ /A1* /SIZ0
+ /A1* A0)
+ /R95* /MemStart* ClearRef* StartRefresh
/CAS_LM = MemStart* /AS* DoCAS*( RW
+ A1* /A0
+ /A1* SIZ0* SIZ1
+ /A1* /SIZ0* /SIZ1
+ /A1* SIZ1* A0)
+ /R95* /MemStart* ClearRef* StartRefresh
/CAS_LL = MemStart* /AS* DoCAS* ( RW
+ A1* SIZ1
+ /SIZ0* /SIZ1
+ A1* A0
+ SIZ0* SIZ1* A0)
+ /R95* /MemStart* ClearRef* StartRefresh
; Async Set fuer RAS verzoegern
DelCAS2 = /CAS_UU * ClearRef * /R95
DelCAS = DelCAS2
;******* RAS Selection fuer 4 Baenke
/RAS_0A:= StartRefresh* /MemStart* ClearRef* /R95
+ /StartRefresh* /AS* RightAdr* BANK_0A
+ MemStart* /AS* /RAS_0A* RightAdr* BANK_0A
;RAS_0A.SETF = /CAS_UU* ClearRef* /R95
RAS_0A.SETF = DelCAS
/RAS_0B:= StartRefresh* /MemStart* ClearRef* /R95
+ /StartRefresh* BANK_0B* /AS* RightAdr
+ BANK_0B* MemStart* /AS* RightAdr* /RAS_0B
;RAS_0B.SETF = /CAS_UU* ClearRef* /R95
RAS_0B.SETF = DelCAS
/RAS_1A:= StartRefresh* /MemStart* ClearRef* /R95
+ BANK_1A* /StartRefresh* /AS* RightAdr
+ BANK_1A* /RAS_1A* MemStart* /AS* RightAdr
;RAS_1A.SETF = /CAS_UU* ClearRef* /R95
RAS_1A.SETF = DelCAS
/RAS_1B:= StartRefresh* /MemStart* ClearRef* /R95
+ /StartRefresh* /AS* BANK_1B* RightAdr
+ /RAS_1B* MemStart* /AS* BANK_1B* RightAdr
;RAS_1B.SETF = /CAS_UU* ClearRef* /R95
RAS_1B.SETF = DelCAS
/WE_1 = /RW* MemStart
/WE_0 = /RW* MemStart
;******* Andere Adressen
RightAdr = FC0* /FC1
+ /FC0* FC1
;******* Handshake
MemStart := BankOK * RightAdr * /AS * /StartRefresh
+ BankOK * RightAdr * /AS * MemStart
C_AS := /AS* MemStart
STermBankOK = /BankOK
STERM.TRST = /AS* RightAdr* /STermBankOK
STERM = STerm1
STerm1 = STermInt
/STermInt := BankOK* RightAdr * /AS* (/0WS* /MemStart* /StartRefresh
+ 0WS* MemStart* /C_AS)
UmDel1 = /MemStart
+ UmDel1* RAS_1B* RAS_1A* RAS_0A* RAS_0B
UmDel2 = /UmDel1
/Row = 0WS* UmDel2
+ /0WS* /UmDel1
DoCAS = /Row
;----------------------------------- Reset, Preset etc. ------------
Div[7..0].RSTF = GND;
Div[7..0].SETF = GND;
Div[7..0].CLKF = CLK16;
StrRef.CLKF = CLK16
StrRef.SETF = GND;
StrRef.RSTF = GND;
StartHidden.CLKF = CLK16
StartHidden.SETF = GND;
StartHidden.RSTF = GND;
R103.CLKF = CLK16
R103.SETF = GND;
R103.RSTF = GND;
StartRefresh.CLKF = CLK16
StartRefresh.SETF = GND;
StartRefresh.RSTF = GND;
R95.CLKF = CLK16
R95.SETF = GND;
R95.RSTF = GND;
ClearRef.CLKF = CLK16
ClearRef.SETF = GND;
ClearRef.RSTF = GND;
RAS_0A.CLKF = CLK16
RAS_0A.RSTF = GND;
RAS_0B.CLKF = CLK16
RAS_0B.RSTF = GND;
RAS_0B.RSTF = GND;
RAS_1A.CLKF = CLK16
RAS_1A.RSTF = GND;
RAS_1B.CLKF = CLK16
RAS_1B.RSTF = GND;
MemStart.CLKF = CLK16
MemStart.SETF = GND;
MemStart.RSTF = GND;
C_AS.CLKF = CLK16
C_AS.SETF = GND;
C_AS.RSTF = GND;
STermInt.CLKF = CLK16
STermInt.SETF = GND;
STermInt.RSTF = GND;
Es geht wohl darum dieses anzupassen ->
STermBankOK = /BankOK
STERM.TRST = /AS* RightAdr* /STermBankOK
STERM = STerm1
STerm1 = STermInt
/STermInt := BankOK* RightAdr * /AS* (/0WS* /MemStart* /StartRefresh
+ 0WS* MemStart* /C_AS)
Der MC68020 hat kein STERM Signal und müßte mit Warteschleifen mit DSACK0 und 1 umgesetzt werden ?
-
Mit simpler GLUE-Lösung meinte ich die wenigen zusätzlichen GAL-Gleichungen für meine uninteressante Lösung. Mit den MACH210-Quellen für die Magnum TT habe ich mich nicht beschäftigt, da muss ich passen. SRAM ist eben einfacher anzuspechen als DRAM ;)
-
Das war mir Klar ...
Wenn man minimal 16MB Fastram so eingebunden wie beim Atari TT mit SRAM recht einfach umsetzen könnte warum nicht.
Die Magnum TT ist halt da, funktioniert und ist freigegeben. Ein neues Layout der PAK68/2 mit Magnum TT zusammen auf einer großen Platine wäre ja machbar. Die Magnum TT besteht aus recht wenigen Teilen als da wären einige Widerstände, F157, ein MACH210 und eben die beiden PS/2 Simm Sockel. STERM ist ein Ausgang auf der Magnum TT hin zur CPU, vielleicht wäre es ja möglich die Magnum TT so zu lassen wie sie ist und mit einem zusätzlichen GAL die DSACK Umsetzung für die MC68020 CPU zu machen, keine Ahnung ...
Für mich wäre sowas sehr Interessant da es etwas neues wäre, Fastram mit einer 020 CPU. Immer schneller und so, davon halte ich nichts. Ist eh selbst wenn es 10x schneller wäre im Grunde immer noch zu langsam. Selbst die Firebee ist eine Schnecke. Langsamkeit macht mir nichts aus ;-)))
-
DSACK ist einfach. Wenn Du das RAM 32-Bit-breit anbindest und es schnell genug ist, dass keine Waitstates nötig sind, musst Du nur /DSACK0 und /DSACK1 low ziehen, um der CPU einen erfolgreichen 32-Bit-Buszyklus anzuzeigen.
Davon abgesehen hat joejoe vollkommen recht und die Logik wird viel, viel einfacher, wenn es um SRAM geht und nicht um DRAM.
-
Laut Holger Zimmermann sind aber Warteschleifen nötig. DSACK0 und 1 haben doch mehrere Funktionen ?
SRAM wäre ja gut wenn man damit eine ansprechende Menge/Größe bewerkstelligen kann. So minimum 16MB sollte schon sein, meine ich.
-
Holger Zimmermann sollte es wissen, :)
allerdings meine ich mich erinnern zu können, das in dem Artikel zur PAK/2 in der c't damals von dem großen Geschwindigkeitsvorteil von 32-bit ROM mit, wie ich meine 0- wait-states, die Rede war. Die verbreiteten SRAMS waren mit 55-70ns damals schon schneller als die empfohlenen 100ns EPROMs sollten also ebenso fix angesprochen werden können.
btw.
Ich habe zum RAM-Baustein der mir bis gestern unbekannten MonSTer keine Doku im Netz finden können, ist aber vermutlich ein DRAM? Ansonsten wären zwei Stück davon schon einmal die geforderte Minmal-FastRAM-Größe.
-
MonSTer Anleitung -> http://www.atarikit.co.uk/monster/monster.html
Da ist auch SRAM drauf wahrscheinlich ein 4096kBx16 Baustein, keine Ahnung.
Also 4MB ST Ram plus 16MB TT Ram sind schon brauchbar. Je mehr desto besser ...
-
ja, aber zu dem dort eingesetzem Chip finde ich nix im Netz.
Du schriebst in dem MonSTer Thread, das wäre ein R1MV6416RSA,
dazu finde ich nix, weder ein PDF noch Preise, habe aber auch nur ge-googled.
-
Laut Holger Zimmermann sind aber Warteschleifen nötig.
Aha. Wieso?
DSACK0 und 1 haben doch mehrere Funktionen ?
Nicht wirklich. Ein Busteilnehmer signalisiert der CPU damit den Abschluss des Datentransfers und die Größe des Datentransfers, nicht mehr. Wie gesagt: /DSACK0 = /DSACK1 = low heißt 32 Bit. Siehe MC68020 User Manual.
-
Die Monster hat einen SRAM on Board, welches wirklich sehr Simpel anzusteuern ist, es braucht keinen Refresh, und keinen Adressgenerator wie die DRams, adressdecoder ist ausreichend. Hab damit auch schon gespielt hatte aber nur 1MB da ich nur kleine SRAMs hatte. Den hatte ich damals mit einem GAL angesprochen.
-
Du schriebst in dem MonSTer Thread, das wäre ein R1MV6416RSA,
Da hat sich wohl jemand beim Ablesen vertan und es ist ein Renesas R1WV6416RSA: https://www.arrow.com/en/products/r1wv6416rsa-7srb0/renesas-electronics
Tatsächlich SRAM, 64 MBit, 16 Bit breit.
EDIT: Wie schon irgendwo erwähnt, ist das ein 3V-Typ, Pegelwandlung passiert im CPLD.
-
Das sehe ich als Problem an, die großen SRAM Bausteine sind alle 3V Typen. Dann doch vielleicht lieber Magnum TT mit DRAM und Warteschleifen ...
-
Laut Holger Zimmermann sind aber Warteschleifen nötig.
Aha. Wieso?
Der 030 hat einen Burst Modus für besonders schnelle Zugriffe so wie ich das verstehe. Dazu ist die STERM Leitung dar. Der 020 hat dieses Signal nicht und wenn man mit -70ns DRAM arbeitet und der DSACK Steuerung braucht es vielleicht eine Warteschleife ...
-
Wenn das RAM schnell genug ist für (schnelle) synchrone Buszyklen mit STERM, warum sollte es dann für (langsame) asynchrone Buszyklen mit DSACK Waitstates brauchen? Hast Du Dir die entsprechende Abschnitte in den User Manuals mal durchgelesen?
Klar, wenn das RAM insgesamt zu langsam ist, dann brauchst Du Waitstates, das gilt aber für STERM genauso wie DSACK und ist auch kein Problem, weil Du STERM bzw. DSACK0/1 dazu nur verzögert aktivieren musst.
-
Das leuchtet ein, bestechend ...
Das Problem ist das am MACH210 kein Pin mehr frei ist. Wenn man jetzt das zweite Simm weglässt kann das gehen mit DSACK0 und 1 ...
-> http://www.uweschneider.de/Download.php
-
Du musst /DSACK0 und /DSACK1 ja nicht individuell bedienen können, zur Signalisierung eines abgeschlossenen 32-Bit-Zugriffs ziehst Du beide gleichzeitig auf Low. Es müsste also reichen, einen Pin (durch das Einsparen des STERM-Pins) über zwei Dioden mit den DSACKs zu verbinden.
-
Gute Idee, oder zwei Gatter mit Open Collector Ausgängen, oder ?
Dann kann die Magnum TT ja so bleiben wie sie ist und ich sorge nur dafür das beim aktivieren von STERM das Signal Low Aktiv ist ?
-
Sowohl /STERM als auch /DSACKx sind low-aktiv, Du solltest es weiterverwenden können.
Muss halt getestet werden, denn es kann natürlich immer noch sein, dass z.B. das Timing irgendeines Signals beim TT/68030 anders ist als bei der PAK/68020. Die Logik der Magnum TT ist zudem leider so komplex, dass ich sie nicht mehr durchschaue.
-
Schau dir mal den Schaltplan an. Ausser STERM sind alle Signale am MC68020 vorhanden. Da ist noch das Signal POR, welches auf der Magnum aber nur an einen Pullup Widerstand geht. Dieses POR hat mit der Magnum dann folglich nichts zu tun. Oder bin ich Blind ?
-
POR ist kein Signal des MC68030, das muss im TT generiert werden. ("Power On Reset", vielleicht?)
Ja, sonst sind die Signale auch am MC68020 vorhanden, aber ob im MACH210 der Magnum TT etwas mit diesen Signalen gemacht wird, das am MC68020 nicht funktionieren würde, kann ich nicht überblicken. Wird man wohl erst wissen, wenn es jemand testet...
-
Das Signal ist XPOR im Atari TT. Auf Seite eins ist es in der Funktion ein Reset Signal. Wird auch über ein 74 Gatter von der Reset Quelle abgeleitet. Hat also nichts zu sagen ...
Ich denke das ich mir die Magnum TT mal auf Lochraster aufbaue und dann an die PAK68/2 hänge, mal schauen ...
-
So, kann ja nur ab und zu reinschauen, weil ich hier in dem kuhkaff noch nicht mal Edge auf dem Handy habe. Verfolge das nur hier Häppchen Weise mit. Die ansetze für fastram finde ich interessant. Die pak 68/2 ist ja an dem Original Layout abgelehnt. Diese kann man sehr wohl noch verkleinern und lese mich gezwungenermaßen Massen z. Zt. Alles über CPLD ein, weil ich nichts anderes machen kann. Dieser ist sehr vielseitig und man kann locker durch diesen die gals einsparen. Natürlich ist der nicht voll 5v tollerant, aber durch ein Spannungsteiler kann man das regeln. Das mit SRAM ist ein sehr guter Ansatz. @tuxie macht zur Zeit beim tt Fortschritte und denke, er wird auch dann beim ST mithelfen. Mal schauen, was in Zukunft kommt. Vielleicht kriegen wir eine Allround Lösung hin, damit wir die schönen megas mit einer Lösung zur einer zeitgemäßen Aufrüstung bringen kann (denke da auch an WLAN mit der @cietz Lösung, usw.) Ansätze gibt es genug, nur kein komplett Paket.
-
Habe bei Kessler die letzten 8Stk. GAL20V8-15ns gekauft, jetzt haben die keine mehr. Muss mal schauen ob ich eine andere Quelle auftun kann die bezahlbar ist ...
Edit: Habe eine günstige Quelle, wenn jemand welche braucht PM an mich ...
-
AS6C8008.pdf
http://www.alliancememory.com/pdf/AS6C8008.pdf (http://www.alliancememory.com/pdf/AS6C8008.pdf)
das ist ein 8*8Mbit SRAM mit 2,7 bis 5,5V Versorgung.
16 Stück davon ergeben die geforderten 16MByte FastRAM.
D.h. damit wird noch nicht einmal eine zusätzlich 3,3V Spannungsquelle plus Pegelwandler nötig.
Wobei ich das Datenblatt zum Chip auf der MonSTer-Ram-Karte (all I/O are fully TTL-compatible) so deute, dass auch heir keine Pegelwandlung für die Adress-/Daten-Leitungen nötig sind.
Nach meiner Meinung sitz das RAM auf der PLCC-CPU-Variante nicht umsonst mitten im PLCC-Adapter. Hier sind alle Aderess- und Daten-Leitungen auf kurzem Wweg erreichbar. Müssten die alle noch durch CLPD dann wäre eine ander Lage günstiger.
Alliance bietet größere SRAMs nur in 3,6V an, vermutlich sind diese aber auch TTL-kompatibel
16 TSOPs sollten sich in einem neuen Layout halbwegs problemlos auf der schmalen Seite der PAK/2 unterbringen lassen, wenn das ROM einem Flash-Baustein weicht.
-
Problem ist das diese Rams ziemlich Teuer sind, und damit kommst du bei 16 Stück auf eine große Summe.
Habe eben geschaut zwischen 5-8€ pro stück je nachdem wo du es bekommst. Was bei 16 Stück gleich mal 80€ nur für die Rams sind.
-
Alan hat ja auch eine extra 8MB Alternate Ramkarte nur mit 8MB SRAM und einigen 74 TTL zur Ansteuerung ...
-> http://www.atarikit.co.uk
(http://www.fairlite.co.uk/AtariKit//8mb/8mbmegast.jpg)
Da sind keine Pegelwandler nötig. Auf der MonSTer das gleiche denke ich mal.
Wie müsste denn die Ansteuerung der SRAMs aussehen damit das TOS 3.06 das auch als Fastram erkennt. Der nächste Schritt ist erstmal das ich ein PAK gepatches TOS 3.06 auf die PAK68/2 setze. Ich weiss nicht wie das ist da die PMMU fehlt, keine Ahnung ...
-
Man müßte einen Adressdecoder zusammensetzen der ein Enable Signal erzeugt und ein entsprechendes DTACK Signal. Was den Speicher im Entsprechenden Signal einblendet. Dann brauchst du wohl 2 dieses SRAMS da du ja 32Bit haben willst.
Ist vergleichbar der Logik des IDE Interfaces.
-
Man könnte dafür auch die SRAM Chips benutzen die ich für meine RAM-Disk im Portfolio verwendet habe. sind 8Mbit (1Mb) pro Stück und kosten 4,65.
Natürlich immernoch teuer bei 16 Stück ...
Reichelt (https://www.reichelt.de/DRAM-FRAM-SRAM/CY62158ELL-45ZSX/3/index.html?&ACTION=3&LA=2&ARTICLE=146557&GROUPID=2954&artnr=CY62158ELL-45ZSX)
-
Bei 16Stk. 8bit breite SRAM Bausteine muss man doch eine Art Bankswitching machen, oder nicht ?
Ich finde ja die Lösung mit der Magnum TT immer noch besser, DRAM ist billig über Ebay zubekommen. Zum Beispiel zwei 32MB PS/2 Simm Module, bei der Magnum kann es ja auch EDO sein ...
-
Wobei man ja bei einer SRAM Lösung auch 16 Plätze Layouten kann und dann in vierer Schritten je nach Bedarf nachbestücken könnte ...
-
und Du musst natürlich die Logic für beliebigen (8?-16-32bitigen) Schreib-Zugriff auf das RAM realisieren. Die ROMs können einfach 32bittig gelesen werden, die CPU verwertet nur das was sie braucht; beim Schreiben muss natürlich die Zugriffsbreite korrekt beachtet werden. Ich weiß nicht, ob ich noch lesbare Kopien meiner GAL-Änderungen für die PAK/2 habe (auf Diskette???).
Habe mich aber damals an den Ergänzungen zur PAK/2 für den Amiga orientiert. Als Select-Signal habe ich einfach A24 genommen; die Spiegelungen werden vom TOS bei RAM-Test ermittelt.
-
also, meine magnum TT (Nachbau von Simbo ) läuft auch nach Mach austzausch (Danke nochmals an Gaga) weder mit meinen eigenen alten EDO-RAMs nach mit extra (teuer) auf ebay erworbenen (ebenso alten), welche laut Kompatibilitätslsite eigentlich laufen sollten.
Das finde ich teuer...
Hatte aber immer noch keine Zeit / Muße diesem Thema näher auf die Spur zu gehen.
Dann lieber aktuelle(re) (S)DRAM-Typen und entsprechend aufwändige Ansteuerung.
-
Das klingt doch schonmal gut. Suche doch bitte mal nach deinen GAL Gleichungen und poste die hier ...
-
also, meine magnum TT (Nachbau von Simbo ) läuft auch nach Mach austzausch (Danke nochmals an Gaga) weder mit meinen eigenen alten EDO-RAMs nach mit extra (teuer) auf ebay erworbenen (ebenso alten), welche laut Kompatibilitätslsite eigentlich laufen sollten.
Das finde ich teuer...
Hatte aber immer noch keine Zeit / Muße diesem Thema näher auf die Spur zu gehen.
Dann lieber aktuelle(re) (S)DRAM-Typen und entsprechend aufwändige Ansteuerung.
Ich weiss ja nicht was Simeon da damals gemacht hat aber ich hatte eine Magnum TT mit zwei 128MB Modulen in meinem Atari TT und hatte keinerlei Probleme damit. Auch mit anderen kleineren Simms die ich so rumliegen hatte ging es immer ...
-
Man könnte auch einen Adapter bauen um die TT-Ram Karte die wir aktuell Entwickeln zu verwenden, dort könnte man auch im CPLD Änderungen vornehmen für den Fall das sie nicht läuft.
-
btw.
warum nehmt Ihr denn eigentlich nicht die PAK/3 als Basis?
gibt es da (noch) rechtliche Probleme?
oder integriert alternativ die HuckePAK Aufsetz-Adapterplatine (68030 auf der PAK/2) von Herrn Zimmerman in das Layout.
Preislich sollten da keine großen Unterschiede existieren zwischen einer 68020 und 68030 CPU.
-
Die 020 CPU gibt es in neu bei Kessler in 20Mhz für knapp 30,- Euro. Eine 030 kostet mehr. Aber Geld ist da nicht das Problem. Die Cache Rams und Tag Rams sind doch schwierig zu bekommen, oder ?
Und ich für meinen Teil finde ja die PAK68/2 mit Fastram gut weil es etwas neues wäre das es noch nicht gab.
-
stimmt, das mit dem Cache-Ram ist ein Argument.
Allerdings, ist nicht der interne Cache der 68030 größer als der einer 68020?
Wenn ich mich recht entsinne, war dazu (Cache-miss-Verwaltung 68030 bei extzernen DMA-Zugriffen) auf der HuckePAK Platine eine weitere Logic nötig, aber bei einem re-Design ja kein ernsthaftes Problem. Zudem hat die 030 ja eine (bessere, größere, überhaupt) PMMU, was weitere Vorteile bringt. Das einfachere, zum ST-Bus synchrone, Design der PAK/2 hat ja auch seine Vorteile.
-
Das ist der betreffende Artikel
Tausch mit Turbo
c't 10/1991, S. 178
-
Dazu kommt noch das es wahrscheinlich nur mit 4-Layer bei einer PAK68/3 geht. Die original PAK68/2 ist zwar auch 4-Layer aber ich habe keine Unterschiede zu der neuen in 2-Layer festgestellt.
Eine PAK68/3 ohne L2-Cache wäre vielleicht gut. Was mich stört ist dieses Türmchen bauen mit der FRAK. Eine größere Leiterplatte wo alles drauf ist fände ich schöner da man so das Gehäuse noch zu bekommt. Es gab ja damals einige 030 Karten mit Fastram alles auf einer großen Leiterplatte ...
-
Das ist der betreffende Artikel
Tausch mit Turbo
c't 10/1991, S. 178
Kaufe ich heute Abend mal -> https://shop.heise.de/archiv/search/result?query=tausch+mit+turbo
-
zum Thema (CPU-) Türmchen gebe ich Dir völlig Recht.
Meine PAK/3 mit FRAK/2, Panther/2, PuPla und c't TOS-Adapterkarte brauchte auch schon einen großen PC-Tower und hatte oftmals Kontaktprobleme; der Hebelarm war dann doch etwas groß, zudem ich schon 4 68000-Sockel brauchte, um den Turm auf eine Höhe oberhalb der anderen Einbauten (HDD-Speeder) auf einer ST520-Platine mit 4 MB Ram zu bringen. Stabil war dann doch etwas anderes.
-
Ich fürchte, das war der falsche Link, der von mir gepostetet klingt doch stark nach der ersten PAK.
Sorry
-
Nee, Tausch mit Turbo ist schon die PAK68/2 ...
Die alte PAK mit TTL Grab war früher.
-
Ja, aber das war nicht der Artikel mit der zusätzlichen, kleinen Adapterplatine für die PAK/2 welche einen Adapter für eine 68030-CPU auf den 68020-Sockel der PAK/2 darstellt. Der Artikel dazu in der c't ist wenige Monate vor Erscheinen der PAK/3 herausgekommen.
Ich muss 'mal gucken, ob ich den richtigen Artikel finde.
-
Ja genau, ich erinnere mich ...
Hatte ich damals auch mal gekauft und funktionierte nicht meine ich. Keine Ahnung warum, vielleicht wegen dem TOS ?
-
Da ist es -> https://shop.heise.de/katalog/hochsitz
Holger Zimmermann ist bestimmt so nett und sucht bei Bedarf das JED Files raus ...
-
Yep, Hochsitz, nicht HuckePAK (man kann sich ja auch nicht an alle Kleinigkeiten erinnern).
Bei einem Freund lief das Teil aber.
-
Ja sollte laufen, ich weiss auch nicht was ich damals falsch gemacht habe ...
-
Habe mir an meinem letzten Urlaubstag gleich den Hochsitz-Artikel gegönnt:
hier zwei Zitate daraus:
In älteren Rechnern, etwa im Mac II, auf Eurokarten-Computern (wie unserem c't 68020), aber vor allem auf 68000-Beschleunigerboards (wie unserer PAK68) findet sich der Prozessor 68020 als genügsames Arbeitspferd. Dort könnte er auch alt werden - würde nicht der 68030 mit seiner eingebauten PMMU (Paged Memory Management Unit, seitenorientierte Speicherverwaltungseinheit) und dem zweiten (Daten-) Cache locken. Über den Sinn eines Daten-Cache braucht man nicht zu streiten - dort vorrätiges Zahlenmaterial ist schnellstmöglich zur Stelle und muß nicht aus dem Hauptspeicher hervorgekramt werden. Je nach Software ergibt sich allein durch dieses Zwischenlagern ein Geschwindigkeitsvorteil von 15 Prozent gegenüber dem lediglich mit einem Befehls-Cache ausgerüsteten 68020. Die PMMU nützt allerdings nur in Verbindung mit entsprechender Software-Unterstützung etwas: Virtual Memory von Apples System 7 zum Beispiel macht regen Gebrauch davon
.
=> Da würde dann auch Mint davon profitieren.
Gleichlautende Prozessor-Pins sind durchverbunden, nur die 68030-spezifischen Pins müssen adäquat behandelt werden - entweder durch Pull-Ups oder durch das angeflanschte GAL.
=> Dieser Aufwand sollte für jemanden, der das alte Layout nachvollzogen hat dann ja eher kein Problem darstellen.
-
Das GAL ist aber sehr wichtig bei der ganzen Sache.
-
ja, aber mit simplem Inhalt (den will ich aus rechtlichen Gründen hier nicht im direkten Zusammenhang posten, denn viel mehr Informationen gibt es im ganzen c't Artikel nicht).
Das cache -Signal wird aus der Verknüpfung von den u.a zum Datenaustausch mit dem CoPro benötigten FC0 bis FC2 und dem cacheablen RAM.-Bereich gebildet. Wenn FastRAM (also oberhalb A23) vorhanden ist, dann müssen die betroffenen Adressleitungen natürlich ebenfalls mit ins GAL einfließen.
Aber ich glaube, es gab auch noch eine Ergänzung zu diesm Artikel.
-
Die GAL-Gleichungen im Artikel sind sowieso nur passend für einen Mac SE, für den Atari müssen sie neu geschrieben werden. Ist aber nicht schwer.
-
Irgendwie fehlt da dann auch das Signal um Cache zu verwerfen, wenn z.B. ein DMA-Schreibzugriff aufs RAM erfolgt ist. Wollte man nur das FastRAM chahen (auf welches sowieso nur die CPU Zugriff hat) dann könnte jegliche Adresse unterhalb 16MB als nicht cachable ins GAL eingehen.
-
Irgendwie fehlt da dann auch das Signal um Cache zu verwerfen, wenn z.B. ein DMA-Schreibzugriff aufs RAM erfolgt ist.
Stimmt, das war mir noch nicht aufgefallen. Das ist aber auch schwierig, weil der 68030 nach meinem Verständnis gar kein Eingangssignal dafür bietet.
Invalidieren TOS-Versionen, die auf einem 68030 laufen, denn wenigstens den Cache für den entsprechenden Speicherbereich, bevor sie DMA-Zugriffe starten? Dann wären nur Programme gefährdet, die den DMA direkt programmieren, an TOS vorbei.
Wie ist das eigentlich im TT gelöst?
Wollte man nur das FastRAM chahen (auf welches sowieso nur die CPU Zugriff hat) dann könnte jegliche Adresse unterhalb 16MB als nicht cachable ins GAL eingehen.
Das ist die sicherste Lösung, sicherlich.
-
Das ist aber auch schwierig, weil der 68030 nach meinem Verständnis gar kein Eingangssignal dafür bietet.
/CIIN - in Zusammenhang mit /BR, /BG und /BGACK
Abgesehen davon läuft der SE m.W. komplett DMA-los.
-
ups, da war jemand schneller:
hier (aus anno 1991 !!) ein paar weitere Infos dazu.
http://www.verycomputer.com/79_e0bfb7d5de99563c_1.htm#p5 (http://www.verycomputer.com/79_e0bfb7d5de99563c_1.htm#p5)
-
/CIIN - in Zusammenhang mit /BR, /BG und /BGACK
/CIIN verhindert doch nur, dass ein vom Bus gelesenes Datenwort im Cache landet? Das ist bei IO-Zugriffen natürlich richtigerweise aktiviert, das ist auch genau das, was das GAL im Artikel macht.
Wenn ich aber nun ein Wort aus cachebarem RAM lese (/CIIN = high), landet es im Cache und zukünftige Lesezugriffe werden natürlich aus dem Cache bedient und landen nicht mehr auf dem Bus.
Wenn sich dann aber das Wort im RAM durch einen DMA-Zugriff ändert, wie teile ich der CPU per Signal mit, dass dieses Wort im Cache invalidiert werden soll? Klar, per Software geht das (Cache Control Register) aber per Hardware-Signal? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht. Eigentlich kann ich da nur wie von joejoe geschrieben den kompletten vom DMA erreichbaren RAM vorsichtshalber als nicht-cachebar markieren.
-
Invalidieren TOS-Versionen, die auf einem 68030 laufen, denn wenigstens den Cache für den entsprechenden Speicherbereich, bevor sie DMA-Zugriffe starten? Dann wären nur Programme gefährdet, die den DMA direkt programmieren, an TOS vorbei.
Wie ist das eigentlich im TT gelöst?
Und das kann ich mir selbst beantworten mit dem TT030 Companion [1]: "any program which uses DMA directly (as opposed to making the BIOS or XBIOS calls) needs to invalidate the caches after the DMA operation completes".
Also: Es kümmert sich nicht die Hardware darum, nach DMA den Cache zu löschen. TOS auf dem TT macht es, aber Programme die eigene DMA-Zugriffe machen (z.B. Festplattentreiber) müssen sich auch selbst um den Cache kümmern. Wenn man nur nach dieser Devise entwickelte Software einsetzt, kann man allen RAM cachebar machen und das GAL wird -- wie von mir schon geschrieben -- sehr einfach.
[1] http://dev-docs.atariforge.org/files/TT030_Companion-Dev_Notes.pdf
-
? /CIIN hilft nach meinem Verständnis dort nicht weiter, weil die CPU ja gar keine Bus-Zugriffe auf die betroffene Adresse macht
na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein. Wobei /CIIN = A24 das Thema dann recht simple löst.
-
Alternativ könnte (ein gepatchtes) TOS 3.06 das CI-Bit der Pagedeskriptoren für non-cacheable Bereiche setzen. Hab mir aber die MMU nie genau angesehen.
-
na ja, die CPU liest natürlich trotzdem vom Bus. Wenn aber bei allen relevanten Zugriffen durch eine Hardware-Logik das CIIN-Signal aktiviert wird, landen die Daten der betreffenden Adressen eben nicht im Cache, damit sollte das Problem auch lösbar sein.
Drücke ich mich irgendwie unverständlich aus? Es geht doch gerade darum, dass wenn ein Wort einmal im Cache ist, es kein Hardware-Signal mehr gibt, der CPU mitzuteilen, es nicht mehr zu verwenden, weil es unterdessen von DMA modifiziert wurde. Genau in diesem Fall hilft /CIIN überhaupt nicht mehr weiter, denn es hätte schon beim ersten Zugriff gesetzt sein müssen, als man evtl. noch gar nicht wusste, dass DMA später in diesen Speicheradresse schreiben würde.
Entweder muss die Software nach DMA den Cache invalidieren (wie es Atari beim TT empfiehlt und ich bereits schrieb) ...
Wobei /CIIN = A24 das Thema dann recht simple löst.
... oder man muss das komplette ST-RAM vorsorglich als nicht-cachebar markieren (wie Du vorgeschlagen hast und ich ebenfalls bereits schrieb) und halt auf die Vorteile des Caches für das ST-RAM verzichten.
Beides ist keine optimale Lösung, weil man im ersten Fall auf anständig programmierte Software angewiesen ist und im zweiten Fall Performance verschenkt, gerade das langsamere ST-RAM gar nicht zu cachen.
-
nein, Deine Worte sind klar und verständlich.
Trotzdem ist es auch richtig, dass es kein Problem geben sollte, wenn eben die Daten einer speziellen Adresse erst gar nicht im Cache landen (z.B. per /CIIN, sonst hätte Motorola sich den Pin ja auch schenken können). Allerdings wäre dann im konkreten Fall /CIIN = A24 = low, dann liefe auch jegliche "non 68030 aware soft", zumindest, was dieses "Problem" anginge.
-
Ich hoffe, ich lande damit nicht gleich in der Kategorie Raubkopierer:
Der Schaltplan des Hochsitzes:
(http://forum.atari-home.de/index.php?action-gallery;sa=view;pic=373)
-
wie stellt man hier ein Bild ein?
In die Gallery und dann den Link drauf scheint nicht zu funktionieren?
-
-> Anhänge und andere Optionen <- beim Schreiben ...
-
Danke
-
Schaue mal da -> http://forum.atari-home.de/index.php?topic=6841.0
Bild in neuem Tab öffnen -> Link kopieren -> Bild einfügen im Beitrag mit den grössen Optionen einfügen
-
Ein paar Überlegungen zum Preis:
die günstigste MonSTer kostet 50 GBP, also etwa 65€. Wenn das 8Mbyte große SRAM max. 2/3 des Gesamtpreises ausmacht, was ich nicht glaube, dann würden - entsprechende Stückzahlen vorausgesetzt- 16MByte auf etwa 80€ kommen, Das liegt ja zumindest in derselben Größenordnung wie der Renesas Chips bei Einzelkauf. Okay, altes EDO-RAM gibt es günstiger, zum Preis der sehr viel aufwändigeren Ansteuerung und wie mit der Magnum-TT würden dann auch nicht alle beliebigen EDO-/FastPage-RAMS laufen.
Wie Frank (oder Lukas?) schon schrieb, wäre eine Vervielfältigung der Lötplätze für eine variable Bestückung ja kein großes Ding, der Ausbau könnte also an den Bedarf / Geldbeutel angepasst werden. Und bei Sammelbestellung der Bauteile (aus China?) dürfte es auch noch etwas Rabatt geben.
Btw.
An eine synchrone Vervierfachung des ST.Bus Taktes für die CPU/FPU + schnelles (SRAM) FastRAM hat sich noch niemand gewagt, oder?
Die PAK/3 lief asynchron ja mit bis zu 50MHz.
-
Bei 16Stk. 8bit breite SRAM Bausteine muss man doch eine Art Bankswitching machen, oder nicht ?
Da hatten sich neue Antworten mit meiner Antwort überschnitten.
Soldergirl hatte den Einsatz von 128KByte*8 SRAM vorgeschlagen.
Das war ja genau meine damalige Lösung, allerdings in DIP32 je vier SRAMs huckepack übereinander gelötet und mit einem zusätzlichen Sockel oben drauf für die ROMs.
/WR und /CS müssen dabei abgewinkelt werden (/WR zumindest in der untersten Lage)
/WR wird dann über alle SRAMS durchverbunden
/CS je Lage
/OE für die ROMs entsprechend
In einem der originalen Decoder GALs (keine Ahnung welches es war) wird das Rom-Select Signal durch /OE0../OE3 (Ausgänge zu den vier Sockeln) ersetzt, und mit den bereits an diesem GAL anliegenden /DS0 und /DS1 in passender Logik erzeugt. Diese vier Signale gehen dann jeweils an alle Chips eines (ehemaligen) ROM-Sockels.
/DSACK0 und /DSACK1 müssen korrekt erzeugt werden.
Das ist wichtig, denn nur weil FastRAM üblicherweise 32bittig angelegt ist, erfolgen die Zugriffe natürlich auch je nach Befehl gegebenenfalls auch mal nur 8- oder 16-bittig. Das ist insbesondere bei Schreibzugriffen wichtig!
Einfach /DSACK0 und /DSACK1 (über Dioden) zu verbinden funktioniert nur bei Longword Schreibzugriffen!
Um die vier Lagen = Adressbänke ansprechen zu können sind dann noch vier passende Adressen gemeinsam mit A24 an ein auf das original vorhanden GAL huckepack aufgesetztes GAL geführt udn mit einer simplen Logic werden hier die /CS -Signale für das TT-kompatible FAstRAM erzeugt.
Das alles läßt sich reversibel mit jeder PAK/2 mit wenig Aufwand testen, um 'mal einen EIndruck vom Nutzen von Fast(S)RAM zu erhalten.
PALASM-Virtuosen haben damit alle Informationen zur HAnd, selbst wenn ich meine alten Quellen nicht wiederfinden sollte.
-
Als erster Test sind die 512kB ja in Ordnung aber in Grunde viel zu wenig. TT Ram ist und funktioniert sehr gut wie der Atari TT zeigt. So gut wie alle Programme ziehen einen großen Nutzen vom Fastram. Entweder laufen die Programme im Fastram oder legen auch Ihre Daten dort ab. Das kann man über Programmflags vorgeben.
Es braucht jemanden der die Logik dafür zusammen bekommt, ich kann das nicht.
Ebenso gut wäre den 030 Adapter mit dem GAL auf die PAK68/2 zu setzen. Oder wenn man an die Quellen der GALs kommt eine PAK68/3-20 oder besser -030 ohne Level 2 Cache aber mit Fastram in Form von je mehr desto besser SRAM auf der Platine. Das man je nach Geldbeutel in vierer Schritten nachbestücken kann.
-
Ganz meine Meinung. 8)
Der Logik Aufwand steigt bei einer SRAM Lösung nicht mit der RAM Größe, es müssen nur die passenden Adressen dekodiert werden.
Entsprechend müssen dann eine passende Menge an Eingängen im GAL vorhanden sein (je variabler die FastRAM Größe (z.B. bei Teilbestückung), umso mehr Adressleitungen müssen ans zusätzliche Adressdekoder-GAL gelegt werden.
Es bietet sich daher an, das auf der original PAK/2 vorhanden GAL durch eine modernere Variante mit mehr Ein- und Ausgängen zufinden, und die "alte" Logik mit der zusätzlich fürd FastRAM notwendigen Logik gemeinsam in diesem Baustein zu implementieren.
-
Das ist wichtig, denn nur weil FastRAM üblicherweise 32bittig angelegt ist, erfolgen die Zugriffe natürlich auch je nach Befehl gegebenenfalls auch mal nur 8- oder 16-bittig. Das ist insbesondere bei Schreibzugriffen wichtig!
Einfach /DSACK0 und /DSACK1 (über Dioden) zu verbinden funktioniert nur bei Longword Schreibzugriffen!
FALSCH! Liest hier eigentlich jemand (außer mir) auch mal die MC680x0 User Manuals vor dem Posten??
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11344;image)
Was man natürlich je nach Zugriffsbreite (8 Bit, 16 Bit, 24 Bit, 32 Bit) aus A0, A1, SIZ0, SIZ1 erzeugen muss, sind die Chip-Selects für die RAMs. Die von Frank geposteten Gleichungen der Magnum TT zeigen, wie's geht, siehe dort CAS_UU, CAS_UM, CAS_LM, CAS_LL.
DSACK0 und DSACK1 kann man hingegen bei 32-bittigem RAM auch bei 8- oder 16-bittigen Zugriffen immer beide zusammen über eine Diode auf Low ziehen!
-
Okay, ich gebe mich geschlagen.
Das war allerdings auch alles aus beinahe 25-jähriger Erinnerung heraus posaunt.
Die von Dir genannten Signale sind die relevanten!
Das ACK in DSACK zeigt ja schon ganz eindeutig die "Signalrichtung".
Die Selektlogik ist dann für alle RAM-Größen gleich (einfach).
Und Du hast Recht, ich habe derartige Literatur seit > 10 Jahren nicht gelesen.
Beschäftige mich derweil auch nur noch mit Excel und Powerpoint ;)
-
Würde das gehen -> http://pdfserv.maximintegrated.com/en/ds/DS1270AB-DS1270Y.pdf
Gibt es über Digikey, konnte aber keinen Preis in Erfahrung bringen ...
-
Das ist nicht-flüchtiges SRAM mit eingebauter Lithium-Batterie, ein Nachfolger der Dallas-NVRAMs, die früher in PCs (und auch im Falcon?) eingesetzt wurden. Für eine RAM-Erweiterung eher nicht geeignet, es sei denn, Du willst, dass der RAM über's Ausschalten hinaus erhalten bleibt. ;)
Der Preis steht da ja bei Digikey: 276,12(!) US-Dollar pro Stück. Es gibt von Cypress noch (normale) 16 MBit SRAMs für 5V, z.B. CY7C1069G aber deren Preise (wenngleich einiges günstiger) sind auch noch zum "Vorher-besser-Hinsetzen".
PS: @joejoe, ja, ich bin echt froh, dass ich auch außerhalb meiner Freizeit auch noch mit Elektronik zu tun habe und nicht nur mit Powerpoint und Co. :)
-
Ja, das könnte funktionieren.
Habe ich auch schon gesehen (online), ist ein "etwas dickeres" Modul.
Das Pinout scheint eine Weiterführung der mir bekannten JEDEC-Pinouts zu sein. (ohne das jetzt im betreffenden Datenbuch verifiziert zu haben ;) ).
Das heißt, die "unteren 32 Pins" entsprechen im Wesentlichen denen der PAK/2 Roms, die zusätzlichen 4 Pins stellen die gegenüber den vorgenannten 1MBit SRAM zur Adressierung von 16MBit zusätzlich notwendigen 4 Adressleitungen (2°4=16) zur Verfügung.
Eine Lage (= 4*8 Bit SRAMS parallel adressiert) ergäben dann 2MByte FAstRAM, auch nicht der Renner im Vergleich zu dem Chip auf der MonSTer.
Da diese Chips mit Lithiumzellen gepuffert werden, sind das vermutlich auch keine Schnäppchen.
<edit> Ich tippe zu langsam...</edit>
-
Wenn man sehr viele kleinere SRAMs nutzt bekommt man doch bestimmt Probleme mit der Treiberleistung auf den Daten und Adressleitungen, oder ?
-
Theoretisch schon (FAN-in bzw. FAN-out sind die Stichworte)
Damals (mit 1MBit SRAMs) machten 4 parallele Lagen keine Probs.
-
Ich dachte nur wenn man 16 Stück 512kBx8 Static Rams benutzt, was dann bei Vollbestückung nur 8MB Fastram ergeben ...
Hatte auch mal 8192kBx8 gesehen, kann die aber nicht mehr finden.
-
wie czietz schon herausfand:
Der Renesas R1WV6416RSA ist ein 64MBit SRAM, laut Datenblatt "fully TTL compatible" (die 3,3V Vcc sind also nicht das Problem, da sehe ich eher die Bauform. Der Link zeigt auf einen BGA-Typen.
Aber das RAM der MonSTer (vermutlich nur eine andere (TSOP-) Bauform des Renesas-Chips) wäre doch der richtige Kandidat. Da die MonSTer verkäuflich ist, wäre das bei einer PAK/2++ mit 68030 und 16MByte Fast(S)RAM vermutlich auchg nicht anders. Wenn das Layout vier oder acht dieser Chips (ev. auf der Unterseite) vorsähe, wäre ein Ausbau auf 64MByte möglich, sofern der Geldbeutel mitmacht.
-
Dieses Renesas R1WV6416RSA SRAM sieht doch gut aus. Kostet aber 24,- Euro pro Stück -> https://www.rutronik24.com/product/renesas/r1wv6416rsa-5si%23b0/2843615.html
Sollte man eigentlich D0 mit D8 verbinden/Brücken oder das ganze 16bit breit betreiben. Da sind ja diese LB und UB Eingänge zusammen mit CS ...?
Bei zwei Stück in minimal Bestückung wäre das doch mit 48,- Euro in Ordnung wie ich finde ...
-
Den Preis, den Du da gefunden hast, bekommst Du aber nur bei Abnahme von 192 Stück (Minmum Order Quantity). Da müsstest Du schon in die Serienproduktion von Speichererweiterungen einsteigen...
Natürlich 16-bit-breit betreiben, dann kannst Du aus zwei Stück parallel ein 32-bittiges FastRAM bauen. Wie schon von joejoe und mir angemerkt, musst Du (aus A0, A1, SIZ0 und SIZ1) dekodieren, welche Bytes gelesen bzw. geschrieben werden und die Chipselects und /LB und /UB passend setzen.
Ich gebe außerdem noch zu bedenken, dass Du Dir Gedanken um die Pegelwandlung machen musst. "All inputs and outputs are TTL compatible" heißt nämlich mitnichten, dass das Ding 5 V verträgt. Mehr als Vcc=3,6 V und Spannungen an den Pins von Vcc+0,2 V = 3,8 V werden nicht empfohlen, abs. Max. ist 4,6 V. Also vielleicht die Idee der Monster kopieren und ein 5-V-tolerantes CPLD gleichzeitig die Pegelwandlung machen lassen?
-
Da habe ich nicht genau geschaut ...
Ich denke nicht das auf der MonSTer eine Pegelwandlung stattfindet. Alan hat ja auch das Alternate Ram only und da ist ausser ein paar TTL für das Selektieren nichts weiter drauf ...
(http://www.fairlite.co.uk/AtariKit//8mb/8mbmegast.jpg)
Ich kann Alan mal fragen ...
-
Ich kann Alan mal fragen ...
Mach das mal. Mit 5V an den Eingängen betreibt man das RAM definitiv jenseits der Absolute Maximum Ratings. Das ist schlechtes Design und es ist Glück, wenn's nicht kaputt geht.
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11346;image)
-
Wenn das so ist, ist das ganze hier zum Thema SRAM als Fastram uninteressant und nichtig. Die kleinen 5V SRAMs die es gibt sind ja viel zu klein ...
Also dann über DSACK0 und 1 und dann mit PS/2 Ram und der Magnum TT ...
-
Trotzdem würde mich interessieren, was Alan Hourihane sagt, falls Du ihn kontaktieren solltest. Ich meine, er wird sich doch bestimmt auch Gedanken zu diesem Problem gemacht haben...
-
Jepp, mich auch.
Es gibt z.B. von Alliance Memory SRAMs, welche bereits für die Versorgungsspannung (VCC) einen Bereich von 2,7V bis 5,5V zulassen, z.B den AS6C8016, ein 512K * 16Bit SRAM (=2MByte) allerdings habe ich keine größeren gefunden. Zur Not muss dann eben noch ein Datenbustreiber mit zwei Versorgungsspannungen zur Pegelwnadlung in die Datenleitungen. Für die Adress leitungen sollten Spannungteiler reichen.
Allerdings sehe ich auch solte Bauteile nicht auf der MonSTer.
Das von Alan genutzte SRAM wird schon (hoffentlich für alle Besitzer) 5V tolerante Eingänge haben, was bei 3,3V ICs nicht völlig unüblich ist.
Die Angaben zu den Absolute Maximum Ratings sprechenn allerdings dagegen, sofern das derselbe Chip ist.
TTL (TransistorTransitorLogik) allein sagt eben wenig über die absoluten Spannungspegel aus, wobei eine synonyme Verwendung für 5V-TTL schon recht häufig an zutreffen ist.
Aber das Datenblatt des Herstellers sollte es schon wissen...
Frage ihn (Alan) am besten nach einer Bezugsquelle ;)
-
Trotzdem würde mich interessieren, was Alan Hourihane sagt, falls Du ihn kontaktieren solltest. Ich meine, er wird sich doch bestimmt auch Gedanken zu diesem Problem gemacht haben...
habe schon gefragt, sage hier Bescheid was er antwortet ...
-
Also zur MonSTer kann ich sagen das ich an meinem Regelbaren Mega ST Netzteil schonmal längere Zeit 5,5V eingestellt hatte weil einige Erweiterungen fehlten und nichts ist passiert.
Ich musste die 5V Spannung anpassen da bei den ganzen Erweiterungen nur noch 4,5V da waren und der Rechner so nicht mehr stabil lief. Und je nach dem was ich einsetze oder raus nehme passt die Spannung natürlich nicht mehr. Das Netzteil läuft immer bis Anschlag bei den ganzen Sachen ...
-
Auf dem Foto der MonSTer http://www.fairlite.co.uk/AtariKit//monster/1MonSTer.JPG (http://www.fairlite.co.uk/AtariKit//monster/1MonSTer.JPG) sieht es so aus, als würden die Leitungen zum SRAM durch das CPLD XC9572XL gehen. Letzteres ist 5-V-tolerant, daher ging ich bislang davon aus, dass dort die Pegelwandlung stattfindet.
Falls nicht und wirklich bei MonSTer und Altram-Karte ein nicht-5-V-tolerantes SRAM zum Einsatz kommt, ist "bei mir ist nichts passiert" keine Beleg, dass alles OK ist. Beim Betrieb über abs. Max. geht nicht jedes IC sofort kaputt. Vielleicht geht nur jedes 100ste IC kaputt. Oder die ICs sterben gehäuft erst nach 2 Jahren. Oder sie zeigen "nur" schwer aufzudeckende Fehlfunktionen aufgrund der Schädigung der Eingänge durch die 5 - 5,5 V.
Alles in allem ist es für halbwegs seriöse Elektronikentwicklung ein totales No-Go, Komponenten über ihren Absolute Maximum Ratings zu betreiben, selbst wenn es (auf den ersten Blick) vielleicht mal gut geht. Diese Grenzen nennt der Hersteller nicht ohne Grund Absolute(!) Maximum(!).
-
Die 5V konforme Sachen gehen gar nicht, das steht ausser Frage. Warten wir mal was Alan schreibt ...
-> http://www.alliancememory.com/pdf/AS6C8016.pdf
Das wären dann bei einer Bestückung in 2er Schritten bei maximal 8 Stück je 2MB, 4MB, 6MB und 8MB Fastram. Das ist nicht viel aber geht so. Bei 16 Bausteinen, selbst die 8 Stück, da weiss ich nicht ob das geht mit der Belastbarkeit auf den Datenleitungen.
Billig scheinen die Bausteine auch zu sein wenn ich das richtig gesehen habe.
Bin immer noch bei einer Magnum TT zusammen auf einer Platine mit der PAK68/2 ...
-
Das Bild dieser Variante spricht gegen das Duchschleifen durch das CPLD:
http://www.fairlite.co.uk/AtariKit//monster/3monSTEr.JPG (http://www.fairlite.co.uk/AtariKit//monster/3monSTEr.JPG)
Hier liegt das RAM (physikalisch) inmitten des ST-BUS (also garantiert 5V) PLCC-Steckers
soetwas würde niemand designen, wenn sämtliche SRAM Adress- und D<tenleitungen zusätzlich zu den 64 CPU-Leitungen durch den Stecker geführt werden müssen.
-
Bustreiber für zu viele Bausteine und/oder Pegelwandler würden das ganze viel zu komplex werden lassen ...
-
Wieso, es werden doch minimal nur 4 Stk für die Datenleitungen benötigt?
Die Adressleitungen sind unidirektional, da spricht wenig gegen Spannungsteiler, wenn es denn tatsächlcih notwendig wird.
-
Wenn ich Geld über habe kann ich das mal Testen wenn czietz mir bei den GALs hilft ...
Ich baue mal wenn die PAK68/2 Geschichte abgearbeitet ist eine Magnum TT auf Lochraster mit nur einem Simm Steckplatz auf. Habe noch einige PS/2 Simms, auch ein 64MB Modul.
-
Die Datenbustreiber mit dualer Spannungsversorgung würden auch (zumindest für den Datenbus) das von Dir angesprochene "Problem" mit den vielen ?? parallelen SRAMs lösen.
z.B. https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwi_sZzIpaPNAhXrDpoKHR9jB9UQFggeMAA&url=http%3A%2F%2Fwww.nxp.com%2Fdocuments%2Fdata_sheet%2F74LVC_LVCH8T245.pdf&usg=AFQjCNFdLe_enYUG-Weamb12VZQpEUTX3A&cad=rja (https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwi_sZzIpaPNAhXrDpoKHR9jB9UQFggeMAA&url=http%3A%2F%2Fwww.nxp.com%2Fdocuments%2Fdata_sheet%2F74LVC_LVCH8T245.pdf&usg=AFQjCNFdLe_enYUG-Weamb12VZQpEUTX3A&cad=rja)
-
Ja die kenne ich, hatte die mal wegen einen Logic Analyzer mit 3V FPGA drin. Habe das Ding aber leider nicht mehr ...
Da braucht es ja 4 Stück von und was macht man mit den Adressleitungen. Spannungsteiler mit einfachen Widerstände geht doch bestimmt nicht, oder ?
-
warum nicht?
Das Ohmsche Gesetz ist immer noch gültig!
Halbwegs hochohmig sehe ich da keinerlei Probleme.
Natürlich ist eine Prozessor-Austausch Karte mit zusätzlichen Funktionen un Bauteilen immer eine -im positiven Sinn- Bastellösung.
Aber darum geht es doch, oder?
-
wenn es nur um Rechenleistung ginge, dann stimmt die Aussage von Holger Zimmerman zum Ende seiner Aufwändungen mit/für die PAK/3 immer noch:
Wenn eine Emulation mehr Leistung als eine original Hardware mit - zunehmend instabiler- aufwändiger Erweiterung bringt, dann macht die Investition in Hardware keinen Sinn.
-
warum nicht?
Das Ohmsche Gesetz ist immer noch gültig!
Halbwegs hochohmig sehe ich da keinerlei Probleme.
So in der Theorie der Einfachheit halber jetzt erstmal pro Volt ein Kiloohm dann müsste der Spannungsteiler für die Adressleitungen an den SRAM so aussehen: Vom SRAM Adresspin jeweils 3,3k auf Masse und vom Adresspin 1,7k auf den Adressbus der ST 5V Logic ...
Mein Problem war jetzt das ich nicht wusste dass die Adressanschlüsse an den SRAMs nur Eingänge sind. Und parallel zu dem Spannungsteiler aus zwei Widerständen würde da wenn man annimmt das der Innenverstand vom Netzteil sehr klein ist im Ohm Bereich durch die 4,7k Pullups an den Adressleitungen im Atari ST zu dem 5k Spannungsteiler noch 5k parallel liegen ...
Ich möchte das gerne umsetzen habe aber null Ahnung davon was ich da mache ...
-
Dann spendiere noch vier weitere DualPower Bustreiber (wie für den Bidirektionalen Datenbus) als aktive Pegelwandler, lege den DIR Eingang passend auf 0 oder 1 und Du hast gepufferte 32Bit= 4GByte Adressraum.
Die nehmen letztlich fast weniger Platz ein als Spannungsteiler aus bedrahteten Widerständen.
Damit wären dann auch Deine Bedenken hinsichtlich der Treiberleitung / Busbelastung durch die (vielen) zusätzlichen SRAMs ausgeräumt.
-
Es hilft, sich ein Ersatzschaltbild aufzumalen. Das habe ich mal gemacht, selbst wenn ich die tatsächlichen Größen nicht parat habe:
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11362;image)
Die Ausgangstreiber der CPU ziehen über ihre Innenwiderstände eine Adressleitung gegen Masse oder gegen Vcc=5V. Beim 68000er in NMOS-Technologie ist RCPU,H vermutlich einiges größer als RCPU,L, beim 68020, der ja in CMOS-Technologie gefertigt ist, sind sie vermutlich eher gleich. Der Pullup-Widerstand hilft dem Ausgangstreiber daher ein wenig beim High-Setzen.
Der Spannungsteiler aus RT1 und RT2 muss zunächst einmal natürlich verhindern, dass die Spannung am RAM-Eingang über 3,3 V (+ 0,3 V) wird, damit die Schutzdiode (ebenfalls eingezeichnet) nicht durchschaltet. Diese Bedingung legt aber nur das Verhältnis der Teilerwiderstände fest, dass Du ja auch schon bestimmt hattest.
Es gibt nun zwei (widersprüchliche) Forderungen an die Größe der Widerstände. Sind sie zu klein, belastet man den CPU-Ausgangstreiber zu stark und evtl. kommt die Spannung nicht mehr so weit hoch. Man darf die Widerstände aber auch nicht zu groß machen! Der Eingang des RAMs (ebenfalls CMOS, natürlich) ist so hochohmig, dass man ihn hauptsächlich als Eingangskapazität CRAM,in modellieren kann. Diese Kapazität muss nun schnell genug (<< Zugriffszeit auf das RAM) umgeladen werden können, was ja nur über die Widerstände passieren kann.
-
Ich habe 16-Bit-Bidirectionale Treiber mit zwei Spannungsversorgungen.
Ich muss sie nur finden...
-
Dann läuft das ganze ja wohl mal auf ein Eagle Layout hinaus für ein paar Prototypen ...
-
Wegen den Fehlern werden die Platinen so ausgeliefert wie man auf den Bildern sehen kann.
Patchliste:
- IC4 /ROMSEL Pin10 auf IC6 Pin20 nicht da.
- IC4 A1 Pin23 auf 68000 CPU Pin29 A1 nicht da.
- IC6 /Berr00 Pin22 auf 68000 CPU Pin22 /Berr00 nicht da.
- IC3 (FPU) Pin44 D23 auf 68000 CPU Pin62 (D7) oder auf 68020 CPU Pin_L5 (D23) nicht da.
Die Widerstände sind kleine Typen, bei Kessler "M0204 4,7K" u.s.w.
Die bestellten Teile sind noch immer nicht da obwohl die Bestellung die ich zwei Tage später aufgegeben habe heute Morgen kam. Wenn Morgen nichts kommt versuche ich das zu klären ...
Die Patch Arbeiten an den Platinen nehmen einiges an Zeit in Anspruch, kann also noch ein wenig dauern ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11376;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11378;image)
Bei der Bestückung muss man ein wenig aufpassen und zwar muss wenn man einen 64pol DIL Sockel zerschneidet die beiden Einzelteile dann um 180 Grad verdreht eingelötet werden weil es ansonsten nicht passt. Der Abstand zwischen den CPU Padreihen ist zu gering.
-
Hallo, kann man für die FPU auch den anderen Sockel mit Pins bekommen? Da habe ich nämlich noch 2 oder 3 FPUs...
-
Hallo, kann man für die FPU auch den anderen Sockel mit Pins bekommen? Da habe ich nämlich noch 2 oder 3 FPUs...
Meinst du PGA FPUs ? Wird so nicht funktionieren. Man könnte aber noch ein platinchen machen, was das PGA auf PLCC adaptiert
-
Hallo, kann man für die FPU auch den anderen Sockel mit Pins bekommen? Da habe ich nämlich noch 2 oder 3 FPUs...
Schau Dir die FPUs mal an, so wie ich mich erinnere haben die ein anderes Pinout als der Sockel.
-
Hab wohl untertrieben, es sind ein paar mehr als 2-3 ... Da sind auch 20er, hauptsächlich 16 Mhz, aber auch 20 und 25 MHz, und eine 68EC030. Und diverse AMDs, Cyrix, 386er, einer davon "16 Bit Only", Pentiums ab 100 Mhz aufwärts, ein Weitek, ...
-
Ja das geht nicht so einfach mit der FPU. Das PGA Pinout ist völlig anders. Ich war für eine PLCC FPU da die einfacher und billiger zu bekommen ist. Auf Ebay sind die PGA FPUs in aller Regel aus den USA ...
-
Mal gerade ein Eagle probiert. man könnte ein kleines adapterplatinchen basteln. habe mal PGA und PLCC übereinander gelegt, die Pins berühren sich untereinander nicht. Ob sich das lohnt, hierzu platinchen machen zu lassen, denke ich eher weniger. @1ST1, da mußte wohl doch auf PLCC FPU zurückgreifen, sorry.
-
Die Stiftpfostenleiste wie auch bei der CPU ist recht Teuer und bei Kessler haben die keine PGA68 pol. Sockel. Die haben nur 64pol und man muss basteln. Ich würde für 14,90 Euro im Amiga Shop eine 68882/33Mhz kaufen und gut is ...
-
Mal gerade ein Eagle probiert. man könnte ein kleines adapterplatinchen basteln. habe mal PGA und PLCC übereinander gelegt, die Pins berühren sich untereinander nicht.
Vielleicht bekommst Du es hin in der überarbeiteten Version der Platine mit beiden Pinouts hin?
-
Naja, dann werde ich noch so zwei PLCC-FPUs besorgen müssen, habe gerade festgestellt, das mein Zweit-Falcon auch noch keine hat - Sockel sind dafür da, dass sie befüllt werden. (Aber die Idee mit dem PAK-Layout für beide Varianten ist genial.)
-
hier übrigens der Link auf den c't Artikel über SRAM auf der PAK/2.
http://www.heise.de/artikel-archiv/ct/1992/10/228_kiosk (http://www.heise.de/artikel-archiv/ct/1992/10/228_kiosk)
Die Aussagen beziehen sich zwar auf den AMIGA, waren aber damals der Ausgangspunkt für meine gleichzeitige Verwendung von ROM und Fast(S)RAM auf der PAK/2 im Atari mit einem gepatchten TOS 3.06.
Zum Durchforsten meiner alten Backups auf der Suche nach den GAL-Quellen habe ich noch nicht die Zeit gefunden.
-
Mal gerade ein Eagle probiert. man könnte ein kleines adapterplatinchen basteln. habe mal PGA und PLCC übereinander gelegt, die Pins berühren sich untereinander nicht.
Vielleicht bekommst Du es hin in der überarbeiteten Version der Platine mit beiden Pinouts hin?
Neue Revision mache ich auf jeden Fall noch. Alleine wegen den fehlenden Signalen. Ich probiere das dann mal aus, nur ich befürchte, dass es platzmässig zu eng wird, weil die Pins nicht schön gleich angeordnet sind. VCC und GND z. B. Liegen etwas blöd dann auseinander. Alleine diese müssen schon dicker sein als die bahnen der Signale. Probieren kann ich es, wird aber wahrscheinlich nix.
-
Wenn das mit dem SRAM Fastram was wird kommt da ja noch jede Menge drauf auf die arme Platine ...
-
Wenn das mit dem SRAM Fastram was wird kommt da ja noch jede Menge drauf auf die arme Platine ...
Wenn das funktionieren würde, sollte das auf jeden Fall mit drauf. Dann sollte man aber auch komplett auf smd setzen. Cpu und fpu plcc, gals gibt es glaub ich auch in plcc oder über den Schatten springen und es doch mit cpld probieren... werde mir mal auf jeden Fall nach dem Umzug das ätzaquarium von Reichelt zulegen. Wird dann auf Dauer billiger als Prototypen in Asien herstellen zu lassen. Werde dann auch mit Belichtung anfangen, als mit der Toner Transfer Methode.
-
So, alles abgearbeitet und alle Sachen zur Post gebracht ...
Mit den Pfostenleisten zum Mainboard hin muss man immer sehr Vorsichtig umgehen. Es sollte da immer ein normaler 64pol. Sockel drauf stecken. Wenn mal ein Pin verbogen ist und man versucht ihn wieder gerade zu biegen bricht er in aller Regel ab, also wie ein rohes Ei behandeln. Um die Sockel auseinander zu bekommen nutze ich eine spitze gekröpfte Pinzette die vorne an der Sitze so keilförmig ist.
-
so also ich habe mal nachgeschaut, ob ich dem wunsch PGA und PLCC auf einer Platine nachkommen kann. Antwort: nö! geht absolut nicht, weil bei PGA und PLCC komplett die Pins anders beschaltet sind und man diese nicht einfach mal so gegenüberlegen kann für beide optionen. Ist zwar schade, aber wenn man beides auf einem Board haben möchte, wäre die Platine doppelt so groß. Was man machen könnte, wäre 2 Revisionen zu erstellen für jeweils PGA und PLCC. Dies bedeutet dann für CPU und FPU. Ich schaue mal weiter, was möglich ist, nur bei dem Layout muß man dann abstriche machen. Ich wäre für ein Layout, dass SMD Bauteile beinhaltet, gefolgt mit PLCC CPU und FPU ohne Sockel. So kann man wirklich das Ganze auf 50% schrumpfen, sogar vielleicht mehr. Bis dahin wird erstmal das bestehende bereinigt und ich sehe mich wirklich gezwungen, mich mit CPLD auseinander zu setzen.
-
Die CPLD Bausteine sind aber wieder 3V Typen. Bei Kessler gibt es einen 5V Typ mit 32 I/O Pins. Da müssen auch mehrere von auf das Board. Für die ersten 10 Prototypen mit den SRAM Bausteinen drauf sollte man der einfachheitshalber GAL Bausteine verwenden. Eine Baustelle nach der anderen ...
-
Die CPLDs die wir verwenden benötigen 3,3V Versorgungsspannung sind aber an den I/O s 5V fest.
Wie der hier Xilinx 95144XL
-
117 I/O Ports ist ja mal eine Ansage, sehr schön ...
-
So, hier nun meine GAL-Gleichungen aus dem letzten Jahrtausend.
In den PDS-Dateien sind Hinweise zur Verdrahtung enthalten; die aktuelleste Version ist wohl "froam.pds" (bzw.jed), welche schon Hinweise auf den Hochsitz (68030-Adapter) enthält.
Antworten auf mögliche Fragen müsste ich mir vermutlich erst selbst wieder erarbeiten.
Viel Spaß mit FastSRAM.
Diese Gals wurden von mir auf einer PAK/2 mit 4 bzw. 8 Stück 128 kByte SRAMs gemeinsam mit TOS 3.06 eingesetzt. Um die notwendigen Hardware-Patches (Umlegen von GAL Eingangs-Pins auf andere Pins etc.) reversibel zu halten hatte ich für das 22V10 GAL mehrere Zwischensockel eingesetzt. Dabei läßt sich dann auch das Isolieren einzelner Pins gegen die jeweils untere Sockellage durch Entfernen des betreffenden Pins im unteren Sockel realisieren. Der oberste Sockel kann dann das Gal ohne abgebogene Pins aufnehmenn, damit dieses unverbogen neu programmiert werden kann.
Die her realisierten 1MB FastRAM vermitteln auf schnellem Weg einen Eindruck, was eine Platinen-Variante mit 8 oder 16MByte Fastram leisten könnte. Der Aufbau ist reversibel durchführbar.
-
es ist nur eine der Variante zur Zeit nötig. Je nachdem, was man so möchte (nur FastRAM, Fastram mit ROM).
-
Naive Zwischenfrage:
Hat schonmal jemand versucht einen 168pin-SD-Dimm zu verwenden?
Ich habe mir da mal das Pinout angeschaut, und das müsste eigentlich weitgehend kompatibel sein. Natürlich bräuchte man Buffer-Chips für die Umsetzung von 64bit auf 32/16-bit und von 5V auf 3,3V, aber die Steuersignale sind weitgehend gleich.
Ohne das eingehender untersucht zu haben würde ich vermuten, das es mit ein bisschen zusätzlicher Logik bzw. einem GAL möglich sein sollte die 64 Datenbits des SD-DIMM dem Atari als 4 Adressen zu je 16 bit zu präsentieren, oder eben 2x32bit.
Das wäre zwar etwas zusätzlicher Schaltungsaufwand, hätte aber der Vorteil das die DIMMs leichter erhältlich sind als PS/2-Module und auch in ganz anderen Größenordnungen.
-
Kann man denn synchrones DRAM (SDRAM) auch asynchron betreiben, wie es im Atari üblich/(nötig?) wäre?
-
Das S in SDRAM hat leider nichts mit static zutun, die Betonung liegt immer noch auf D (dynamic) RAM, also zyklischer Refresh etc. nötig. d.h. in der Regel auch deutlich höhere Strombedarf.
Zudem ist SDRAM -zumindedt in den klassischen Formen mit 66MHz oder 133MHz zwar in den attraktiven Größen sicher verbeiteter gewesen als z.B. EDO-RAM, und damit günstiger zu haben. Aber langfristig ebenso eine Sackgasse wie PS/2-Riegel (wer weiß denn, wie lange die ATaris noch leben? ;)
-
Kann man denn synchrones DRAM (SDRAM) auch asynchron betreiben, wie es im Atari üblich/(nötig?) wäre?
Gute Frage. Ich habe keine Ahnung, wie gesagt, ich hab mir nur mal das Pinout angeschaut und eine kurze Beschreibung gelesen, und der erste Eindruck war, das zumindest die Signale im großen und ganzen gleich sind. Abgesehen vom Pegel natürlich.
Das S in SDRAM hat leider nichts mit static zutun, die Betonung liegt immer noch auf D (dynamic) RAM, also zyklischer Refresh etc. nötig. d.h. in der Regel auch deutlich höhere Strombedarf.
Stimmt. Aber ich glaube die SD-DIMMs hatten von den Chips her eher weniger Strombedarf als die älteren Chips auf den PS/2-Modulen wegen der moderneren Fertigungstechniken. Das könnte sich halbwegs ausgleichen. Außerdem haben die DIMMs wohl eine Autorefresh-Funktion, so das man sich darum zumindest Schaltungstechnisch nicht wirklich kümmern müsste. Und selbst wenn, bei den PS/2ern klappt das ja auch irgendwie.
Zudem ist SDRAM -zuminset in den klassischen Formen mit 66MHz oder 133MHz zwar in den attraktiven Größen sichj verbeiteter gewesen als z.B. EDO-RAM, und damit günstiger zu haben. Aber langfristig ebenso eine Sackgasse wie PS/2-Riegel (wer weiß denn, wie lange die ATaris noch leben?
Stimmt auch. Aber ich glaube es wird deutlich schwieriger, wenn nicht gar unmöglich, DDR-RAM am Atari zu betreiben. Von dem her ist eigentlich alles mehr oder weniger Sackgasse.
Die einzige andere Möglichkeit wäre, etwas komplett eigenes zu machen, sozusagen einen neuen Standard für Speicherriegel zu entwickeln. Allerdings denke ich das wäre bei den verfügbaren technischen und humanen Resourcen ein epochales Projekt was vermutlich nie fertig werden würde.
-
Nun ja, mehrere -aktuelle, wie auf der MonSTer- SRAMS parallel geschaltet benötigen keinen neuen Standard. Die wären zwar etwas teurer als DRAMs aber ungleich einfacher anzusteuern.
-
Die ersten PPC Apple Macintosh hatten 5V SDRAM Riegel z.B. die 8200 und 9600 Modelle, meine ich. Ist aber sehr schwer zu bekommen ....
Die CT60 hat doch mit dem 68060 auch SDRAM ...
Ich würde immer noch eine Magnum TT mit PS/2 Ram gut finden, da auch EDO funktioniert. So schwer sind die gar nicht zu bekommen. Müssen ja nicht immer zwei 128MB Riegel sein ...
Ich mache mal einen Schaltplan mit dem SRAM die Tage ...
-
Kann man denn synchrones DRAM (SDRAM) auch asynchron betreiben, wie es im Atari üblich/(nötig?) wäre?
Gute Frage. Ich habe keine Ahnung, wie gesagt, ich hab mir nur mal das Pinout angeschaut und eine kurze Beschreibung gelesen, und der erste Eindruck war, das zumindest die Signale im großen und ganzen gleich sind. Abgesehen vom Pegel natürlich.
Der signifikante Unterschied ist das Vorhandensein eines Clock-Signals. Wenn Du Dir das Timing von SDRAM anguckst http://techwww.in.tu-clausthal.de/site/Dokumentation/IC_digital/Speicher/SDRAM/HY57V653220B/SDRAM_timing.pdf dann siehst Du, dass alles synchron zum Takt passiert und mit der passenden Latenz. Damit ist ein SDRAM-Controller im CPLD aufwändiger als ein DRAM-Controller.
-
offtopic: @SolderGirl, schick mir bitte deine Adresse per PN, dann schicke ich dir Leerplatinen, wo ich in den tiefen meiner Kartons gefunden habe, zusammen mit EEPROMS und dem GAL (beschrieben). Mußt dir nur noch den Inverter zulegen und den ATTiny13. Gibt es ja günstig. Ich schreibs deswegen hier rein, weil über PNs keine Bilder gehen.
-
Habe mal ein wenig Google bemüht und dachte es gib sowas wie HCT245 mit 5V Ein und 3V aus aber dem ist wohl nicht so. Es gibt diese VHCT245 die wohl 3V tolerant sind aber das nutzt ja nichts wenn die den 5V Pegel mit 5V weiter an die SRAM Bausteine weitergeben.
Es gibt wohl so AN10441 irgendwas das sind FET Transistoren mit einen Pullup an 5V und am anderen Anschluß an 3V. Aber die gibt es so einfach nicht zukaufen.
Ehrlich gesagt Missfällt mir diese ganze 3V Geschichte ...
-
Habe mal ein wenig Google bemüht und dachte es gib sowas wie HCT245 mit 5V Ein und 3V aus aber dem ist wohl nicht so. Es gibt diese VHCT245 die wohl 3V tolerant sind aber das nutzt ja nichts wenn die den 5V Pegel mit 5V weiter an die SRAM Bausteine weitergeben.
Doch, es gibt spezielle 245er mit zwei Versorgungsspannungen für Pegelumsetzung. Du kannst Dich ja mal ein bisschen durch die Liste klicken: http://www.nxp.com/products/discretes-and-logic/logic/voltage-level-translators:MC_29482 (http://www.nxp.com/products/discretes-and-logic/logic/voltage-level-translators:MC_29482). Und dann gibt es noch Logikfamilien, die Du aus 3,3V versorgst, die aber 5 V an den Eingängen vertragen und somit auch die Pegelwandlung von 5 V auf 3,3 V vornehmen können.
Es gibt wohl so AN10441 irgendwas das sind FET Transistoren mit einen Pullup an 5V und am anderen Anschluß an 3V. Aber die gibt es so einfach nicht zukaufen.
AN10441 ist nur die Nummer der "Application Note" von NXP, die deren Level-Shifter beschreibt. Die Teile selbst heißen GTL20xx. Sie haben den Vorteil, dass sie bidirektional sind, ohne dass man die Richtung vorgeben muss. In der Firma setzen wir sie in einem unsere Produkte ein. Sie tun genau, was sie sollen. Sie sind für wenig Geld z.B. bei Farnell oder Digikey erhältlich.
-
Ein paar Links auf mögliche Bustreiber-Kandidaten:
74LCX245, 3,3V Bustreiber mit 5V toleranten Eingängen:
https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjaqo7KtbjNAhXI6xQKHQjdD5gQFgg1MAM&url=https%3A%2F%2Fwww.fairchildsemi.com%2Fdatasheets%2F74%2F74LCX245.pdf&usg=AFQjCNERfgJr1TraDh-QMCMZ-fPKg2KU-Q&bvm=bv.124817099,d.d24
(https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjaqo7KtbjNAhXI6xQKHQjdD5gQFgg1MAM&url=https%3A%2F%2Fwww.fairchildsemi.com%2Fdatasheets%2F74%2F74LCX245.pdf&usg=AFQjCNERfgJr1TraDh-QMCMZ-fPKg2KU-Q&bvm=bv.124817099,d.d24)
oder eine dual voltage Variante F74LVXC4245:
https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwjaqo7KtbjNAhXI6xQKHQjdD5gQFgg8MAQ&url=https%3A%2F%2Fwww.fairchildsemi.com%2Fdatasheets%2F74%2F74LVXC4245.pdf&usg=AFQjCNHs95JxnzPV3Zz1rVoFgsrWhZz9Aw&bvm=bv.124817099,d.d24 (https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwjaqo7KtbjNAhXI6xQKHQjdD5gQFgg8MAQ&url=https%3A%2F%2Fwww.fairchildsemi.com%2Fdatasheets%2F74%2F74LVXC4245.pdf&usg=AFQjCNHs95JxnzPV3Zz1rVoFgsrWhZz9Aw&bvm=bv.124817099,d.d24)
oder direkt bei farnell:
http://de.farnell.com/webapp/wcs/stores/servlet/Search?catalogId=15001&exaMfpn=true&mfpn=74LVC8T245PW%2C118&categoryId=&langId=-3&searchRef=SearchLookAhead&storeId=10161&showResults=true (http://de.farnell.com/webapp/wcs/stores/servlet/Search?catalogId=15001&exaMfpn=true&mfpn=74LVC8T245PW%2C118&categoryId=&langId=-3&searchRef=SearchLookAhead&storeId=10161&showResults=true) 60Cent das Stück in SMD.
8 Stück (4x Daten und 4x Adressen) davon und sämtlich 3,3Volt Bedenken sind passe.
-
Ich würde vorschlagen anstatt der 245 Pegelwandler die auch noch Enable und Dir Anschlüsse beschaltet haben wollen. Besser die NXP GTL2003 8-bit Pegelwandler zu benutzen. Das würde alles um einiges Einfacher machen. Man braucht vier Bausteine für die Datenleitungen und vier für die Adressleitungen und dann noch einen Baustein für das GAL um die CS Eingänge der SRAM Bausteine anzusteuern.
-> http://www.nxp.com/documents/data_sheet/GTL2003.pdf
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=11463;image)
-
Ich habe noch sieben Platinen.
Ich kann auch komplett aufgebaute und getestete anbieten ...
-
Hallo,
Ich habe noch sieben Platinen.
Ich kann auch komplett aufgebaute und getestete anbieten ...
Das wäre erstmal nicht uninteressant (aufgebaut und getestet klingt gut :) )...
Aber...
Also ich hab mir mal am Stück den ganzen Thread durchgelesen, nun steh ich erst recht auf dem Schlauch. Die PAK um die es hier geht ist doch, soweit ich das rauslesen konnte, (nur?) für den Mega ST gedacht? Im TT würde sie ja wenig Sinn machen. Dann kam aber mehfach die Magnum TT zur Sprache, und ob denn die PAK mit der Magnum harmoniert. Die Magnum ist doch aber wieder nur für den TT gedacht?
Also mich würden ja beide Karten interessieren (für die jeweiligen Rechner), aber inwiefern die beiden etwas miteinander zu tun haben, überfordert mich jetzt ein wenig... ich werde das Gefühl nicht los, etwas wichtiges überlesen zu haben ???
VG
Sven
-
Die PAK2 kannst du in jeden ST bauen, der eine 64-polige DIP CPU hat. Es gibt auch Adapter für den MegaSTE, oder zumindest eine Anleitung dafür, meine ich gelesen zu haben.
In meinem MegaST werkelt zur Zeit eine PAK3/020, die ich bei ebay ergattern konnte. Zudem ist dazu eine Mega4000 Adapterplatine mit ET4000 Grafikkarte eingebaut, eine Marpet 4MB Speichererweiterung und eine MagnumST mit 8MB Speicher und schaltbarem TOS 2.06 und Magic. In diesem Fall nur 8 statt 16 MB, wegen dem Speicherbereich der Grafikkarte. Ohne Grafikkarte könntest du auch 16MB einsetzen.
Es läuft alles rel. gut miteinander. Das einzige Manko, welches ich noch nicht gelöst habe ist, daß ich das TOS auf der PAK3 disablen und stattdessen das TOS auf der Magnum nehmen muß. Das hat den Nachteil, das es nicht, wie auf der PAK 32 bittigen Zugriff hat, sondern nur 16 bit. Damit verschenke ich noch etwas Leistung der PAK.
Somit denke ich, das die PAK2 sich auch mit der MagnumST vertragen wird. Beide habe ich hier, die ich auch in einem weiteren MegaST einbauen will, leider fehlt mir momentan die Zeit und auch ein bischen die Lust dazu.
http://forum.atari-home.de/index.php?topic=12862.0
Sollte dich explizit die MagnumTT interessieren, würde ich lieber auf die IDE-Fastram-Karte von pakman, tuxie und gaga warten.
-
Die Magnum TT mit auf der PAK68/2 Platine würde nur dazu dienen zusätzliches Fastram zu haben ...
Die PAK68/2 ist für alle Atari ST egal ob Mega oder etwas anderes. Bei den anderen kommt nur das Gehäuse Problem hinzu, da es viel zu klein ist. Beim Mega ST passt es so ...
-
Das PAK/3 gepatche TOS 3.06 läuft sehr gut auf der PAK68/2. Allerdings nicht mit der MonSTer Erweiterung, mit der geht es seltsamerweise nur wenn die vier 27C512 Eproms mit TOS 2.06 auf der PAK68/2 sind. Auf einem Atari Mega ST Mainboard mit TOS 1.04 drauf funktioniert es aber einwandfrei. Erst dachte ich es liegt daran das wir nur 2-Layer Platinen haben aber damit hat es nichts zu tun. Dann kann das Abenteuer Fastram ja bald losgehen ...
Pascal hat schon mit dem Layout angefangen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=12006;image)
-
Meinen Pak68/2 bootet nür wenn irgend einen Tos im MB steckt.
Und der Blitter muss auch ausgeschaltet sein, denn der kann nicht zugreifen auf das Pak-OS.
Mit Blitter an, wirdt den Bildschirm nicht gut augebaut, der Rechner bleibt aber am laufen....
MFG/
Guus
-
Das Problem mit dem Blitter hat die PAK68/3 auch ...
Beim TOS 3.06 für die PAK wird der Blitter gleich ausgeschaltet falls vorhanden. Das TOS 3.06 für die PAK68/3 läuft auch sehr gut auf der PAK68/2 in vier 27C010 Eproms oder Proms.
Als Voraussetzung ist allen PAK68 Karten gleich das diese ein kleines TOS (irgendwas) auf dem Mainboard brauchen um das 32bit breite TOS auf der Karte selber booten zu können.
-
Für die PAK muss unbedingt ein TOS auf der Hauptplatine stecken, weil ein paar Adressen davon den Resetvektor beinhalten, der aus Prozessorsicht an einer ganz anderen Stelle im Adressraum liegt als der Rest von TOS. Bei dem ROMs auf der PAK ist dieser Resetvektor nicht auf die für den CPU-Start benötigte Adresse ummaskiert. Ohne TOS auf der Hauptplatine würde die CPU beim Reset den Resetvektor nicht finden. Soweit ich mich erinnere, muss es auch ein TOS 1.04 auf der Hauptplatine sein, denn nur dessen Resetvektor zeigt auch auf die richtige Einsprungadresse in TOS 2.06.
Zum Blitter: Ein 68020-16 oder gar eine 68030 ist schneller als der Blitter. Der Blitter bringt garnix. Allerdings wundert mich, dass mit Blitter scheinbar Müll kommt. Bei meiner PAK 68/2 ging das, der Blitter funktionierte ganz normal, nur eben waren alle GEM-Benchmarks zum Blitting, Fenster zeichnen usw. langsammer als wenn der Blitter ausgeschaltet war. Ich habe den Blitter damals daher wieder ausgebaut und in einen anderen ST ohne PAK eingesetzt.
-
TOS 1.02 geht auch, ebenso KAOS. KAOS ist ja im Grunde ein gepatches 1.04 ...
-
Weiss jemand eine Quelle zum Einkauf gerader PS/2 72pin Sockel mit Metallklammer in Europa oder England, vielleicht auch China ?
In den USA gibt es welche aber da ist das mit den Portokosten so ein Problem ...
-
Ja den gibt es. Den haben wir für unser Projekt schon bemüht. Muss ich nachsehen, wo das war. Kann ich Dir in Kürze verraten.
-
Freut mich ...
-
Bei Kessler erhältlich, Bestellnummer: SISO72G
Preis: 1,99 ab 10 Stk. 1,89
Mit gerade meinst Du das Speichermodul steht senkrecht zur Platine, oder?
-
Bei Kessler sind nur noch PS/2 Simm Adapter und 30pol. Sockel zu haben. Vor Monaten hatte ich mal die paar Reste gekauft auch für die Magnum ST aber habe keine mehr.
Habe auch schon gefragt ob die Kessler Leute ihren Warenbestand auffrischen aber bis jetzt nichts ...
-
Das PAK/3 gepatche TOS 3.06 läuft sehr gut auf der PAK68/2. Allerdings nicht mit der MonSTer Erweiterung, mit der geht es seltsamerweise nur wenn die vier 27C512 Eproms mit TOS 2.06 auf der PAK68/2 sind. Auf einem Atari Mega ST Mainboard mit TOS 1.04 drauf funktioniert es aber einwandfrei. Erst dachte ich es liegt daran das wir nur 2-Layer Platinen haben aber damit hat es nichts zu tun. Dann kann das Abenteuer Fastram ja bald losgehen ...
Pascal hat schon mit dem Layout angefangen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12916.0;attach=12006;image)
Mich würde interessieren ob diese Platine so oder ähnlich noch gebaut wird? Die ist ja fast so groß wie ein ATX-Board... :D :D :D
-
Nein, auch weil das mit dem Fastram nicht geht.
-
Hut ab, was Pascal da gemacht hat.
-
Ich hoffe jemand bringt irgendwann mal eine Neuauflage der PAK68/3 mit FRAK ...
-
Ja, wird aber nicht leicht sein wegen des Timings.
-
Wieso sollte es ein Problem mit dem Timing geben? Lief doch damals auch ...
-
Bin gerade auf dem Sprung... hatte aber hier im Forum gelesen dass das Timing bei 50MHz doch nicht so einfach in den Griff zu kriegen sei... und die Umsetzung Frak und Pak auf einer Platine da nicht unbedingt Atok umzusetzen ist. Mag mich aber auch irren.
-
Hallo,
bin neu in eurem Forum also zunächst ein freundliches "HuHu" an alle hier. Bin hochinteressiert meinen Mega1 (Noch allesOriginal) aufzurüsten. Ich habe den mindestens 20 Jahre nich mehr an gehabt.
Lief auf Anhieb...das hat mich sehr beiendruckt. 8)
Wird denn das Projekt PAK68/2 oder xxx/3 noch weiter hier verfolgt? Wo bekommt man detaillierte Infos her?
Würde mich u.U. auch selbst daran wagen. Wird dann wohl dauern...aber gut Ding will Weile haben.
War doch so ähnlich das Sprichwort oder? :)
Grüss
Lao Mu
-
Das PAK68/2 Projekt ist tot von meiner Seite. Im Prinzip läuft es zwar aber die Platine kann Probleme machen. Bei mir lief es aber zum Beispiel SolderGirl hat große Probleme damit. Ich habe noch einige Platinen. Zum Selbstkostenpreis von 10,- Euro incl. Porto kannst du eine haben. Unterstützung gibt es aber keine ...
-
Hallo,
würde mich interessieren...von der PAK68/3 auch?
-
Nicht bei mir ..,.
-
:) ...wer ist denn da anzusprechen?
-
Pak3/030 isnt redesigned at the moment, ...
Pak3/030 ist noch nicht neu aufgelegt... was nicht ist, kann ja noch werden. Es gibt einen in Polen der hat die Pak neu aufgelegt.. vielleicht da einfach mal versuchen.
-
-> http://atari.wroclaw.pl/hardpak.html
-
PAK68/3B (kompatibel zur 3A, allerdings mit 2 zusätzlichen Adressleitungen an CON1), FRAK/3 (neue Version mit bis zu 256MB RAM), PuPla/2 und Panther/2A (2. GAL auf der Slotkarte entfällt und wurde durch nen Latch ersetzt) hab ich als ungetestete Eagle-Layouts hier. Allerdings hab ich keinen Bock, dass jemand mit meiner Arbeit groß Kohle macht (heise und Holger Zimmermann nebenbei auch nicht).
Wenn wer von euch bereit ist eine CC-BY-NC-SA Lizenz einzugehen könnte man darüber sprechen.
-
Lass sein Marius, es läuft auf eine komplette Neuentwicklung irgendwann hinaus... Vor allen die Tag Rams kaum noch zu bekommen sind, und schon aus gründen der Stabilität macht es sinn die Gals durch CPLD´s zu ersetzen. Zwei CPLDs drauf, einer macht das Bushandling inkl. Buffer und der Zweite bildet die Statemachine und Adressdecoder. Dann gleich mit Adapter um TT Karten auf der Karte zu betreiben, somit kann man Thunder und Storm dann drauf setzen.
-
Dann versteh ich nicht, weshalb der Name PAK68/3 immer wieder fällt, diskutiert wird und dann abgetan wird wenn ich nen Schritt nach vorne mach - aber gut, dann brauch ich mich darum weiterhin nicht zu kümmern.
Achja, Realname und Nicknames mischen find ich kacke, Ingo.
-
Hat eigentlich schon jemand die TerribleFire eingesetzt? Mit 68030, 68882, IDE und den fest aufgelöteten 2 MB "Alt RAM"?
-
Hat eigentlich schon jemand die TerribleFire eingesetzt? Mit 68030, 68882, IDE und den fest aufgelöteten 2 MB "Alt RAM"?
Hast du mal nen Link dazu?
-
Hat eigentlich schon jemand die TerribleFire eingesetzt? Mit 68030, 68882, IDE und den fest aufgelöteten 2 MB "Alt RAM"?
Hast du mal nen Link dazu?
https://github.com/terriblefire/tf530
Aber läuft die überhaupt in einem Atari? Der Autor war eine Zeit lang im Atari-Forum.com aktiv, weil es sich als gar nicht so einfach herausgestellt hat, eine für den Amiga entwickelte Beschleunigerkarte auf dem Atari lauffähig zu bekommen. Sein letztes Update dort ist allerdings aus dem April 2017 und es lautete: "Just a quick update here. The TF530 and the TF520 both now boot on the Atari STFM with a 2.06 ROM (TBoard). I havent managed to get the RAM working yet on the TF530 with the Atari".
Ich weiß nicht, ob er danach das Interesse an der Atari-Plattform verloren hat?
-
Danke, kannte ich noch nicht.
-
Er hat einen Youtube channel, verfolge ihn schon eine ganze weile. Er hat ihn am ST am Laufen, sogar mit 50mhz, und auch der Ram soll wohl mit dem Altram treiber von der Monster laufen. Die Karte hat auf jedenfall Potential und da Open Source auch Verändertbar. Ich würde z.b. eine Adapterplatine noch drauf setzen mot 32Bit Tos2.06 und das Ram ummappen auf den Platz wo das TT-Ram liegt. Weiß nicht ob man es so konfiguriert bekommt.
https://www.youtube.com/channel/UCu4uiUtALy1ILAxNh7TGsmQ
-
https://github.com/terriblefire/tf530
Aber läuft die überhaupt in einem Atari? Der Autor war eine Zeit lang im Atari-Forum.com aktiv, weil es sich als gar nicht so einfach herausgestellt hat, eine für den Amiga entwickelte Beschleunigerkarte auf dem Atari lauffähig zu bekommen. Sein letztes Update dort ist allerdings aus dem April 2017 und es lautete: "Just a quick update here. The TF530 and the TF520 both now boot on the Atari STFM with a 2.06 ROM (TBoard). I havent managed to get the RAM working yet on the TF530 with the Atari".
Ich weiß nicht, ob er danach das Interesse an der Atari-Plattform verloren hat?
Sie läuft in einem 1040STFM, laut seinem Youtube-Kanal. Nur für das Alt-RAM gibt es wohl noch keinen „Treiber“, AFAIK. Wobei das, wenn ich das richtig verstanden habe, auch nur eine Frage wäre, wo im Adreßraum der dann läge.
Ich fände das ja als kleine Karte für 68000-Ataris durchaus spannend, grade weil auch noch gleich IDE drauf ist, und da die Quellen offen liegen, ist das nicht wieder Sackgasse, wenn der Autor nicht mehr mag.
Ist nur die Frage, ob die offenen Probleme noch klärbar sind.
-
Er hat einen Youtube channel, verfolge ihn schon eine ganze weile. Er hat ihn am ST am Laufen, sogar mit 50mhz, und auch der Ram soll wohl mit dem Altram treiber von der Monster laufen.
Ach? Das hatte ich noch gar nicht gesehen? Wo hast du das her?
Die Karte hat auf jedenfall Potential und da Open Source auch Verändertbar. Ich würde z.b. eine Adapterplatine noch drauf setzen mot 32Bit Tos2.06 und das Ram ummappen auf den Platz wo das TT-Ram liegt. Weiß nicht ob man es so konfiguriert bekommt.
https://www.youtube.com/channel/UCu4uiUtALy1ILAxNh7TGsmQ
Vielleicht eine ketzerische Frage, aber ist’s nicht einfacher, das TOS ins RAM zu laden? Spätestens wenn man NVDI lädt, ist ja ein Teil eh dort, fehlen nur noch GEMDOS und AES :)
-
Wenn ich einen 68030 habe möchte ich auch MiNT/XaAES laufen lassen und sind mir die 2MB Fastram viel, viel zu wenig ...
-
Wenn ich einen 68030 habe möchte ich auch MiNT/XaAES laufen lassen und sind mir die 2MB Fastram viel, viel zu wenig ...
Tja – kannst das Layout ja erweitern :) Mehr ist natürlich immer toller, aber 2 MB wären schon gut für mich.
-
Wenn ich einen 68030 habe möchte ich auch MiNT/XaAES laufen lassen und sind mir die 2MB Fastram viel, viel zu wenig ...
Gegen „viel, viel zu wenig“ gibt’s da immer noch nichts, aber die TerribleFire TF534S hat nun 4 MB SRAM.
-
Das PAK68/2 Projekt ist tot von meiner Seite. Im Prinzip läuft es zwar aber die Platine kann Probleme machen. Bei mir lief es aber zum Beispiel SolderGirl hat große Probleme damit. Ich habe noch einige Platinen. Zum Selbstkostenpreis von 10,- Euro incl. Porto kannst du eine haben. Unterstützung gibt es aber keine ...
Meine Probleme kamen offenbar nicht von der PAK selbst, die funktioniert inzwischen perfekt.
Ich überlege gerade ob ich irgendwie tricksen kann, um die oberen 16 bit vom Datenbus des 68020 mit den oberen 16 bit von meinem PS/2-Modul zu verbinden, so das er direkt mit 32 bit auf den Speicher zugreifen kann.
Theoretisch sollte das doch möglich sein, wenn man die 244er und 373er auf dem Board quasi nochmal verbaut, mit den gleichen Steuerleitungen. Nur müsste man die zusätzlichen 16 bit direkt an die PAK verdrahten. Aber das könnte Probleme geben weil ja der Rest vom System immernoch mit 16 bit auf den Speicher zugreift.
Ein anderer Gedanke, der 68020 hat ja auch mehr Adressleitungen, könnte man die nicht nutzen um einfach noch ein zweites SIMM anzusteuern?
Die Datenleitungen laufen ja nicht durch die MMU, also der dürfte es egal sein. Man müsste nur irgendwie sicherstellen das die Refresh-Zyklen bei allen SIMMs ankommen. Das wäre vielleicht sogar besser wegen der Kompatibilität. Dann hätte man ein SIMM das mit 16 bit angesteuert wird im unteren Adressbereich, und ein (oder mehrere) die mit vollen 32 bit am 68020 hängen. Das müsste man natürlich dem TOS irgendwie begreiflich machen, entweder durch einen Patch oder Treiber.
-
Das direkte Verbinden der oberen 16 Bit deines Speichermoduls wird nicht ohne weiteres funktionieren. Da muss noch irgendwas dazwischen, was den DRAM-Refresh macht. Außerdem musst du das ganze TOS umschreiben, damit es Daten, die für den Shifter, DMA (und Blitter) gedacht sind, nur noch an jede zweite RAM-Adresse schreibt.
Versuche besser, der PAK TT-RAM hinzuzufügen, so wie Lukas Frank es versucht hat.
-
Um bei einer PAK68/3 das Fastram 32bit breit anzusprechen sind da zwei 74F541 auf der PAK und die zusätzlichen Adresssignale kommen über CON1. Habe die c´t DVD und kann dir den Schaltplan zukommen lassen.
-
Um bei einer PAK68/3 das Fastram 32bit breit anzusprechen sind da zwei 74F541 auf der PAK und die zusätzlichen Adresssignale kommen über CON1. Habe die c´t DVD und kann dir den Schaltplan zukommen lassen.
Ich habe ja die PAK68/2, also nicht die 030-Variante.
Es wäre aber trotzdem mal interessant den Schaltplan zu sehen.
Hat die PAK/3 eine eigene MMU, oder wie wird das da gelöst?
-
Ich habe ja die PAK68/2, also nicht die 030-Variante.
Es wäre aber trotzdem mal interessant den Schaltplan zu sehen.
Hat die PAK/3 eine eigene MMU, oder wie wird das da gelöst?
Der 68030 hat, in der Normalvariante, eine PMMU eingebaut.