Posts by 1570

    Schonmal ein paar Werte aus VICE (64'er Speed Test):


    1541: Überall 1x
    Jiffy+1541: Format 3,7x, SAVE 2,54x, LOAD 9,84x, SEQ schreiben 2,2x, SEQ lesen 5,3x, REL anlegen 1,14x, Validate 1,26x, Scratch 1,25x, Datentransfer 4,2x.
    FC3+1541: Format 1x, SAVE 5,4x, LOAD 9,34x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1x, Validate 1x, Scratch 1x, Datentransfer 1x.
    FC3+Jiffy+1541: Format 3,7x, SAVE 2,6x, LOAD 10,4, SEQ schreiben 2,2x, SEQ lesen 5,31x, REL anlegen 1,14x, Validate 1,26x, Scratch 1,25x, Datentransfer 4,2x.
    AR7.5+1541: Format 1x, SAVE 7x, LOAD 15,3x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1x, Validate 1,3x, Scratch 1,3x, Datentransfer 1x.
    AR7.5+Jiffy+1541: Format 3,7x, SAVE 7,6x, LOAD (file not found), SEQ schreiben 2,4x, SEQ lesen 2,37x, REL anlegen 1,14x, Validate 1,36x, Scratch 1,3x, Datentransfer 4,2x.


    1581: Format 2,3x, SAVE 2,15x, LOAD 1,31x, SEQ schreiben 2,4x, SEQ lesen 1,34x, REL anlegen 14x, Validate 11,2x, Scratch 10x, Datentransfer 1,13x.
    Jiffy+1581: Format 2,3x, SAVE 6,37x, LOAD 19,54x, SEQ schreiben 8,11x, SEQ lesen 11,18x, REL anlegen 14,22x, Validate 11,2x, Scratch 10x, Datentransfer 6,55x.
    FC3+1581: (nicht unterstützt)
    AR7.5+1581: Format 2,3x, SAVE 11x, LOAD 16x, SEQ schreiben 2,4x, SEQ lesen 1,34x, REL anlegen 14x, Validate 11,2x, Scratch 10x, Datentransfer 1,13x.
    AR7.5+Jiffy+1581: Format 2,3x, SAVE 11,3x, LOAD 16,7x, SEQ schreiben 7,89x, SEQ lesen 11,34x, REL anlegen 14,22x, Validate 11,4x, Scratch 10x, Datentransfer 6,55x.


    Dummerweise läuft der Test nicht auf einem DTV (benutzt Time of Day-Timer des CIA, die auf dem DTV nicht implementiert sind), sonst hätte ich mal das MMC2IEC-Jiffy damit ausprobiert.


    Die Format-Werte sind Quatsch, weil vom 64'er-Test bei den Cartridges nicht die beschleunigten Routinen aufgerufen werden.


    Man sieht ganz gut, dass die Cartridges LOAD und SAVE beschleunigen, sequentiellen Zugriff (EE13/CHRIN) aber nicht. Das widerum kann Jiffy machen. Leider funktioniert anscheinend die AR7.5+Jiffy+1541-Kombi nicht, ansonsten wäre das wohl insgesamt recht fix.


    Wenn in in x64 allerdings - ohne Speed-Test - mit 1541+Jiffy LOAD abstoppe, komme ich eher auf 6x. Komisch.

    Dankeschön. Kannst du hier nochmal kurz erklären was du jetzt gepatch hast ?

    Naja, bei der Division, die zum Errechnen des Speed-Faktors gemacht wird, wird halt ggf. eine Division durch Null abgefangen und einfach Null zurückgeliefert. Nichts Spannendes. x1541 hat schon recht, bringt eigentlich nichts, was man durch den anderen Start nicht auch machen könnte, aber vielleicht kann ja das eine oder andere Laufwerk kein LOAD, dann würde der (ungepatchte) Test da mit Division durch Null aussteigen ;). Nicht dass man mit so einem Laufwerk was Sinnvolles machen könnte ;).

    Jetzt müssen wir das nur noch mit der Software regeln ...

    Angehängt eine gefixte Version des 64'er-Speed-Tests. Gibt bei zu kurzer Zeit "0" als Speed-Faktor aus. Ggf. könnte auch das noch auf "1" umbiegen, damit der Gesamtfaktor hinkommt, aber der ist ja eh' eher zum Spaß da.


    VICE/x64 mit "True Drive Emulation" liefert übrigens überall praktisch genau Faktor 1. Dessen Timing ist also offensichtlich ziemlich genau.

    CHRIN bedeutet genau was ? Also wenn du da was schreiben könntest, wäre das ne feine Sache.

    Das ist die Kernal-Routine, die ein Byte vom Bus holt. Ein LOAD macht wie gesagt normalerweise nichts anderes als OPEN/38437xCHRIN/CLOSE. Unseen meinte gerade, dass der 64'er Speed-Test das beim SEQ-Geschwindigkeitstest machen sollte. Mit welchen Laufwerken soll das denn nicht gehen?

    Nachladesachen sind in erster Linie zu aufwendig das Messtechnisch zu erfassen da ja nicht nur Kernelroutinen genutzt werden.

    Also die Geschwindigkeit von CHRIN lässt sich einfach testen und beeinflusst sehr wesentlich die Nachladegeschwindigkeit bei entsprechenden Spielen. Wenn's dafür nicht schon einen Benchmark gibt (weiß ich nicht) bastele ich auch gerne ein entsprechendes Programm, das muss ja nichts anderes machen, als Kernal-OPEN/GET/CLOSE aufrufen, und in Form des Kernal-LOADs gibt's das ja auch schon ;). Bzw. ich könnte ggf. auch eine Nachladeroutine aus einem Spiel auskoppeln (hatte damit beim DTV-Patchen häufiger zu tun). Wobei man dann vermutlich auch direkt irgendwelchen Dreamload-Democode nehmen kann :).

    Wir wollen die Vor- und Nachteile grafisch darstellen sodass Kaufinteressenten sich ein genaues Bild der Eigenschaften der einzelnen Hardware machen können.

    LOAD alleine ist dann aber nicht sonderlich aussagekräftig, da es z.B. von den meisten Multiload-Spielen gar nicht genutzt wird - die benutzen entweder eigene Routinen (dann ist man mit der meisten nicht-1541-Hardware schlecht dran) oder die Kernal-Standardroutinen. Letztere wiederum werden z.B. von Jiffy beschleunigt, aber von den Steckmodulen nicht. Nicht zu vergessen, dass Jiffy z.B. mit der demnächst kommenden MMC2IEC/sd2iec-Firmware beim LOAD 20fach erreicht, aber z.B. mit einer 1541 bei 6fach herumdümpelt, während andere Speeder da viel höhere Geschwindigkeiten erreichen - hat mit der limitierten Rechenleistung der 1541 zu tun.


    Also: LOAD testen, SAVE testen, CHRIN testen (Kernalroutine für Multiloader), den Sonderstatus von Jiffy nicht vergessen, vielleicht noch kurz Format und andere Aktionen testen. Ich kann beim Test an sich leider nicht helfen (habe nur MMC2IEC hier), aber kann gerne ansonsten beim Artikel mithelfen.


    Ah übrigens, dass der serielle Bus an sich langsam ist, ist übrigens ein Märchen. MMC2IEC schafft damit in der Praxis mit einem speziellen Speeder (aber ganz normal am seriellen Bus und an einem C64) 40fach und hat Potential für mehr.


    Ein paar Texte zum Thema (hatte ich gerade letztens dran gewerkelt):
    http://www.c64-wiki.com/index.…t_is_MMC2IEC.27s_speed.3F
    http://www.c64-wiki.de/index.php/Schnelllader

    Du kannst Dir einfach von Spiffs Website die Spiele holen, die Du haben möchtest (die Originalspiele gibt's da ja inzwischen auch) und LSMenu oder DTVSlimIntro dazu; das Ganze mit dtvmkfs zusammengeklatscht, ggf. in x64dtv getestet, geflasht und fertig. Etwas genauer ist das im DTV Hacking-Wiki beschrieben. Das Originalmenü wegzuwerfen ist schon deswegen eine gute Idee, weil bei DTVSlimIntro ein Palettenwechsler dabei ist; die Original-Farbpalette beim DTV ist ziemlicher Mist.

    Rechtlich ist das kein Problem, alle DTVTrans-Varianten stehen unter einer BSD-ähnlichen Lizenz.


    TULF kann übrigens nicht mit langen .prgs umgehen, soweit ich herausfinden konnte; zumindestens ließen sich die Programme schon nicht von Floppy laden, und das Original-DTV-Menü kommt damit soweit ich weiß auch nicht klar. Ich hätte mir das mal angesehen, aber zu TULF gibt's keinen Quelltext.

    Was machst Du denn mit einem C64, wenn Du noch keine Hexeditoren kennst? ;)


    Kleine Anleitung: Im DTVMON-Readme steht, dass die "- DTVBOOT..."-Signatur an $0009 steht. Wenn Du einfach die DTVMON_ROM.PRG im Hexeditor aufmachst, siehst Du aber vermutlich, dass sie an $000B anfängt (mit dem Cursor draufgehen und die angezeigte Adresse ansehen). Das ist die Verschiebung um zwei Bytes, von der tlr im Readme spricht. Kommt, weil die Startadresse (00 40 = $4000) noch ganz vorne davorsteht, wenn man sich die Datei und nicht die *geladene* Datei (im Speicher des DTV) ansieht.


    Also einfach $1d+2=$1f und $24+2=$26 entsprechend ändern.

    DTVMON kommt nach $1F8000 bis $1FAFFF (ist eigentlich etwas kürzer, spielt aber keine Rolle), der Alternativkernal nach $1FE000-$1FFFFF (jeweils inklusive). Woher Du andere Adressen hast, weiß ich nicht ;).


    Für das Ändern der Voreinstellungen brauchst Du keine Maschinensprachenkenntnisse, sondern nur einen Hexeditor Deiner Wahl. DTVMON_ROM.PRG öffnen, zur im README beschriebenen Stelle gehen, neuen Wert reinschreiben, save, flashen.


    Nein, die Ram-Version habe ich zwar am Anfang auch mal ausprobiert, habe aber danach die Flash-Version gestartet.
    Es kam auch der Hinweis mit der Installation im Flash.


    Die DTVMON_ROM.PRG lässt sich gar nicht so starten, da sie bei $4000 anfängt, da kommt also natürlich auch kein Hinweis irgendeiner Art.


    Wenn Du die DTVMON.PRG (also die RAM-Version) startest, kommt ein Hinweis, dass DTVMON sich bei $018000 installiert hat. Das heißt aber eigentlich "DTVMON hat sich nach $018000 im RAM kopiert" und hat insbesondere mit $1F8000 im FlashROM nichts zu tun.


    Bei sowas einfach sehr genau lesen... :)

    Kann man einen bereits gepatchten Kernal zwecks einer kleinen Änderung direkt noch einmal patchen,
    oder sollte man den DTV vorher wieder in den Auslieferungszustand (mit dem original Kernal) bringen
    um dann erneut den Kernal zu patchen?

    Ersteres. Direkt neu flashen, jedenfalls sofern der gepatchte Kernal mit tlrs Kernalpatcher erstellt wird.

    Wird dtvmon beim Start direkt geflashed, so dass man es immer wieder verwenden kann?
    Laut Doku habe ich das so verstanden, bin mir aber jetzt nicht mehr so sicher.
    Denn nach ein paar Neustarts meines DTV ist dtvmon verschwunden.
    Es lässt sich jedenfalls mit Feuerknopf und gleichzeitigem Reset nicht mehr aufrufen.

    DTVMON/DTVBOOT muss im Flash bei $1F8000 liegen, damit es vom gepatchten Kernal erkannt und ggf. gestartet wird. Funktioniert das nicht, ist die Signatur bei $1F8000 kaputt. Vermutlich hast Du die RAM-Version gestartet, die ist natürlich spätestens nach Aus/Ein futsch (Reset überlebt sie aber). Selbst flashen (ohne tlrs Flash-Programm o.ä.) tut sich da nichts.

    Wie integriert man auf einfache Weise einen alternativen Kernel (z.B. den von Peiselulli) in dtvmon?

    Man flasht ihn nach $1FE000.

    Für mich liegt daher die Vermutung nahe, daß der Programm Code auf dem Flash-Eprom beschädigt worden ist (durch was auch immer). Mein nächster Schritt wird also sein, daß ich mit dtvtrans neue Firmware aufspiele.

    Würde ich dann auch vermuten. Versuch' doch erst, das ganze ROM per dtvtrans rd 0x0-0x200000 brokenrom.bin auszulesen und dann in x64dtv/VICEplus zu testen. Wenn da die gleichen Fehler auftreten, ist's klar. In jedem Fall erstmal Finger weg von 00xxxx! Also nix Kernal neu flashen oder so, bis Du nicht sicher bist, dass sich das Flash vernünftig neu beschreiben lässt. Lieber erstmal ganz am Ende des Flashes testen.

    Jiffy-Unterstützung ist in sd2iec so gut wie fertig. Geschwindigkeit ist ziemlich gut, siehe MMC2IEC-Seite. Bei Jiffy sollten die Chancen, dass das auch ohne Quarz (also der 1.6) läuft, ganz gut sein (ist noch ungetestet), und mit 20facher Originalfloppygeschwindigkeit kann man doch leben, oder? ;)

    Die Menge des Speichers, die Pointer verbrauchen, ist bei dieser Speichermenge absolut vernachlässigbar.
    Ich meine, die Pointer machen schon beim Programmcode nur einen geringen Anteil aus. Und der Programmcode selbst nur ein Bruchteil von den meisten geladenen Programmen. Der Rest geht an Daten, Grafiken, Icons oder was weiß ich.
    Ich kenne aber keine Statistik, aber es würde mich wundern, wenn bei einem Programm, das geladen etwa 10MB verschluckt, mehr als 40kb durch Pointer belegt sind.

    Kommt halt aufs Programm an. Bei Graphik mag es egal sein, aber Programme, die z.B. mal eben ihre 4 Byte-Integers als verkettete Liste speichern, brauchen dann eben mal ein Drittel mehr Speicher ;). Jedenfalls kenne ich Fälle, in denen z.B. 2GB in 32 Bit gerade knapp wurden, mit 64 Bit aber das Ganze auch erst mit 4 GB wieder Spaß machte. War aber auch nicht gerade sauberster Code ;).

    Hatte es Vorteile, auf 64 Bit zu gehen?
    Zunächst einmal hatte es von der Geschwindigkeit hier keine Nachteile gehabt.
    Allerdings sind in meinem Rechner jetzt schon 4 Gig Speicher drin und ich hätte gerne noch mehr. (ja, die nutze ich auch tatsächlich aus!)

    Würdest Du ihn auch unter 32 Bit ausnutzen? Da Pointer bei 64 Bit doppelt so groß sind wie bei 32 Bit, braucht so manches Programm unter 64 Bit deutlich mehr Speicher...

    Öhm, Du fragst, wie Du ein Datentransferkabel testen kannst? Mal Daten übertragen und schauen, ob sie stimmen? :)
    Schnapp' Dir irgendein .prg irgendwoher, dann dtvtrans auf DTV-Seite starten und "dtvtrans wr programm.prg" auf PC-Seite, dann ESC beim DTV und LIST/RUN.
    Alternativ auch "dtvtrans rd r0x0-0x1fffff flashrom.bin" zum Auslesen des ganzen ROMs des DTVs, das kannst dann im Hexeditor ansehen oder per "x64dtv -c64dtvromimage flashrom.bin" in VICEplus ausführen. Beim Transfer sollte der Bildschirmrahmen beim DTV schön bunte Streifen anzeigen.


    Keine Befehle außer "dtvtrans sync" fassen das FlashROM schreibenderweise an.