Posts by skoe

    Die NMOS-Logik (und HMOS) der 6xxx, 7xxx und 8xxx Familien haben Push-Pull-Transistoren an den Ausgängen, bis auf die Ausnahme unten.


    Dabei handelt es sich um Enhancement Mode N-MOS FETs sowohl für die High-Side als auch für die Low-Side. Deswegen sind die High-Pegel, wie Unseen schon sagte, auch nur etwa 5 V - VthGS = ca. 4V. Und die H-Flanken werden ziemlich flach, wenn der Ausgangspegel schon recht hoch ist. Dann wird logischerweise VGS immer kleiner und in der Nähe von 4V kann er kaum noch Strom liefern. Ein N-MOS-Transistor für obenrum ist halt ungünstig. Aber leichter zu fertigen als CMOS.


    die CIAs mit den "passiven Pull-Ups" haben oben auch einen FET, aber einen Enhancement Mode FET. Dieser hat die Eigenschaft, "immer an" zu sein. Der Nachteil ist, dass der Pull-Down-FET gegen ihn ankämpfen muss, was insbesondere für Bus-Treiber doof ist, weil so eine Stufe entweder schwach/langsam oder sehr stromfressend wäre.


    Für interne Logik werden fast ausschließlich die platzsparenden Enhancement FETs benutzt. Außer für große interne Signale und Busse, wo auch Push-Pull mit Depletion Mode FETs gemacht wird. Dort findet man auch oft Bootstrap-Schaltungen (war das der Name dafür?), also Ladungspumpen, die die Gate-Spannung eines FETs über 5V schieben können. Dann sind die H-Flanken auch schnell.


    HMOS ist letztendlich nur ein Marketingname. Wenn man vom Back-Gate-Bias absieht, ist diese Technologie technisch nämlich identisch, nur kleiner.


    Ein paar Quellen:
    https://en.wikipedia.org/wiki/Depletion-load_NMOS_logic


    Infos zum Begriff "HMOS", besonders Kapitel 4.2:
    http://skoe.de/docs/c64-dissec…64_pla_dissected_a4ds.pdf

    Oh, ich kann mich ja tatsächlich hier noch einloggen :)


    I added FC3 support to the EasyFlash 2 already in 2010. The sources are freely available for everybody who needs them (search for MODE_FC3):


    https://bitbucket.org/skoe/eas…eviewer=file-view-default


    There are still some remains in some EF3 sources even:
    https://bitbucket.org/skoe/eas…eviewer=file-view-default


    I ported it to EF3 too, but never released it because of the CPLD space issue and because I didn't want to maintain two CPLD images. Since the EF2 and EF3 are very similar, it's quite easy to port it.


    Peto74, yes, you have the same rights to use the EF2/EF3 sources as Unseen. You can derive a new work from it and release it for free or for money, whatever you want. As long as you fulfill the license terms, of course. For example you are not allowed to release modified source code w/o marking it as modified by you. Just read the license boiler plate carefully.

    Das "selten, aber dann ohne Probleme" hatte ich weggelassen, weil das kaum als zuverlässiges Ja oder Nein wertbar ist. Mhhh, wobei einige andere Antworten auch in die Kategorie fallen. Nunja, nachträglich füge ich das jetzt nicht mehr hinzu.

    Huhu,


    lange nicht mehr hier gewesen - sorry auch für nicht beantwortete Nachrichten. Gerade bin ich dabei, den Schriebs zum externen KERNAL zu aktualisieren. Dazu stellt sich die Frage: Wer benutzt diese Funktion ab und an einmal und kann etwas zur Kompatibilität sagen?


    Bitte unterscheidet klar die Kompatibilität der Funktion "externer KERNAL" und der Kompatibilität des KERNALs, der dort läuft. Mich interessiert natürlich ersteres. Gern auch mit Kommentaren zu den Antworten.


    Vielen Dank für die Rückmeldungen!

    Es kann also sein, daß es, ja nach Board, nicht nur wichtig ist, daß alles auf den Zyklus genau passiert, sondern auch wann innerhalb eines Zyklus Adressen und Daten auf dem Bus erscheinen und Steuerleitungen gesetzt werden.


    Definitiv. Das hat bei EF3 und realPLA auch eine Weile gedauert, bis alles gestimmt hat. Die Kisten sind manchmal ganz schön zickig, wenn etwas 100 ns früher später als bei den Original-Teilen kommt.


    Funktioniert die realPLA?


    Klar ;)

    Bevor hier aber der total-pillepalle-Eindruck entsteht: Die Herrausforderung dabei ist nicht das 99%-Implementieren der CPU, sondern das verlässliche und reproduzierbare Testen der 100%-Kompatibilität. "Opcode X macht Y" ist trivial, aber Randfälle wie (z. B.!) zyklengenauen Interrupts, besonders bei verschachtelten NMI und IRQ etc. verlangt schon ein gut durchdachtes Testen. Ansonsten wird es nicht lange dauern, bis Meldungen wie "Edge of Disgrace stürzt manchmal ab" kommen. Und dann such mal einer, wenn er nicht von Anfang an entsprechende Vorkehrungen getroffen hat... Und gerade die vorhandenen quelloffenen HDL-Cores haben da ihre Grenzen, weils an den Stellen nämlich keinen Spaß mehr macht.


    Irgendjemand hier im Forum müsste eigentlich ein Lied davon singen können.


    Trotzdem, 10 Jahre sind's nicht :)


    Nun klar, aber wenn du sowieso die CPU durch nen FPGA oder gar durch eine CPU ersetzt, müsstest du die illegalen Opcodes halt mitemulieren. -> so gut es geht halt. Da werden zwar immer noch physikalische Nebeneffekte auftreten, aber schlechter als z.B. im VICE kanns ja nicht werden.. (oder?)


    Genau, wenn man die 6502/10-Emulation in vice als Maßstab ansetzt, läuft im Prinzip schon alles. Und die wenigen Exoten, die im Vice nicht laufen, tun das mit hoher Wahrscheinlichkeit nicht wegen der CPU-Emulation.


    Ich sehe da Entwicklungszeiten von über 10 Jahren bis das 100% so wie eine originale 6510/8500 in einem C64 Board funktioniert...


    Ich nicht.

    Sowas hatte ich mal mit einem kleinen Cortex M0+ oder M3 (für die CPU-Emulation) und einem kleinen CPLD (für Tristate-Geraffel und so) angefangen. Das wäre im Gegensatz zu einem FPGA recht preisgünstig geworden und hätte etwa wie eine realPLA ausgesehen. Hab dann aber aus Zeitmangel und Projektsinnkrise wieder damit aufgehört. Denn: Die Dinger gehen doch selten kaputt und es gibt noch genügend Ersatz.

    Das gefällt mir auch gut! Wusste gar nicht, dass die Kanten nach dem Lasern noch so klar sind. Hatte gedacht, sie würden rauh aussehen.


    Das Logo hat damals Retrofan gemacht. Hab gerade einmal nach der alten Mail zu dem Thema gesucht. Er schrobte:


    Quote

    Ja, im Zusammenhang mit dem EasyFlash könnte ihr die Gestaltung von Logo und
    Label verwenden, wie ihr wollt.


    Das sollte ja hier der Fall sein :)

    Hallo!


    Wenn das gleiche EF mit anderen Flash-Bausteinen funktioniert, muss mit denen wohl was im Argen sein. Leider kann ich auch nur dazu raten, die mit V wegzulegen und welche ohne V zu suchen - oder andere mit V, wenn die's dann tun...)


    Viel Erfolg!

    Don't worry, everything is fine with your posting.


    The PCB looks well soldered. You tried a different RAM and different C64s already. The message you saw appears when the RAM cannot be read from or written to. For this test the RAM (obviously) and the logic chips must work (all except the 174). If you have, you could try to replace these logic ICs. Theoretically you could remove the flash ICs temporarily during the tests, until you pass the error message which complains about the non-working RAM. Additionally you could check all tracks on the PCB.


    Let us know if you are able to do this and what you found out.

    z. B. welche, die BASIC benutzen. Oder aus anderen Gründen das Modul vollkommen ausblenden müssen. Aber bevor ich Hand anlege: Wenn jemand mal testet, bei wie vielen Modulen das Ändern des CRT-Typs mittels Hex-Editor wie in dem anderen Thread beschrieben funktioniert, wüssten wir, ob es funktioniert.

    Weil jetzt schon mehrmals das Thema EF/EF3 und RGCD/MD-Kompatibilität aufkam:


    RGCD hat sich entweder bewusst oder unbewusst für ein anderes Format entschieden, obwohl (oder evtl. weil) damals mehrere 100 EFs in Umlauf waren. Das Format ist fast - aber nicht ganz - Ocean-kompatibel. Leider ist der Unterschied so unterschiedlich, dass man ihn nicht ignorieren kann.


    Das einzige, was ich machen kann ist, dass EasyProg den Typ akzeptiert und als Ocean behandelt. Dann funktioniert aber das "Kill-Bit" nicht. könnte trotzdem mit diversen Modulen funktionieren.

    Frag doch mal im Flohmarkt an. Dann bekommst Du sicher das eine oder andere Angebot. Aus eigener Erfahrung (z. B. die Sache mit den Netzschaltern damals) weiß ich, dass hier einige Leute genug Vorrat haben.

    Ein einfacher Nachbau ist gar nicht sooo kompliziert, aber ein guter: Die Characteristiken der I/Os müssen wenigstens halbwegs stimmen, damit diverse Peripherie ordentlich funktioniert. Unter 30 bis 40 Euro "Endverbraucherpreis" ist das nicht zu machen, und dafür sind gebrauchte noch zu billig. Aber vielleicht später ;)

    Nur für die Akten: Das USB-Testprogramm wird im nächsten EasyProg/EasyTransfer Release enthalten sein. Ich habe pcollins schon vor einiger Zeit eine Vorab-Version zugeschickt. Damit hat er auf seinem EF3 tatsächlich ein reproduzierbares Problem gefunden, das auf einen Lötfehler oder Defekt hindeutet. Ob sich das durch Umtausch/Nachlöten lösen ließ, weiß ich nicht.

    Ja, ich arbeite dran. Nur stört das Berufs- und Privatleben am Vorankommen :)


    Jedenfalls waren wir ja schon bei dem Punkt angekommen, dass Ferndiagnose ohne für den Fall passende Testfunktionalität nicht so sehr sinnvoll ist. Na dann frickel ich mal weiter...