Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » Kodeknacker » Themenansicht

Autor Thread - Seiten: -1-
000
24.11.2020, 11:52 Uhr
Rüdiger
Administrator


Ich habe Magnetbänder aus der DDR, die auf unbekannte Weise entstanden sind, inhaltlich komisch aussehen und vermutlich K1600-Rechnern bzw. PDP11 zuzuordnen sind. Hier ein Stück davon im Hex-Editor:



Statistisch aufgeschlüsselt (ganz links ist #00, ganz rechts ist #FF) sieht das so aus:



Der hohe Balken ist #C0, könnte eventuell der Repräsentant für das Nullzeichen oder das Leerzeichen sein.
Wenn ich den ausblende, sieht die Statistik so aus:



Es fällt sofort auf, dass zwei Bereiche (0...39) und 80...BF) unbesetzt sind: das Bit 7 ist also permanent eingeschaltet.
Auch innerhalb der beiden Gebirge treten nur die Hälfte der möglichen Kombinationen auf.

Hat jemand schon mal sowas gesehen bzw eine Idee, was das für eine Kodierung ist bzw. welches Programm sowas produziert?

Ich halte die Daten für inhaltlich valide.
Textpassagen lassen sich nicht erkennen, weder als ASCII noch als EBCDIC noch als Radix50.
Es gibt Bänder, die strukturiert wirken (also eventuell Datenbanken beinhalten) und andere, die "unstrukturiert" wirken, also eventuell binäre Programme beinhalten.
Eine Komprimierung zwecks Platzsparung ist es sicher nicht.
Eine Verschlüsselung zwecks Datenschutz wahrscheinlich auch nicht.
Eher eine technische Kodierung, vielleicht um eine hohe Fehlersicherheit zu gewährleisten, vielleicht kompatibel mit einem Lochbandcode oder irgendwas, das gut über Modems versendbar ist?
Die Aufkleber verraten leider nichts über das Kodierverfahren bzw. Herkunft.


Im Vergleich dazu, ein normaler Datenträger mit binärem Inhalt sieht statistisch so aus:


--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
24.11.2020, 12:37 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

ist das vielleicht noch GCR-codiert (group coded recording) ?
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
24.11.2020, 15:27 Uhr
Rüdiger
Administrator



Zitat:
volkerp schrieb
ist das vielleicht noch GCR-codiert (group coded recording) ?



Die Idee ist grundsätzlich gut.
Ich habe zwar keine Erfahrung mit GCR, würde aber bei deren 5-nach-4-Bit-Umwandlung erwarten, dass bei GCR solche Bereiche mit gleichartigen Bytes...

...nicht auftreten können. Was meinst Du?
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
25.11.2020, 13:57 Uhr
PIC18F2550

Avatar von PIC18F2550

wenn sich das nur um Steuerdaten handelt kann es so aussehen.
Beim Schuhlausflug hatte ich mal eine Fräße mit Magnetband gesehen.
Das Band pfiff dauernd hin und her um am ende ein Stückchen weiter zu kommen.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
25.11.2020, 14:28 Uhr
Rüdiger
Administrator


So sieht so ein Band blockmäßig aus:

Quellcode:

