Wie jetzt, kommt der C65 gar nicht mehr?
Posts by Claus
-
-
Es scheint mir seltsam warum Microsoft dieses <GO> Token implementiert hat.
Meine Vermutung ist, dass es aus historischen Gründen existiert. Basic basiert ja auf Fortran II, und dort sind Leerstellen zwischen den Zwei-Wort-Befehlen optional. Sucht man nach Fortran-Programmen, findet man daher eine lustige Mischung aus "GOTO" und "GO TO". Vermutlich wollte man es Fortran-Programmierern besonders einfach machen. Ob man den Platz im vollgestopften BASIC ROM nicht besser für etwas anderes hergenommen hätte erscheint allerdings fragwürdig
.
-
Der letzte zählt aber nicht
Grummel, ja ihr habt ja recht, ich wollte halt auch mal was cooles zu Basic schreiben, wenns schon sonst so uncool ist
-
Es müsste aber GOTO 0.5 heißen ...
Dann wärs ja nicht *zwischen* den Zeilen
.
EDIT: also naja, hast schon recht...
-
Einen hab ich noch: man kann auch zwischen die Zeilen springen
-
Jaja, der alte Trick, Bugs als gewollte Features zu verkaufen. Mach ich auch immer so: "Der Programmaufruf mit einem nicht-unterstützten Parameter wird extra behandelt und dem Benutzer durch die Ausgabe eines Segmentation Faults signalisiert."
-
Keine Ahnung wem das oben beschriebene was nuetzt, einige werden es kennen, einige andere werden Tools wie C64Studio benutzen, aber wer wie ich mit normalen Text-Editoren und Linux-Terminals unterwegs ist, dem wird das vielleicht eine Hilfe sein.
Mach ich ganz genauso. Ich habe noch ein "break .break" in der moncommands.txt, so dass ich im Source schnell mal ein ".export break=*" einfügen kann für einen Breakpoint in ca65.
-
Wer? ICH? Ich weiß von nix!!
-
Die zweistellige Disk-ID nicht vergessen! Sonst werden lediglich BAM und eine leere Directory geschrieben.
Danke, hatte ich verschusselt und habs oben nachgetragen!
-
Das ist dann ohne Verify oder?
Doch, die Originalroutine beschreibt die gesamte Diskoberfläche und testet sie, besser als jedes "normale" Verify. Z.B. deckt dies auch die Bereiche zwischen den Sektoren ab, wo nach einem späteren Fast Format wiederum Daten liegen könnten. Außerdem vermisst sie die Spurlänge und verteilt die Sektoren gleichmäßig, das kann sinnvoll sein wenn das formatierende Laufwerk nicht die korrekte Drehgeschwindigkeit hat. Tatsächlich ist die Originalroutine zwar saulangsam, aber nicht ineffizient. Alles was sie macht ist schon sinnvoll und auch nicht unnötig lahm (im Gegensatz zur originalen Load-Routine). Wenn Du die Zeit hast, würde ich sie definitiv empfehlen. Je nach Zahl der Disketten verstehe ich aber natürlich auch, wenn man die Zeit nicht investieren will
. Da kann ein Schnellformat mit Verify dann ein guter Kompromiss sein.
-
-
Also kein Fast Formater nutzen sondern Open 15........... ?
Ja, die originale Routine testet die Diskette sehr ausführlich, wenn die durchläuft ist sie mit sehr großer Sicherheit in Ordnung. Schnellformatter testen weniger bis teilweise gar nicht.
-
Gibt es Software mit der man die Disketten testen kann, oder eine Art Routine, mit der man an "alte" Disketten ran geht?
Meinst Du die Diskette selber testen, um sie mit neuen Daten zu beschrieben, oder die existierenden Daten auf der Diskette auf Lesbarkeit testen? Für ersteres ist die originale Formatierroutine bestens geeignet (wenn auch nicht besonders schnell).
-
Die Krücke ist halt, dass man am Anfang des Programmes detektieren muss, dass es nach dem Ladevorgang neu gestartet wurde und abhängig davon irgendwo hinspringen muss, anstatt dass nach dem Laden einfach die nächste Zeile ausgeführt wird. Beide Lösungen sind natürlich eigentlich Krücken
-
Ah, hab den Grund: Die Archive dürfen nicht länger als 127 Blocks sein, sonst kommt entweder Mist dabei raus oder der Exomizer verweigert.
Also ich habe testhalber gerade mal Gianna Sisters mit Exomizer mit "sfx basic" gepackt, was ein 177 Block großes Archive ergibt. Das funktioniert problemlos.
-
Das Dolbi (Rauschunterdrückung), das nur mit CrO2 Sinn macht, dürfte dafür verantwortlich sein.
Ist das so? Ich dachte immer, Dolby (egal ob B oder C) wäre das egal? Aber CrO2 Bänder hatten auch sonst schon ein geringeres Rauschen, oder?
-
-
Das Claus SD2IEC Kernal unterbindet den Modulstart
Die Version 2.0 und 2.1 des sd2iec Kernals hatten einen Bug, so dass sie per Default den Modulstart verhindert hat (nicht wenn man Run/Stop gedrückt hält). In der Version 2.2 wurde das gefixt: https://csdb.dk/release/?id=159050
-
Läuft das dann nicht viel zu schnell?
-
Wenn ich das richtig gelesen habe, bezieht sich der Vergleich aber auf gehärtete Köpfe, die für Typ II Kassetten ausgelegt sind.
Tatsächlich weiß ich nicht, welches Kopfmaterial die Datasette enthält, aber da steht:
QuoteIronically, in spite of all its unsung technical benefits, chromium dioxide has suffered from a charge still widely accepted, that chromium dioxide is very abrasive to recorder heads. Particles of chromium dioxide are harder than ferric oxides, and their frictional characteristics are also different. Tapes coated with the magnetic powder of CrO2 particles produce less wear on mu-metal heads, which are the softest type and most likely to suffer wear damage.Also dass CrO2 weniger Abrieb auf weichen Köpfen erzeugt. Ob das auf Datasette-Köpfe übertragbar ist, hängt auch davon ab, ob diese aus Mu-Metall bestehen, vielleicht weiß das hier jemand?
Commodore selbst hat das nie zu den Datasettenköpfen gesagt und deren Empfehlung von Typ I Kassetten läßt einen anderen Schluß zu.
Ich denke als die Datasette rauskam, hat CrO2 einfach noch keine Rolle gespielt. Entworfen wurde sie also sicher für Typ I, aber ob das wirklich Rückschlüsse darauf erlaubt, dass Typ II den Kopf beschädigt?
Desweiteren wird kein Vergleich mit Typ I Kassetten aufgezeigt sondern mit den zwei Sorten von Typ II Kassetten.
Da hast Du wohl Recht, es geht in der Tat um einen Vergleich mit Ferric-Cobalt, nicht mit Eisenoxid. Da habe ich nicht genau genug gelesen.
Von daher sehe ich da keinen Widerspruch, eher die Bestätigung.
Eine Bestätigung kann ich aber auch dann nicht daraus ableiten
.