Beiträge von Wiesel im Thema „TurboTrans+ / Turbo Access“

    Die Schaltbilder der 8050 sind äußerst interessant. Man sieht wie sie die GCR Dekodierung/Kodierung mit einem wahren TTL Grab gemacht haben. 74LS133, 164, 157, was es da alles für Zeugs gab ...

    Alles um ein kleines Rom zu vermeiden. Ich vermute, dass die 8050 irgendwie Verwandschaft zum Floppycontroller des Sirius 1 (Victor 9000) haben, der (auch) von Chuck Peddle entwickelt wurde. In dem Controller ist ein Hardware-GCR en/decoder drin, aber auf Basis eines kleinen ROMs. Chuck Peddle hat später maßgebliche Arbeit am C64 gemacht, daher vermute ich, dass er auch bei anderen Commodore-Teilen seine Finger drin hatte.

    Die 6502 bekommt nie GCR Daten zu sehen. Man kann per Software gar keine üblen Sachen machen, weder schreiben noch lesen. Gab es denn keinen Kopierschutz damals? Auch ein Nibblecopy kann es so gar nicht gegeben haben?

    Zu der Zeit war man froh, dass man überhaupt Daten speichern und wieder herstellen konnte. Kopierschutz kam erst auf, als Computer ein Massenphänomen wurden (achtung: dies ist eine unbelegte Behauptung). Damals war's noch üblich, dass jedem Programm eine Anleitung beilag, wie man ein Backup macht.

    Jens

    Ich würde auch erstmal nicht die mega-hardwareschlacht machen und die Modifikation auf die Floppy begrenzen. Auch das standard-Parallelkabel ist wohl die beste Idee, denn das haben die Meisten schon. Den Speicher-Crossover zwischen C64 und Floppy kann man im Chameleon machen: Da kann die MMU den Floppy-Speicher und den C64-Speicher in den REU-Speicher mappen, so dass eine REU-Operation "kopiere von Floppy in C64" möglich wird. *Das* wäre dann richtig schnell :smile:

    Diddl,
    OK, verfolgen wir also wieder die Idee, den 256K-Cache *auch* für GCR-Daten zu nutzen. Deine GCR-Dekodierung im CPLD kostet 16 Makrozellen? Das finde ich reichlich viel, denn es macht schon ein Viertel der Kapazität aus, wenn wir von einem 64-Makrozellen-CPLD ausgehen. Genau das war der Grund, warum ich wieder zu einer Tabelle im Flash wollte: Ein D-Ram Controller kostet nämlich auch reichlich Makrozellen. Grober Überschlag für meine Idee eines 2-Bit-breiten 256K-Puffers wäre allein 45 Makrozellen, wobei der schon den Luxus des auto-Increment hätte. Wenn man immer nur mit Bitpaaren arbeitet, wird die GCR Kodierung ein bischen kleiner. Vielleicht kann man sogar einen Teil davon in den Ausgangs-Datenpuffern unterbringen, aber das würde einen MACH in jedem Fall sprengen. Vom Bauchgefühl her braucht man da nen CPLD, der sehr viel mehr Produktterme pro Makrozelle aufnehmen kann. Keine Ahnung wer da die Nase vorn hat: Altera Max3000 oder die Xilinx 95XL-Serie.

    Jens

    Geniale Idee! Ich würde dann nur 2 Lesezugriffe benötigen und ein STA sparen.

    Kommt noch besser: Du kannst sogar den

    Code
    LDA GCRREG+n
    STA (bp),Y

    verkürzen, wenn Du nen Pseudo-DMA-Mode einbaust. In diesem Mode könntest Du normal auf den Speicher schreiben und es würde auch das passieren, was Du erwarten würdest. Wenn Du aber liest, startest Du beim Ram keinen Lesezyklus, sondern einen Schreibzyklus. Zusätzlich schaltest Du an Deinem CPLD das Auslesen des GCRREG+n frei. Voilá, wieder einen "load-store" durch einen "move" ersetzt. Aus dem Code-Block oben würden dann ein

    Code
    LDA (bp),Y

    Danach steht im Akku der Wert aus GCRREG+n, den Du wegwerfen oder weiter auswerten kannst. Zusätzlich hat Deine Hardware an der Position (bp),y den Wert von GCRREG+n geschrieben. Nachteil: Die unteren zwei Bits der Ram-Adresse bestimmen auch das "+n" auf Dein GCR-Register. Der Aufwand dafür wäre minimal - aber mit den gewonnenen Zyklen musst Du auch was anfangen können. Wie gesagt, Vorsortieren der Daten wäre ein Masterplan. Wenn Du das packst, wird das ein echt geiler Speeder.

    Jens

    Da wird der 6502 ja richtig langweilig ... :)

    Hast Du das schon in der Praxis ausprobiert? Wenn Du nämlich in Deinem CPLD das eine Bit das immer gleich ist nicht mehr auswertest, kommt Grütze dabei heraus. Du kannst es durchverbinden, ja, aber auswerten musst Du's auch noch, weil die anderen Ausgangsbits sich mit Änderung dieses "gleich-Bits" auch ändern können.

    Ansonsten sieht's so aus, als würdest Du mit knapp weniger als 26 Zyklen hinkommen, so dass Du wirklich mit 1MHz lesen und dekodieren kannst. Hast Du das schon in einer Schleife, so dass Du nach 5x Lesen und 4x Schreiben wieder am Anfang herauskommst und im worst case (branch taken bei allen BVC) wieder ganz oben bist? Mit Abbruchbedingung der Schleife könnte das knapp werden.

    Dann kommt natürlich gleich die nächste Disziplin, nämlich das Finden und Auswerten von Sektorheadern und das Prüfen der Checksumme. Da könte es von Vorteil sein, wenn Du nicht mehr in den CPLD schreiben musst, sondern wenn der CPLD "mit horcht" und bei einem Lesezugriff auf das VIA-Datenregister die Daten mit speichert. Je nachdem auf welche Spiegelung Du zugreifst (VIA taucht mehrfach auf) holt der CPLD sich den Kram in Dein Register A oder B - spart vier Zyklen in der Schleife, in denen Du z.B. Prüfsummen checken kannst oder die Daten schonmal an 2-hoch-N-Potenzen legen kannst, damit Sektoren superschnell ausgelesen werden können.

    Jens

    Wiesel

    Ich glaub du wolltest es so machen, dass man überhaupt nur ein LDA braucht? Und der CPLD lädt vom VIA und dekodiert und stellt sofort die dekodierten Daten bereit.

    Nee, ich wollte nicht aus der VIA lesen, sondern aus dem Speicher. Wenn Du aus der VIA liest, kommen nur 8 Bits, das reicht nicht für's Dekodieren eines ganzen Byte. Zuerst würde man durch Lesen aus der VIA den 256k-Speicher "normal" befüllen mit den ganzen GCR-Werten die aus der VIA kommen. Damit stehen GCR-Daten im 256K-Cache. Dieser Cache kann normal byteweise gelesen und geschrieben werden, so wie beim TurboTrans-Modell. Unterschied wäre, dass man einen automatischen pointer-Increment (+8 Bits, also ein Byte weiter) einführen könnte und so den Schleifen-Overhead reduziert.

    Zusätzlich würde ich ein Speicherfenster machen, das mit *einem* LDA nicht 8, sondern 10 Bits aus dem Speicher holt und sofort dekodiert. Die CPU würde in dem Fall die GCR-Daten nicht zu Gesicht bekommen. Auch der Pointer auf den 256K-Cache würde automatisch erhöht - und zwar um 10 Bit, so dass das Shifting auch automatisch erledigt ist.

    Mittlerweile bin ich schon wieder weg von der Idee, das GCR en/decoding im CPLD zu machen, weil man doch ohnehin ROM braucht. Das gibt's in der kleinsten sinnvollen Größe in 128KBytes. Mit der richtigen Verdrahtung kann man eine GCR-Tabelle von insgesamt 1280 Bytes darin unterbringen: 1024 Bytes zum Lesen, 256 Bytes zum Schreiben. Die 256K Disk-Cache wären dann entweder 256KBytes GCR-Daten, oder 204,8KBytes Nutzdaten, vollkommen transparent für die CPU.

    Jens

    Hmm.. also das Pimpen der Umdrehungsgeschwindigkeit wird leichter als ich dachte: Die 1541-II hat nen 3-Phasen Direktantrieb mit digitaler Steuerung. Das Teil nimmt 610,2kHz als Basisfrequenz und macht daraus eine 3-Phasen Ansteuerung für den Motor. Erfahrungsgemäß sind solche Teile *sehr* tolerant bei Übetraktung, speziell wenn man trotz 300RPM-Setting auf ein paar Prozent mehr will. Ich würde an dem Setting nichts verändern (Mode-Pin), sondern nur den Takt von außen vorgeben (762,75kHz), dann dreht das Teil quarzgenau schneller.

    Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.

    Mods: vielleicht sollten wir einen neuer-Speeder-Thread abtrennen?

    Jens

    Da würde ich doch mal die Standardtheorien anbringen: Entweder wurde die Ramdisk-Variante aus einem schon existierenden Speedersystem entwickelt welches die 8K Track-Puffer schon hatte oder das System wurde mit dem Ziel entwickelt, das gleiche System einmal mit und einmal ohne Ramdisk auf den Markt zu bringen.

    OK, aber dann würde ich doch die Hardware so entwickeln, dass ich nicht an einer Stelle massig Ram verschenke, nur um's an einer anderen Stelle nochmal kaufen zu müssen. Ist aber auch egal, denn ich bin gestern noch davon ausgegangen, dass Nutzdaten im Speicher abgelegt werden. Wenn aber die Disk ohne 2MHz-Mode und ohne hardware-Unterstützung beim GCR-Decoding in den Cache gelesen werden soll, dann bleibt nichts Anderes übrig, als Rohdaten zu speichern. Die Datenmenge wird damit 25% höher, oder anders herum: Die 256K Cache reichen nur für rund 200K Nutzdaten (schließlich müssen Header mit abgelegt werden). Es ist also gut möglich, dass bei Verwendung von 41 Tracks keine 8k mehr frei waren.

    Ich hab' noch ein bischen nachgedacht über "GCR-Decoding im CPLD" - das sollte eigentlich problemlos machbar sein, denn um ein Nibble zu dekodieren, braucht man nur drei Gleichungen mit je maximal 8 Produkttermen. Kein Bit wird mehr als 8 mal innerhalb der 16er Tabelle 1 bzw. 0, so dass die Menge der Gleichungen sehr überschaubar ausfällt. Selbst die alten MACHs von Anfang der 90er Jahre können das schon: Jeder Output kann bis zu vier Produktterm-Cluster zu je vier Produkttermen verwenden, man braucht also nur die Hälfte der Kapazität (dadurch entstehen im MACH andere Engstellen weil im Schnitt nur ein Cluster pro Makrozelle da ist, aber da kann man drumherum arbeiten). Damit wäre der Weg frei für die persönliche Herausforderung: "Baue einen Speeder, der so schon möglich gewesen wäre, als Commodore noch im Geschäft war".

    Man kann auch auf der mechanischen Seite noch mehr Speed 'rausholen: Die Floppy dreht nur mit 300RPM, also 200ms pro Umdrehung. Das limitiert auf rund 7,5 Sekunden Einlese-Zeit pro Diskette. Vom Catweasel wissen wir aber, dass eine C64-Disk in unter 7 Sekunden gelesen werden kann (wert vom Amiga). Grund dafür ist, dass die PC-Laufwerke mit 360RPM drehen, also nur 167ms pro Umdrehung. Mit Sync-Overhead und Stepping landet man bei rund 6,2 bis 6,3 Sekunden. Das Drehen mit 20% mehr Speed liegt also voll in den Spezifikationen der 5,25"-Scheiben. Wenn wir den Motor der 1541 auf 360RPM aufdrehen, müssen wir nur den 16MHz-Quarz der Floppy gegen einen 19,2MHz-Quarz tauschen, dann ist der Nachteil der 1541 gegenüber dem Catweasel auch aufgeholt. Jetzt sind Quarze dieser Frequenz nicht gerade häufig, deswegen würde ich auf 20MHz gehen. Resultat wäre:

    - Diskette dreht bei 375RPM (160ms pro Umdrehung)
    - CPU läuft bei 1,25MHz (moderate Übertaktung)
    - Einlesezeit einer ganzen Disk mit 35 Tracks reduziert sich auf theoretisch 5,9 Sekunden (gerechnet mit 5% overhead pro Track, was nicht immer ausreicht)

    Natürlich würden jede Menge Probleme bei der Kommunikation mit dem C64 auftreten, denn das Timing der IEC-Routinen würde komplett zerschlagen. Aber hey, Diddl wollte doch ohnehin ein neues DOS schreiben, oder 8) ?

    Jens

    Man muss PD gar nicht schlagen.

    Doch, muss man. Wo ist sonst der Spaß hin? Dolphin hat PD in irgendeiner Disziplin mal abgehängt, sogar ohne 2MHz-Mode. Da geht also noch was.

    Mal rechnen: 21 Sektoren, 350 Bytes Nettodaten und ein bisschen verlust durch Sync Bytes ...

    ... Also etwa 7500 Bytes in 200ms. Entspricht etwa 27 µs Zeit, ein Byte zu übernehmen, zu dekodieren und zu speichern.

    Mach's Dir doch nicht so schwer: Die höchste Datenrate die Du bei der 1541 einstellen kannst, ist 307,7kBit (4/13 MBit am Clock-Generator). Damit hat jedes Byte 26µs Zeit vorbeizufliegen. Das sind GCR-Bytes, die man eigentlich problemlos im Disk-Cache ablegen kann, während der Lesevorgng läuft. Die Daten müssen nur abgelegt, nicht verarbeitet werden. Natürlich kannst Du nicht den ganzen Track roh ablegen - die Lücken zwischen Sektoren und Headern sollten noch weg, sonst kommst Du mit 256K für eine Disk nicht hin. Aber selbst das passiert automatisch: Während ein Sync vorbeifliegt (also lauter 1er), wird der Counter für das Schieberegister nicht hochgezählt, so dass Du nur ein $ff bekommst, egal wie lang der Sync war (achtung: Halbwissen aus Schaltplan-Studium der 1541 mit ganz langer Platine - Software-Leute sollten das nochmal bestätigen!).

    Aber zurück zum Thema: 26 Zyklen halte ich für luxoriös, da kann man problemlos ne saubere Schleife ohne Tricks drin bauen.

    Jens

    Die Professional-DOS Geschichte ist immer noch 2-stufig. Wenn man das speedmäßig schlagen will, braucht man einen single-cycle-Konverter, also etwas, was 10 Bits liest und dekodierte 8 Bits an die CPU übergibt, ohne dass man irgendwas zwischendurch machen muss: LDA (indexed-pointer) und das Ergebnis muss direkt der übersetzte Wert sein. Dann kann man auch einen 256K-Puffer mit GCR-Daten halten, denn es wäre transparent für die CPU.

    Muß ich mal drüber nachdenken - vielleicht lässt sich da was mit 2 Bit breitem Speicher machen, den man entweder mit einem 4er CAS-Burst anspricht um 8 Bits zu lesen/schreiben, oder mit einem 5er Burst der dann durch einen GCR Decoder geschickt wird. Immerhin hat man in der 1541 den kompletten Zyklus, nicht nur den halben wie im C64. Da gibts reichlich Zeit für solche Spielereien :wink:

    Jens

    Wenn Du schon dabei bist einen neuen Speeder zu entwickeln, dann bau' auch gleich ein paar Gimmicks ein. Beispielsweise kann ich mir vorstellen, dass Du die GCR en/dekodierung sehr viel schneller hinbekommst, wenn Du vom Speicherfenster sieben Spiegelungen (S0 bis S6) hast:

    Die Spiegelung S0 zeigt Dir den ganz normalen Speicher Byte für Byte.

    Die nächsten sechs Spiegelungen maskieren Speicherinhalt um je zwei Bit:

    Zugriff auf S1 maskiert die Bits 7 und 6. Lesend bekommst Du immer den Wert von S0 "AND $3F". Schreibend werden die Bits 7+6 nicht angefasst.

    Zugriff auf S2 maskiert die Bits 7 bis 4. Lesend bekommst Du immer den Wert von S0 "AND $0F". Schreibend werden die Bits 7 bis 4 nicht angefasst.

    Zugriff auf S3 maskiert die Bits 7 bis 2. Lesend bekommst Du immer den Wert von S0 "AND $03". Schreibend werden die Bits 7 bis 2 nicht angefasst.

    Zugriff auf S4 maskiert die Bits 5 bis 0. Lesend bekommst Du immer den Wert von S0 "AND $C0". Schreibend werden die Bits 5 bis 0 nicht angefasst.

    Zugriff auf S5 maskiert die Bits 3 bis 0. Lesend bekommst Du immer den Wert von S0 "AND $F0". Schreibend werden die Bits 3 bis 0 nicht angefasst.

    Zugriff auf S6 maskiert die Bits 1 und 0. Lesend bekommst Du immer den Wert von S0 "AND $FC". Schreibend werden die Bits 1 und 0 nicht angefasst.

    Damit sollte der 8-Bit/10-Bit Kram nicht mehr ganz so schmerzvoll sein und man kann reichlich Zyklen sparen. Oder gibts ne bessere Möglichkeit - außer Monster-Tabellen zu schaffen?

    Außerdem sind CPLDs heute gross genug, dass man Zähler komplett implementieren kann. Anstatt also mit indexed-Zugriffen auf den Cache zuzugreifen, kann man eine feste Adresse mit auto-Increment einführen. Das spart weitere Zyklen für Zeropage-Increment, Übertrag oder auch nur Index-Register-Increment. Sogar den Schleifenabbruch könnte man in Hardware realisieren, denn in der Floppy gibt's üblicherweise keine NMIs. Man könnte den Pointer auf Wert A setzen, einen Wert B als Abbruchkriterium einstellen und einfach endlos Daten schaufeln. Wenn der NMI kommt, macht die NMI-Serviceroutine nur ein paar Stack-Operationen, damit aus der Endlos-Schleife herausgesprungen wird.

    Jens

    Wird es eventuell ne verbesserte Neuauflage geben ?

    Diddl hat auf jeden Fall mit seiner Wiki-Seite den Startschuss zum Reversen gegeben. Wenn wir dann irgendwann so weit sind, dass wir das Reverse-engineering als "fertig" bezeichnen, müssen wir's auch verifizieren - dafür macht man sich sein eigenes PAL (dann wohl ein GAL) und hat *grundsätzlich* die Möglichkeit, die Hardware auch nachzubauen. Ob das aber Sinn macht, sei dahingestellt. Speziell in diesem Fall halte ich's für überdimensioniert, weil man dem C64 noch einen zusätzlichen Parallelport verpassen muss. Der wird aller Wahrscheinlichkeit nach einen Speicherbereich belegen, der von den heutigen standard-Cartridges belegt wird (Action Replay, Retro Replay).

    Mein persönlicher Antrieb ist rein akademisch. Ich habe auch andere Cartridges reverse-engineert ohne dass ich sie nachbauen wollte.

    Sauhund hat die Arbeit aber immer mit in den VICE übernommen - ich kann mir vorstellen, dass das bei TurboTrans auch passiert, wenn wir fertig sind.

    Jens

    Dann darf ich auch mal ne wilde Theorie äußern:

    TurboTrans kam auf jeden Fall nach Professional DOS, welches fast ausnahmslos jeden Test gewonnen hatte. Außerdem gab es für Professional DOS auch eine 256K-Platine für einen kompletten Diskettenpuffer. Ältere Professional DOS Versionen hatten die 8K S-Ram bei $a000-$bfff, spätere Versionen hatten's bei $4000-$7fff. Vielleicht sollten wir mal schauen, ob's "ähnlichkeiten" zwischen dem TT-Code und dem PD-Code gibt?

    Ich will jetzt wissen, wie TurboTrans wirklich in die Floppy eingebaut wird: Müssen die Roms raus? Gibts da ne Bastelei mit einem Pin der CPU, der nicht zur Floppy 'runter darf? Weil.. sonst hätten wir nicht viele Bereiche, in denen man extra-Hardware unterbringen kann. Links zum Handbuch sind irgendwie nicht vorhanden oder tot - Diddl, das wäre ne super Ergänzung für Deine Wiki-Seite.

    Außerdem will mir noch nicht so richtig in den Kopf, warum man 256K Buffer für ein Diskettenimage von unter 200K braucht, also fast 60K verschenkt, aber dennoch ein 8K S-Ram auf der Karte unterbringt. Wir sollten einen Nachbau wirklich *clever* machen indem wir herausfinden ob's 8K in dem 256K-Buffer gibt, die standardmäßig von der Software nie verwendet werden. Den Teil blenden wir dann in den 8K S-Ram Bereich ein und sparen uns weitere Hardware.

    Jens

    Hmm.. das klingt äußerst ineffizient, denn wenn ich der FLoppy 8K S-Ram verpasse, dann doch in der Regel um damit einen ganzen Track auf einmal zu lesen und zu dekodieren - in einer Umdrehung.

    Wenn Du jetzt doch den Sektorpuffer in den unteren 2k unterbringst und von dort direkt in das "große Array" (Du nennst es Cache - wir sollten einen gemeinsamen Begriff finden!) schreibst, ist der Nutzen des 8k S-Ram nahe null.

    Du hast aber Recht, dass der eine verschobene Takt evtl. nicht zum Generieren einer früheren CAS-Flanke für write, sondern evtl. doch für Refresh gut ist. Das würde auf jeden Fall einen der zwei unbeschalteten Pins erklären.

    Die Zugriffe auf $6bfc und $6bfd kann das PAL nicht unterscheiden - das kennt nur 2K-Blöcke. Die letzte Version von Dolphin-DOS (V3) hat an der Stelle die 8K Ram gehabt - vielleicht ist das hier auch so? Das erklärt dann die drei von Dir gefundenen Zugriffe. Wenn das Ram sonst nicht gebraucht wird, müssen wir mutmassen, dass Du Trashcode gefunden hast.

    Jens

    ich frag Skern nachher bei der Party mal ob er weiß wo das TT ab geblieben ist.

    Mach mal, und poste das Ergebnis hier. Wenn das Teil grad im Bunker ist, bau's doch mal ein und schau ob's funktioniert. Falls ja, komme ich evtl. am Sonntag kurz mit dem logic analyzer vorbei, dann haben wir wenigstens ein paar Anhaltspunkte in Sachen Timing und Speicherlayout.

    Jens

    Mal langsam mit "messerscharf" - bloß weil's grad gut passt muss das noch nicht heissen, dass das richtig ist. Auf die zwei getrennten Bereiche für die zwei Bänke bin ich gekommen weil ich mir überlegt habe, wie man Makrozellen bzw. IO-Pins sparen könnte. Das ist ne Standard-Überlegung, wenn man ein PLD-Design macht, denn IO-Pins sind *immer* Mangelware.

    Es kann aber trotzdem falsch sein, denn da sind zwei unbeschaltete Pins am PAL, die irgendeinen Zustand speichern könnten. Wenn wir Pech haben, gibt es eine Init-Sequenz, mit der man das erweiterte Rom und die Ram-Bänke freischalten muss. Und wenn wir Glück haben, sind die Pins überhaupt nicht benutzt. Die Antwort bekommen wir nur per logic analyzer.

    Ich würde mich aber freuen, wenn sich noch jemand an der Aktion hier beteiligen würde und den Schaltplan des Expansionsport-Moduls zeichnet. Außerdem fehlt uns noch die Belegung des Parallelkabels.

    Und was das Wetter angeht: Turbo Trans ist schon einige Jahre alt (sind's schon 20?), da kommt's auf ein paar Wochen auch nicht mehr an. Ich habe auch immer nur minutenweise Zeit, mich in die Schaltung einzudenken - immer wenn der design rule check über das Nequester-Design läuft.

    Übrigens würde ich es als echte Herausforderung sehen, einen Nachbau *nicht* mit S-Ram zu bauen, sondern auch mit D-Ram - und zwar mit vier Stück 1Mx1. Vernünftigen Refresh einbauen und per double-CAS aus vier Bits acht machen.

    Jens

    Ähemm.. grad nochmal den Schaltplan angeguckt: Also das mit der Op-Amp Schaltung für tri-state Terme können wir uns sparen, denn die zwei kombinatorischen Outputs sind die zwei CAS-Leitungen. Damit sind schonmal ne Menge Dinge klar:

    - Die Pins 12 und 19 sind immer output und gehen sinnvollerweise nie hochohmig.
    - Die Outputs 13 bis Pin 18 sind auch immer niederohmig, da Pin 11 auf GND liegt
    - die einzigen Input-Werte sind Adressen, R/W und zwei Takte
    - Ein fest liegender, zum Phi2 leicht verschobener Takt wird für die sechs Flipflops verwendet (Pin 1)
    - ein schwer driftender Takt, dessen Lage aus dem Schaltplan nicht erkennbar ist (Wert von C1 nicht bekannt) wird für die Zugriffserkennung benutzt. Ein Hinweis darauf ist die Verdrahtung zum '590, welcher auch mit diesem Takt gefüttert wird. Es würde mich nicht wundern, wenn dieser Takt dem eigentlichen Phi2 *vor*läuft (also ca. 330 bis 350 Grad nach hinten verschoben ist), denn dann kann man recht sauber einen Schreibzugriff vor Ende des Gültigkeitsfensters beenden - somit dürften die zwei kombinatorischen Outputs wirklich RS-Flipflops sein.

    Weiter vermute ich, dass es nicht ein, sondern zwei 2k-Fenster gibt, in denen der Speicher sichtbar ist. Ein Fenster für die untere 256K-Bank und ein weiteres Fenster für die obere Bank. Wie gestern schon geschrieben, muss es innerhalb dieses Fensters eine Spiegelung geben, so dass sich im Speicher dieses Muster ergibt:

    1a
    1b
    2a
    2b

    1a und 1b sind identisch, 2a und 2b sind auch identisch. Dadurch ergibt sich der Nebeneffekt, dass man bei linearem Zugriff auf 1b und 2a ein kontinuierliches 2k-Fenster hat. Das ist aber wilde Spekulation und lässt sich ohne logic analyzer nicht belegen. Da TurboTrans auch mit nur 256K ausgeliefert wurde, wird die Software wohl kaum von einer solchen Anordnung Gebrauch gemacht haben, denn sie funktioniert nur im Vollausbau.

    Jens

    Gut, aber man könnte damit doch wenigstens die PAL Funktionalität testen? Also die CS und Adressleitungen für Eprom und statisches RAM? Und eventuell RAS und CAS?

    Dafür würde ich das PAL in eine kontrollierte Testumgebung holen. Zwei der acht Ausgänge sind kombinatorisch und haben programmierbare Tristate-Terme (jeweils nur ein Produktterm). Allein für die würde ich erstmal ne kleine OpAmp-Schaltung bauen, die einen High-Z Zustand erkennt.

    Dann hast Du noch das Problem, dass die sechs registered-Ausgänge wieder Feedback in den Rest der Logik haben. Dieses Feedback kann Dir beim Reversen immer das Genick brechen, denn es kann unter Umständen sehr lange dauern, bis Du alle 64 möglichen Zustände der Outputs forcieren kannst. Damit nicht genug: Die kombinatorischen Ausgänge könnten auch als RS-Flipflops programmiert werden. Wenn dem so ist, hast Du sogar 256 statische Zustände.

    Mit ein bischen Logik und Sachverstand müsste das aber zu knacken sein. Blockdiagramm des 16R6 im Anhang.

    Jens

    Bzw. könnte man natürlich auch ganz einfach die 6502 durch einen 644er ersetzen: Einfach R/W, Phi2, A0 - A15 und D0 bis D7 an die Ports des Mega legen.

    Das ist FAIL. TurboTrans wird nur bei genau eins-komma-null-null-null-null MHz und Zimmertemperatur funktionieren. Wenn Du irgendwie davon abweichst, fällt das Kartenhaus zusammen. Messungen machen ausschließlich in der "Heimatumgebung" Sinn. Mein Vorschlag von gestern, das Teil an einen VC20 zu klemmen wird ebensowenig funktionieren.

    Jens

    Yep, das müsste nach ner Zeit dazu führen, dass große Teile des Speichers auf ihren Normalwert kippen, also ein charakteristisches 00/FF-Muster bilden (merke: Rams werten unterschiedliche Zellen unterschiedlich aus, mal ist "Ladung enthalten" ne 1, mal ne 0).

    Jens