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

  • Hallo PAW -

    ich habe ein lupenreines 8080 cp/m 2.2, das müsstest du bereits bei dem Ablaufprotokoll von der Displayanzeige über den PRINTER-AUSGANG ( über V24 Kabel auf das TeraTerm (WIN-Prog) als File (.txt) geleitet - wie dort zu sehen ist.


    Hast du mal deine identische Testdiskette mit dem DU.COM ( läuft auf jedem cp/m > vers. 2.0 und Z80, 8080, 8085 Chip) zum Vergleich gedumpt?


    Ich meine in DDUMP050 ist bei der „S“ ector keine „0“ erlaubt! Fehler-Eingabe_Bell!

    Das ist auch völlig richtig von der Bedeutung, sonst kommen doch ein USER mit deinem Prog. ins schleudern.


    Wie ich zuvor angedeutet - sollte man die Ursache in der BIOS-Anpassung ( möglich ) über den HostBuf und den Block - DeBlock zu finden können. Schau doch mal was du in deinem Prg. gemacht hast.


    Bei dieser cp/m von mir ist der HostBuf 2 kB, also je ein EXT-Block. Siehe meine Protokolle zuvor!


    Wie arbeitet deine READ/ WRITE cp/m Anpassung?

  • Zitat von helwie44

    Hast du mal deine identische Testdiskette mit dem DU.COM ( läuft auf jedem cp/m > vers. 2.0 und Z80, 8080, 8085 Chip) zum Vergleich gedumpt?

    Habe von DU.COM eine Version v89 runtergeladen und auf der P2500 ausprobiert.




    Die gleichen Sektoren mit DDUMP betrachtet:


    Wie man sieht, sind die Daten identisch.


    Offenbar funktionieren die Programme auf den beiden Systemen nicht gleich!


    Zitat von helwie44

    Ich meine in DDUMP050 ist bei der „S“ ector keine „0“ erlaubt! Fehler-Eingabe_Bell!


    Auf der P2500 kann ich bei der Sektoreingabe auch 0 eingeben. Allerdings werden mit R)ead keine gültigen Daten gelesen. Die P2500 kopiert offenbar die zuletzt gelesenen Daten in den Recordbuffer (auf DMA-Adresse). Der Recordbuffer wird vor dem Lesen mit einem Text initialisiert, welcher überschrieben wird.


    Der Sektor 0 sollte auf deiner Maschine auch eingebbar sein. Ob er dann was richtiges liest, wäre interessant, da ja DDUMP die ersten 128 Bytes bei dir nicht anzeigt.



    Was mir noch aufgefallen ist: bei DU.COM beim ersten Sektor:

    S1

    G=00:00, T=2, S=1, PS=0



    Auf der P2500 steht dort bei DU.COM: G=00:00, T=2, S=1, PS=1




    PAW

  • Hallo PAW - ich schau das noch mal intensiver an.


    Das mit der Bezeichnung im DU.COM - mit der S und PS hatte ich schon immer gesehen, aber die Datenfolgen waren richtig - weil ich ganz damals mit SID einige Testsektoren mit dem physikalischem Floppydisks-Treiber gelesen und gegen DU.COM geprüft hatte.

  • Nun PAW - mit dem SID habe ich einfach über den BIOS-Vektor (bei mir mit 0xF200 h, 62 k cp/m)

    In 6. THE BIOS ENTRY POINTS (cp/m Alteration Guide !!)


    einige Subroutinen mit Reg C = 0 auf

    Diskette A: call 0xF21B ,

    Track 0 call 0xF21E h, den ersten

    Sektor (cp/m) mit 0 call 0xF221 h, und

    DMA mit 0x6500 h call 0xF224 h, mit BC=0x6500 h eingestellt.

    Dann einfach ein „read“ 0xF227 ,

    unten die erwarteten (bekannter INHALT) DATEN zu sehen.



    Wenn ich also die cp/m Sektoren von 0 bis 31 anwähle kommen alle Sektoren einer SPUR!

    Im DiskPARABlock sind Anzahl auf 32 (cp/m sec/trk), offenbar von 0 bis 31!

    Bei 32 in Reg C = 20h liefert ein Fehler - später nach einem „READ“ !!!

    Offenbar erkennt das DU.COM die Mimik mit dem „S“ und dem „PS“ immer richtig.

  • Hallo @helwie44


    Danke für die Tests!


    Wenn du noch Zeit hast, könntest du noch DDUMP ausprobieren, aber mit Sectornummer 0. (Obwohl dort steht Enter Sector (1..nn): 0 eingeben! Der Sektor 0 sollte auf deiner Maschine auch eingebbar sein. Ob er dann mit Read etwas richtiges liest, wäre interessant, da ja DDUMP die ersten 128 Bytes bei dir nicht anzeigt hat.


    Gruß, PAW

  • Nun PAW -

    Anfang mit "T" und "0" weiter mit der "S" Eingabe und "0" wird angenommen dann mit "R" gelesen und gedumpt: RICHTIG angezeigt.

    Mit der N ext / P rev - bei mir 32 Anzahl / Trak cp/m Records (128 Byte) geht richtig (die Anzeige) bis S nach 31.

    Wenn ich nur bis "S" auf "31" gehe holt sich der Dump richtig.


    Geht man weiter mit N ext - (auf oder über 32 !! ) sollten eigentlich die nächste TRACK auf den ersten cp/m Record angesteuert und gedumpt werden.


    Nur zur INFO:

    ABER der DUMP zeigt offenbar was aus dem sonstigen Memory! ??

    Das geht weiter bis 64 Sector bei DDUMP50.COM - mit ERROR und Bell!

    Das scheint auch deine Funktion E rrSec mit einem Abbruch bis 64 Sectoren.


    Es reicht mir das DU.COM

    ok - für den Hausgebrauch.


    Grüße helwie44 †

  • Zitat von helwie44

    Anfang mit "T" und "0" weiter mit der "S" Eingabe und "0" wird angenommen dann mit "R" gelesen und gedumpt: RICHTIG angezeigt.

    Mit der N ext / P rev - bei mir 32 Anzahl / Trak cp/m Records (128 Byte) geht richtig (die Anzeige) bis S nach 31.

    Wenn ich nur bis "S" auf "31" gehe holt sich der Dump richtig.


    Geht man weiter mit N ext - (auf oder über 32 !! ) sollten eigentlich die nächste TRACK auf den ersten cp/m Record angesteuert und gedumpt werden.

    Danke für die Tests!


    Ein Weitergehen auf den nächsten Track mit "N)ext" ist nicht vorgesehen, da DDUMP nicht weiß, wieviele Sektoren auf dem Track sind. War auch für den ursprünglichen Zweck nicht nötig. Soll ja nur ein kleines Tool sein, um die Checksummenfehler besser aufspüren zu können und die tatsächlich gelesenen Daten zu sehen. Da die wirklich gelesenen Daten vom BIOS im Fehlerfall nicht immer an den Aufrufer zurückgeliefert werden, habe ich die Memorysuchfunktion eingebaut, um den tatsächlichen Sektorpuffer beobachten zu können.


    Grüße, PAW

  • Digital Research STAT.PLM zum cp/m 80 - das Tool STAT.COM

    Kleine Nachbetrachtung

    Soll ja nur ein kleines Tool sein


    Hier habe ich noch original die cp/m 80 Quelle von dem DR Tool als "STAT.PLM".

    Dort kann viel von dem Hintergrund der Hantierung mit/über die DiskParameter-Blöcke und mehr zu erkennen.

    Ein Auszug aus dem STAT.PLM - die Quelle ist unten zu betrachten. Einfach nur .txt ändern/löschen nach dem download.


    Ich krame mal einem lauffähigen unter cp/m 80 - PLM - COMPILER raus. Ich meine von Syssoft SYS-OPT?

    Mit allen Dokus und die Quelle für die erzeugen einer PLMLIB.REL.

    Damit hatte ich damals mal genau das Tool STAT.PLM übersetzt und weiter mit dem M80, DANN MIT L80 zum laufen gebracht.