Könnte man ja mit dem "german tank problem"-algo recht genau schätzen.
Für die insgesamt gebauten hat das mist64 ja schon mal vorgerechnet.
Mich würde aber interessieren, wie du da die nicht mehr funktionsfähigen herausrechnen willst.
Posts by strik
-
-
es ist aber auf jeden Fall richtig, daß die Systemmeldungen ("FOUND ...", "SEARCHING FOR ...") im Programmmodus ausgeschaltet sein sollen.
Nicht zu vergessen der "I/O ERROR #" Fehler, den die meisten gar nicht kennen oder je gesehen haben...
-
Die Abfolge JSR $A659/JMP $A7AE in Beitrag #4 führt nun genau die Routinen im Interpreter aus, die RUN ohne Parameter auch ausführen würde, ist aber nicht darauf angewiesen, daß der Stack wie gerade beschrieben präpariert ist. Heißt also: Geht. Tut. Funktioniert.
Du hast recht, ich hatte mir RUN nicht genau genug angeschaut. Irgendwo im Hinterkopf hatte ich noch, dass es etwas anders macht, ich hatte es bloß nicht mehr im Kopf.
Ich habe aber auch nicht behauptet, dass ein JSR die Lösung ist.
Ich habe nur behauptet, dass dort die Routine steht. 
Dein Ansatz hat aber noch eine Schwäche: Es vergisst, das Programm-Modus Flag zu setzen, welches in $A871 als erstes gemacht wird. (LDA #0, JSR $FF90). Je nachdem, in welchem Modus man vorher war (wie also das Maschinenspracheprogramm aufgerufen wurde), kann das überflüssig sein oder nicht.
Und je nachdem, was das Programm macht, kann es zumindest die Ausgabe zerhauen, wenn es falsch steht.
-
Im C64: $A871. Beachte aber, dass es testet, ob danach noch eine Zeilennummer kommt. Daher sollte das Z-Flag beim Einsprung gelöscht sein, weil er sonst die Zeilennummer lesen will (mittels CHRGET)
-
Auch wenn das Problem wohl gelöst wurde hier noch eine Antwort, da ich direkt angeschrieben wurde:
Naja, wenn "formatieren" klappt, würde ich "schreiben" explizit annehmen.
Außer vielleicht, man formatiert eine bereits formatierte, leere Disk erneut. ( strik
)Da könnte ich mir vorstellen, dass genau das verifiziert wird. was erwartet wird und daher der Fehler nicht erkannt wird, wenn nicht geschrieben werden kann.
Es ist kompliziert.
Grundsätzlich erfolgt beim Formatieren natürlich ein Schreiben. Die Original-Routine in der 1541 misst zuerst die Länge der Spur aus, indem die Hälfte mit $FF und die andere mit $55 vollgeschrieben wird. Erst, wenn damit die Länge der Spur gefunden wurde, wird der Track geschrieben. Wenn also gar nichts geschrieben werden kann, wird das Formatieren dort schon fehlschlagen.
Andererseits ist der abschließende Test, ob die Spur korrekt geschrieben wurde, meiner Meinung nach fehlerhaft und kann viele fehlerhaft geschrieben Spuren gar nicht feststellen.
Andere Formatierroutinen (die hier aber wohl nicht benutzt wurden) schreiben einfach die Spur. Manche machen gar kein Verify, die würden vermutlich gar nicht merken, wenn die Disk schon formatiert war und gar nichts geschrieben werden konnte. Andere machen ein Verify; wenn sie dies "richtig" machen sollte dann auffallen, dass nicht der geschriebene Inhalt auf der Disk steht.
-
Ein alter Laptop mit Win8.1 32bit (Win10 & Win11 erzeugten Treiberprobleme) war schnell installiert
Win10 & Win11 Treiberprobleme kenne ich nur von externen, fehlerhaften oder veralteten Anleitungen. Sollte mit 0.4.99.104 nicht auftreten.
-
Bei Flachbett-Scanner geht es nur bei den ersten paar Seiten gut, sobald es dicker wird bzw. Richtung Mitte geht, wird die Handhabung immer schlechter .
NB: Es gibt Flachbett-Scanner mit Bücher-Kante.
-
Das hat hat die KI auf Deine Frage (wenn ich sie richtig formulierte habe) geantwortet. Es würde mich interessieren ob sie auch bei Deiner Frage richtig gelegen hat.
"U1:0" liefert ein Statusbyte? Wäre mir neu.
-
Aber gibt es vielleicht noch eine andere Möglichkeit?
Hängt natürlich davon ab, wofür.
Die 154x und 157x sind sich sehr ähnlich, da könntest du die Schreibschutz-Lichtschranke direkt abfragen ($1801 Bit 4) (aus der Floppy heraus, wohlgemerkt)
Die 1581 und CMD FDx000 nutzen einen MFM-Kontroller, da müsste man den programmieren. Kein Hexenwerk, aber aufwendiger.
Andere Laufwerke (IEEE wie 8050, 8250, 4040, x03x usw.) sind dann wieder etwas anders zu handhaben.
Ansonsten wäre eine Möglichkeit, per Jobschleife einen Block zu lesen und danach direkt wieder zu schreiben. Das bringt bei einem Schreibschutz einen eigenen Fehlercode ($08).
Wenn es natürlich "moderne" Datenträger sind, dann wird es noch komplizierter.
Also: Wirklich universell ist nur der Schreibversuch, man kann allerdings auch vieles mit Fallunterscheidung anders machen.
-
So ich habe jetzt nochmal die 9 Zeilen eingetippt, mit run gestartet, dann kam wieder 00,ok,00,00 hab auf enter gedrückt und dann kam wieder 31 Syntax error,00,00
Ready
Zeile 80 ist falsch abgetippt:
Beachte das "N:" vor dem DISKNAME, das fehlt bei dir.
-
Das Problem beim C64 ist wenn man das Directory lädt wird der Basic Speicher gelöscht und das soweit ich weiß auch wenn es fehlschlägt.
BASIC wird nur gelöscht, wenn das Lesen schon begonnen wurde und er erst dann abbricht, z.B. weil ein Sektor auf Track 18 (154x/157x) nicht mehr lesbar ist.
Wenn er gar nichts lesen kann, bleibt das BASIC-Programm erhalten. Das dürfte der überaus häufigste Fall sein. -
50 GOSUB 10 : A=1
Bitte umdrehen:
sonst gibt es eine Endlossschleife, bis der Stack voll ist.
-
Hast du dein Laufwerk nach dem erfolglosen Laden ausgeschaltet?
Die Meldung 73,CBM DOS ... kommt nämlich nur nach einem RESET (es gibt eine Ausnahme, die interessiert hier aber nicht).
Beim nächsten Mal sollte "00, OK,00,00" kommen.
Und nach dem erfolglosen Laden vermutlich etwas "20, ..." oder "21, ..." oder irgendetwas anders, das mit "2" beginnt. Diese Zahl ist hier das wichtige.
Falls du das Laufwerk nicht selber neu gestartet hast, dann scheint es selber in einen RESET gelaufen zu sein - oder es denkt, dass die Diskette nicht zum Laufwerk passt.
-
Nur spare ich mir eben pro Jahr gefühlte 5 Millionen ./
Da stellt sich mir die Frage: Was machst du, dass du so häufig Programme im aktuellen Verzeichnis ausführen musst?
Ich brauche das vor allem bei Skripten sowie selbst-kompilierten Programmen bzw. während der Entwicklung, ansonsten beinahe überhaupt nicht. Dabei lebe ich hauptsächlich auf der Kommandozeile. Mounts werden bei mir auch gerne mit noexec angelegt, womit eine Ausführung auch mit ./ gar nicht möglich ist. -
Ich komme aus der Nähe von Wolfsburg, also durchaus aus der Nähe. Ich bin aber leider eher ein SW-Mensch als ein HW-Mensch.
Ich könnte aber notfalls mit Quertauschen beim Suchen der Fehlerursache helfen, würde aber jemandem, der mehr Ahnung von der HW hat, auch den Vortritt lassen.
Die Frage nach der Kommunikation halte ich aber auch für wichtig.
Was gibt denn das folgende Progrämmchen, welches den Fehlerkanal ausliest, aus:
Bitte nach dem Einschalten der Floppy aufrufen, dann nochmal, und dann nach einem erfolglosen Leseversuch noch ein drittes Mal...
-
Bitte bei der ganzen Sache bedenken: Falls von einer Diskette Abrief auf dem Kopf ist, kann jede Diskette, die danach in das Laufwerk gesteckt wird, schon beim Leseversuch zerstört werden!
Also bitte jetzt nicht wahllos mit verschiedensten Disketten rumprobieren, vor allem nicht, wenn dir der Inhalt der Disketten wichtig ist.
-
Dann Schreib halt PATH=./:$PATH in deine ~/.bashrc und werde glücklich.
Dann aber bitte nicht vergessen, auch LD_LIBRARY_PATH=./ zu setzen, sonst wird es langweilig. War ja lange sehr beliebt unter Windows.
-
Und was liefert ein "sudo lsmod|grep hp_wmi" zurück?
NB: lsmod sollte auch ohne sudo anstandsfrei funktionieren.
-
- Da habe ich mir dann von dieser GitHub Seite die Treiberdatei runtergeladen und diese dann in Windows im Gerätemanager zugewiesen. Dadurch wurde das XUM richtig erkannt.
- Dann habe ich mir die Software "opencbm-0.4.99.104" vom internet runtergeladen und mir auf meinen Desktop gelegt. in diesen Ordner kann ich dann über Windows cmd zugreifen, wenn ich in dieses Verzeichnis "amd64" gehe, gibts die ganzen Befehle um zu lesen, schreiben etc....
Die Treiberdatei runterladen sollte man nur unter Windows XP. Ansonsten bitte diesen Schritt überspringen! Sonst läuft man Gefahr, an der Signierung von Windows-Treibern zu scheitern.
-
Also ZoomFloppy und gleichzeitig TapeXUM könnte Probleme verursachen?
Ich will nicht sagen, dass es unbedingt Probleme geben muss. Ich habe nur ein bisschen reingeschaut und habe festgestellt, dass der Autor von TapeXUM sich nicht viel Mühe gegeben hat, Probleme abzuwenden. Ich investiere aber auch keine Zeit von mir um herauszufinden, ob es Probleme gibt.
Er hat einfach Werte genommen und denen eine Bedeutung gegeben, die von mir zwischenzeitlich anders vergeben wurden. Eine einfache Mail hatte gereicht und man hätte das koordinieren können. Das war ihm den Aufwand aber wohl nicht wert...
