letzter Beitrag von darkvision am
Erst die Datei normal öffnen, dann mit dem "B-P"-Befehl den Lesezeiger auf Offset 0 setzen, ein Byte lesen, mit "B-P" den Zeiger auf Offset 1 stellen, wieder ein Byte lesen, Datei schließen. Jetzt hat man den ersten Linkpointer und kann die restlichen Blöcke per U1 lesen.
Wenn ich das so mache, dann erhalte ich Track 1, Sektor 8, also Loadadresse $0801. Das hilft mir nicht weiter.
Oder wie ist das gemeint "Erst die Datei normal öffnen" ?
Vom IDE64 Directory-Aufbau habe ich keine Ahnung. Die "CMD-HD, RL, FD-2000" Im Nativemodus, sollten einen identischen Directoryaufbau haben. Bei der "1541, 1571, 1581" funktioniert das Einlesen.
Ich werde mich dann mal an die Arbeit machen.
Besteht die Möglichkeit, einen IFFL-Scanner für soetwas zu nutzen. Letzendlich zählt eine Routine dieser Art auch nur Bytes.
Hatte auch direkt an so etwas gedacht, aber leider viel zu wenig Kenntnisse, um so etwas selber zu programmieren oder so anzupassen, dass es unabhängig einsetzbar wäre. Innerhalb von etwas über einer Umdrehung der Disk kann man von einem Track rein technisch betrachtet genug lesen und mehr oder weniger gleichzeitig an den C64 übertragen, um die Track/Sector-Chains und beim jeweils letzten Sektor eben noch die Anzahl Bytes ermitteln zu können, um so auf die Gesamtlänge zu kommen.
Versuch macht klug... jedenfalls halbwegs.
B-P mit Kanalangabe funktioniert nun wenigstens für die Track, nicht aber für den Sektor ?
Was mache ich noch falsch ?
Tut mir leid, mein Fehler. Nach dem Lesen des ersten Bytes muss die Datei geschlossen und wieder geöffnet werden, dann kann man das zweite Byte des Links lesen.
(ich nehme an, das hängt damit zusammen, dass man ja von einer Stelle liest, von der im Normalbetrieb eben nicht gelesen würde, und das DOS setzt für diesen Buffer dann irgend ein Unterlauf/Überlauf-Flag oder so)
Was mir gerade noch einfällt: Nach dem Lesen des zweiten Bytes hat man das Problem nicht, die darauf folgenden "normalen" Datenbytes kann man problemlos lesen. Die brauchst Du zwar nicht, aber vielleicht heißt das, dass es anders herum klappt: Erst auf Offset 1 positionieren und das zweite Byte lesen, dann auf Offset 0 positionieren und das erste Byte lesen. Vielleicht kann man dann das Datei-Schließen und Neuöffnen weglassen. Aber auch wenn man schließen und erneut öffnen muss, einfacher als Verzeichnisse zu scannen ist es allemal.
Einfach die komplett belegten Sektoren zählen und vom letzten Sektor dasBbyte $01.
Ich habe mal mein Software Archiv durchsucht. Hier ein Byte-Counter für den C128 im 80-Zeichen Modus glaube ich. Ich bekomme das Teil nicht zum Laufen.
Vielleicht hast du mehr Erfolg und eventuell kannst du es gebrauchen.
Dann könnte man auch IF c$=f$ THEN machen.
Nein, weil in c$ die chr$(160) am Ende vorhanden sind. Da muss du f$ mit CHR$(160) auf 16 auffüllen. Dann ja.
mit LEFT$ hat man dann das Verhalten "test*" ...
3 open 15,8,15:open8,8,8,f$:print#15,"b-p 8 0":get#8,t$:close8:close15
4 open 15,8,15:open8,8,8,f$:print#15,"b-p 8 1":get#8,s$:close8:close15
Warum denn das?
Da muss doch auch
open 15,8,15:open8,8,8,f$:print#15,"b-p 8 0":get#8,t$,s$:close8:close15
reichen ... 
Zumindestens zählt das Programm die Bytes, so wie ich mir das vorgestellt habe. Alle vollen Sektoren mal 254 plus den Rest.
200 print"qfirst block in file: "pg+sq
205 print"qtotal full blocks: "b1" = "b1*254" bytes"
210 print"qtotal bytes in partial block: "b2" = total program bytes: "bc
215 ifft=130thenprint"qplus two bytes for the load address"
220 end
Jetzt wo das Prgramm so gut funktionierte, habe ich das mal am U64 mit SoftIEC ausprobiert. -> funktioniert nicht. 
Mal sehen wie sich das am SD2IEC verhält.
Da muss doch auch
open 15,8,15:open8,8,8,f$:print#15,"b-p 8 0":get#8,t$,s$:close8:close15
reichen ...
Hatte ich auch zuerst gedacht. Aber das ging so nicht. Es war immer ein falscher Wert für den Sektor in s$.
Erst wenn das File geschlossen, neu geöffnet und neu positioniert wird, funktionierte es wie erwartet.
Mal sehen wie sich das am SD2IEC verhält.
Auf dem SD2IEC ausserhalb eines DiskImages... vermutlich das gleiche Problem. Der befehl "U1" funktioniert nur innerhalb von DiskImages, im Verzeichnis einer SD-Karte eher nicht.
Wenn sich SoftIEC wie VDrive/VICE verhält, dann liegt es da auch am "U1"-Befehl...
Kann bei dem SoftIEC oder dem VDrive die Track- oder Sektorennummer höher als 255 ausfallen, wie beim IDE64?
Kann bei dem SoftIEC oder dem VDrive die Track- oder Sektorennummer höher als 255 ausfallen, wie beim IDE64?
U1 funktioniert bei VICE/VDrive und SD2IEC im Verzeichnis-Modus gar nicht, da kannst Du erst gar keine Blocks einlesen. Vice meldet glaub ich Fehler "30, SYNTAX ERROR"... das SD2IEC "20, READ ERROR(?)". Ich vermute SoftIEC funktioniert da ähnlich. Zumindest bei VICE/SD2IEC bin ich mir aber sicher, da ich den Fehlercode auswerte wenn ich solche Laufwerke suche/identifizieren muss.
Oder gibt es noch andere (bessere) Möglichkeiten ?
Wenn sd2iec die exakte Dateigrösse kennt, liefert es diese modulo 254 in einem Byte im Directory-Listing zurück, das müsste zusammen mit der Blockanzahl reichen um die exakte Länge ausrechnen zu können. Das gilt allerdings nur für das Dir-Listing als BASIC-Programm, nicht für das Rohformat (Sekundäradresse > 0).
Ich bin mir nicht sicher ob das jemals wer ausprobiert hat, aber es steht seit Jahren im README (Zeile 254)
Kurze Rückmeldung zum SoftIEC vom U64. Eine 100 Diskblocks (25393 Bytes) Datei zu lesen dauert knapp 3 Sekunden -> akzeptabel
Fehlt mir nur noch, wie ich SoftIEC erkennen kann.
SD2IEC muss ich mir dann heute Abend mal ansehen. Erkennung ist da kein Problem, sollte also auch in ein paar Zeilen machbar sein.
Hat denn einer von euch ein IDE64, mit dem er die letzte Version aus Post#46 mal ausprobieren kann ?
Ich habe leider selbst kein IDE64.
Fehlt mir nur noch, wie ich SoftIEC erkennen kann.
Produziert ein U1-Befehl da auch eine Fehlermeldung? D.h. Befehlskanal öffnen, Datenkanal öffnen, U1 senden, Fehlerkanal abfragen.... ich kann's nicht testen, hab noch eine alte Firmware auf dem U64.
Ich bin mir nicht sicher ob das jemals wer ausprobiert hat, aber es steht seit Jahren im README (Zeile 254)
Zeile 914 Ich hatte mir das sogar nochmal durchgelesen (wegen B-P ausserhalb DiskImage) und hab die Stelle auch gesehen, konnte aber damit nichts anfangen.
