Hallo Fritz fritzeflink
habe mal alles rausgesucht was mit P2 zu tun hat. Stammen alle aus SuperC...
Die Definitionen sollten sich auf 22DISK übersetzen lassen.
Wenn du ein .IMD-File hochlädst, kann ich morgen eventuell mit SAMCONV.xls versuchen diese zu lesen. Oder Du versuchst es selbst. Müsstest die IMD mittels SAMdisk in eine DSK umwandeln und dann mit SAMCONV einlesen.
Schönen Abend!
PAW
danke, mit SCopy muss ich wohl einen 486er nehmen.
JenGun hat mich auf das PDrive vom genie IIIs verwiesen ... 
Ich hatte ja die Hoffnung dass zum P2 schon Definitionen für 22disk vorhanden sind.
Bei 2 Images habe ich in der RAW Datei vor den Dateinamen überall E5 gesehen - ist ja blöd wenn alles als gelöscht markiert wurde.
Danke erst mal an alle - muss ich mir morgen genauer anschauen.
Aus PDrive:
Format Nummer 83 : ALPHATRONIC P2UV
Logische Parameter:
1216 128 Byte Record Capacity
152 Kilobyte Drive Capacity
64 32 Byte Directory Entries
64 Checked Directory Entries
128 Records / Extend
8 Records / Block
32 Sectors / Track
2 Reserved Tracks
Drive Parameter Block (DPB):
2000 03 07 00 9700 3F00 C000 1000 0200
Physikalische Parameter
Sektorlaenge: 256 Bytes
Double Density
Normale Aufzeichnung
Double Step
Sektortabelle: 16 Physikalische Sektoren
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 ,
9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 ,
#
Format Nummer 84 : ALPHATRONIC P2UR
Logische Parameter:
1216 128 Byte Record Capacity
152 Kilobyte Drive Capacity
64 32 Byte Directory Entries
64 Checked Directory Entries
128 Records / Extend
8 Records / Block
32 Sectors / Track
2 Reserved Tracks
Drive Parameter Block (DPB):
2000 03 07 00 9700 3F00 C000 1000 0200
Physikalische Parameter
Sektorlaenge: 256 Bytes
Double Density
Normale Aufzeichnung
Double Step
Doppelseitig
Rueckseite laut Sektortabelle
Sektortabelle: 16 Physikalische Sektoren
1 R , 2 R , 3 R , 4 R , 5 R , 6 R , 7 R , 8 R ,
9 R , 10 R , 11 R , 12 R , 13 R , 14 R , 15 R , 16 R , Hallo Fritz,
es gibt für die P2 zwei prinzipiell unterschiedliche CP/M Versionen. Eine für 48KB RAM (TPA ab 4300H) und eine für 64KB RAM (TPA ab 100H).
Die Programme für die Version mit TPA ab 4300H laufen vermutlich nur auf einer entsprechenden P2.
Gruß
netmercer
Hallo Fritz,
es gibt für die P2 zwei prinzipiell unterschiedliche CP/M Versionen. Eine für 48KB RAM (TPA ab 4300H) und eine für 64KB RAM (TPA ab 100H).
Die Programme für die Version mit TPA ab 4300H laufen vermutlich nur auf einer entsprechenden P2.
Gruß
netmercer
Danke für die Info,
dann ist es die 48K Version sein.
Sonst könnte hier auch Martin.W helfen...
Hallo Fritz,
ja, es ist die Version für P2's mit 48KB RAM.
Im zweiten Bild sieht man den ersten Sektor der Disk mit einer Batch Datei, um CP/M in den Speicher zu laden.
Diese Batch Datei wird mit dem Befehl "B" vom MOS Betriebssystem aus in den Speicher geladen und ausgeführt. Die beiden "I" Befehle laden dann CP/M in den Speicher und der "U" Befehl springt den Kaltstart von CP/M an.
Gruß
netmercer
Die Disks haben unterschiedliche Formate (oder die .BINs sind fehlerhaft) !
7, 8, 10, 11 und 13 tanzen aus der Reihe - scheint kein CP/M Format zu sein.
Für Disk 6 fehlt die .BIN Datei.
Hier der entsprechende 'diskdefs' Eintrag für cpmtools:
diskdef tap2
seclen 256
tracks 38
sectrk 16
blocksize 1024
maxdir 64
boottrk 2
os 2.2
end
Korrekt, die Disketten ohne CP/M werden aus dem MOS des P2 bedient.
Die Formatdefinition für CP/M ist inzwischen geklärt. Da es, wie netmercer oben schrieb, ein angepasstes CP/M für 48k Hauptspeicher ist kann es nur
auf der passenden P2 Maschine getestet werden.
Die Formate aus Scopy und Pdrive stimmen überein.
Hallo Fritz,
ja, es ist die Version für P2's mit 48KB RAM.Im zweiten Bild sieht man den ersten Sektor der Disk mit einer Batch Datei, um CP/M in den Speicher zu laden.
Diese Batch Datei wird mit dem Befehl "B" vom MOS Betriebssystem aus in den Speicher geladen und ausgeführt. Die beiden "I" Befehle laden dann CP/M in den Speicher und der "U" Befehl springt den Kaltstart von CP/M an.
Anbei die Images, es wäre schön wenn die jemand auf einer TA P2 48K Maschine mal testen würde.
Hallo Fritz, fritzeflink
habe mir das Image TAP2-01.IMD (aus obigem ZIP-File) angesehen und mit TAP2-01.BIN verglichen. Wollte SAMCONV.xls testen, hatte aber Probleme nach der Umwandlung von IMD auf DSK, da bei Track 1 (ist noch ein SYS-Track) der letzte Sektor fehlerhaft war (statt ID 16 ... ID 19). Dadurch stürzte SAMCONV ab, weil die Sektordaten nicht in DSK vorhanden waren. Habe das jetzt behoben (SAMCONV überspringt jetzt die SYS-Tracks korrekt), bekomme aber die Meldung, dass das Directrory nicht passt.
Das CP/M Verzeichnis unterscheidet sich vom Inhalt der beiden Images komplett!
Das IMD-Image scheint 128 Byte Sektoren zu haben ... siehe @@@@@
obwohl die Sektoren 256 Byte haben.
Eventuell nochmal das IMD-Image ansehen. Sollte so eigentlich nicht funktionieren?
Grüße, PAW
Dateiname: TAP2-01.BIN
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
0000.2000 00 42 41 53 43 4F 4D 20 20 43 4F 4D 00 00 00 80 │.BASCOM COM....│
0000.2010 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 │................│
0000.2020 00 42 41 53 43 4F 4D 20 20 43 4F 4D 01 00 00 78 │.BASCOM COM...x│
0000.2030 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 00 │.............. .│
0000.2040 00 4D 42 41 53 49 43 20 20 43 4F 4D 00 00 00 80 │.MBASIC COM....│
0000.2050 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 │!"#$%&'()*+,-./0│
0000.2060 00 4D 42 41 53 49 43 20 20 43 4F 4D 01 00 00 36 │.MBASIC COM...6│
0000.2070 31 32 33 34 35 36 37 00 00 00 00 00 00 00 00 00 │1234567.........│
0000.2080 00 47 42 41 53 49 43 20 20 43 4F 4D 00 00 00 80 │.GBASIC COM....│
0000.2090 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 │89:;<=>?@ABCDEFG│
0000.20A0 00 47 42 41 53 49 43 20 20 43 4F 4D 01 00 00 42 │.GBASIC COM...B│
0000.20B0 48 49 4A 4B 4C 4D 4E 4F 50 00 00 00 00 00 00 00 │HIJKLMNOP.......│
0000.20C0 00 4C 38 30 20 20 20 20 20 43 4F 4D 00 00 00 46 │.L80 COM...F│
0000.20D0 51 52 53 54 55 56 57 58 59 00 00 00 00 00 00 00 │QRSTUVWXY.......│
0000.20E0 00 42 41 53 4C 49 42 20 20 52 45 4C 00 00 00 80 │.BASLIB REL....│
0000.20F0 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 │Z[\]^_`abcdefghi│
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEFIMD ist natürlich im Dump gegenüber BIN etwas verschoben.
Die bei BIN für BASCOM.COM allokierten Blöcke 02, 03, 04, ... sind bei IMD für STAT.COM reserviert.
Dateiname: TAP2-01.IMD
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
0000.1E80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................│
0000.1E90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................│
0000.1EA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................│
0000.1EB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................│
0000.1EC0 00 00 00 00 00 00 00 00 00 00 02 00 00 05 02 00 │................│
0000.1ED0 10 01 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E │................│
0000.1EE0 0F 10 01 00 53 54 41 54 20 20 20 20 43 4F 4D 00 │....STAT COM.│
0000.1EF0 00 00 28 02 03 04 05 06 00 00 00 00 00 00 00 00 │..(.............│
0000.1F00 00 00 00 00 4D 38 30 20 20 20 20 20 C3 4F 4D 00 │....M80 .OM.│
0000.1F10 00 00 80 07 08 09 0A 0B 0C 0D 0E 16 17 28 2A 2F │.............(*/│
0000.1F20 30 31 34 00 45 44 20 20 20 20 20 20 43 4F 4D 00 │014.ED COM.│
0000.1F30 00 00 34 0F 10 11 12 13 14 15 00 00 00 00 00 00 │..4.............│
0000.1F40 00 00 00 00 4D 38 30 20 20 20 20 20 C3 4F 4D 01 │....M80 .OM.│
0000.1F50 00 00 10 35 36 00 00 00 00 00 00 00 00 00 00 00 │...56...........│
0000.1F60 00 00 00 40 40 40 40 40 40 40 40 40 40 40 40 40 │...@@@@@@@@@@@@@│
0000.1F70 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEFHallo,
die Sektor ID 19 für den letzten Sektor der Systemspuren kann durchaus korrekt sein. TA hatte meines Wissens Vorkehrungen getroffen, daß die von TA verkauften Disketten mit CP/M Runtime nicht beliebig einfach kopiert werden konnten.
Waren das original TA Disketten von denen fritzeflink die Images gezogen hat?
Das war vermutlich so eine Art Kopierschutz mittels einen absichtlich "defekten" Sektor.
Darüber könnte helwie44 † eventuell mehr wissen.
Viele Grüße
netmercer
danke für den Hinweis, anbei die gesamten Images in der ZIP
Das IMD-Image scheint 128 Byte Sektoren zu haben ... siehe @@@@@
obwohl die Sektoren 256 Byte haben.
Ja - merkwürdig. Ich weiss natürlich nicht was mit der Diskette passiert ist, Ich denke aber ich habe die verkehrte IMD Datei eingetütet.
Das werde ich mir noch mal anschauen.
Ich habe jetzt die TAP2-01 und die TAP2-01a dabei. Die Disketten sind keine Originale sondern Kopien, welche mir obbi zugesteckt hat.
Das Format für 22disk welches ich nutze:
BEGIN P2UV Alphatronic P2 Vorderseite - 1x40x16x256 48tpi 5.25"
DENSITY MFM ,LOW
CYLINDERS 40 Sides 1 SECTORS 16,256
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
BSH 3 BLM 7 EXM 0 DSM 151 DRM 63 AL0 0C0H AL1 0 OFS 2
END
Darüber könnte helwie44 † eventuell mehr wissen.
helwie44 † ist leider verstorben. 
Ich habe jetzt die TAP2-01 und die TAP2-01a dabei.
Habe die Dateien aus TAP2-01a mit SAMCONV.xls verglichen. Sind identisch! Ist auch kein Fehler im Systemtrack vorhanden.
Auch wenn ich ein glaubwürdiges Directory habe muss ich mir das noch genauer anschauen.
Hier handelt es sich offenbar um TAP2-04. Ein Vergleich der Dateien mit SAMCONV ist ebenfalls identisch.
Hier ist jetzt wieder der Fehler (Kopierschutz?) zu sehen.
Außerdem sind auch die Direktoryeinträge jeweils nur 128 Byte lang. Der Rest ist mit 128 x @ aufgefüllt. Möglicherweise auch Kopierschutz?
Dateiname: TAP2-04.IMD
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
0000.1F80 01 00 53 54 41 54 20 20 20 20 43 4F 4D 00 00 00 │..STAT COM...│
0000.1F90 28 02 03 04 05 06 00 00 00 00 00 00 00 00 00 00 │(...............│
0000.1FA0 00 00 4D 38 30 20 20 20 20 20 C3 4F 4D 00 00 00 │..M80 .OM...│
0000.1FB0 80 07 08 09 0A 0B 0C 0D 0E 16 17 28 2A 2F 30 31 │...........(*/01│
0000.1FC0 34 00 45 44 20 20 20 20 20 20 43 4F 4D 00 00 00 │4.ED COM...│
0000.1FD0 34 0F 10 11 12 13 14 15 00 00 00 00 00 00 00 00 │4...............│
0000.1FE0 00 00 4D 38 30 20 20 20 20 20 C3 4F 4D 01 00 00 │..M80 .OM...│
0000.1FF0 10 35 36 00 00 00 00 00 00 00 00 00 00 00 00 00 │.56.............│
0000.2000 00 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │.@@@@@@@@@@@@@@@│
0000.2010 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2020 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2030 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2040 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2050 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2060 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
0000.2070 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 │@@@@@@@@@@@@@@@@│
Adresse 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEFSchönen Abend!
PAW
Wenn ich mich recht entsinne, gab es bei der P2 (CP/M) eine Besonderheit mit den Spuren. Für Gewöhnlich hatte man die geraden Spurnummern auf Side 0 und die ungeraden auf Side 1 - bei der P2 galt das aber erst ab Spur 4
Side 1 2 3 5 7 ...
Side 0 0 1 4 6 ...
Es gab bei der P2 (CP/M) zwei reservierte Spuren für das Betriebssystem Side0 Track 0 und Track 1 ...
Alles schon verdammt lang her, ca. 40 Jahre - und - was ich damals programmiert habe - obwohl es halbwegs dokumentiert ist, erschließt sich mir heute nicht mehr so ganz ..
Hallo Nittygritty,
vermischt Du hier eventuell etwas mit dem CP/M Diskettenformat für die P3?
Die P2 hat unter CP/M eigentlich nur ein einseitiges Format. Bei den Doppelkopflaufwerken der P2S bzw P2U werden die Rückseiten der Disketten über einen eigenen Laufwerksbuchstaben angesprochen. Man hat dann zusätzlich zu Laufwerk A: und B: noch die CP/M Laufwerke C: und D:, die hardwaretechnisch nur die Rückseiten von A: und B: sind.
Viele Grüße
netmercer