Nach einigen Missverständnissen ist das Ding nun nicht nur bei mir eingetrudelt, sondern ich weiß sogar davon
Werde mich wahrscheinlich am Freitag mal damit auseinandersetzen, ne Messung an der Umschalt-Logik zu machen.
Jens
Nach einigen Missverständnissen ist das Ding nun nicht nur bei mir eingetrudelt, sondern ich weiß sogar davon
Werde mich wahrscheinlich am Freitag mal damit auseinandersetzen, ne Messung an der Umschalt-Logik zu machen.
Jens
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
Ägypten? Rembrand? Kofferpacken?
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...
*$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 *
Alles anzeigen
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
U2.12 -> U7.13(D2)
"§$!$/&%*!* Datenbusverwürfelung. Klar, auf Eprom-Seite ist es D2.
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 ![]()
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:
FCEA D0 03 BNE $FCEF
FCEC EA NOP (Cartridge nicht anspringen)
FCED EA NOP
FCEE EA NOP
FCEF F0 09 BEQ $FCFA (mit dem BNE von $FCEA ist das ein BRA oder JMP)
---
FCF1 A9 FC LDA #$FC (Rücksprungadresse-1 für RTS in Stack ablegen)
FCF3 48 PHA
FCF4 A9 EE LDA #$EE
FCF6 48 PHA
FCF7 4C 3F E0 JMP $E03F (Modul aus und bei $FCEF das normale Kernal ausführen)
---
FCFA A2 FF LDX #$FF (hier gehts weiter bei Reset)
FCFC AC 02 DC LDY $DC02
FCFF 8E 02 DC STX $DC02
FD02 AE 00 DC LDX $DC00
FD05 A9 10 LDA #$10
FD07 8D 00 DC STA $DC00
FD0A AD 01 DC LDA $DC01
FD0D 8E 00 DC STX $DC00
FD10 8C 02 DC STY $DC02
FD13 C9 EF CMP #$EF
FD15 D0 03 BNE $FD1A
FD17 4C F1 FC JMP $FCF1 (kein Cart anspringen)
FD1A A9 FC LDA #$FC (Rücksprungadresse-1 für RTS in Stack ablegen)
FD1C 48 PHA
FD1D A9 EB LDA #$EB
FD1F 48 PHA
FD20 4C 3F E0 JMP $E03F (Modul wieder abstellen und Code bei FCEC fortsetzen, also Cart anspringen)
Alles anzeigen
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:
...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?
Ausschalten ist dann in Basic nicht.
Das ist natürlich Blödsinn, denn es gibt PEEK.
Jens
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:
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 ![]()
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:
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