Suche CP/M 2.2-Tool zum sektorweisen Lesen/Dumpen von Disketten via BIOS

  • :grübel: Kennt wer ein CP/M 2.2 Tool mit dem man einzelne Sektoren von einer Floppy lesen (dumpen) kann. Dieses soll am Originalsystem laufen. Der Zugriff darf aber nicht über BDOS erfolgen, sondern direkt über BIOS-Aufrufe.


    Problem ist folgendes: Aquarius und ich sind auf Fehlersuche beim Lesen von, mit FLUXCOPY, kopierten Disketten. Auf dem Bull Questar/M lassen sich manche Tracks nicht fehlerfrei einlesen. Es gibt zwar ein Dumpprogramm (läuft über BDOS Calls), dieses liefert aber bei Auftreten eines Checksumfehlers keine Daten.


    Info: Questar verwendet hardsektorierte Disketten (16 Sektoren, 80Track, DS) mit MFM-Formatierung. Details zu Questar: Bull Questar


    Wir bräuchten ein Programm das auch die fehlerhaften Sektoren anzeigt.


    Vielen Dank im Voraus!


    Grüße PAW

  • Wenn die Randbedingungen für die AUFGABE richtig formuliert ist:

    Der Zugriff darf aber nicht über BDOS erfolgen, sondern direkt über BIOS-Aufrufe.

    muss man sich sicher dann ein "WUNSCH_PROGRAMM" sowas selber bauen.

    Da musst du in die BIOS Liste und Parameterversorgung einsteigen. Bisher kenne ich z.B. nur cp/m Programme wie ähnliche : DU.COM (disk utility, aber klar per BDOS!) .


    Viel Erfolg.

  • Danke für die Infos und das Tool!


    Zitat von helwie44

    ... muss man sich sicher dann ein "WUNSCH_PROGRAMM" sowas selber bauen.

    Das "WUNSCH_PROGRAMM" wollte ich mir ersparen.


    Zitat von kkaempf

    Ich hätte hier "DPATCH", Version 2.20, von "Advanced Micro Techniques". Das bietet 'direct file alteration' und 'direct disk alteration'. Ob über BDOS oder BIOS kann ich leider nicht sagen.


    Wenn Aquarius wieder an seiner Maschine sitzt, kann er es ja ausprobieren.


    Im Prinzip wären auch BDOS-Calls möglich, ich befürchte jedoch, dass Checksummenfehler einen Dump der Daten verhindern.


    'direct disk alteration' könnte auf BIOS hindeuten. Soweit ich mich erinnere beziehen sich die BDOS-Calls auf Files und nicht auf native Sektoren. Kann mich aber auch irren. Leider kann ich nicht selber testen, da ich nicht über das Zielsystem verfüge.


    Werden jedenfalls berichten, wie es ausgeht.


    Schönen Tag!


    PAW

  • So etwas hatte ich auch gesucht. Bin das momentan selber am programmieren. Aus Zeitgründen war ich schon fast 14 Tage nicht mehr dran.

    Die Eingabe und Sektorleseroutine ist fertig, ich muss die Ausgaberoutine noch basteln. Mein Tool ist für einseitige 8“ Disketten mit 77 Tracks und 26 Sektoren zu jeweils 128 bytes.


    Wenn man zB Track 22, Sektor 18 lesen will, dann tippt man ein:


    Tdisk 2218


    Dann wird der Sektor gelesen, an Speicheradresse 1000h abgelegt und auf dem Bildschirm dargestellt.

    Das Programm greift direkt auf den Controller zu ohne „Umwege“.



    Gruss Jan

  • Soweit ich weiss gibt es bei CP/M 2.2 keinen BDOS-Call der direktes Lesen und Schreiben von Sektoren ermöglicht,

    es gibt nur Calls für den Umgang mit Dateien.


    Direkter Zugriff auf Sektoren ist mit BIOS Calls möglich, allerdings ist das eine virtuelle Sektor bzw. Spurnummer.

    Ausschliesslich bei 8" Disketten, Single Sided, Single Density stimmt das mit den physikalischen Sektoren überein.

    Verwendet ein Format z.B. 512 Byte Sektoren müssen, um die ganzen 512 Bytes zu lesen, die Sektoren 0,1,2 und drei

    vom BIOS angefordert werden. Das Mapping der virtuellen auf die echten Sektoren erfolgt im BIOS-Code und ist

    systemabhängig.


    Will man also tatsächlich die physikalischen Sektoren lesen bleibt einem nichts anderes übrig als den Floppycontroller direkt

    anzusteuern.

  • Ganz genau so ist es. Deswegen muss man dann das Programm, von dem ich oben erzählt habe im Source auf den Controller über die Equates anpassen. Also controller ports und commands.


    Gruss Jan


  • Das Programm dpatch sieht vielversprechend aus.

    Es läuft auf dem Questar!


    Habe die Diskoparationen getestet. Lesen von Sektoren geht - siehe Bild.

    Leider ist die Bildschirmausgabe zerstückelt - habe keine Option im Programm gefunden zum ändern der Bildschirmsteuerzeichen.


    Gruss Aquarius


    P.S.: Power.com hat die notwendige Funktion nicht.

  • Zitat von Pyewacket

    Will man also tatsächlich die physikalischen Sektoren lesen bleibt einem nichts anderes übrig als den Floppycontroller direkt

    anzusteuern.

    Wenn man alle Sektoren liest, dann kann man das Mapping auch rausfinden.


    Was allerdings ein Problem wäre, ist den Floppycontroller direkt anzusprechen, da von diesem vermutlich nichts bekannt ist. Es handelt sich ja bei den Disketten um hardsektorierte 5.25" MFM. Die Formatierung der Spur hat keinerlei Ähnlichkeit mit den üblichen Softsektor-Formaten, die mit µPD765 und Co. bearbeitet werden können. Es gibt auch keinen CRC, sondern eine 2 x 8 Bit Checksumme.


    Deshalb scheint mir der Weg über das BIOS der einfachste zu sein. Ob DPATCH auch die fehlerhaften Sektoren lesen kann wird sich noch rausstellen.



    Zitat von Jan1980

    Ganz genau so ist es. Deswegen muss man dann das Programm, von dem ich oben erzählt habe im Source auf den Controller über die Equates anpassen. Also controller ports und commands.

    Welchen Controller verwendest Du in Deinem Program und welche Modulation haben Deine 8" Disketten (FM, MFM ?)



    Gruß, PAW

  • Deshalb scheint mir der Weg über das BIOS der einfachste zu sein.

    Sehe ich auch , über die cp/m - BIOS Vektoreneinträge sind ja üblich über die verbauten EPROMs / ROMs genau auf die Hardware zu zugreifbar.

    Ob dann möglich bei einem Lesefehler die gewünschte Information im Speicher (DMA-Adresse) vorhanden ist - kann man nicht immer sagen?

  • Leider ist die Bildschirmausgabe zerstückelt - habe keine Option im Programm gefunden zum ändern der Bildschirmsteuerzeichen.


    Bin gerade dabei, dpatch zu disassemblieren. Voreingestellt ist ein 80x24 Terminal.

    Es wird "ESC =" zur Cursorpositionierung benutzt. Weitere Controlsequenzen habe ich noch nicht gefunden.


    Welche Terminalemulation brauchst Du ? Wie wird dort der Cursor positioniert ?

  • Zitat von kkaempf

    Bin gerade dabei, dpatch zu disassemblieren. Voreingestellt ist ein 80x24 Terminal.

    Es wird "ESC =" zur Cursorpositionierung benutzt. Weitere Controlsequenzen habe ich noch nicht gefunden.


    DPATCH verwendet offenbar die Steuerzeichen für ein Televideo-Terminal TVI925/950. Das habe ich empirisch durch Probieren mit 22NICE rausgefunden. Mit dieser Einstellung wird der Bildschirm im CP/M-Emulator richtig angezeigt.

  • Mit den Steuerzeichen habe ich mich bisher noch nicht beschäftigt.


    Werde ich nun tun, damit die Arbeit mit dpatch Besser funktioniert.


    Da ich die Spiele Ladder und Catchum schon drauf habe auf meinem System und dort auch die Steuerzeichen völlig durcheinander sind, kann mir jemand Tipps geben, wie ich schrittweise vorgehen kann, um die richtigen Zeichen rauszubekommen?

  • Ich hätte hier "DPATCH", Version 2.20, von "Advanced Micro Techniques". Das bietet 'direct file alteration' und 'direct disk alteration'. Ob über BDOS oder BIOS kann ich leider nicht sagen.

    Bin jetzt mit dem Disassemblieren soweit durch und kann bestätigen, dass DPATCH direkt auf's BIOS geht !

  • kann mir jemand Tipps geben, wie ich schrittweise vorgehen kann, um die richtigen Zeichen rauszubekommen?

    Doku suchen / finden ;)


    Hast Du ein Programm, welches korrekt den Bildschirm ansteuert ?


    Ansonsten werde ich mal das System ROM aus dem Questar/M Thread unter die Lupe nehmen.

  • Zitat von Aquarius

    Mit den Steuerzeichen habe ich mich bisher noch nicht beschäftigt.


    Werde ich nun tun, damit die Arbeit mit dpatch Besser funktioniert.


    Da ich die Spiele Ladder und Catchum schon drauf habe auf meinem System und dort auch die Steuerzeichen völlig durcheinander sind, kann mir jemand Tipps geben, wie ich schrittweise vorgehen kann, um die richtigen Zeichen rauszubekommen?

    Wie schon kkaempf schrieb, schaut man, ob ein, mit Steuerzeichen, funktionierendes Programm existiert.


    Falls keines verfügbar, kannst Du es mit z.B. mit TURBO PASCAL 3.0 versuchen. Dieses hat ein Installationsprogramm (TINST.COM) welches eine ganze Reihe von bekannten Terminals via Menü anbietet. Die kannst Du der Reihe nach durchprobieren.



    Also mit TINST.COM ein Terminal auswählen und danach TURBO.COM starten.


    Sieht der Schirm z.B. so aus, dann stimmt das Terminal nicht.




    Eine richtige Installation sollte so aussehen:



    Wenn das richtige Terminal einmal bekannt ist, dann kannst Du im Netz nach einer Dokumentation zu dem Terminal suchen, in dem die Steuersequenzen beschrieben sind.


    Grüße, PAW

  • kkaempf und PAW , sorry wenn ich hier mal etwas offtopic reingrätsche, aber irgendwie passt es doch. Könnt ihr bitte mal schauen, welche Terminal-Steuercodes das angehängte CP/M-Programm verwendet? Ich wüsste gerne, was für eine Terminalemulation das ist. Wenn man das Programm startet, erscheinen auf italienisch zwei Menüeinträge, die man per Cursortasten auswählen kann, womit der ausgewählte Eintrag invertiert dargestellt wird. Es wäre toll, wenn ich endlich mal wüsste, was für eine Terminalemulation dieses System benutzt, wo das Konvertierungstool dazu gehört. Danke!

  • Zitat von ralle

    Hab ihr das schon versucht:

    POWER.COM.zip


    Einfach auspacken und auf eine CPM-Diskette schaufeln. POWER TEST a: testet Diskette im Laufwerk a: auf Fehlerfreiheit. Reclaim stellt gelöschte Datein wieder her.

    Siehe Antwort auf POWER.COM


    Laut Aquarius bietet POWER.COM nicht die Funktionalität die wir suchen.


    Unser Problem ist nicht die Diskette zu testen, sondern genau das Bit (bzw. den Fluxwechsel) zu finden, das falsch eingelesen wird. Auf dem betreffenden Track befinden sich nicht einmal Daten von Dateien, sondern die Sektoren sind quasi unbenutzt. Daher ist es notwendig mittels direktem Lesen der Sektoren festzustellen, in welchem Sektor der Fehler auftritt (noch dazu tritt er nicht immer auf). Dann muss der "fehlerhafte" Dump mit dem Original verglichen werden, um genau die Position feststellen zu können.


    Die Hoffnung ist, dass der BIOS-Aufruf auch fehlerhafte Sektoren zurückliefert, die man dann dumpen kann.

    • Offizieller Beitrag

    Also erstmal gibt der BIOS-Aufruf unter CP/M nicht einen Sektor zurück, sondern ein Record (128 Byte Block). Bei einigen Disketten (8", 26 Sektoren etc) ist ein Record = ein Sektor.

    Und dann kommt noch die Translation-Table im BIOS dazwischen, die logische und physikalische Sektoren umrechnet. Diese ist fest im BIOS kodiert, also da nachsehen.


    Wenn du wirklich einen Sektor (ungleich Record) einlesen musst, kannst du nur direkt den Floppy-Controller ansprechen.


    Ihr bastelt mit hard-sector Discs. Aus meiner Erfahrung sind solche Controller Gattergräber, also fest verdrahtete Logic. Einzelne Bits kannst du m.E. nur mit einem LA suchen.

    Selbst bei einem Soft-sector Floppycontroller läuft intern eine Statemachine, die die Bits zu einem Byte zusammen basteln. Wenn da ein Bit kippt, wie willst du rauskriegen, was die Statemachine intern macht. Also Daten oder Fehler ausgeben.


    Viel Erfolg

  • Zitat von funkenzupfer

    Also erstmal gibt der BIOS-Aufruf unter CP/M nicht einen Sektor zurück, sondern ein Record (128 Byte Block). Bei einigen Disketten (8", 26 Sektoren etc) ist ein Record = ein Sektor.

    Und dann kommt noch die Translation-Table im BIOS dazwischen, die logische und physikalische Sektoren umrechnet. Diese ist fest im BIOS kodiert, also da nachsehen.

    Das ist bekannt. Um den Inhalt eines, hier 256 Byte großen, Sektors zu bekommen, muss man halt zwei 128-Byte-Records lesen. Voraussichtlich werden wir den ganzen Track dumpen.


    Zitat von funkenzupfer

    Ihr bastelt mit hard-sector Discs. Aus meiner Erfahrung sind solche Controller Gattergräber, also fest verdrahtete Logic. Einzelne Bits kannst du m.E. nur mit einem LA suchen.

    Selbst bei einem Soft-sector Floppycontroller läuft intern eine Statemachine, die die Bits zu einem Byte zusammen basteln. Wenn da ein Bit kippt, wie willst du rauskriegen, was die Statemachine intern macht. Also Daten oder Fehler ausgeben.

    Für das, was wir rausbekommen wollen, ist kein LA nötig. Wir wollen nur sehen was der Zielrechner bei einer Originaldiskette an Daten liest und was er bei einer fehlerhaften Diskette bekommt. Wenn der Fehler nicht gerade im Sektorheader oder in der Checksumme liegt, dann ist aus den Hexdumps ersichtlich, bei welchem Bit der Fehler auftritt. Sobald das Bit bzw. die Position bekannt ist, läßt sich die Position des Fluxwechsels ermitteln. Die brauchen wir für eine Analyse des Fehlers.


    Was der Controller dabei tut wäre zwar interessant, wird aber vermutlich nicht (ohne riesigen Aufwand) zu eruieren sein und ist auch hoffentlich nicht nötig.


    Grüße, PAW

  • Zitat von 1ST1

    kkaempf und PAW , sorry wenn ich hier mal etwas offtopic reingrätsche, aber irgendwie passt es doch. Könnt ihr bitte mal schauen, welche Terminal-Steuercodes das angehängte CP/M-Programm verwendet? Ich wüsste gerne, was für eine Terminalemulation das ist. Wenn man das Programm startet, erscheinen auf italienisch zwei Menüeinträge, die man per Cursortasten auswählen kann, womit der ausgewählte Eintrag invertiert dargestellt wird. Es wäre toll, wenn ich endlich mal wüsste, was für eine Terminalemulation dieses System benutzt, wo das Konvertierungstool dazu gehört. Danke!

    Habe versucht das Programm auszuführen. Es kommt aber überhaupt keine Meldung am Schirm.

    • Offizieller Beitrag

    Das ist bekannt. Um den Inhalt eines, hier 256 Byte großen, Sektors zu bekommen, muss man halt zwei 128-Byte-Records lesen. Voraussichtlich werden wir den ganzen Track dumpen.

    Das ist gut. Ich wollte es nur erwähnt haben weil bei CP/M der Begriff Sektor etwas schwammig ist.

    Und bei einigen Posts hatte ich auch dieses Gefühl.


    Wenn der Fehler nicht gerade im Sektorheader oder in der Checksumme liegt,

    Aus meiner Erfahrung:

    Wenn ein Fehler im Sync Byte auftritt, wird der Sektor wahrscheinlich gar nicht gelesen. Alles nach dem Sync Byte wird i.a gelesen und nachher in Software analysiert, Checksum etc.

  • Mit der Hilfe von Antikythera habe ich gestern die ersten Steuerzeichen des Questar/M herausbekommen:


    Dez

    Hex

    ASCII

    Questar Befehl

    12

    0C

    Form Feed

    Bildschirm löschen

    27

    1B

    ESC

    ESC

    102

    66

    B

    Absolute Cursorpositionierung


    Cursorpositionierung nach 1B 66 in der Reihenfolge Column, Row.


    Nullpunkt liegt bei Dezimal 31,31


    Beispiel - Cursor in Basic an Stelle 1,1 setzen:

    PRINT CHR$(27)+CHR$(102)+CHR$(32)+CHR$(32)


    Das Spiel Ladder lies sich damit konfigurieren und die Bildschirmausgabe war einwandfrei. Das Spiel macht sogar richtig Spass. :)

  • Mir ist so ein "generisches" CP/M Tool noch nicht untergekommen, ich befürchte das müsste immer Hardware-spezifisch erstellt werden.
    Seid Ihr denn sicher, dass es ein Fluxcopy Software-Problem und kein Hardware-Problem (ungleiche Spurlage der Laufwerke, fehlerhaftes Medium) ist?

    Aquarius : Hast Du schon mit einem zweiten Laufwerk am Fluxcopy getestet? Verwendest Du "echte" Hardsektor-Disketten oder die "Eigenbau-Medien"? Gibt es das Problem unter Prologue oder CP/M?

  • kkaempf und PAW , sorry wenn ich hier mal etwas offtopic reingrätsche, aber irgendwie passt es doch. Könnt ihr bitte mal schauen, welche Terminal-Steuercodes das angehängte CP/M-Programm verwendet?

    Beim starten de CRLF.CPM bekommen ich nur die Meldung
    "End of void setup." hier im RunCPM und dann haengt RunCPM. Ansonsten keine Ausgabe :(

  • Seid Ihr denn sicher, dass es ein Fluxcopy Software-Problem und kein Hardware-Problem (ungleiche Spurlage der Laufwerke, fehlerhaftes Medium) ist?

    Aquarius : Hast Du schon mit einem zweiten Laufwerk am Fluxcopy getestet? Verwendest Du "echte" Hardsektor-Disketten oder die "Eigenbau-Medien"? Gibt es das Problem unter Prologue oder CP/M?

    Danke der Nachfrage gpospi . Manchmal übersieht man ja was.


    Hardware Probleme sollten ausgeschlossen sein, da ich das Fluxcopylaufwerk von TEAC mal an den Questar angeschlossen hatte und dort an den gleichen Stellen Probleme auftraten mit dem kopierten Medium.


    Für diese Tests verwende ich original 16 Hard Sektor Disks. Auch das sollte passen.


    Wir testen gerade nur unter CPM.


    Habe übrigens vier weitere Laufwerke mit Fluxcopy getestet mit diesem Szenario. Das jetzige TEAC FD55 bringt die besten Ergebnisse.