Kennt vielleicht jemand dieses Module?

Es gibt 45 Antworten in diesem Thema, welches 10.687 mal aufgerufen wurde. Der letzte Beitrag (7. Dezember 2017 um 23:34) ist von SubZero.

  • Ü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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Die waren damals bei Modulen wohl nicht in Mode: Bei dem sezierten Ocean-Modul war auch keiner drin. Aber im Layout vorgesehen.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Es führt wohl kein Weg dran vorbei, das modul mal komplett zu strippen und zu reversen.


    Bitte schön.

    Nicht schön aber selten :)

    Hat Subzero mit mir grad gemacht.

  • Nicht schön aber selten :)

    Hat Subzero mit mir grad gemacht.


    Sieht prima aus, daraus habe ich mal diese Zuordnungen abgelesen:

    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.

    Dateien

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • 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).

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

    Einmal editiert, zuletzt von Wiesel (9. Mai 2009 um 08:47)

  • 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 melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Ausschalten ist dann in Basic nicht.

    Das ist natürlich Blödsinn, denn es gibt PEEK.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • 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?

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

    Einmal editiert, zuletzt von Wiesel (9. Mai 2009 um 10:38)

  • Zitat von "Wiesel"

    Sind die Pins 1 und 19 des LS244 wirklich NICHT verbunden?


    Sind sie. gefixt

    Zitat

    Wo sind die zwei Kondensatoren?


    gefixt

    Zitat

    Ist R2 wirklich nur an der einen Seite an Vcc und an der anderen Seite am Input des Inverters?


    Ausser dem Kondensator, laut Messung, ja.

    Zitat

    Ist R2 wirklich nur an der einen Seite an Vcc und an der anderen Seite am Input des Inverters?


    Subzero misst noch Durchgang auf Eprom D1. hmm

    Zitat

    kannst Du da nochmal gucken, ob die Reset-Leitung noch irgendwoanders hingeht?


    Anscheinend nur auf U5 Pin 13, der ist aber laut Datenblatt NC.

    Zitat

    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?


    Anscheinend nicht.


    Hab dem Plan noch mal kurz überarbeitet, ausser der Verbindung R2 -> Eprom U7.D1


    gruss,
    und danke für´s Interesse

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Zitat

    Wer kommentiert die anderen Einsprünge?


    Also ich steig noch nicht so ganz durch :) Werde mir das auf jeden Fall noch genauer anschauen.

    Zitat

    Ich tippe auf D0 zum Gatter U2d.


    U2.12 -> U7.13(D2) -> D0 Exp.Port

  • U2.12 -> U7.13(D2)

    "§$!$/&%*!* Datenbusverwürfelung. Klar, auf Eprom-Seite ist es D2.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Ach du heilige Kamelhaardecke... und da behaupte nochmal jemand, die Kernal-Traps a la VICE wären nicht vorbildgerecht.

    Ich tippe übrigens nach Sichtung des Dela-Katalogs 1/88 auf das 'DELA DOS für C64/128', Bestell-Nummer 01007006 für 79 DM (zum Vergleich: andere Speeder/Universalmodule 30-40 DM, Expert Cartridge 140 DM)

    Das Modul hat nicht nur einen Turbo (8x LOAD, 3x SAVE), Centronics am Userport, F-Tasten-Belegung, Reseterweiterung, Hardcopyfunktion 'und vieles weitere', sondern es wirbt auch damit, daß Kassetten- und RS232-Routinen erhalten bleiben... letzteres klingt IMHO nach einer plausiblen Erklärung für das doch recht aufwendige Einblend-Verfahren mit dem Schattenrom.

    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.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Wiesel,

    leider funktioniert der p.code nicht. er bleibt bereits schon am anfang hängen.(noch for dem ändern des bildschirm randes) er stürzt regelrecht ab.

    den quellcode hab ich so abgetippt:

    Bitte melde dich an, um dieses Bild zu sehen. Quellcode

    *=$1000

    SEI

    LDA #$35

    STA $01 ;Ram unterm Kernal einschalten

    LDA #$20

    STA $FCEA

    STA $FCEB ;einen Vektor ablegen

    JMP (FCEA)

    *=$2020

    LDA #$01

    STA $D020

    JMP * ;damit man in Ruhe auf den Bildschirmrand gucken kann

    *=$0320

    LDA #$07

    STA $D020

    JMP *


    ist da ein fehler?

  • 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?

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

    Einmal editiert, zuletzt von Wiesel (12. Mai 2009 um 15:35)