Beiträge von Wiesel im Thema „Kennt vielleicht jemand dieses Module?“

    Da Subzero gerade online ist: *push*

    Das mit den zwei STAs die möglicherweise umschalten ist natürlich Quatsch, weil nur Lesezugriffe die Logik triggern können. Vermutlich war's ne schlechte Idee mit $0320, aber ich weiß ja nichtmal, wie der Code eingegeben wurde!

    Jens

    ist da ein fehler?

    Kann sein, ja. Durch die zwei STA in Folge könnte es sein, dass schon das alternative Kernal eingeblendet wird. Wie gesagt, ich habe keine genaue Analyse der Zähl-Logik gemacht, es kann sein, dass die vier Taktzyklen, innerhalb derer diese Zugriffe gemacht werden, schon ausreichen, um das Umschalten auszulösen.

    Die Idee wäre, mal die zwei STA-Adressen zu tauschen, also zuerst FCEB, dann FCEA zu beschreiben. Die Umschalt-Logik wird dann in jedem Fall sperren.

    Alternativ kannst Du auch zusätzlich eine Randfarbe-ändern-Routine nach $03D0 legen. Wenn die angesprungen wird, wissen wir, dass die zwei STAs schon "böse" sind für dieses Modul.

    Außerdem finde ich, dass dieses Modul mal mit dem 64er Speed-Test Programm durchgemessen werden sollte. Siehe auch Bitte melde dich an, um diesen Link zu sehen. und die Tabelle auf der Bitte melde dich an, um diesen Link zu sehen..

    Jens

    Edit:
    Ich hab' mal die C64 memory map angeguckt, wahrscheinlich ist es ne schlechte Idee, bei $0320 was abzulegen, denn da liegen irgendwelche Vektoren. Code an der Stelle kann man nicht wirklich ablegen. Aber $03D0 liegt im Datasettenbuffer, das sollte ungefährlich sein. Wie hast Du den Code eingegeben? Irgendein Modul?

    Die Einschaltverzögerung muß (ebenfalls IMHO) sein, weil das EPROM schlicht zu langsam wäre im gleichen Zyklus die neuen Daten rechtzeitig parat zu haben.

    Einspruch.

    Das Eprom braucht rund 200ns Zugriffszeit, um in dieser Schaltung korrekt zu funktionieren. Im ausgeblendeten Mode wird Kernal-Zugriff schätzungsweise 20ns nach Beginn des CPU-Zyklus erkannt (Laufzeit des LS30), dann bekommt das Eprom schon den Select. Jetzt die geschätzten 200ns des Eproms, dann rauscht das Signal durch vier LS00-Gatter (nochmal worst-case 80ns), so dass bis zum Ziehen von /GAME 300ns oder weniger vergangen sind. Da das Eprom selected bleibt (CE-Zugriff ist langsamer als OE-Zugriff oder Adressänderung!), verkürzt sich die Zugriffszeit nach Änderung der Eprom-Adresse A13, so dass die Gatterlaufzeit durch den LS244 nicht mehr ins Gewicht fällt. Voila, alles in 500ns passiert, also innerhalb der Zeit, die der CPU-Zugriff dauert. Das sind alles worst-case-Zeiten, wahrscheinlich ist das alles noch einen guten Schluck schneller, denn das Eprom sieht für mich nach einem CMOS-Typen mit 12,5V Programmierspannung aus, das sollte rund 150ns schnell sein.

    Meiner Meinung nach handelt es sich bei der Zähler-Schaltung nicht um eine Einschaltverzögerung, sondern um eine Schaltung, die einen Datenzugriff von einem Opcode-Fetch unterscheiden kann. Die Umschaltung wird nur innerhalb von 4 Zyklen (oder sind's drei?) zugelassen, in denen das letzte $fe-Byte gelesen wurde. Das passiert nur dann, wenn das Kernal-Rom wirklich *ausgeführt* wird, aber nicht, wenn es (wie bei meinem ersten Versuch unter Basic) einfach ausgelesen wird. Dadurch bleibt das Ram unter dem Kernal zumindest unter gewissen Bedingungen verfügbar, denn es gibt "nur 15 böse Adressen", die ein Spiel oder Demo nicht mit ausführbarem Code füllen darf (siehe mein Posting von gestern).

    Gleichzeitig ist das aber auch ein prima Auslese-Schutz, denn man kann nur dann das Rom einblenden, wenn man diese "magischen Adressen" kennt, und wenn man die Schaltung kennt. Mal nachdenken...

    Mit dem indirekten JMP werden die zwei magic-Adressen schnell hintereinander ausgelesen, das Rom eingeblendet, aber die CPU hat ihren PC immer noch im un-angetasteten Ram-Bereich. Ich bin mir jetzt gar nicht sicher, was bei $0320 liegt (kann man da gefahrlos ein paar Bytes ablegen?), aber ich bin mir zu 99% sicher, dass dieser Code nach $0320 und eben nicht nach $2020 springt, denn das zweite Byte kommt schon aus dem Eprom. Die Rahmenfarbe wird Auskunft geben.

    Jens

    Da müsste noch eine Verbindung vom Eprom in den Logik-Bereich sein. Ich tippe auf D0 zum Gatter U2d.

    Grund: Jeweils ein Byte vor dem $fd-Byte steht immer ein $fe-Byte in der oberen Bank. Vermutlich wird damit die Einschalt-Logik freigeschaltet und wartet dann maximal vier Takte auf ein Einschaltsignal. Falls man nur Daten aus $e000-$ffff liest, blendet sich das Modul nicht ein. Wenn aber die Adressen schnell genug hintereinander gelesen werden, nimmt die Hardware an, dass Code ausgeführt wird und drängelt sich rein.

    Jens

    Subzero misst noch Durchgang auf Eprom D1. hmm

    Dann haben wir's :smile:

    Während das Modul abgeschaltet ist, lauscht es weiterhin mit (der LS30 bleibt aktiv!). Die Obere Bank des Eproms wird während dieses Lausch-Modes eingeschaltet, und in dieser Bank findet sich eben nicht nur $ff, sondern ab und zu auch mal ein $fd, also D1 gelöscht. Wenn das mit dem Inverter verbunden ist, wird das Flipflop gekippt, und das Modul ist aktiv. Nachteil: Auch wenn Code im $e000-Ram ausgeführt wird, drängelt sich das Modul 'rein. Nicht die feine Art...

    An insgesamt 15 Stellen blendet sich das Modul ein:

    $E387
    $E5A9
    $E5EB
    $EB83
    $EB90
    $EB92
    $EBA0
    $EBA2
    $F1CC
    $F3D6
    $F4C5
    $F616
    $FCEB mitten in der Reset-Routine
    $FD66
    $FE74

    Beim Einschalten wird also die Reset-Routine wie folgt abgeändert:

    Wer kommentiert die anderen Einsprünge?

    Jens

    Ich begreif's nicht. Ich finde im Original-Kernal keine Stelle, die auf $dfxx zugreift, also gehe ich davon aus, dass das externe Kernal beim Einschalten eingeblendet ist. Mit der komischen Startroutine ranzt der Rechner aber bestimmt direkt mal ab.

    Immerhin scheint das Abschalten so zu funktionieren wie ich vermute:

    Code
    E03F   8D 00 DF   STA $DF00
    E042   60         RTS

    ...und im Original-Kernal steht auch ein RTS bei $E042, also wird hier sauber übergeblendet. Ich warte mal auf das Update des Schaltplans, Wetter ist zu gut um sich jetzt darüber den Kopf zu zerbrechen.

    Jens

    Edit: Just wenn man grad aufhören will... also bei einem Reset wird das Modul in jedem Fall AUSgeschaltet. Auf irgendein Signal, das ein standard-C64 immer gibt, reagiert dieses Teil. Bei der Verdrahtung kann das nur noch IO2 sein. Macht das Basic irgendwas damit?

    Die Datenbits stimmen definitiv, bei den Adressbits könnte noch ein Fehler in der Tabelle oder dem Schaltbild sein, die Verteilung der 0xff-Blöcke sieht ein wenig komisch aus.

    Naja, ich hab' so meine Zweifel, dass der Computer starten kann. Wenn wirklich das Kernal beim Power-up schon eingeblendet wird, dann stehen alle drei Vektoren (reset, IRQ, NMI) auf $ff00, wo nur zu lesen ist:

    Code
    FF00   48         PHA
    FF01   08         PHP
    FF02   AD 0D DC   LDA $DC0D
    FF05   28         PLP
    FF06   68         PLA
    FF07   40         RTI

    Da wird fröhlich auf einem nicht-initialisierten Stack 'rumgeackert und eine Rücksprungadresse per RTI abgeholt, die wahrscheinlich irgendwo ins Nirwana zeigt. Da steckt mehr hinter - weiß jemand, ob das Original-Kernal in $dfxx herumsaut?

    Jens

    Bitte schön.

    Danke schön :smile:

    Ein paar Fragen:
    Sind die Pins 1 und 19 des LS244 wirklich NICHT verbunden?
    Wo sind die zwei Kondensatoren?
    Ist R2 wirklich nur an der einen Seite an Vcc und an der anderen Seite am Input des Inverters?

    Meiner Meinung nach kann das Teil so nicht funktionieren. Ein bischen Beschriftung an den Leitungen wäre schon schön, sonst hat man beim Lesen des Schaltplans in etwa die gleiche Arbeit, wie beim Reversen der Platine (Bahnen verfolgen). Ich hab' trotzdem schon ein bischen was gefunden:

    Der LS30 kodiert wirklich Kernal aus, und zwar hübsch sauber mit Phi2 und BA (bus available vom VIC). U1a und U1b bilden wirklich ein RS-Flipflop, das gesetzt und gelöscht werden kann. Der Ausgang des Flipflops schaltet die (dynamische) Ultimax-Anforderung ein/aus (das passiert in U2A). Der invertierte Ausgang des RS-Flipflops geht an das Eprom und könnte als Bank-Umschaltung gemeint sein, aber das klappt so nicht, da das Eprom in dem Fall gar nicht selektiert wird (war hier mal ne Erweiterung vorgesehen?).

    Ein Zugriff (egal ob Lesen oder Schreiben) auf den $dfxx-Bereich schaltet das Modul aus. Dabei ist IO2 sauber mit Phi2 gegated, also werden die Glitches des alten C64 ignoriert, so wie's sein soll. Im Aldi-64er sind diese Glitches übrigens nicht mehr vorhanden.

    Zum (wieder-)einschalten muß der Ausgang von U1C low werden. Seltsamerweise ist hier nichts schaltungstechnisches vorgesehen, was einen definierten Zustand beim Power-On festlegt. base2khid, kannst Du da nochmal gucken, ob die Reset-Leitung noch irgendwoanders hingeht?

    Scheinbar ist da noch mehr unvollständig, denn so richtig kann ich noch nicht erkennen, was da mit dem Zähler und den Gattern abgeht. Der Zähler bekommt Phi2, zählt also mit 1MHz. Drei Bits des Zählers werden benutzt, die async-Reset Leitung wird irgendwie mit dem Ausgang gegated, sieht also so aus, als ob ein Puls von vier CPU-Takten gebildet wird. Leider erkenne ich keinen Auslöser eines solchen Impulses. base2khid, bitte nochmal checken, ob IO2 nicht noch an mehr Pins geht als nur an den Input von U1D. Vielleicht geht aber auch der Ausgang von U1D noch irgendwoanders hin?

    *ab hier wilde Mutmaßungen*

    Das Gate U2D ist momentan mein größter Kandidat für den Software-Impuls zum Wieder-Einschalten (bzw. Power-on-Status), denn auch da ist ein Input nur mit einem Widerstand gegen 5V gelegt (pull-up). Vermutlich ist das ganze Konstrukt dafür da, dass mit einem Zugriff auf $dfxx der Modul-Zustand gekippt wird (von an nach aus oder von aus nach an). Mit dem Zähler wird das Set-Signal 4 Takte lang gehalten, so dass auch mit einem Basic-Poke der Zustand eingeschaltet werden kann (merke: Basic-Poke macht immer zwei Zugriffe in Folge). Ausschalten ist dann in Basic nicht.

    Jens

    Edit: Neue Mutmaßung. Ein Einzelner Zugriff schaltet das Modul ab (z.B. LDA $df00). Ein Read-modify-write Zugriff schaltet es wieder ein, weil dann IO2 innerhalb von vier Zyklen zwei mal low geht (z.B. INC $df00).

    Da fällt mir noch was auf: Das Design hat keinen einzigen Abblock-Kondensator. Ich kann mir nicht vorstellen, dass das in Serie so gefertigt worden ist. Oder hat Dela auf die Weise "Geld gespart" und ist dann wegen Garantieansprüchen nahe der Pleite gewesen?

    Jens

    Übrigens haben meine Dela Module das gleiche Symbol und eine 5-Stellige Artikelnummer (z.b. 86653)

    ...und Du wohnst sogar in der Stadt, in der Dela damals gewesen ist. Irgendwie habe ich nur noch im Kopf, dass Rex den Laden gekauft hat, aber frag' mich nicht, wer damals hinter Dela steckte. Ich hatte auch einen Dela II Prommer mit so einem lustigen handgeklebten Layout, aber Rex hat die Designs nach und nach auf CAD umgestellt - damals mit NewIO auf dem Amiga.

    Hat jemand alte 64er Zeitschriften zur Hand und blättert mal nach Anzeigen "kurz vor der Dela-Übernahme"? Vielleicht ist das eins der letzten Module das die entwickelt haben? Mir ist es auf jeden Fall NICHT geläufig.

    Jens

    hab das so gemacht. (siehe anhang) habs aber schon verglichen mit dem kernel, sind jedoch identisch.

    OK, dann schauen wir mal die Leiterbahnführung genauer an:

    A0 bis A7 sind korrekt am Eprom angelegt, demnach kann man immer ganze Pages korrekt lesen.
    A8 des C64 liegt an Pin 2 an, wo das Eprom eigentlich A12 hat.
    A9 des C64 liegt an Pin 21 an, wo das Eprom eigentlich A10 hat.
    A10 des C64 liegt an Pin 23 an, wo das Eprom eigentlich A11 hat.
    A11 und A12 verschwinden nach zwei Durchkontaktierungen unter dem Sockel des Eproms, da bräuchte ich nen Durchgangspiepser um zu wissen, wo die hingehen. Nach Blick ins Binary und das Pinout des Eproms sind die beiden mit Pins 24 und 25 des Eproms verbunden. Wenn das Layout einigermaßen straight ist, dann ist:
    A11 an Pin 24 (Eprom A9)
    A12 an Pin 25 (Eprom A8 )

    Das zeigt auf jeden Fall schonmal, dass die Adressleitungen wild vertauscht sind, und dass man sich ein Programm schreiben sollte, mit dem die Binärdaten aus dem Eprom wieder zurecht gewürfelt werden müssen.

    Datenleitungen sind was schwieriger, da ist fast gar nichts zu sehen auf den Fotos. Wahrscheinlich ist da auch noch was verwürfelt. Es führt wohl kein Weg dran vorbei, das modul mal komplett zu strippen und zu reversen.

    Jens

    Da ist übrigens ein Krönchen und die Zahl 87761 am Rand - evtl. ein Modul von Rex Datentechnik?

    Das Krönchen von Rex sieht anders aus, außerdem hatten die 4-stellige Artikelnummern. Zudem wage ich zu behaupten, dass Rex so etwas kompliziertes wie eine dynamische Modul-Abschaltung nicht konnte. Deren Designs waren in Sachen Komplexität weit darunter angesiedelt. Nur wenn sie Dinge zugekauft haben (Jann Datentechnik, Dela), haben sie kompliziertere Dinge gebaut.

    Wenn wir weiter über die Zahl orakeln wollen (wollen wir das wirklich?), könnte die 87 das Jahr sein. Wann kam Exos? Wie schnell ist der Fastloader? Mehr 6-fach (also Hypra-Load) oder mehr in Richtung 14-fach (Exos)?

    Ich verspreche mir vom Auslesen des Moduls mit dem Basic-Programm eigentlich am meisten, denn damit können unsere Software-Profis sicherlich die Fastloader-Routine isolieren und uns sagen, was die wirklich kann.

    Jens

    ich habe nur keine idee wie ich denn vernüftig auslesen könnte, sodass man damit was anfangen kann.

    Einschalten, dieses Programm laufen lassen:

    Code
    10 FOR I=0 to 8191
    20 POKE 8192+I,PEEK(57344+I)
    30 NEXT

    SMON laden, Bereich von $2000 bis $4000 abspeichern, dann hier posten. Oder hat das Modul sogar einen eigenen Monitor?

    Wenn meine Vermutung stimmt, liegt ein anderes Kernal im Bereich $e000, das irgendwie über $df00 diese Einblendung abschaltet und so mehr Kompatibilität erreicht, als andere Kernal-Replacements am Expansionsport.

    Jens

    Der LS244 ist als Datenbustreiber geschaltet. Dabei ist interessant, dass die Datenleitungen scheinbar nirgendwoanders hinzeigen, also kann zwar gelesen werden, aber nicht geschrieben. Oder anders: Falls man Schreibzugriffe im Rom findet, ist nur die Adresse, nicht aber die Daten relevant.

    Von den 16K im Eprom sind nur die ersten 8K genutzt. Möglicherweise ist die Verdrahtung vom Eprom zum LS244 ein bischen verdreht, so dass nur Mülldaten zu sehen sind. Vielleicht sind auch Adressleitungen invertiert (LS04!) oder vertauscht, dann kommt noch mehr Müll beim Auslesen per Prommer 'raus.

    Die Adressleitungen A13, A14 und A15 gehen zusammen mit PHI2 und R/W in Richtung LS30 - das riecht sehr verdächtig nach Kernal-Auskodierung. Das Rom wird also bei Lesezugriff auf $e000-$ffff eingeblendet.

    Die beiden LS00 riechen nach RS-Flipflop; man erkennt, dass ein Ausgang eines Gates mit dem Eingang eines anderen Gates verbunden ist. Vermutlich ist die zweite Rückverbindung unter dem Chip. Außerdem ist die Select-Leitung von $df00 an einem der LS00 angeschlossen, wahrscheinlich wird das Modul damit ein- und ausgeschaltet (oder nur ausgeschaltet, wenn der Ladevorgang beendet ist).

    Das mich verwirrt ist der Zähler (LS93), aber um den zu erklären, müsste man wahrscheinlich das Modul komplett reversen. Wenn jemand einen Schaltplan zeichnet, würde ich die Software-Doku daraus erstellen. Alternativ würde es ausreichen, wenn jemand alle Teile 'runterlötet und die Platine von beiden Seiten fotografiert, dann könnte ich den Schaltplan zeichnen, ohne die Hardware hier zu haben.

    Es ist auf jeden Fall mehr als "nur ein 8K/16K Rom Modul". Vermutlich aber nicht viel mehr.

    Jens