Beiträge von Diddl

    Nun ja ...

    1. 32 Pins sind viel zu wenig
    2. nur 6 Pins können highvoltage sein
    3. die Spannung geht nur bis 22V
    4. Algos fehlen noch weitgehend


    Auf der Plus Seite

    1. offenes Design
    2. Arduino kompatibel



    Die Sache ist die, die perfekte Hardware gibt es ja schon öfters: Galep 5, T56, TL866 ...


    Man müsste "nur" die Dinger reverse engineeren und man hätte eine tolle Hardwrae Lösung.


    Und dann fehlt es aber immer noch an der Software.

    Wertvoll wird das erst wenn die ganzen Algos auch in Software unterstützt sind.

    Allein das kann viele Jahre brauchen.



    Alles in allem fährt man mit einem T56 oder einem GALEP einfach besser.

    Unterstützen die beiden echte Integer-Arithmetik? Das bringt in der Regel die meiste Geschwindigkeit, wenn man kein Floating-Point braucht.

    PETSPEED hat nicht nur Integer Arithmetik, es kompiliert sogar solche Dinge in echten Assembler.


    Austro-Comp hat, soweit ich weiß, keine Integer Arithmetik.

    Austro-Comp ist nach wie vor ein Interpreter.

    Er verwendet Token und führt die aus mit einem beigepackten Interpreter.

    Deswegen ist der auch so kompatibel.


    Allerdings ist der Token Stream hoch optimiert.

    Zeilennummer sind ersetzt durch echte Adressen.

    Syntax Prüfung entfällt und die Token werden direkt ausgeführt.

    Typ Prüfungen entfallen, es wird immer direkt der richtige Code angesprungen.


    Austro-Comp hat den Vorteil, dass die Code Größe sehr klein ist.

    Es hat zwar eine Runtime, aber je größer das Programm desto weniger schmerzt der Runtime Code.

    Also kleine Programme werden größer.

    Große Programme sind kompiliert kaum größer als der Source Code.

    Ich habe in meiner Jugend kommerzielle Software für den 8032 entwickelt.

    Da hatte ich PETSPEED zur Auswahl und eine Art von Austro-Comp, ich glaub der hat anders geheißen.


    Nun ja, richtig guten und sauschnellen Code macht nur der PETSPEED, der ist wirklich genial!


    ABER: PETSPEED ist nicht wirklich BASIC 4 kompatibel.

    Man kann nicht einfach ein beliebiges BASIC Programm "kompilieren und läuft".


    Der Austro-Comp schon.

    Fast jedes BASIC Programm das läuft kann man kompilieren und es läuft ein bisschen schneller.

    Vor allem hat der Kunde dadurch den Sourcecode nicht, das war auch ein Ziel.




    FAZIT:


    Der PETSPEED ist sehr gut, wenn man die Features kennt und die ganze Entwicklung auf PETSPEED auslegt.


    Der Austro-Comp ist gut, wenn man ein fertiges BASIC Programm hat und es einfach kompilieren will.

    Eine eche floppy und ein floppy Emulator hat bei mir nicht gut funktioniert.

    ??

    Sowohl echte Floppy als auch Gotek arbeiten tadellos bei mir.



    Es ist nur einfach so, dass es mit dem CoCoSDC einfach viel bequemer ist, weniger Platz braucht und keine Verkabelung etc.0

    Die RTC ist Bestandteil des SD2IEC.


    Der ATMEGA des SD2IEC bedient die RTC per I2C.

    Deshalb geht das setzen der Uhrzeit per Floppy Befehl.


    Wenn die Uhrzeit nach einem Reset oder ausschalten weg ist, dann kann das eines der folgenden Gründe haben:

    • der ATMEGA kann den RTC Chip per I2C nicht ansprechen (falsche I2C Adresse, Chip defekt, falsche SD2IEC Firmware ...)
    • der RTC Chip braucht eine Batterie Pufferung, möglicherweise ist da was faul?



    Das SD2IEC ist nicht von mir sondern von @UNSEEN im F64.

    Das SD2IEC ist ein ganz separater Teil im FE3.

    Eventuell einfach mal bei den SD2IEC Experten nachfragen.

    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

    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:

    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.

    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.