Beiträge von Claus

    Hm, mir scheint es schon am sinnvollsten, die als frei markierten Dir-Einträge (File Type 0) gar nicht erst zu printen. Zum einen kann man sie ja tatsächlich nicht laden (die 1541 überliest sie), und zum anderen zeigen sie zwar noch auf einen Track/Sektor, aber der kann mittlerweile schon für irgendetwas anderes in Verwendung sein (z.B. einen Block mitten in einem anderen File enthalten).

    Offene DEL-Files gibt es eigentlich nicht. Ein entsprechender File Type von 0 signalisiert, dass der Directory-Entry unbenutzt ist.

    in Track 18, Sektor 0 werden auf eine mögliche "Geheimnachricht" durchforstet. Ist das ein reales Phänomen?

    Ja das wurde zum Teil genutzt. In meinen frühen Tagen haben wir dort unsere Mail swapping Adresse "versteckt", mit Hinweis im Intro ".... read the BAM...".

    Ist auch garnicht soo selten, und natürlich findet man das auch heute beim Einlesen alles wieder. Manche (moderne) Image Tools können nach sowas scannen.

    Z.B. das äußerst moderne (hüstel) cc1541, siehe hier: https://acoustic-velocity.com/cc1541/#cc1541_H

    aber 4,76 cm/s klang schon ziemlich verrauscht.

    Interessant. Ich habe keine Ahnung von Tonbandgeräten, hätte aber intuitiv vermutet, dass eine niedrigere Bandgeschwindigkeit sogar zu weniger Rauschen führt. Zumindest wenn man annimmt, dass Bandrauschen eine konstante Energie pro Zentimeter hat, denn dann würde die Rauschleistung bei höherer Geschwindigkeit ja ansteigen. Aber vielleicht stimmt das mit der konstanten Rauschenergie natürlich auch gar nicht.

    Die „bestmögliche“ Grafikqualität im Sinne von so wie die Darstellung von Grafik gedacht war bekommst Du mit einer Röhre. Ein Broadcastmonitor wie Sony PVM oder von Barco machen ein sichtbar besseres Bild als die Commodore-Monitore. Muss halt genug Platz da sein und die Bereitschaft, ihn zu reparieren oder zu ersetzen, wenn er mal kaputt geht.

    In 1-2 Diskettenseiten kriegt man schon eine Meeenge Content, wenn man es geschickt anstellt. Videos sind nun allerdings nicht die Stärke des C64, da hätte ich persönlich wenig Motivation.

    Ja, Zeit der Stille 2 ist nicht tot, aber es ist schon ein Brocken Arbeit, weil ich mir persönlich die Messlatte sehr hoch gesetzt habe. Leider kamen 2 Schicksalsschläge dazwischen, die meine Aufmerksamkeit weg von der Entwicklung gelenkt haben. Es ist halt ein Zeitvertreib, für den ich überschüssige Energie zur Verfügung haben muss. Aber das Leben geht weiter und irgendwann habe ich auch wieder mehr Zeit und Langeweile :). Zum Glück ist alles so gut dokumentiert, dass ich auch nach langen Pausen leicht wieder reinkomme.


    Edit: oh, leichte Themaverfehlung: ZdS ist ja kein Point&Click

    Pardon, da habe ich tatsächlich nicht genau genug gelesen :whistling:. Nein, für Cartridge-Programmierung hatte ich mich nur mit einem sehr sehr speziellen Problem beschäftigt und erinnere mich an keine speziellen Quellen.

    Hallo Claus.

    ich habe mich in den Ferien mit Cartridge-Programmierung beschäftigt

    Das wird für mich auch irgendwann interessant. Hast du empfehlenswerte Quellen dafür gefunden?

    Nicht wirklich, ich habe mich hieran durchgehangelt: http://www.unusedino.de/ec64/t…/misc/c64/romlisting.html


    EDIT: ach so, ich habe natürlich auch den Source zu meinem Kernal in der csdb angehängt, da kannst Du sehen, an welchen Stellen ich Code ersetzt habe (ist alles unter !if).

    FPGAs sind im Grunde nicht viel anders als Prozessoren. Sie sind nur viel flexibler und können z.B. Funktionen parallel ausführen, weshalb sie gerade in Sachen Timing komplexe Systeme besser abbilden können. Aber damit hat sichs dann auch schon, eine Emulation auf einem FPGA bleibt eine Emulation, die nicht per se „besser“ ist als ein Emulator auf einem PC.

    bringt aber nicht wirklich was

    Warum? JiffyDOS macht genau das beim abspeichern und das bringt messbar Geschwindigkeit (zumindest zeigen das Messreihen, die andere schon gemacht haben). Ist ja auch ganz logisch. Beim PC macht man das ja mit herkömmlichen Festplatten auch. Da muss der Kopf nicht so viele Bewegungen machen und das spart Zeit.

    Was macht JiffyDOS denn da genau? Dadurch, dass ja Zeit verbraucht wird, um die Daten von GCR zu decodieren und durch das Nadelöhr serielle Schnittstelle zu quetschen, wird für die CBM-Routinen z.B. ja ein Sektor-Interleave von 10 verwendet (siehe z.B. hier). Dadurch fallen Trackwechsel nicht so stark ins Gewicht wie man meinen würde. Natürlich ist es aber auch nicht ideal, wenn Sektoren sich abwechselnd auf Track 1 und Track 35 befnden :D.


    Das Programm von mist64 bringt nichts, wie er ja selber schreibt:


    Zitat

    For simplicity, we are just filling the disk linearly, starting with track 1, and not using an interleave. This doesn’t make the defragmenter very useful, because the disk might actually read more slowly after this, but it makes for a very clean visualization!

    Eine simple Methode zu defragmentieren wäre, alle Files mit cc1541 zu extrahieren und in ein neues Disk-Image zu schreiben. Geht aber natürlich nicht so gut, wenn das Directory irgendwie speziell ist (mit Directory Art etc.).