//   +---File 0: 1 records
//   |   `---Record 0.0: 2976 bytes
//   +---File 1: 22 records
//   |   +---Record 1.0: 138 bytes
//   |   +---Record 1.1: 4614 bytes
//   |   +---Record 1.2: 4614 bytes
//   |   +---Record 1.3: 4614 bytes
//   |   +---Record 1.4: 4614 bytes
//   |   +---Record 1.5: 4614 bytes
//   |   +---Record 1.6: 4614 bytes
//   |   +---Record 1.7: 4614 bytes
//   |   +---Record 1.8: 4614 bytes
//   |   +---Record 1.9: 4614 bytes
//   |   +---Record 1.10: 4614 bytes
//   |   +---Record 1.11: 4614 bytes
//   |   +---Record 1.12: 4614 bytes
//   |   +---Record 1.13: 4614 bytes
//   |   +---Record 1.14: 4614 bytes
//   |   +---Record 1.15: 4614 bytes
//   |   +---Record 1.16: 4614 bytes
//   |   +---Record 1.17: 4614 bytes
//   |   +---Record 1.18: 4614 bytes
//   |   +---Record 1.19: 4614 bytes
//   |   +---Record 1.20: 4614 bytes
//   |   `---Record 1.21: 2310 bytes
//   +---File 2: 11 records
//   |   +---Record 2.0: 138 bytes
//   |   +---Record 2.1: 4614 bytes
//   |   +---Record 2.2: 4614 bytes
//   |   +---Record 2.3: 4614 bytes
//   |   +---Record 2.4: 4614 bytes
//   |   +---Record 2.5: 4614 bytes
//   |   +---Record 2.6: 4614 bytes
//   |   +---Record 2.7: 4614 bytes
//   |   +---Record 2.8: 4614 bytes
//   |   +---Record 2.9: 4614 bytes
//   |   `---Record 2.10: 4611 bytes
//   +---File 3: 11 records
//   |   +---Record 3.0: 138 bytes
//   |   +---Record 3.1: 4614 bytes
...



Es gibt offenbar einen einen 2076-byte-großen Bandkopf und jeweils einen 138-Byte-großen Dateikopf vor jeder Datei. Die Datenblöcke sind dann 6411 Bytes groß, der letzte Block ist entsprechend der Dateilänge kürzer.
Alle Blockgrößen sind geradzahlig, was auf einen 16-Bit-Rechner hinweist.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
26.11.2020, 10:03 Uhr
Rüdiger
Administrator


Soweit ich das sehe, ist die Bitanzahl bei allen Bytes geradzahlig.
Damit ist es wahrscheinlich, dass ein Paritätsbit mit drin ist.
Die Anzahl der nutzbaren Datenbits reduziert sich damit auf sechs.
In der Annahme, dass der Inhalt nicht nur Texte darstellt, muss man davon ausgehen, das jedes 8-Bit-Zeichen auf mindestens zwei Bytes verteilt wurde.
Wie 664-Code sieht es zumindest nicht aus, da dürfte es keine Folgen von gleichen Zeichen geben.
Was für 6-Bit-Codes gibt es denn noch? Brailleschrift?

In der Annahme, dass #C0 (Binär 1100 0000) das #00-Zeichen repräsentiert und das 7. Bit fest ist, dürfte das 8.Bit das Paritätsbit sein.

Bit 7 und Bit 8 wegzusägen und dann vier 6-Bit-Bytes zu drei 8-Bit-Bytes zusammenzufassen funktioniert nicht, da nicht alle Blocklängen durch vier teilbar sind.
--
Kernel panic: Out of swap space.

Dieser Beitrag wurde am 26.11.2020 um 17:18 Uhr von Rüdiger editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
26.11.2020, 18:07 Uhr
Wusel_1



Das kommt mir irgendwie bekannt vor. Dann knalle mal das auf einen 8-Bit-Lochstreifen

https://www.bilder-upload.eu/bild-346656-1606410335.jpg.html

und suche die passende CNC-Maschine dazu.
--
Beste Grüße Andreas
______________________________________
DL9UNF ex Y22MF es Y35ZF
JO42VP - DOK: Y43 - LDK: CE

*** wer glaubt, hört auf zu denken ***

Dieser Beitrag wurde am 26.11.2020 um 18:09 Uhr von Wusel_1 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
27.11.2020, 09:13 Uhr
Rüdiger
Administrator



Zitat:
Wusel_1 schrieb
Das kommt mir irgendwie bekannt vor. Dann knalle mal das auf einen 8-Bit-Lochstreifen

