-
Offene DEL-Files gibt es eigentlich nicht. Ein entsprechender File Type von 0 signalisiert, dass der Directory-Entry unbenutzt ist.
Das hat mich tatsächlich auch schon gewundert. Ich werde mal noch etwas im Programm und in der Literatur rumwühlen! 
Also, meine Recherchen haben Folgendes ergeben:
Filetyp $00
- Wird nicht im "normalen" Directory angezeigt
- wird bei nächster Gelegenheit überschrieben
- wird vom DOS durch den Scratch-Befehl erzeugt
Filetyp $a0
- Wird im normalen Directory als "DEL" angezeigt
- wird durch Abspeichern *nicht* überschrieben
- Wird vom DOS nicht angelegt, sondern muss händisch erzeugt werden
Ja, mit "offen" hat das alles eigentlich nichts zu tun. Aber die Kennzeichnung mit Stern ist dennoch praktisch, um sichtbare DEL-Files von "unsichtbaren" zu unterscheiden. Man könnte natürlich speziell dafür noch ein anderes Symbol verwenden.. 
Alles anzeigen
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).
-
Also, in X-Dir wird nichts sortiert. Es fällt mir aber auf, dass die DEL-Files bisher immer am Schluss kamen. Vielleicht sortiert das DOS das ja von sich aus so?
Nein, eine 1541 hat gar nicht genug RAM um ein Directory maximaler Länge zum Sortieren im Speicher zu halten.
Im RAM meinte ich auch nicht, sondern dass vielleicht die Verlinkung auf der Disk entsprechend angepasst wird?
Aber das kann man ja testen!
Antwort: Stimmt nicht, die Position der DEL-Files ganz unten war also nur Zufall. 
Alles anzeigen
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
-
Dazu hab ich eine "Historisch passende" Maschine hergenommen und ein kleines Video draus gemacht.
Die Saba 600SH kommt selbst aus den späten 60er Jahren, also voll aus der Zeit dieses Bandes.
Ist der YouTube-Ton von der Saba oder der Studer?
-
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.
-
Vermutlich ab 7 Stunden 45 Minuten kommt was zu hören! 
Kurz vor Ende: „Hatte ich zurückgespult? Ach, wird schon passen. Hier also die umfangreiche Beschreibung, wie man an meinen vergrabenen Goldschatz kommt: Räusper… *click*“
-
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.
-
Und was Handy angeht, geht der Begriff auf zurück.
Ich dachte das kommt aus dem Schwäbischen: "Hen di koi Schnürle dran?" 
-
Für Jump'n'Run oder Shoot'em Up-Spiele wird TSB (oder eine andere BASIC-Erweiterung) niemals geeignet sein.
Vielleicht für Schweb und Schleich-Spiele ?
-
Ich habe mich schon ein paar Mal gefragt wo die maximale Spiele Größe liegt.
Mit einer 16 MB Speichererweiterung hätte man doch viel mehr Möglichkeiten?
Da wären doch sogar Filmsequenzen im Spiel möglich?
Koalavideos zb.
Labyrinthe könnte man doch mit 3Sek Videos lösen. Links ,rechts, gerade aus wären dann nur einzelne Kapitel im Video.
Oder stelle ich mir das leichter vor als es ist ?
Alles anzeigen
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
-
Das speziell für einen Befehl einzuführen fände ich fürchterlich inkonsistent. Und es für alle Befehle zu machen wirft jede Menge Fragen zu den Defaults für die weggelassenen Werte auf. Dabei ist die Lösung so einfach: einfach Variablen für alle drei Farben mitführen.
-
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).
Alles anzeigen
Vielleicht hast du mich missverstanden? Ich bezog mich auf die Cartridge-Programmierung - nicht auf dein Kernal-Replacement. Oder ist da ein Zusammenhang?
Alles anzeigen
Pardon, da habe ich tatsächlich nicht genau genug gelesen . 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).
-
Sehr schön, vielen Dank für die Mühe!
-
Vielleicht müsste man mal eine verbesserte Version von Simons‘ Basic erstellen, in der solche Fehler korrigiert sind. Ich hätte schon eine Namensidee: FSB für „Frisiertes Simons Basic“ .
-
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.
-
Für das Behandeln eines transparenten Characters in der momentanen Lösung bräuchte man ja theoretisch nur 4 Bytes:
cmp #SPEZIALCHARDASUNSICHTBARBLEIBT
beq nix_poken
-
Oder schauen, dass das Sample auf dem Wert 15 endet (was quasi das gleiche ist, wie Endurion s Vorschlag)?
-
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 .
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.).
Alles anzeigen
