Disketten Alphatronic P2 archivieren mit SAMDISK/SAMCONV

  • Es handelt sich offenbar um das AT2.ZIP. (Dank von PAW und/oder Toshi )


    Die Datei AT2.DSK habe ich einfach in den HxC-EMU geschoben.



    Grfischer DUMP der AT2.DSK


    Gut die zwei Sonderheiten zu erkennen.

    Den üblichen TA K-Schutz (rot) auf Track 2 und Sektor 16 !


    Eigentlich hat diese "MACKE" keinen Sinn. Weder beim cp/m und/ oder auch nicht bei einem üblichen Programm.

    Weil offenbar in der SPUR 16 in den 1-16 Sector (möglich USER-DATEN_TEXTE?) vorhanden sind.

    Zusätzlich befindet sich aus meiner Sicht - Fragmente eines 8080 CODE sind dort vorhanden.


    Bei evtl. einer undefiniertem Bediener / Aktionen kam es zu dieser Anormalität!!

    Die 16 Daten-sectoren sind/sollten bei einem USERProgramm ohne weiteres verarbeit sein sollten.


    Das Fragment vom 8080 CODE im DATEN -ENDE!


    Was aber unüblich ist - warum hier ein Benutzer auf dieser TA mit K-Schutz die cp/m Diskette mit voll geknallten Benutzer Daten haut.

    Besser mit Übersicht sollte man DATEN auf nurmale Disketten belegen.


    Und noch besser die cp/m Diskette per WRITE protect SICHERN

    (den strip entfernen bei BASF TA/sks nach ECMA!!).


    Also mit diesen Diskette bin ich durch.

    • Offizieller Beitrag

    FORTH für die P2 mit Quellcode


    Könnte sich jemand bitte mal diese Diskette anschauen?

    samdisk hat sie ohne murren eingelesen, aber die mit SAMCONV ausgegebenen files scheinen leider nicht komplett zu sein :(

    Zumindest die liesmich.datei scheint nach der Hälfte abzubrechen und der in Forth geschriebene Editor hat die Länge 0 bytes.... Womöglich fehlt noch mehr, das kann ich ohne lauffähige P2 gerade nicht ersehen.

    • Offizieller Beitrag

    Anbei ein Wordstar. Habe es nach PAW s Methode mit "gutedisk.dsk" gemerged.

    Dann kann man mit SAMCONV die Dateien extrahieren. Leider wie beim Forth, offensichtlich etwas defekt. DIe beiden kurzen Beispieltexte sind jedenfalls verstümmtelt. Vielleicht ist das Executable und die Overlaydatei nicht betroffen? Vielleicht mag das jemand prüfen?

    • Offizieller Beitrag

    Ja, gibt es. Ich habe gerade den Basic-Compiler gescannt, mit "gutedisk" gemerged und bekomme die Fehlermeldung wegen der Klammeraffen von SAMCONV.


    bas1c ist die mit gutedisk korrigierte Datei, bas1.dsk das Original von Samdisk.


    "Zusätzlich gelöschte Einträge wieder aktivieren (hex E5

    auf 00 setzen" habe ich nicht verstanden, kannst Du mir das bitte kurz erklären?

  • Anbei ein Wordstar. Habe es nach PAW s Methode mit "gutedisk.dsk" gemerged.

    Dann kann man mit SAMCONV die Dateien extrahieren. Leider wie beim Forth, offensichtlich etwas defekt. DIe beiden kurzen Beispieltexte sind jedenfalls verstümmtelt. Vielleicht ist das Executable und die Overlaydatei nicht betroffen? Vielleicht mag das jemand prüfen?

    Ich werde mir das am Wochenende ansehen. PAW meint mit "gelöschte Einträge wieder aktivieren" ein "Undelete" im Directory. Beim Löschen wird lediglich das erste Zeichen auf E5 gesetzt, wenn Du das wieder auf 00 umstellst dann taucht die Datei im Inhaltsverzeichnis wieder auf. Das funktioniert inhaltlich natürlich nur wenn der Dateiinhalt noch nicht überschrieben wurde.

  • Im MAME Emulator konnte ich mit dem Systemtyp "AlphatP2" folgende Disketten-Images erfolgreich nutzen:

    • AT2 / Programm "TEXT"
    • WS-ORIG sowie WS-KORR / Programm "WS"
    • BAS1 sowie BAS1C / Programm "BASCOM"

    FORTH0 funktioniert hingegen nicht:

    Das ist aber keine Überraschung, da die Disk ja offenbar schon auf einem PC mit 22DISK/22NICE modifiziert wurde (deshalb *.CPM statt *.COM). Ich muss hier also noch versuchen, die Files wieder in den "Originalzustand" zu bringen und auf eine korrekt formatierte CPM Disk zu kopieren...

    Einmal editiert, zuletzt von gpospi ()

  • Hallo,

    habe mir das Image FORTHP2 mal angesehen. Vermutlich hat diese Diskette nicht das CP/M Format der P2.

    Wenn ich die Extentnumerierung und die Recordzähler richtig deute, dann werden bei dieser Disk Datenblöcke mit einer Größe von 2KB verwendet. Das Diskformat der P2 hat 1KB große Blöcke.

    Ich habe das mal an der Liesmich.TXT Datei überprüft und es würde zum DIR Eintrag passen, vorausgesetzt man verwendet 2KB Blöcke. Aufgrund der Blockanzahl auf der Disk müßte es sich dann um ein zweiseitiges Format handeln, damit die alle unterzubringen wären.

    Weiterhin enthält der Bootsektor keine MOS Batchdatei, sondern startet gleich mit einem 8085 Befehl, um den Stackpointer zu laden. Deutet auf einen Rechner hin, der den ersten Sektor liest und als Maschinensprache direkt ausführt. Macht die P2 so nicht.

    Tippe auf eine Diskette für den TA alphatronic PC.

    Vielleicht kann Toshi mal schauen, ob auf der Rückseite der Disk auch etwas drauf ist.


    Viele Grüße

    netmercer

    • Offizieller Beitrag

    netmercer : :Meister:


    Danke für den Hinweis! Es scheint so, als wäre sie nicht leer, die zweite Seite!


    Habe mal gescannt ....


    Könntest Du bitte mal bei Gelegenheit erklären, womit es sich bei den Recordzählern und den Extentnummern handelt.... ?

    Danke schonmal!

  • Wenn da eine PC 8 TA Mühle mit dem eine Disk erzeugt wurde - ja dann habe ich doch extra das TA P2 cp/m aufgebohrt!!

    In der MAME und klar real könnte evtl. lupenreine cp/m mit pip.com von/zu diversen kopiert werden.

    (Sonderwunsch doch für netmercer eingebaut)

    Später mal sehen was auf der FORTH - Disk ist?

  • Hallo Toshi und eventuell Interessierte,


    Könntest Du bitte mal bei Gelegenheit erklären, womit es sich bei den Recordzählern und den Extentnummern handelt.... ?

    gerne, räusper :prof: (Klugscheißmodus aktiviert)


    Erklärung zum DIR Eintrag:

    Jeder DIR Eintrag hat eine Länge von 32 Byte. Davon werden in 16 Bytes die Blocknummern eingetragen (bei 8 Bit Blocknummern, es sind auch 16Bit Blocknummern möglich, dann passen nur 8 Blöcke in einen DIR Eintrag)

    Bei CP/M 2.2 darf aufgrund der verschiedenen zulässigen Blockgrößen (1024, 2048, 4096, 8192 und 16384 Bytes) in einem DIR Eintrag mehr als ein "Extent = 16KB" abgebildet werden. In unserem Fall mit Blockgröße 2048 Bytes x 16 Blocknummern ergibt das 32KB, also 2 Extents. Der Recordzähler im 16. Byte des DIR Eintrages zählt die Records in einem Extent und endet daher bei 128, da ein Extent genau 16KB entspricht. Die Extents werden im 13. Byte des DIR Eintrages gezählt.

    Beispiel für Blockgröße 2048:
    Eine Datei kleiner gleich 16KB (z.B. 2304Bytes = 18 Records) erhält einen DIR Eintrag mit einem Extent
    also Extentzähler = 00h und Recordzähler = 12h und 2 Blocknummern belegt

    Eine Datei größer 16KB und bis zu 32KB (z.B. 25600 Bytes = 200 Records) erhält einen DIR Eintrag mit zwei Extents
    also Extentzähler = 01h und Recordzähler = 200 - 128 = 72=48h und 13 Blocknummern belegt.

    Eine Datei größer 32KB und bis zu 48KB (z.B. 38400 Bytes = 300 Records) erhält zwei DIR Einträge mit drei Extents, der erste DIR Eintrag enthält zwei Extents und der zweite nur einen Extent.
    1. DIR Eintrag: Extentzähler = 01h und Recordzähler = 80h und alle 16 Blocknummern belegt
    2. DIR Eintrag: Extentzähler = 02h und Recordzähler = 300 - 256 = 44=2Ch und 3 Blocknummern belegt

    usw.


    Einfach mal in den Directorys der Images stöbern, dann wird das Prinzip schnell klar.


    Endlich (Klugscheißmodus aborted) :whistling:


    Viele Grüße

    netmercer

  • Hallo Toshi


    Zitat

    Danke für den Hinweis! Es scheint so, als wäre sie nicht leer, die zweite Seite!


    Habe mal gescannt ....


    Der Scan hat leider einen defekten Track 3 auf Rückseite .


    Daher kann SAMCONV nicht lesen.


    Eventuell nochmals versuchen die Diskette einzulesen (und das image mit SAMdisk überprüfen, ob der Fehler immer noch vorhanden ist.)


    Auf der Rückseite sind jedenfalls Daten. Die von netmercer beschriebene Geometrie ist aus meiner Sicht richtig beschrieben. Danke!


    Sobald ein korrektes Image vorliegt, kann man versuchen das richtige Format für SAMCONV zu finden.


    Sollte die Diskette selbst defekt sein, dann kann man versuchen das image selbst zu korrigieren. Dabei würden allerdings Daten verloren gehen (d.h. sie sind schon verloren, wenn sie nicht von der Diskette gelesen werden können), aber der Rest kann dann wenigstens gelesen werden.


    Gute Nacht!


    PAW

  • Guten Morgen,


    habe versuchsweise das Image der forth2s.dsk Disk korrigiert. (Sollte aber denoch versucht werden richtig von Diskette einzulesen, da nicht klar ist, was beim Fehler zerstört wurde.) Hier das korrigierte Image.


    forth2sX.zip


    Zitat von netmercer

    Tippe auf eine Diskette für den TA alphatronic PC.

    Guter Tipp!:thumbup:


    Die korrigierte Version läßt sich dann mit SAMCONV 2.10 Format für PC8 problemlos einlesen.


    Hier das Ergebnis:


    ###DOS### forth PC8.zip


    Zum Test habe ich noch die Datei FIGFOR.MAC mit dem M80 durchlaufen lassen:



    Bis auf einen Fehler lief die Umwandlung. Sieht also gut aus!


    Schönen Tag!


    PAW

    • Offizieller Beitrag

    Hallo PAW !

    Ich habe das Image nun auf einem anderen Rechner, mit Image Disk unter DOS und einem DD Diskettenlaufwerk mit 40 Retries eingelesen. So wie ich das nun beurteilen kann, war Image Disk zufrieden, ebenso beklagt sich "samdisk info" nicht über fehlerhafte Tracks.


    SAMCONV beklagt sich am Anfang aber über ein falsches "SKEW".


    Es wird aber ansonsten ohne weitere Fehlermeldung konvertiert. Einige Dateien haben aber 0 bytes Größe.



    Das war PAW s Ergebnis:



    Die oben gezeigten Dateien mit Inhalt 0 sind in beiden Images vorhanden. Die guten Dateien sind zumindest gleich groß...


    Könnte Ajax interessieren, der hat ja grade einen PC8 aufgebaut.


    Gruß

    Stephan

  • Hallo Toshi,

    Zitat von Toshi

    Ich habe das Image nun auf einem anderen Rechner, mit Image Disk unter DOS und einem DD Diskettenlaufwerk mit 40 Retries eingelesen. So wie ich das nun beurteilen kann, war Image Disk zufrieden, ebenso beklagt sich "samdisk info" nicht über fehlerhafte Tracks.

    Falls es Dir möglich wäre die Disk nochmal mit SAMdisk einzulesen, wäre es interessant, ob es sich beim ersten mal Einlesen mit SAMdisk nur um einen simplen Lesefehler gehandelt hat, oder ob SAMdisk etwas erkennt, was vielleicht IMD entgangen ist.


    Zitat von Toshi

    SAMCONV beklagt sich am Anfang aber über ein falsches "SKEW".

    Das wird SAMCONV bei zukünftigen Versionen nicht mehr tun! Außerdem versuche ich gerade dem Programm mehr Toleranz beim Lesen beizubringen, was nicht ganz einfach ist. Ich hoffe aber, dass es in Zukunft nicht mehr nötig sein wird mit GUTEDISK zu mergen.



    Der Sektorfehler von der SAMdisk-Version würde sich bei FORTH.COM auswirken! Alle anderen Dateien sind nicht davon betroffen. Man könnte einen Vergleich der zwei konvertierten Programme FORTH.COM durchführen (von DSK und von IMD Images). Falls eine Differenz existiert, wäre es interessant, welche Version tatsächlich auf dem PC8 läuft.



    Hier nochmal ein Aufruf an alle UCSD-User:


    Bitte um UCSD-Images, wie im nachfolgenden Artikel beschrieben:


    STANDARD TESTDISK FÜR UCSD


    damit ich SAMCONV auch für andere UCSD-Maschinen adaptieren kann!:sabber:

    Je mehr unterschiedliche UCSD-Systeme ich bekomme, desto leistungsfähiger kann SAMCONV werden!


    Vielen Dank!


    PAW

    • Offizieller Beitrag

    Hallo Toshi,

    Falls es Dir möglich wäre die Disk nochmal mit SAMdisk einzulesen, wäre es interessant, ob es sich beim ersten mal Einlesen mit SAMdisk nur um einen simplen Lesefehler gehandelt hat, oder ob SAMdisk etwas erkennt, was vielleicht IMD entgangen ist.

    Kann ich probieren. Ich habe nur an meinem WinXP Rechner (für SAMDISK) keine Möglichkeit, ein 360kb DD Laufwerk zu betreiben. Auf meinem 386er, wo ich ein DD Laufwerk habe, läuft natürlich keine Samdisk.

    Vielleicht liegt es daran, daß man DD Disketten doch ein wenig zuverlässiger mit einem nicht-HD Laufwerk lesen kann.

    • Offizieller Beitrag

    wäre es interessant, welche Version tatsächlich auf dem PC8 läuft.

    Die Version, die ich mit IMD eingelesen haben (unter DOS, mit DD Laufwerk) und welche ich mit SAMDISK unter XP (mit HD Laufwerk) geschrieben habe, kann ich - wie das Original - auf dem Alphatronic PC8 lesen und ausführen!

    • Offizieller Beitrag

    Wenn es ein ok -.imd <diskette für den PC8 sind - sollte sowas auf einer KISS / TA P2 (evtl. 100h TPA) laden könnten, oder?

    Der Assembler Source Code ist ja auch dabei.

    FWallenwein habe ich gefragt, es wurde mit dem Microsoft-Assembler 80 übersetzt.

    Ich vermute aber, daß es nicht so einfach geht, weil der PC8 kein MOS hat und das das Wallenwein-Forth speziell auf die PC8

    angepaßt ist (Farbgraphik z.B.)

    Es wäre vmtl. sinniger, das Fig-Forth für den 8080 an MOS anzupassen, oder?

  • wäre es interessant, welche Version tatsächlich auf dem PC8 läuft.

    Die Version, die ich mit IMD eingelesen haben (unter DOS, mit DD Laufwerk) und welche ich mit SAMDISK unter XP (mit HD Laufwerk) geschrieben habe, kann ich - wie das Original - auf dem Alphatronic PC8 lesen und ausführen!

    Super.
    Ich hatte mir damals das Listing des FIG-Forth aus den USA schicken lassen.
    Scheck per Post in die USA geschickt. Wochen später kam das Listing.
    In stundenlanger Arbeit abgetippt und Tippfehler gesucht. Später an TA-PC8 angepasst und erweitert. Später habe ich eine Annonce in der c't aufgegeben. Interessenten habe eine Postkarte geschickt und ich habe die Floppys verschickt.

    Kaum noch vorstellbar heute.
    :)