Hintergrund
Als Liebhaber von Retro-Eisen habe ich einmal ein ZX Spectrum + von einem britischen Verkäufer gekauft. Zusammen mit dem Computer selbst erhielt ich mehrere Audiokassetten mit Spielen (in der Originalverpackung mit Anweisungen) sowie Programme, die auf Kassetten ohne besondere Bezeichnung aufgezeichnet wurden. Überraschenderweise waren die Daten von 40 Jahre alten Kassetten lesbar und ich konnte fast alle Spiele und Programme von ihnen herunterladen.
Auf einigen Kassetten fand ich jedoch Aufnahmen, die eindeutig nicht vom ZX Spectrum-Computer gemacht wurden. Sie klangen völlig anders und begannen im Gegensatz zu den Aufnahmen des oben genannten Computers nicht mit einem kurzen BASIC-Bootloader, der normalerweise in den Aufnahmen aller Programme und Spiele enthalten ist.
Einige Zeit wurde ich davon verfolgt - ich wollte wirklich wissen, was in ihnen verborgen ist. Wenn Sie das Audiosignal als eine Folge von Bytes lesen könnten, könnten Sie darin nach Zeichen oder etwas suchen, das den Ursprung des Signals anzeigt. Eine Art Retro-Archäologie.
Jetzt, wo ich den ganzen Weg gekommen bin und mir die Etiketten der Kassetten selbst angesehen habe, lächle ich, weil
Die Antwort war die ganze Zeit direkt vor meinen Augen
— TRS-80, : «Manufactured by Radio Shack in USA»
(Wenn Sie die Intrige bis zum Ende behalten möchten, gehen Sie nicht unter den Spoiler)
Vergleich von Audiosignalen
Der erste Schritt ist die Digitalisierung von Audioaufnahmen. Sie können hören, wie es sich anhört:
Und wie immer klingt die Aufnahme vom ZX Spectrum-Computer:
In beiden Fällen ertönt zu Beginn der Aufnahme ein sogenannter Pilotton - ein Ton mit einer Frequenz (bei der ersten Aufnahme ist er sehr kurz <1 s, aber unterscheidbar). Der Pilotton signalisiert dem Computer, sich auf den Empfang von Daten vorzubereiten. In der Regel erkennt jeder Computer nur "seinen" Pilotton an der Wellenform und seiner Frequenz.
Ich muss über die Signalform selbst sagen. Beim ZX Spectrum ist seine Form beispielsweise rechteckig:
Wenn ein Pilotton erkannt wird, zeigt das ZX Spectrum abwechselnd rote und blaue Streifen am Rand des Bildschirms an, um anzuzeigen, dass das Signal erkannt wird. Der Pilotton endet mit einem Synchronimpuls, was dem Computer signalisiert, Daten zu empfangen. Es zeichnet sich durch eine kürzere Dauer (im Vergleich zum Pilotton und den nachfolgenden Daten) aus (siehe Abbildung).
Nach dem Empfang des Synchronisationsimpulses zeichnet der Computer jeden Anstieg / Abfall des Signals auf und misst dessen Dauer. Wenn die Dauer unter einem bestimmten Grenzwert liegt, wird Bit 1 in den Speicher geschrieben, andernfalls 0. Bits werden in Bytes gesammelt und der Vorgang wird wiederholt, bis N Bytes empfangen werden. Die Nummer N wird normalerweise aus dem Header der heruntergeladenen Datei entnommen. Die Startsequenz lautet wie folgt:
- Pilotton
- Header (feste Länge), enthält die Größe der geladenen Daten (N), den Namen und den Dateityp
- Pilotton
- die Daten selbst
Um sicherzustellen, dass die Daten korrekt geladen werden, liest ZX Spectrum das letzte Byte der sogenannten Byte-Parität (Paritätsbyte), das berechnet wird, wenn Sie die Dateioperation XOR über alle Bytes der aufgezeichneten Daten speichern. Beim Lesen der Datei berechnet der Computer das Paritätsbyte aus den empfangenen Daten und zeigt, falls das Ergebnis vom gespeicherten abweicht, die Fehlermeldung "R Bandladefehler" an. Genau genommen kann der Computer diese Meldung früher ausgeben, wenn er beim Lesen den Impuls nicht erkennen kann (er wird übersehen oder seine Dauer entspricht nicht bestimmten Grenzen).
Lassen Sie uns nun sehen, wie ein unbekanntes Signal aussieht:
Dies ist ein Pilotton. Die Wellenform unterscheidet sich erheblich, aber Sie können sehen, dass das Signal aus sich wiederholenden kurzen Impulsen einer bestimmten Frequenz besteht. Bei einer Abtastrate von 44100 Hz beträgt der Abstand zwischen den "Peaks" ungefähr 48 Abtastwerte (was einer Frequenz von ~ 918 Hz entspricht). Erinnern wir uns an diese Zahl.
Betrachten
wir nun das Fragment mit den Daten: Wenn wir den Abstand zwischen einzelnen Impulsen messen, stellt sich heraus, dass der Abstand zwischen den „langen“ Impulsen immer noch ~ 48 Abtastwerte und zwischen den kurzen - ~ 24 Abtastwerten beträgt. Wenn ich ein wenig voraus laufe, werde ich sagen, dass sich am Ende herausgestellt hat, dass "Referenz" -Pulse mit einer Frequenz von 918 Hz kontinuierlich vom Anfang bis zum Ende der Datei folgen. Es kann angenommen werden, dass während der Datenübertragung ein zusätzlicher Impuls zwischen den Referenzimpulsen als Bit 1 betrachtet wird, andernfalls als 0.
Was ist mit dem Synchronimpuls? Schauen wir uns den Anfang der Daten an:
Der Pilotton endet und die Daten beginnen sofort. Wenig später stellten wir nach der Analyse mehrerer verschiedener Audioaufnahmen fest, dass das erste Datenbyte immer das gleiche ist (10100101b, A5h). Der Computer beginnt möglicherweise mit dem Lesen von Daten, nachdem er diese empfangen hat.
Sie können auch auf die Verschiebung des ersten Referenzimpulses unmittelbar nach der letzten 1 im Synchrobyte achten. Es wurde viel später bei der Entwicklung eines Programms zur Datenerkennung entdeckt, als die Daten am Anfang der Datei nicht stabil gelesen werden konnten.
Versuchen wir nun, einen Algorithmus zu beschreiben, der eine Audiodatei verarbeitet und Daten lädt.
Daten werden geladen
Schauen wir uns zunächst einige Annahmen an, um den Algorithmus nicht zu komplizieren:
- Wir betrachten Dateien nur im WAV-Format.
- Die Audiodatei muss mit einem Pilotton beginnen und darf zu Beginn keine Stille enthalten
- Die Quelldatei muss eine Abtastrate von 44100 Hz haben. In diesem Fall wurde der Abstand zwischen den Referenzimpulsen von 48 Abtastwerten bereits bestimmt, und wir müssen ihn nicht programmgesteuert berechnen.
- Das Beispielformat kann beliebig sein (8/16 Bit / Gleitkomma) - da wir es beim Lesen in das gewünschte konvertieren können;
- Wir gehen davon aus, dass die Amplitude der Originaldatei normalisiert ist, was das Ergebnis stabilisieren sollte.
Der Lesealgorithmus lautet wie folgt:
- Wir lesen die Datei in den Speicher und konvertieren gleichzeitig das Beispielformat in 8 Bit.
- Bestimmen Sie die Position des ersten Impulses in den Audiodaten. Dazu müssen Sie die Anzahl der Proben mit der maximalen Amplitude berechnen. Der Einfachheit halber zählen wir es einmal manuell. Speichern wir es in der Variablen prev_pos.
- Addiere 48 zur Position des letzten Impulses (pos: = prev_pos + 48)
- 48 , ( , ), pos. (pos-8;pos+8) . , , pos. 8 = 48/6 — , , . , 48, , ;
- , . , , . , , . , . 2 : , . ;
- ( 0 1), (prev_pos;pos) middle_pos middle_pos := (prev_pos+pos)/2 middle_pos (middle_pos-8;middle_pos+8) . 10, 1 0. 10 — ;
- prev_pos (prev_pos := pos)
- 3, ;
- . - , 8, . - 8 . . A5h,
Ruby,
Ruby, .. . , .
# gem 'wavefile'
require 'wavefile'
reader = WaveFile::Reader.new('input.wav')
samples = []
format = WaveFile::Format.new(:mono, :pcm_8, 44100)
# WAV , Mono, 8 bit
# samples 0-255
reader.each_buffer(10000) do |buffer|
samples += buffer.convert(format).samples
end
# ( 0)
prev_pos = 0
#
distance = 48
#
delta = (distance / 6).floor
# "0" "1"
bits = ""
loop do
#
pos = prev_pos + distance
#
break if pos + delta >= samples.size
# pos [pos - delta;pos + delta]
(pos - delta..pos + delta).each { |p| pos = p if samples[p] > samples[pos] }
# [prev_pos;pos]
middle_pos = ((prev_pos + pos) / 2).floor
#
sample = samples[middle_pos - delta..middle_pos + delta]
# "1" 10
bit = sample.max - sample.min > 10
bits += bit ? "1" : "0"
end
# - 256 ( )
bits.gsub! /^[01]*?10100101/, ("0" * 256) + "10100101"
# ,
File.write "output.cas", [bits].pack("B*")
Nachdem ich verschiedene Varianten des Algorithmus und der Konstanten ausprobiert hatte, hatte ich das Glück, etwas äußerst Interessantes zu erhalten:
Nach den Zeichenketten zu urteilen, haben wir ein Programm zum Zeichnen von Graphen. Der Programmtext enthält jedoch keine Schlüsselwörter. Alle Schlüsselwörter werden als Bytes codiert (jeder Wert> 80h). Jetzt müssen wir herausfinden, welcher Computer aus den 80ern Programme in diesem Format speichern kann.
Dies ist eigentlich einem BASIC-Programm sehr ähnlich. In ungefähr demselben Format speichert der ZX Spectrum-Computer im Speicher und speichert Programme auf Band. Für alle Fälle habe ich die Schlüsselwörter anhand der Tabelle überprüft . Das Ergebnis war jedoch offensichtlich negativ.
Ich habe auch die BASIC-Schlüsselwörter der beliebten Atari-Computer, des Commodore 64 und mehrerer anderer Computer überprüft, für die ich Dokumentation gefunden habe, aber ohne Erfolg - mein Wissen über die Arten von Retro-Computern war nicht so umfangreich.
Dann beschloss ich, die Liste durchzugehen , und dann fiel mein Blick auf den Namen des Herstellers von Radio Shack und des TRS-80-Computers. Diese Namen wurden auf die Etiketten der Kassetten geschrieben, die auf meinem Tisch lagen! Schließlich kannte ich diese Namen vorher nicht und war mit dem TRS-80-Computer nicht vertraut. Daher schien mir Radio Shack ein Hersteller von Audiokassetten wie BASF, Sony oder TDK zu sein, und TRS-80 war die Dauer der Wiedergabe. Warum nicht?
Computer Tandy / Radio Shack TRS-80
Es ist sehr wahrscheinlich, dass die fragliche Audioaufnahme, die ich zu Beginn des Artikels als Beispiel gegeben habe, auf einem solchen Computer gemacht wurde:
Es stellte sich heraus, dass dieser Computer und seine Varianten (Modell I / Modell III / Modell IV usw.) in ihrem sehr beliebt waren Zeit (natürlich nicht in Russland). Es ist bemerkenswert, dass der in ihnen verwendete Prozessor auch Z80 ist. Auf diesem Computer finden Sie im Internet viele Informationen . In den 1980er Jahren wurden Informationen über den Computer in Magazinen verbreitet . Im Moment gibt es mehrere Computer - Emulatoren für verschiedene Plattformen.
Ich habe den Emulator trs80gp heruntergeladenund zum ersten Mal konnte ich sehen, wie dieser Computer funktionierte. Natürlich unterstützte der Computer keine Farbausgabe, die Bildschirmauflösung betrug nur 128 x 48 Pixel, aber es gab viele Erweiterungen und Modifikationen, die die Bildschirmauflösung erhöhen konnten. Es gab auch viele Optionen für Betriebssysteme für diesen Computer und Optionen für die Implementierung der BASIC-Sprache (die im Gegensatz zum ZX Spectrum bei einigen Modellen nicht einmal in das ROM "geflasht" wurde und jede Option von einer Diskette sowie vom Betriebssystem selbst booten konnte)
. Ich habe ein Dienstprogramm zum Konvertieren von Audioaufnahmen in das CAS-Format gefunden, das von Emulatoren unterstützt wird, aber aus irgendeinem Grund konnte ich die Aufnahmen von meinen Kassetten mit deren Hilfe nicht lesen.
Nachdem ich das Format der CAS-Datei herausgefunden hatte (es stellte sich heraus, dass es sich nur um eine bitweise Kopie der Daten vom Band handelte, die ich bereits in meinen Händen hatte, mit Ausnahme des Headers mit einem Synchronisationsbyte), nahm ich mehrere Änderungen an meinem Programm vor und konnte am Ausgang eine funktionierende CAS-Datei abrufen es funktionierte im Emulator (TRS-80 Modell III):
Die letzte Version des Dienstprogramms zum Konvertieren mit automatischer Erkennung des ersten Impulses und des Abstands zwischen den Referenzimpulsen, die ich als GEM-Paket entworfen habe, ist der Quellcode auf Github verfügbar .
Fazit
Der durchquerte Weg erwies sich als aufregende Reise in die Vergangenheit, und ich bin froh, dass ich am Ende eine Lösung gefunden habe. Unter anderem habe ich:
- Ich fand das Format zum Speichern von Daten im ZX Spectrum heraus und studierte die integrierten ROM-Routinen zum Speichern / Lesen von Daten von Audiobändern
- Ich habe den TRS-80-Computer und seine Varianten kennengelernt, das Betriebssystem studiert, mir Beispiele für Programme angesehen und sogar die Möglichkeit gehabt, Maschinencodes zu debuggen (schließlich sind mir alle Z80-Mnemoniken bekannt).
- Ich habe ein vollwertiges Dienstprogramm zum Konvertieren von Audioaufnahmen in das CAS-Format geschrieben, mit dem Daten gelesen werden können, die vom "offiziellen" Dienstprogramm nicht erkannt werden