https://www.bilder-upload.eu/bild-346656-1606410335.jpg.html

und suche die passende CNC-Maschine dazu.



Die größten Dateien auf diesen Bändern sind 100 KByte groß (siehe [004]), das entspräche drei Lochbandrollen. Mit normalen Lochbandwicklern wäre das damals wie heute nicht zu bewältigen.
Laut Aussage eines CNC-Spezialisten ist es unwahrscheinlich, dass diese Daten zu CNC gehören.
CNC war damals textbasiert: EIA oder ISO. Was ich hier habe, hat eher binären Charakter.
Bei Entfernung des Paritätsbits sieht das restliche Spektrum (#00-#3F) so aus:

--
Kernel panic: Out of swap space.

Dieser Beitrag wurde am 27.11.2020 um 09:21 Uhr von Rüdiger editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
27.11.2020, 11:25 Uhr
kaiOr

Avatar von kaiOr


Zitat:
Rüdiger schrieb
Bit 7 und Bit 8 wegzusägen und dann vier 6-Bit-Bytes zu drei 8-Bit-Bytes zusammenzufassen funktioniert nicht, da nicht alle Blocklängen durch vier teilbar sind.


Bit 7+8 wegsägen, dann jeweils drei 6-Bit-Byts zusammenfassen und die obersten 2 Bits (meist leer, Flags?) auch noch wegschneiden.

Alternativ das erste Bit vom Record weglöschen (Rücksetzter fürs Schieberegister?), jewl. Bit 8 weglöschen und immer drei 7-Bit-Bytes zusammenfassen. Aber mit den Paritätsbits liegst Du vermutlich richtiger.

Ob da Opcode oder ein Strickmuster drinsteckt ist schwer zu sagen.

MfG

Dieser Beitrag wurde am 27.11.2020 um 11:31 Uhr von kaiOr editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
27.11.2020, 12:41 Uhr
Rüdiger
Administrator



Zitat:
kaiOr schrieb
Bit 7+8 wegsägen, dann jeweils drei 6-Bit-Byts zusammenfassen und die obersten 2 Bits (meist leer, Flags?) auch noch wegschneiden.



Auffällig ist, dass alle Blocklängen durch drei teilbar sind, also könnten jeweils drei Band-Bytes ein 8-Bit-Byte repräsentieren.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
30.11.2020, 11:43 Uhr
Rüdiger
Administrator



Zitat:
kaiOr schrieb
Bit 7+8 wegsägen, dann jeweils drei 6-Bit-Byts zusammenfassen und die obersten 2 Bits (meist leer, Flags?) auch noch wegschneiden.



BINGO!
6 Bits + 6 Bits + 4 Bits ergibt den ominösen 664-Code.
Dann noch ein paar mit den Reihenfolgen jongliert und plötzlich wird Text sichtbar.
Zu aller Freude ergibt es ein DDR-Betriebssystem, das seit 30 Jahren verschollen ist:



Die Bänder kann ich damit dem R4200 bzw R4201 zuordnen, das Extrahieren der Einzeldateien war nur noch eine Fleißarbeit.


Zitat:
Ob da Opcode oder ein Strickmuster drinsteckt ist schwer zu sagen.



Letzteres nicht, dafür u.a. eine Inventarliste des damalige Betreibers, womit wir auch dem Thema CNC wieder etwas näher kommen:



Das Problem ist damit gelöst.
--
Kernel panic: Out of swap space.

Dieser Beitrag wurde am 30.11.2020 um 12:00 Uhr von Rüdiger editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
30.11.2020, 12:18 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

Gratulation !!!
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
30.11.2020, 15:50 Uhr
kaiOr

Avatar von kaiOr

Cool, gratuliere!
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
30.11.2020, 20:00 Uhr
ambrosius



Klasse, daß die Bänder dekodiert werden konnten! Aber ich habe dazu mal eine Frage. Ich bin jetzt nicht so der Mathefreak. Warum wurde die Aufzeichnung auf den Bändern so umständlich kodiert? Wenn das ein Betriebssystem ist, dann mußte ja die Dekodierroutine schon im Urlader der Maschine stecken!? Oder diente die Kodierung nur der Redundanz der Informationen? Danke schon einmal für eine Auskunft.
--
viele Grüße
Holger
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
30.11.2020, 20:23 Uhr
Rüdiger
Administrator



Zitat:
ambrosius schrieb
Klasse, daß die Bänder dekodiert werden konnten! Aber ich habe dazu mal eine Frage. Ich bin jetzt nicht so der Mathefreak. Warum wurde die Aufzeichnung auf den Bändern so umständlich kodiert?



Eine offizielle Aussage kann ich nicht geben, lediglich meine Vermutung aus Anwendersicht. Zunächst: es geht hier um 16-Bit-Rechner.

1/2-Zoll-Magnetbänder sind 9-spurig: 8 Datenspuren + 1 Paritätsbit-Spur.
Da könnte man ein 16-Bit-Wort also auf zwei Sprossen ablegen.

Lochbänder sind maximal 8-spurig: 7 Datenspuren + 1 Partitätsbit-Spur.
Wenn man paritätsgesicherte Daten da ablegen will, kommt man nicht umher, die Bytes auf drei Sprossen aufzuteilen. 7+7+2 Bits wäre möglich, 6+6+4 Bits sieht aber schöner aus.

Wenn man ein Betriebssystem baut, das sowohl auf Lochband als auf Magnetband verfügbar sein soll, nimmt man bei beiden Laufwerken das gleiche Verfahren.



Zitat:
Wenn das ein Betriebssystem ist, dann mußte ja die Dekodierroutine schon im Urlader der Maschine stecken!?



Muss sie nicht zwingend. Der Urlader (primärer Bootstrap) kann zunächst ein einfach strukturiertes Band (sekundärer Bootstrap) laden, das wiederum kompliziertere Bänder lädt. K1600 macht das z.B. so.
--
Kernel panic: Out of swap space.

Dieser Beitrag wurde am 30.11.2020 um 20:25 Uhr von Rüdiger editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
30.11.2020, 20:29 Uhr
Rainer



Cool, da zieh ich den Hut!
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
30.11.2020, 21:01 Uhr
ambrosius



@014
Vielen Dank, das leuchtet ein.
--
viele Grüße
Holger
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
30.11.2020, 21:14 Uhr
constanze czech

Avatar von constanze czech

Geniale Arbeit!
--
biete 3-Raum-Computer 96m², Dusche, WC, Zentralheizung, Ferritkerngrill...(nicht ganz) ruhige Wohnlage....zum Zeitwert...
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
30.11.2020, 22:40 Uhr
hellas



Respekt für diese Knobelei!
Respekt für die Lösung des Problems!
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
01.12.2020, 15:56 Uhr
Gerhard



Respekt auch von mir!
Leider bin ich erst jetzt auf die Sache gestossen, nachdem die Nuss gecknackt ist.
Andernfalls hätten mich wohl die vielen $C0 gleich stutzig gemacht, sowie auch der zweite Teilbereich (also > $C0, d.h. mit Bit 7 = 1). Dieses Bit ist tatsächlich bei allen MC- oder OC-Lochbändern der KRS4200 zu weit über 90% gelocht, mit der einzigen Ausnahme, wenn alle Bits von 1 bis 6 gleichzeitig =1 sind. In dieser Hinsicht muss ich Ambrosius (013) wegen "umständlicher Codierung" widersprechen: Dieser 4/6/6-code ist der Standardcode beim KRS.
Die Bänder müssten sich also ohne weiteres mit dem Anfangslader einlesen lassen.

Dieser Beitrag wurde am 01.12.2020 um 15:58 Uhr von Gerhard editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek