Beiträge von Unseen im Thema „Turbokarte eigenbau möglich?“

    Kann sich jemand mal das GAL Listing anzukucken ob man das auf 2MB erweitern und die Schaltung auch zB auf die PAK3 übertragen könnte ?


    Nur zur PAK3: Von der Hardwareseite her müsste man ein paar Pins der Rams wegbiegen und frei verdrahten, da zB die zusätzlichen Adressleitungen fest auf +5V liegen und das wegen der Multilayer-Platine nicht einfach trennbar ist. GAL-technisch sind IIRC bei Vollausbau nicht genug Pins frei um die Schreibleitungen der Rams noch anzusprechen, wenn man allerdings keinen Cache verwendet sollte es möglich sein.

    Beim Amiga wäre das Ram allerdings nicht autokonfigurierend (ausser man legt ~1.7MB davon ab 0xc00000 ab, was wieder andere Probleme verursachen kann), d.h. es müsste eine AddMem-Anweisung in die startup-sequence damit es auch verwendet wird.

    Ich würde dann eh erstmal ein Exemplar der 30A aufbauen bevor ich die Bauteile mit geproggten GALs weiterversende. Wir wollen ja sicher sein, dass der GAL Inhalt dann auch der richtige ist.


    Ich würde die auch unprogrammiert nehmen.

    Planst du die für Mac oder für Atari programmiert zu versenden? =)

    Die Begründung liegt darin begründet das das ChipRam im Amiga ohne zutun der CPU vom ChipSet angesprochen wird


    Stimmt natürlich. Gibts ein Signal an dem man Chipsatz-initiierte Schreibzugriffe auf das Chipram ablesen könnte oder sieht das für die CPU evtl. sogar wie ein DMA-Zugriff aus?

    Zitat

    dann machen Zorro II Karte zum Teil DMA auf das 16 Bit FastRam, davon würde der Cache nichts mit bekommen und die CPU würde dann veraltete Daten aus dem Cache ziehen.


    Das betrifft die PAK68/3 nicht, die markiert ihren Cache-Inhalt als ungültig wenn auf dem Bus ein DMA-Zugriff erfolgt.

    Zitat

    Der Cache dürfte also nur beim 32 Bit Speicher der PAK3 wirksam sein, da die in der Grundversion aber keinen Speicher hat kann mans auch gleich sein lassen zumal die CPU ja nen kleinen Cache intern hat.


    Der CPU-interne Cache hat prinzipiell die gleichen Probleme.

    ja 2 tag ram pro platine. tepe sagt ja der cache würde im amiga nix bringen, das müsste man mal noch testen.


    Ich würde zumindest für eine Platine einen Satz nehmen.

    Für die Behauptung, der Cache würde im Amiga nichts bringen würde ich eh gerne mal eine gute Begründung sehen...

    Zitat

    ich hab ja auch vor eine platine in einen mac plus einzupflanzen :)


    Hier ist eine der Platinen für einen SE verplant. =)

    Was könnte man da machen das er die unterstützen tut ?
    Liegt es an der Programierung der GALs oder erher an den Register Bausteinen?


    Verdrahtung ändern damit die zusätzlichen Adressbits sinnvolle Werte erhalten, grössere Tag-Rams verwenden (und deren Verdrahtung ändern), damit die Addressbits die zum Cache-Eintrag gehören gespeichert werden können und evtl. ein paar kleinere Anpassungen der GAL-Gleichungen.

    Grössere Tag-Rams werden allerdings nicht in die vorgesehenen Sockel passen...

    aber wahrscheinlich (Pinbelegung müsste ich erst prüfen und im Platinenschaltplan noch etwas nachschauen) durch 29F040 ersetzen die es auch bei Reichelt gibt.


    So, gerade mal nachgeschaut und nachgemessen: Würde man 29F040 in die Sockel setzen, so würden bei denen /WE, A17 und A18 auf high liegen. Damit würden die sich problemlos als 27C010-Ersatz eignen, auch wenn 3/4 der Kapazität ungenutzt wären. Alternativ könnte man die Pins für A17 und A18 verbiegen damit sie keinen Kontakt mit dem Sockel haben und geeignet an zwei Schalter führen um auf der PAK eine 4fach-Kickstart-Umschaltung hinzubekommen.

    SRAMs in den Sockeln für 2MB Fastmem unterzubringen wäre etwas aufwendiger, da am Ram 4 Pins nicht zur vorhandenen Belegung passen würden.

    Zitat von Schmitti

    Wer Probleme hat, die Toshiba TC5588- oder Cypress CY7C185-SRAM's (8k x 8) zu bekommen, kann auch andere SRAM's adaptieren. Da dürfte es keinen Engpass geben. Denkbar sind auch SRAM's mit 16k x 16 oder 16k x 4 (2 Stück parallel).


    Adaptieren ist nicht ganz einfach wenn die Rams planmässig direkt auf der Platine verlötet werden sollen und in den Sockeln der EPROMs liegen.

    Das ChipRam ist doch eh nicht cachbar da dort ohne das die CPU bzw TBKarte das merkt zugegriffen wird.


    Na ja, man kann prinzipiell trotzdem cachen, wenn man den Inhalt bei Schreibzugriffen für ungültig erklärt. Wie einfach das im Amiga beim Chipram ist weiss ich leicher nicht...

    GAL 20V8-15prog.


    Reichelt

    Zitat

    27C010-120 oder 27C512-120


    Kann man auch weglassen, wenn man der Meinung ist dass der Geschwindigkeitsvorteil beim 32-Bit-Zugriff aufs Kickrom sich nicht lohnt. 27C512 gibts bei Reichelt, 010er nicht - aber wahrscheinlich (Pinbelegung müsste ich erst prüfen und im Platinenschaltplan noch etwas nachschauen) durch 29F040 ersetzen die es auch bei Reichelt gibt.

    Zitat

    74F541


    Digikey hat die nur in SMD-Gehäusen (wenn man nicht gleich 450 will), notfalls könnte man die mit viel Geduld passend dranfädeln.

    Zitat

    Ps. was wäre besser wen man ne neue Turbokarte entwerfen will, GALs oder ne andere Bauform.


    Würde heutzutage noch jemand eine Turbokarte designen (hat da etwa jemand Ambitionen was mit Peters 68EC020 zu machen?) dann wäre es das sinnvollste die Logik in ein CPLD zu packen statt sie auf diverse GALs zu verteilen und in 74xxer-Logik höchstens noch ein paar Daten/Adresstreiber auszuführen wenn das Pins am CPLD spart.

    Habe sie dir per mail geschickt!


    Danke, aber ich meinte nicht die Artikelkopien sondern den Zettel der in einem der früheren Fotos teilweise sichtbar ist und der die Änderungen der PAK68/3-30 zur PAK68/3-30A und die dadurch notwendigen Bestückungsänderungen beschreibt. Mindestens ein Teil davon war auf dem Foto verdeckt und der Text deutete Änderungen an den GALs an von denen ich hoffe dass sie ebenfalls im Quellcode vorliegen.

    Falls ich irgendwann mal so weit bin die Karte erfolgreich in einem Amiga betreiben zu können(*) plane ich mal die weiter oben angedachte Möglichkeit für 2MB Fastram näher zu prüfen. In den Artikeln zur PAK 68/3 wurde erwähnt, dass die dort eigentlich vorgesehenen EPROMs mit einem Waitstate angesprochen werden weil 60ns-EPROMs damals (heute auch) kaum bis gar nicht erhältlich waren. Heutzutage bekommt man aber problemlos 55ns-SRAMs mit 512KB, wenn das ganze so funktioniert wie angedacht hätte man dann immerhin 2MB Fastram ohne Waitstates - schneller gehts auch mit Cache nicht. Aber bitte nicht zu früh freuen, das ist zur Zeit rein theoretisch.

    (*) In einem A500 wird die Karte übrigens meiner Meinung nach den Wiedereinbau der Tastatur verhindern.

    Alternativ kann man vielleicht auch einen anderen SRAM-Typ verwenden mit gegebenenfalls kleiner Zusatzbeschaltung.


    Die Zusatzbeschaltung braucht "lediglich" einen hinreichend flotten Vergleicher für die Daten und ein Flipflop pro Byte im SRAM um sich zu merken ob da überhaupt schon gültige Daten gespeichert wurden. Ein zweites SRAM geht dafür nicht, die müssen gemeinsam zurücksetzbar sein.

    Zitat

    Auch müssen die Cache-SRAM's sicher nicht unter allen Umständen die 25 ns Zugriffszeit aufweisen. Diese ist ja auch die maximal 32 MHz der Turbokarten ausgelegt.


    Aber warum sollte man die mögliche Geschwindigkeit durch langsame Rams verschenken?

    Aus meiner Erinnerung waren dir TAG-RAMs beim 486er auch nur ganz normale SRAMs evtl. mit einer anderen Größe (meist kleiner).


    Ja, bei PCs wurden die Vergleicher wohl üblicherweise in den Chipsatz integriert.

    Zitat

    Leider konnte ich kein Datenblatt vom ST-MK48S71 finden. Was ist ein "Match out" ein besonderer Ausgang bei TAG-RAMs?


    Darüber meldet der Chip ob die anliegenden Daten mit den an der anliegenden Adresse gespeicherten Daten übereinstimmen. Den Teil könnte man ja noch halbwegs einfach nachfrickeln, schwierig ist nur das Clear-Signal mit dem alle gespeicherten Tags auf einen Schlag als ungültig erklärt werden können bis wieder neue gespeichert wurden.

    kurze Frage zu den Chips. Stellt es prinzipel ein Problem dar, wenn die Chips eine schnellere Zugriffszeit haben? Also beim RAM, ROM, GALS etc. anstatt 20ns nur 15ns. Das wäre interessant und würde weitere Möglichkeiten eröffnen.


    Sollte mit hoher Wahrscheinlichkeit kein Problem sein.