Posts by Diddl

    Hi


    Sorry, hab das Zeugs nicht mehr im Einsatz, hab jetzt überall MeGALoDOS im Einsatz.


    Aber soweit ich mich erinnern kann war das ganz simpel gestrickt.


    Am c64 4 mal 8kb und in der 1541 halt 4 mal 16K. Und das wird immer gleich geschaltet, also Kemal 1 bis 4.


    Die EPROM haben halt 4 Blöcke hintereinander im EPROM.


    C64:

    Kernal 1: 0000 - 1FFF

    Kernal 2: 2000 - 3FFF

    Kernal 3: 4000 - 5FFF

    Kernal 4: 6000 - 7FFF


    1541:

    DOS 1: 0000 - 3FFF

    DOS 2: 4000 - 7FFF

    DOS 3: 8000 - BFFF

    DOS 4: C000 - FFFF

    Weißt du, was so richtig cool wäre? Eine modernere Version der Karte mit weit weniger Bauteilen- allerdings nach wie vor THT only und vor allem kein Spezialzeug, also nix CPLD oder andere, sehr doofe Bauteile, die kein Normalsterblicher programmieren/benutzen kann. :D

    Genau mein Gedanke.


    Das schreit nach GAL.

    Die sind THT und man kann sie mit jedem TL866 programmieren.

    Das COMAL wäre mein Haupt-Begehr.

    COMAL-80 ist wirklich klasse!!

    Ich finde es ist die beste Programmiersprache für den C64.


    Es gibt auch ein eigenes COMAL-80 für den Commodore c128.


    Für das UC-2 gibt es eine Hybrid COMAL Variante.

    Damit kann man COMAL im c64 Modus und COMAL für den c128 auswählen. :)



    Aber noch rufen der C900 und yalsi mit der LOAD... :neinnein:

    Der C900 ist wirklich ein Traum! :crazy:

    Das Universal Cartridge Modul UC-2 ist ein universell verwendbares Modul für den C64 und c128:

    Universal Cartridge 2 –



    Dank CPLD kann man das UC-2 Modul auch für andere Dinge einsetzen:

    • MagicDesk
    • EasyFlash
    • MultiMax
    • COMAL-80

    Dazu muss man nur ein anderes JEDEC File in den CPLD programmieren.



    Nun steht ein neues JEDEC zur Verfügung, mit dem man ein UC-2 verwandeln kann in das beliebte PageFox Modul:

    Universal Cartridge 2 –

    Ich halte nichts davon, so einen schönen, original erhaltenen und unverbastelten C64 durch einen Kernalumschalter zu verschandeln.

    Nun ja das ist Geschmacksache.


    In meiner Jugendzeit sind alle C64 meiner Freunde mit diversen Schalter und Taster "verbessert" worden.

    Unverbastelte C64 gab es keine in meiner Welt.

    Für mich ist das Normalzustand.



    Mal davon abgesehen gibt es Kernelumschalter die mit dem C64 Keyboard funktionieren.

    Da muss man das Gehäuse des C64 nicht anrühren.


    Zb. von Faszination C64:

    https://www.ebay.at/itm/164236515370

    Naja vor allem beim C64 wäre ja das Problem behoben gewesen weil der ja CIA statt VIA verwendet.


    Und doch hat man den Burstload da nicht implementiert.

    Sonst würde man zumindest mit den 1571 und 1581 Laufwerken schnell laden können.


    Tja Commodore halt...

    Nun zu meiner Frage, lohnt sich der Umbau muss was ausgetauscht werden und ist das einfach so machbar..?


    Jiffy lohnt sich definitiv!

    Speziell wenn man ein SD2IEC verwendet.



    Ausgetauscht werden muss das Kernal ROM im C64 und das DOS in allen Laufwerken.



    Oh ja es ist einfach machbar, wenn die alten ROM gesockelt sind.

    Ansonsten muss man die ROM auslöten.



    Umschalten zu normalen Betrieb ohne Jiffy ist möglich, ja sogar Standard.

    Notwendig ist es nicht.

    Denn mit Jiffy läuft praktisch fast alles ohne Probleme, es ist sehr kompatibel.



    ACHTUNG:

    Für Jiffy werden Lizenzkosten fällig!

    Weil das Ding heute noch immer verkauft wird.


    Jim Brain hat die Rechte auf Jiffy erworben und verkauft Jiffy in zwei Varianten:

    • Jiffy mit Hardware, also einfach ROM raus Jiffy rein (ist schaltbar)
    • Jiffy ohne Hardware, man zahlt eine geringe Summe, ein paar Euro und bekommt das File für ein EPROM zum selber brennen

    Die Lizenz ist pro Computer bzw. Laufwerk zu zahlen.

    Wenn man zwei 1541 und einen C64 hat, sind das drei Lizenzen.

    Aber die paar Euro lohnen sich wirklich!

    Gut das wäre ja schnell ermittelt, wie lange ein Fetch beim Char ROM dauert.

    Speicheroszi oder LA am /CS des Char ROM und mal eine Rasterzeile aufzeichnen.


    Der VIC hat ja sowieso maximal 480 nS Zeit (PHI1 Phase).

    Und da muss er aber viel mehr tun als nur Char ROM lesen.

    Hauptsächlich RAM Zugriffe.


    Wenn Sprites oder Grafik hinzu kommen, dann bleibt es ja nicht bei der PHI1 Phase.

    Dann zwackt der VIC auch Zeit von der CPU ab.

    Dafür spart er sich dann aber CHAR ROM Zugriffe.


    Nun ja, der VIC stresst den Bus schon ganz schön, jedenfalls viel mehr als die CPU.

    Die Firmware auf den 29F040 kannst du auch vom VC-20 aus programmieren.

    Die Spielesammlung auf dem 29F040 kannst du dynamisch hinzu fügen, vom VC-20 aus.


    Der Atmega enthält die Firmware des SD2IEC.

    Fuses sind Einstellungen am ATMEGA, also Flags wenn man so will.

    Clock Teiler und so weiter.

    Jeder Programmer der den ATMEGA flashen kann, der kann auch die Fuses setzen.

    Die 5V sind schon mal da, gut.


    wenn er vorher lief kann es auch nur eine Kleinigkeit sein:

    - alle gesockelten IC vorsichtig raus ziehen und wieder rein drücken, evt. die Kontakte reinigen



    Ansonsten, PLA ist schon mal ein häufiger Fehler.

    Manchmal frisst es die RAM Chips.

    Es ist schon auch mal ein ROM defekt, in deinem Fall müsste es das Kernal ROM sein, sonst gäbe es zumindest einen blauen Hintergrund.

    Ein neuer PIC.


    Der alte PIC funktioniert wahrscheinlich auch.

    Nur ist der halt nicht programmiert.


    Ich kann es nicht testen, weil der neue sich nicht auslesen lässt.

    Es war in der Tat der PIC.

    Wahrscheinlich einfach unprogrammiert, weil der Blanktest sagt: device ok, blanktest ok


    Der neue PIC zeigt nur Nullen beim auslesen.

    Also protected.


    Auf die Platine gesteckt und läuft, tadellos. :)

    Könnte man nicht einfach kleine ESD Tütchen nehmen (oder Notfalls auch Alufolie) und jeweils eine handvoll damit "einrollen" und dann in einen Umschlag stecken? Das wäre wahrscheinlich die kostengünstigste Verpackung.

    Ja so wäre es richtig.



    Aber Fakt ist, diese Dinger sind von Haus aus unverwüstlich.


    Die Chinesen schicken diese GAL in Kunststoff Säckchen.

    Noch nie war eines defekt.


    Ich hab die schon verkehrt rum in den Sockel gesteckt.

    Und falsch verdrahtet.

    Und falsches Jedec eingespielt.

    Die GAL werden höchstens ein bisschen warm und das war es auch schon.

    Mir ist noch keiner gestorben bisher.

    Hi, natürlich gibt es schon eine C64 PLA Ersatz PCB mit diesen PLCC Chips... :0)

    Cool.

    Allerdings ist das SMD und kein PLCC.




    Ich verwende die GAL Ersatz Konstruktion in allen meinen C64


    Normale PLA und auch die PLS100 / 82S100 werden leider immer wieder kaputt.

    Das ist mir mit der GAL Lösung noch niemals passiert.

    Die ist unverwüstlich und extrem kompatibel (Zaxxon Test).



    Zudem wäre ein GAL preisgünstig zu tauschen.

    War aber wie gesagt noch nie der Fall bei meinem Bekannten Kreis und mir selbst.

    ich hätte mehrere Tausend Gal 20V8 in PLCC.

    Nun ja, ich setze die GAL sehr sehr gern ein.

    Ich liebe diese kleinen Dinger.


    Bisher habe ich nur 16v8, 22v10 und ATF750 in Verwendung.

    Etwas erschwerend ist, dass PLCC nicht ohne weiteres in meinen Programmer passt.

    Aber ein Adapter dürfte das beheben.

    Für Nachbauer ist es aber jedenfalls ein Hindernis.


    Ein paar tausend würde ich bis zu meinem Lebensende nicht aufbrauchen können.

    Aber mit ein paar "zig" könnte ich mich anfreunden, wenn der Preis passt.


    Entwickelnde(r)NameDatumPlatformKurz-ErläuterungDetail-LinkArt: Neuentwicklung, Clone / Re-Implementation, Verbesserter Fork, ...
    MicrotronicHamburg / LambdaMikelTalker/802020TRS-80 1, III & 4Sprachsynthesizer für TRS-80 (DECTalk, TRS Voice Synthesizer & VS-100 Emulation)https://github.com/lambdamikel/Talker-80Neuentwicklung
    DiddlUC-1
    UC-1.5
    UC-2
    2021C64, c128Voll konfigurierbares Modul mit SRAM und EPROMhttps://oe7twj.at/index.php?title=Universal_CartridgeNeuentwicklung

    Ich hatte keine Ahnung dass der Dripke sein geniales ExBasic II auch für außerhalb der Commodore Welt implementiert hat.


    Mir hat das ExBasic II immer sehr gut gefallen.

    Speziell am 8032, weil da gab es ja nicht so viele Alternativen.



    Nun ja ein ExBasic am Apple wäre genial wenn es zumindest Sourcecode kompatibel wäre.

    Es würden alle Programme die auf POKE und SYS verzichten ohne Änderung am Apple laufen.


    ExBasic setzt ja stark auf BASIC 2 des Commodore, im Grunde ist es ja nur eine Erweiterung des BASIC 2 bzw. BASIC 4.


    Insofern ist die Apple Version vermutlich nicht kompatibel sondern was ganz eigens.

    Dass es nur 8KB groß ist, unterstützt die Vermutung.

    Es wäre ja rechtlich auch problematisch, ein Commodore BASIC 2 am Apple zu betreiben ...