Disketten Alphatronic P2 archivieren mit SAMDISK/SAMCONV

    • Offizieller Beitrag

    Hallo!


    Habe mir heute nachmittag mal durch die Disketten von FWallenwein gewühlt.

    Leider waren die meisten unbrauchbar. Was ich merkwürdig fand, meistens war Sektor 2 defekt.

    Das Image konnte eingelesen werden, aber mit PAW s SAMCONV konnte dann bis auf wenige Fälle keine Dateien hieraus rekonstruieren.

    Vielleicht ist das einfach so, weil das Material nicht mehr hergibt, vielleicht mache ich aber auch was falsch?


    Verwendet habe ich ein 1.2MB Diskettenlaufwerk & WinXP.


    Meist war die Ausgabe von Samdisk a: xxx.dsk -h0 -c40 -d -ho wie folgt:




    Dann bekomme ich Fehlermeldungen wie:







    Hat noch jemand einen Tip? Mir gehts eher um das grundsätzliche Vorgehen hierbei, ich glaube nicht, daß hier Schätze dabei sind, die man archivieren müsste, weil es sie sonst nirgendwo bekommt.


    Gruß

    Stephan

  • Toshi

    Zitat

    Hat noch jemand einen Tip? Mir gehts eher um das grundsätzliche Vorgehen hierbei, ich glaube nicht, daß hier Schätze dabei sind, die man archivieren müsste, weil es sie sonst nirgendwo bekommt.

    Wenn Du ein paar Images hochlädst, kann ich einen Blick drauf werfen.

    Weiß aber nicht, ob es sich heute noch ausgeht.


    Gruß

    PAW

  • Hallo Toshi ,

    handelt es sich bei den Disketten um Originale? In einem anderen Beitrag wurde schon einmal über einen Kopierschutz bei P2 Disketten diskutiert. Es war die Rede von einer "falschen" Sektorennummer auf Spur 0 und absichtliche CRC Fehler.


    Da Du auf allen Disketten ähnliche Lesefehler immer an der selben Stelle hast, ist es doch eher unwahrscheinlich, daß es sich um echte Defekte handelt. Könnte an dieser Stelle ein eventuell vorhandener "Kopierschutz" ein Image Programm dazu verleiten diesen manipulierten Sektor als defekt einzustufen?

    Es stellt sich dann auch die Frage, ob das Image Programm den realen Inhalt des "defekten" Sektors wirklich 1:1 lesen konnte.


    Nur so ein paar Gedanken...


    Viele Grüße

    netmercer

  • Hallo Toshi ,


    das mit dem Kopierschutz ist nicht von der Hand zu weisen. Da sollte helwie44 † doch mehr darüber wissen!


    Um solche Disketten dennoch mit SAMCONV lesen zu können, kannst Du den "defekten" Systemtrack (Track 0 und 1 sind reservierte Tracks) mit einem "guten" überschreiben. Einfach von einer "guten" P2-Diskette den Track 1 mergen.


    SAMdisk GUTEDISK.dsk SamImage.dsk -c1-1 --merge


    Habe ich mit der Games-Diskette gemacht und dann bekommst man dieses Ergebnis mit SAMCONV:


    ###DOS###-games.zip


    Habe noch versucht ein Programm davon im CP/M-Emulator zu starten, was allerdings nur einen leeren Schirm brachte. Eine Codeinspecktion von PIP.CPM brachte ein ähnliches Bild, wie es bei meinen Systemen üblich ist, allerdings mit kleinen Abweichungen. Wäre interessant, ob die üblichen Programme vom P2 im CP/M-Emulator laufen.


    Für das andere Image hatte ich kaum Zeit! Es sieht jedenfalls seltsam aus, auch wenn man den "defekten" Track weg-merged. Stimmt was mit dem CP/M-Verzeichnis nicht. Ist zerhackt, als ob es einen Interleave gäbe. Allerdings auf Basis von 128 Byte Sektoren, obwohl hier 256 Byte Sektoren gespeichert sind.


    Schönen Tag, PAW

  • Ich würde auch von Kopierschutz ausgehen...

  • Hallo - ich hatte am WE noch andere Dinge zu erledigen.


    Sind das Kandidaten mit ? K-Schutz ?.

    Dateien

    • test.zip

      (190,03 kB, 2 Mal heruntergeladen, zuletzt: Vor 4 Stunden)




    Sagt doch was da auf der/denen Disketten sein sollte ( auch ob FM oder normal MFM?

  • ok - schaue mal in das .zip...


    Aber wenn ich die FOTOS von der FEHLERMELDUNG erkenne, dann ist genau mit

    dem K-Schutz von TA eindeutig zu sehen.


    Vorgang bei TA:

    Auf der Spur 1 und dem eigentlichen 16.ten Sector, wird eine SEC-ID mit 19 dezimal generiert und beim Datenfeld wird nach einigen Bytes mit einem Abord CMD beendet.

    Kann kaum ein normaler TA USER damals...sowas aus zu tricksen.


    Im TA cp/m Lader/Rebooter wird kontrolliert ob bei T=1, und SEC=19 mit Error vorhanden ist!!! Wenn nicht hängt der Rechner.... oder sowas???

  • Zitat von PAW

    PAWFür das andere Image hatte ich kaum Zeit! Es sieht jedenfalls seltsam aus, auch wenn man den "defekten" Track weg-merged. Stimmt was mit dem CP/M-Verzeichnis nicht. Ist zerhackt, als ob es einen Interleave gäbe. Allerdings auf Basis von 128 Byte Sektoren, obwohl hier 256 Byte Sektoren gespeichert sind.

    Habe jetzt Zeit gefunden, das Problem "p2cpm.dsk" näher zu untersuchen!


    Hier nochmal die Geometrie laut SAMdisk SCAN:


    TRIUMPH ADLER\p2cpm.dsk

    40 Cyls, Head 0:

    250Kbps MFM, 16 sectors, 256 bytes/sector:

    0.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    1.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 19[m2,dc]

    diff 15 (19): =17 -1 =238

    2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    3.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    4.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    5.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    6.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    7.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    8.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    9.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    10.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    11.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    12.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    13.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


    Wenn man das Image mit einem Hexeditor betrachtet sieht das so aus:

    Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF

    0000.2500 00 50 49 50 20 20 20 20 20 43 4F 4D 00 00 00 3A │.PIP COM...:│

    0000.2510 02 03 04 05 06 07 08 09 00 00 00 00 00 00 00 00 │................│

    0000.2520 00 43 50 4D 43 4F 50 59 20 43 4F 4D 00 00 00 20 │.CPMCOPY COM... │

    0000.2530 0A 0B 0C 0D 00 00 00 00 00 00 00 00 00 00 00 00 │................│

    0000.2540 E5 54 45 58 54 20 20 20 20 42 41 53 00 00 00 80 │.TEXT BAS....│

    0000.2550 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D │................│

    0000.2560 E5 54 45 58 54 20 20 20 20 42 41 53 01 00 00 27 │.TEXT BAS...'│

    0000.2570 1E 1F 20 21 22 00 00 00 00 00 00 00 00 00 00 00 │.. !"...........│

    0000.2580 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.2590 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25A0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25B0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25C0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25D0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25E0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.25F0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.2600 E5 54 45 58 54 20 20 20 20 43 4F 4D 00 00 00 80 │.TEXT COM....│

    0000.2610 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 │#$%&'()*+,-./012│

    0000.2620 E5 54 45 58 54 20 20 20 20 43 4F 4D 01 00 00 57 │.TEXT COM...W│

    0000.2630 33 34 35 36 37 38 39 3A 3B 3C 3D 00 00 00 00 00 │3456789:;<=.....│

    0000.2640 E5 4B 41 4C 46 4F 20 20 20 42 41 53 00 00 00 74 │.KALFO BAS...t│

    0000.2650 3E 3F 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 00 │>?ABCDEFGHIJKLM.│

    0000.2660 E5 43 55 52 53 4F 52 20 20 52 45 4C 00 00 00 01 │.CURSOR REL....│

    0000.2670 4E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │N...............│

    0000.2680 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.2690 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26A0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26B0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26C0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26D0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26E0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.26F0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.2700 E5 50 52 4F 47 31 20 20 20 52 45 4C 00 00 00 03 │.PROG1 REL....│

    0000.2710 4F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │O...............│

    0000.2720 E5 46 4F 52 4C 49 42 20 20 52 45 4C 00 00 00 80 │.FORLIB REL....│

    0000.2730 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F │PQRSTUVWXYZ[\]^_│

    0000.2740 E5 46 4F 52 4C 49 42 20 20 52 45 4C 01 00 00 4D │.FORLIB REL...M│

    0000.2750 60 61 62 63 64 65 66 67 68 69 00 00 00 00 00 00 │`abcdefghi......│

    0000.2760 E5 42 41 53 4C 49 42 20 20 52 45 4C 02 00 00 76 │.BASLIB REL...v│

    0000.2770 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 │rstuvwxyz{|}~...│


    Es ist unklar, wie die Stellen mit „@@@@@@@@@@@@“ in das Inhaltsverzeichnis kommen. Ob das auch ein Zugriffsschutz ist, oder nur ein Systemfehler? Dies hindert jedenfalls SAMCONV daran das Image zu lesen.



    Korrektur der Diskette mittels Hexeditor im DSK-File (zusätzlich zum Merge mit Systemspur):


    1.) Fehlerhafte Teile in Directory mit hex E5 befüllen (= deleted entry).

    2.) Zusätzlich gelöschte Einträge wieder aktivieren (hex E5 auf 00 setzen).


    Sieht dann so aus (unterstrichene Stellen geändert):

    Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF

    0000.2400 00 50 49 50 20 20 20 20 20 43 4F 4D 00 00 00 3A │.PIP COM...:│

    0000.2410 02 03 04 05 06 07 08 09 00 00 00 00 00 00 00 00 │................│

    0000.2420 00 43 50 4D 43 4F 50 59 20 43 4F 4D 00 00 00 20 │.CPMCOPY COM... │

    0000.2430 0A 0B 0C 0D 00 00 00 00 00 00 00 00 00 00 00 00 │................│

    0000.2440 00 54 45 58 54 20 20 20 20 42 41 53 00 00 00 80 │.TEXT BAS....│

    0000.2450 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D │................│

    0000.2460 00 54 45 58 54 20 20 20 20 42 41 53 01 00 00 27 │.TEXT BAS...'│

    0000.2470 1E 1F 20 21 22 00 00 00 00 00 00 00 00 00 00 00 │.. !"...........│

    0000.2480 E5 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │.@@@@@@@@@@@@@@@│

    0000.2490 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.24A0 E5 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │.@@@@@@@@@@@@@@@│

    0000.24B0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.24C0 E5 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │.@@@@@@@@@@@@@@@│

    0000.24D0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│

    0000.24E0 E5 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │.@@@@@@@@@@@@@@@│

    0000.24F0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│


    test - p2cpm- UNDELETED und 40 auf E5 geändert.zip


    Hier das Ergebnis nach Auswertung mit SAMCONV Vers 2.10:


    ###DOS### p2cpm- UNDELETED.zip


    Es sind sogar zwei Basic-Programme als Quelltext dabei!


    Die „Fehler“ dürften offenbar nur das Inhaltsverzeichnis betreffen, da die Daten ja gut auslesbar waren.


    Frage an Toshi: gibt es noch andere Images mit solchen „@@@@“ im Verzeichnis?

    Wenn ja, dann bitte um Kopie der Images, damit ich sie näher ansehen kann, da es sich dann vermutlich nicht um einen einmaligen Systemfehler handeln kann.


    Gruß, PAW

  • test.zip Analyse

    In dem .zip File sind zwei .DSK images!

    Beim p2cpm.dsk ist ein TA P2 cp/m für 4300h TPA also mit 48 kB.

    Wie vermutet - genau zu sehen ist das der Spur 1 mit Sector eigentlich 16 mit ID als 19 dezimal eingerichtet wurde. (wie zuvor bekannt)


    Ich gehe davon aus - dass der directory - Bereich ab Track 2 und mit zwei cluster belegbar sind. Je cluster wurde bei (sks, TA, HELL) also hier mit 1 kB eingerichtet wurden.


    Das weiss jeder - weil das erstes gespeichters Programm/ File mit dem CLUSTER 2 +++ folgend benutzt wird.

    Daher zählen immer (Anfang) im cp/m mit 0 (null) die CLUSTER / BLÖCKE.

    Somit ist klar das für das Verzeichnis / directory mit 0 und 1 reserviert wurden!

    Popelt man den cp/m CODE raus - würde man den DPB finden und die Aussagen nochmals bestätigen.

    (Wer Lust hat - ist das immer eine schöne Aufgabe - nicht ernst gemeint)


    Hätte oder hat man eine solche Diskette, würde sicher von einem laufendem cp/m (egal mit 0100h oder 4300h TPA) mit identischer cp/m DPB (DiskParameterBlock) von einem anderen DRIVE les- schreibbar sein!!!!


    Die dort befindlichen Programme / Files sind eigentlich an vielen Stellen (4300h TPA) vorhanden.

    Bis auf die ofenbar erstellten BASIC / Fortran ? Anwendungen sind ja ohne Dokumente - also nutzlos, oder?



    Wo und auf welchern SERVERN sind / sollten IMAGES gesichert werden?


    Jetzt eine gute FRAGE:
    Warum sind in einem images nur 128 Byte im director Bereich (physikalischer SECTOR) belegt worden?

    Die weitern 128 Byte sind ja offenbar mit HEX 40h vorbelegt gewesen / oder wurde historisch so eingerichtet.

    Dieser Zustand ist kein Teil von TA als K-Schutz!

    Nur evtl. andere Programm-Analyser kommen ins Schleudern - die Urentstehung ist trivialer!

    helwie44 †

  • Hallo,

    Dank an PAW für die Imageuntersuchung und helwie44 † für die Analyse des Kopierschutzes und der CP/M Struktur.

    Damit sind hier P2 Disketten mit einem 48K CP/M (TPA ab 4300H) aufgetaucht an denen Besitzer einer "Standard" P2 ohne Bankswitching ihre Freude haben dürften. Die üblichen CP/M Programme für eine TPA ab 0100H bleiben solchen P2's ja verwehrt.

    Jetzt gibt es neues Futter für die Maschine... :juchee:


    Mit HEX 40H angefüllte Sektoren sind mir schon auf Disketten mit dem TA Disk-Basic begegnet. Vielleicht ist ja mal eine kleine Verwechslung passiert ???


    Viele Grüße

    netmercer

  • Der Beitrag von FWallenwein "Alphatronic P2....


    Am Anfang war der Bereich ja richtig Biete....

    Nun aber:

    Biete zu einer Aplahtronic P2, Display, Disketten habe ich mit viel "suchen" im FORUM diesen LINK gefunden.


    Denn zu der P2 von guter Hand sind gute FOTOS und viele Informationen zu der Maschine nicht im TA tread leicht zu finden.

    Könnte man die Abhandlung bis zur "feierlicher" Übergabe Toshi doch in den BEREICH TA zu verschieben!!!!

    • Offizieller Beitrag

    erledigt: Wiederbelebung Alphatronic P2, Bildschirm, Disketten

    • Offizieller Beitrag

    Damit sind hier P2 Disketten mit einem 48K CP/M (TPA ab 4300H) aufgetaucht an denen Besitzer einer "Standard" P2 ohne Bankswitching ihre Freude haben dürften. Die üblichen CP/M Programme für eine TPA ab 0100H bleiben solchen P2's ja verwehrt.

    OK - heißt das, bisher gabt es noch kein archiviertes CP/M für TA P2 und nur 48kb?

  • Damit sind hier P2 Disketten mit einem 48K CP/M (TPA ab 4300H) aufgetaucht an denen Besitzer einer "Standard" P2 ohne Bankswitching ihre Freude haben dürften. Die üblichen CP/M Programme für eine TPA ab 0100H bleiben solchen P2's ja verwehrt.

    OK - heißt das, bisher gabt es noch kein archiviertes CP/M für TA P2 und nur 48kb?

    Doch natürlich, ich verwende das auf meinen Rechnern (zur Verfügung gestellt von helwie44 †)

  • Hallo Leute - ich habe auf meiner kleiner WEB-Sammlung ( zu TA, sks, HELL nicht schön aber was ich finde) lege ich möglichst Unterlagen und IMAGES dort ab.

    Sicher könnten noch div. Sachen fehlen.

    Bei einigen Dokumenten hat freundlich fritzeflink oft große FILES auch bei sich auf seinem SERVERN abgelegt.


    Aber evtl. sollten die relevanten Unterlagen besser anders Zukunftssicherung aufgebaut werden?

    Wie habe ich im Moment keinen Plan - aber überlegen wäre schon möglich, oder?

    Grüße helwie44 †

  • Damit sind hier P2 Disketten mit einem 48K CP/M (TPA ab 4300H) aufgetaucht an denen Besitzer einer "Standard" P2 ohne Bankswitching ihre Freude haben dürften. Die üblichen CP/M Programme für eine TPA ab 0100H bleiben solchen P2's ja verwehrt.

    OK - heißt das, bisher gabt es noch kein archiviertes CP/M für TA P2 und nur 48kb?

    Doch natürlich, ich verwende das auf meinen Rechnern (zur Verfügung gestellt von helwie44 †)


    Dann verstehe ich netmercer s Kommentar nicht...


    Hallo,

    meine Euphorie bezog sich weniger auf das 48K CP/M selber, sondern auf die Aussicht auf weitere Programme für eine TPA ab 4300H. Ich weiß nicht, ob es bei jedem so richtig durchgedrungen ist: Nur speziell für das 48K CP/M und eine TPA ab 4300H angepaßte Programme laufen auf einer P2. Die ganze restliche Masse an CP/M Programmen tut das nicht. Deshalb laufen diese 48K CP/M Programme auch nicht auf den üblichen CP/M Emulatoren, so wie es hier versucht wurde.

    Bisher ist mir persönlich nur das 48K CP/M Paket von helwie44 † (herzlichen Dank dafür) über den Weg gelaufen, ansonsten komplette Ebbe (bezogen auf das 48K CP/M). Dann tauchen hier mir bisher unbekannte 48K CP/M Disketten auf, auch noch mit unterschiedlichen BIOS Versionen wie V1.2 und V1.3 und dann noch ein liebenswerter TA Kopierschutz... :juchee:

    Jetzt fehlt mir das Verständnis, wie man hier nicht hoch erfreut sein kann. :hüpf:

    Viele Grüße

    netmercer

  • Hallo Toshi ,

    ja, ich denke so ist es!

    Wenn dies alles 48K CP/M Versionen sind, dann sind das alles spezielle P2 Versionen und damit aus meiner Sicht schon etwas besonderes.


    Viele Grüße

    netmercer

  • Hallo Toshi

    Zitat

    Was hast Du denn in diesem Fall als "gute Disk" genommen?

    Ich habe diese Tracks genommen. Sind wahrscheinlich nicht lauffähig, aber für das Einlesen mit SAMCONV sehr geeignet. Prinzipiell könnte man jeden Track nehmen, der keinen Fehler aufweist.


    GUTEDISK.zip


    Danke auch für die neuen Images. Werde ich mir im Laufe der Woche ansehen.


    Gruß PAW

    • Offizieller Beitrag

    OK!

    Heißt das, wenn ich normal mit samdisk die "kopiergeschützte Disk" einlese und dann wieder unverändert auf Diskette zurückschreibe, müßte sie der Rechner lesen können ? Oder kann Samdisk diesen Kopierschutz nicht korrekt kopieren?


    Nur für das rausschreiben der Files auf PC ist diese Aktion nötig?


    Danke sehr

  • netmercer OK, Ich habe hier aus dem Diskettensatz noch Basic Interpreter und Compiler, Fortran, Forth, Assembler, Wordstar und oben genanntes Adress& Text Programm. Du meinst, das ist womöglich "neu" und hilfreich?

    Das reine 48 KB CP/M ist nix besonderes, aber diese Programme (wenn auf 48 KB P2 lauffähig) finde ich auch cool. Mir fehlt für P2 auch noch jegliche Software, abgesehen vom CP/M Betriebssystem und Diskbasic ;)
    Ich werde mir bei Gelegenheit mal das AT2 Programm ansehen.

  • He, Leute ...

    klar meine chaotische WEB-Sammlung enthält schon seit einigen Jahren zu mindestens

    ein PACK von 4300h TPA SYSTEMPROGRAMMEN.

    Damit kann man richtig was machen / programmieren könnte - wer Lust und Zeit hätte!

    Mein Powerpack4300h hier, gleich sichern!

    Frohes FORSCHEN im TA P2 (only 48 kB cp/m) - Bereich.

    Grüße helwie44 †

  • Aus AT2.ZIP konnte ich beide Disks schreiben, obwohl IMD gemeckert hat. Auf meiner P2 sind die Disks grundsätzlich funktionsfähig. Die AT2 Disk hat allerdings ein paar Macken: Im Verzeichnis gibt es den seltsamen Eintrag (das hatte PAW ja schon festgestellt) und die Programme laufen nur bedingt. Im Editor komme ich bis zur "Kommandoeingabe", dann passiert aber nix mehr. Die Adresserfassung fordert mich zum Einlegen einer Disk und Verriegeln des Laufwerks auf, dann passiert ebenfalls nichts mehr.

    Die zweite Disk (TRANS, d.h. ein CPM Dateitransfer-Programm) funktioniert korrekt (wobei ich die Übertragung selbst nicht getestet habe).

  • Guten Morgen,

    Zitat von Toshi

    Heißt das, wenn ich normal mit samdisk die "kopiergeschützte Disk" einlese und dann wieder unverändert auf Diskette zurückschreibe, müßte sie der Rechner lesen können ? Oder kann Samdisk diesen Kopierschutz nicht korrekt kopieren?


    Nur für das rausschreiben der Files auf PC ist diese Aktion nötig?


    Ich habe versuchsweise eines dieser images mittels SAMdisk auf eine Disk geschrieben und wieder eingelesen. Der SAMdisk SCAN zeigt bei der Kopie die gleiche Struktur wie beim Original-Scan. Das ließe darauf schließen, dass der Kopierschutz mitkopiert wird. Hier die Geometrie von AT2.DSK



    Wäre natürlich interessant, ob eine solche Kopie mit SAMdisk auch tatsächlich funktioniert. gpospi hat ja getestet, aber nur eine Kopie mit IMD. Vielleicht kann das noch jemannd ausprobieren, um sicherzustellen, dass SAMdisk auch dafür einsetzbar ist.


    Interessant ist bei AT2.DSK, dass auf dem Track 16 (hex 10) 17 Sektoren vorhanden sind.

    Hier erhebt sich die Frage, ob dies auch wieder ein Kopierschutz ist und ob die Daten vom 17. Sektor relevant (fürs Extrahieren) sind.


    Wie schon gpospi festgestellt hat, sind bei beiden Disketten im Inhaltsverzeichnis wieder die Blöcke mit den "@@@@@@@@" zu finden. Das is also kein Zufall, sondern hat System. Dies tritt aber jeweils nur auf dem Track mit dem Inhaltsverzeichnis auf, nicht aber auf den nachfolgenden Datentracks.


    TIPP: Beim Erstellen einer neuen Zusammenstellung von Programmen auf einer Disk mit SAMCONV müssen nach Erstellung der DSK-Datei die Original System Tracks 0 und 1 (von einem funktionierenden Systemdisketten-Image) mittels SAMdisk MERGE aufgespielt werden. Dann könnte das neue DSK-image auf Diskette geschrieben und getestet werden.


    Ich wünsche noch einen schönen Tag!


    PAW