Bytes aus File und Diskettengröße auslesen

Es gibt 24 Antworten in diesem Thema, welches 2.042 mal aufgerufen wurde. Der letzte Beitrag (29. September 2024 um 21:19) ist von WebFritzi.

  • Ich möchte gerne aus GUI64 heraus beliebige PRG-Dateien starten können. Mein Plan dafür:

    1. Auslesen der ersten zwei Bytes aus der PRG-Datei. Das ist ja die Adresse, an die die Datei mit LOAD"...",8,1 geladen wird.
    2. Den Code zum Laden und Ausführen der Datei irgendwo in den Speicher schreiben, wo er von der geladenen Datei nicht überschrieben wird.
    3. Alle JSRs mit RTSs quittieren (Stack frei machen) und per JMP in den Lade- und Ausführcode springen --> Datei wird an die in Schritt 1 ermittelte Adresse geladen und ausgeführt.

    Die Schritte 2 und 3 kriege ich schon hin. Es hapert bei Schritt 1. Könnte mir dabei bitte jemand helfen?

    Noch eine Zusatzfrage: Ist auf einer Diskette irgendwo hinterlegt, wie viele Blocks insgesamt darauf passen? Und wenn ja, wie kann ich das einlesen?

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von WebFritzi (29. September 2024 um 14:15)

  • Ok, das hier (Bitte melde dich an, um diesen Link zu sehen.) könnte klappen. Ich würde mich dann wieder melden, wenn ich damit Probleme habe.

    Bleibt noch die Zusatzfrage:

    Zitat

    Ist auf einer Diskette irgendwo hinterlegt, wie viele Blocks insgesamt darauf passen? Und wenn ja, wie kann ich das einlesen?

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • WebFritzi 29. September 2024 um 14:22

    Hat den Titel des Themas von „Erste zwei Bytes aus File lesen“ zu „Bytes aus File und Diskettengröße auslesen“ geändert.
  • hier mal ein Auszug von meinem AMIGA-LOOK-MODUL - Code.

    Bei dem wird getestet, ob das 1. File der Disk die Ladeadresse $0801 (SYSNO) oder eine andere Ladeadresse hat (SYSYES).

    Vielleicht hilft es ja als Grundgerüst ....

    Dass beim 1. Aufruf der Filename ":*" und beim 2. , eigentlich relewanten Aufruf als filename "*" benutzt wird, umschifft das Problem, falls der 1. Filename ein DEL bzw. kein PRG ist (bei Dirart z.B.)

    Das nur zur Erklärung, dürfte für Deine Zwecke aber nicht relevant sein ....


    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • Noch eine Zusatzfrage: Ist auf einer Diskette irgendwo hinterlegt, wie viele Blocks insgesamt darauf passen? Und wenn ja, wie kann ich das einlesen?

    Das ist auf der Diskette nicht hinterlegt, nein. Die Floppy 1541 rechnet das live aus, wenn das Directory angefordert wird (im DOS ab $D075).

    Wenn ich mein DOS-Listing richtig lese, kann man sich nach dem Aufruf des Directory die Blockanzahl in den Speicherstellen $02FA (lo) und $02FC (hi) abholen.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • goloMAK Danke für deine aufschlussreiche Antwort.

    Wenn ich mein DOS-Listing richtig lese, kann man sich nach dem Aufruf des Directory die Blockanzahl in den Speicherstellen $02FA (lo) und $02FC (hi) abholen.

    Das sind aber laut Bitte melde dich an, um diesen Link zu sehen. nur die freien Blocks, die ich ja auch beim Einlesen der Directory mitgeliefert kriege. Ich bin aber an der Gesamtgröße interessiert.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Das sind aber laut Bitte melde dich an, um diesen Link zu sehen. nur die freien Blocks, die ich ja auch beim Einlesen der Directory mitgeliefert kriege. Ich bin aber an der Gesamtgröße interessiert.

    Ja, das stimmt, da hatte ich dich falsch verstanden.

    Also, die Gesamtgröße ist auch nicht auf der Diskette abgelegt. Das Einfachste ist es dann wohl, das Floppy-ROM auf ein paar typische Bytefolgen hin zu untersuchen und damit das Laufwerk zu identifizieren.

    Oder man holt sich das Directory und zählt die belegten Blöcke und die freien zusammen?

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Oder man holt sich das Directory und zählt die belegten Blöcke und die freien zusammen?

    Dazu bin ich zu faul. Außerdem bin ich nicht sicher, ob man dem dann auch trauen kann.

    das Floppy-ROM auf ein paar typische Bytefolgen hin zu untersuchen und damit das Laufwerk zu identifizieren.

    Ja, das geht z.B. so relativ zuverlässig:

    Hab ich aus dem Forum von lemon64.com kopiert. Hatte nur gehofft, dass die Größe irgendwo hinterlegt ist. Du hast mir die Frage beantwortet: Nein. Vielen Dank dafür.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Das Einfachste ist es dann wohl, das Floppy-ROM auf ein paar typische Bytefolgen hin zu untersuchen und damit das Laufwerk zu identifizieren.

    Ja, das geht z.B. so relativ zuverlässig:

    Wenn es Maschinensprache sein soll, hier etwas was schon ein paar Jahre auf dem Buckel hat :wink: .

    Kann:

    ; Available byte representations-

    ; 00 - No serial device available

    ; 01 - foreign drive (MSD, Excelerator, Lt.Kernal, etc.)

    ; 41 - 1541 drive

    ; 71 - 1571 drive

    ; 81 - 1581 drive

    ; e0 - FD drive

    ; c0 - HD drive

    ; f0 - RD drive

    ; 80 - RAMLink

    Gruß

    Werner

  • Ich verstehe den Ansatz nicht. Wieso nicht einfach das KERNAL-LOAD nehmen und danach RUN? Das funktioniert auch mit anderen Laufwerken als der 1541 und auch Nicht-Laufwerken (KFF etc.) schnell.

    Geht's darum, auch z.B. Utilities, die z.B. nach $C000 geladen werden, zu starten? Das wird im allgemeinen nicht funktionieren, weil a) zahlreiche solcher Utilities Parameter erwarten (SYS49152,x,y,z o.ä.) und b) die Ladeadresse nicht unbedingt gleich Startadresse ist.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Oder man holt sich das Directory und zählt die belegten Blöcke und die freien zusammen?

    Dazu bin ich zu faul. Außerdem bin ich nicht sicher, ob man dem dann auch trauen kann.

    das Floppy-ROM auf ein paar typische Bytefolgen hin zu untersuchen und damit das Laufwerk zu identifizieren.

    Ja, das geht z.B. so relativ zuverlässig:

    Hab ich aus dem Forum von lemon64.com kopiert. Hatte nur gehofft, dass die Größe irgendwo hinterlegt ist. Du hast mir die Frage beantwortet: Nein. Vielen Dank dafür.

    Bei 1541 Disketten würde ich mich nicht darauf verlassen, das belegte + freie Blöcke die Gesamtzahl ergeben. Dafür waren die Leute viel zu kreativ in der Manipulation der Directories.

    Bei Festplatten oder ähnlichem gehe ich davon aus das es stimmt. Wäre interessant ob Drive Emulatoren die mehre Formate unterstützen (z.B. D64, D81, D71) diese auch korrekt zurück geben.

  • Eben, wenn du dann noch Kernal-kompatible Zusatzhardware wie SD2IEC etc. nimmst, kannst du dich auf irgendeine Größentabelle nicht verlassen. Es gibt auch hochformatierte Disketten mit extra Spuren.

    Da musst du vermutlich ordentlich auf dem Medium herumpörkeln (potentiell alle Ende-Tracks abgrasen um die Anzahl festzustellen), das scheint mir wenig zielführend und vor allem zeitraubend.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Leider gibt es nicht wie bei MSDOS (FAT) einen Bootsektor mit einem Media Informationen Block.

    Auch ist das DOS in der Floppy welches nur sehr wenige Typen unterscheiden muss.

    Ich fürchte von der Idee einer Füllstandsanzeige musst du dich verabschieden.

  • Wie wäre es denn mit der BAM? Dort sind alle Blöcke vermerkt, volle wie leere. Also kannst du die Gesamtzahl ermitteln und auch anzeigen wie viel belegt ist.

    Ist die Disk manipuliert, kannst du das nicht ändern. Aber auf irgendwas musst du dich verlassen. Wenn in der BAM alles als "belegt" markiert ist wird ja auch die Floppy nichts mehr speichern. Sie schaut auch nur in die BAM.

  • Wie wäre es denn mit der BAM? Dort sind alle Blöcke vermerkt, volle wie leere. Also kannst du die Gesamtzahl ermitteln und auch anzeigen wie viel belegt ist.

    Ist die Disk manipuliert, kannst du das nicht ändern. Aber auf irgendwas musst du dich verlassen. Wenn in der BAM alles als "belegt" markiert ist wird ja auch die Floppy nichts mehr speichern. Sie schaut auch nur in die BAM.

    Das Problem ist, das jedes Laufwerk sein eigenes BAM Format hat.

    Schlimmer noch Dophin DOS, Prologic DOS etc. hat auch noch abweichende BAMs für >35 Tracks.

    Kann man sicher alles lösen aber wenn man dafür schon eine eigene Datenbank benötigt wird das sicher kein kompaktes Programm.

  • Wenn man weiß, wie man die BAM auslesen muss, dann weiß man auch, mit welchem Laufwerk man es zu tun hat, dann braucht man auch keine BAM mehr. :)

    EDIT: Gemeint war der Gerätetyp, also 1541, 1581 usw.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

    Einmal editiert, zuletzt von goloMAK (29. September 2024 um 20:15)

  • Mit der BAM kenne ich mich nicht aus.

    Ich hab's jetzt doch erstmal so gemacht, dass ich alles zusammen zähle. Wenn die Diskette manipuliert ist, dann hat der User eben Pech gehabt. Wenn die BAM allerdings zuverlässiger sein sollte, wäre ich gewillt zu lernen. :smile:

    Ist hier nicht goloMAK der BAM-König?

    Wenn man weiß, wie man die BAM auslesen muss, dann weiß man auch, mit welchem Laufwerk man es zu tun hat, dann braucht man auch keine BAM mehr. :)

    Es geht ja um die Gesamtanzahl der Blöcke ("Sektoren?) und nicht um das Laufwerk.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Auslesen der ersten zwei Bytes aus der PRG-Datei. Das ist ja die Adresse, an die die Datei mit LOAD"...",8,1 geladen wird.

    Die meisten zu startenden Programme dürften nach $0801 geladen werden, müssen dann aber mit RUN oder SYS20xx gestartet werden - nicht mit SYS2049.

    Von den Programmen, die nicht an den Anfang des BASIC-RAMs geladen werden, startet ein Teil automatisch, andere benötigen wie erwähnt Parameter oder machen nur als Unterprogramm eines BASIC-Programms Sinn. Dann bleiben m.E. nur sehr wenige Anwendungsfälle übrig, wo ein "Laden, dann Sprung an Ladeadresse" tatsächlich Sinn macht?

    Ich würde die Funktionen "RUN" (→Laden nach $0801, dann RUN) oder "Boot" (→LOAD,8,1, dann RTS) anbieten.

    Alle JSRs mit RTSs quittieren (Stack frei machen)

    Was meinst du mit "mit RTSs quittieren"? Überflüssige Rücksprungadressen holt man normalerweise mit PLA vom Stack.

    Noch eine Zusatzfrage: Ist auf einer Diskette irgendwo hinterlegt, wie viele Blocks insgesamt darauf passen? Und wenn ja, wie kann ich das einlesen?

    Wie andere schon gesagt haben: Den Laufwerkstyp identifizieren und dann in einer Tabelle nachsehen, wie viele Blöcke drauf passen.

    Laufwerke musst du sowieso identifizieren - es war ja die Rede von einem Schnelllader, der funktioniert natürlich nur mit bestimmten Laufwerken. Also ein mal zum Programmstart (oder wenn der Nutzer eine Funktion "Laufwerke scannen" aufruft) alle Laufwerke identifizieren und ihre Parameter ("Speeder benutzen J/N", "Größe in Blocks", "maximale Anzahl Dir-Einträge"...) in eine Tabelle schreiben.

    Oder, wenn du wirklich nur 1541 unterstützen willst: alles ausblenden, was keine 1541 ist.

  • Das Thema ist echt problematisch da man nicht einmal weiss wo die BAM oder das Directory genau auf der Diskette liegt wenn man nicht weiß um welches Format es sich handelt.

  • Verstehe ich, aber so ist das eben.

    Ich vermute das man genau aus dem Grund bei GEOS den Laufwerkstyp konfigurieren musste.

    Man benötigt einen Treiber der das ganze über eine API zugänglich macht.

    GUI64 muss ja kein Onefiler bleiben. Man muss es sich dann einmal Konfigurieren für sein System.

    Oder es gibt keine Füllstandsanzeige :wink:

  • Wenn man weiß, wie man die BAM auslesen muss, dann weiß man auch, mit welchem Laufwerk man es zu tun hat, dann braucht man auch keine BAM mehr. :)

    Es geht ja um die Gesamtanzahl der Blöcke ("Sektoren?) und nicht um das Laufwerk.

    Mit Laufwerk meinte ich jetzt das Floppy-Modell, also 1541, 1571 usw. Wenn man weiß, mit welchem Gerät man es zu tun hat, braucht man auch keine BAM mehr.

    Wenn die BAM allerdings zuverlässiger sein sollte, wäre ich gewillt zu lernen. :smile:

    Bringt aus dem o.a. Grund keinen Fortschritt.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke