Како сам повратио податке у непознатом формату са магнетне траке

praistorija

Пошто сам заљубљеник у ретро хардвер, једном сам купио ЗКС Спецтрум+ од продавца у Великој Британији. У пакету са самим рачунаром добио сам неколико аудио касета са игрицама (у оригиналном паковању са упутством), као и програме снимљене на касетама без посебних ознака. Изненађујуће, подаци са касета старих 40 година били су читљиви и могао сам да преузмем скоро све игре и програме са њих.

Међутим, на неким касетама сам нашао снимке које очигледно није направио ЗКС Спецтрум рачунар. Звучале су потпуно другачије и, за разлику од снимака са поменутог рачунара, нису почињале кратким БАСИЦ боотлоадером, који је иначе присутан на снимцима свих програма и игрица.

Неко време ме је ово прогањало – заиста сам желео да сазнам шта се крије у њима. Ако бисте могли да прочитате аудио сигнал као низ бајтова, могли бисте потражити знакове или било шта што указује на порекло сигнала. Нека врста ретро-археологије.

Сад кад сам отишао до краја и погледао етикете самих касета, смејем се јер

одговор ми је све време био пред очима
На етикети леве касете је назив рачунара ТРС-80, а одмах испод имена произвођача: „Произвођач Радио Схацк у САД“

(Ако желите да задржите интригу до краја, не идите испод спојлера)

Поређење аудио сигнала

Пре свега, да дигитализујемо аудио записе. Можете послушати како то звучи:

И као и обично, звучи снимак са рачунара ЗКС Спецтрум:

У оба случаја се на почетку снимка налази тзв пилот тон - звук исте фреквенције (на првом снимку је врло кратак <1 секунде, али се разликује). Пилот тон сигнализира рачунару да се припреми за пријем података. По правилу, сваки рачунар препознаје само свој „сопствени“ пилот тон по облику сигнала и његовој фреквенцији.

Неопходно је нешто рећи и о самом облику сигнала. На пример, на ЗКС Спецтруму његов облик је правоугаоник:

Када се детектује пилот тон, ЗКС Спецтрум приказује наизменичне црвене и плаве траке на ивици екрана како би означио да је сигнал препознат. Пилот тон се завршава синхро пулс, који сигнализира рачунару да почне да прима податке. Карактерише га краће трајање (у поређењу са пилот тоном и накнадним подацима) (погледајте слику)

Након што је примљен синхронизациони импулс, рачунар бележи сваки пораст/пад сигнала, мерећи његово трајање. Ако је трајање мање од одређене границе, бит 1 се уписује у меморију, у супротном 0. Битови се сакупљају у бајтове и процес се понавља док се не прими Н бајтова. Број Н се обично узима из заглавља преузете датотеке. Редослед учитавања је следећи:

1. пилот тон
2. заглавље (фиксна дужина), садржи величину преузетих података (Н), назив датотеке и тип
3. пилот тон
4. самих података

Да би били сигурни да су подаци исправно учитани, ЗКС Спецтрум чита тзв паритетни бајт (паритетни бајт), који се израчунава приликом чувања датотеке КСОР-ом свих бајтова уписаних података. Приликом читања датотеке рачунар израчунава бајт парности из примљених података и, ако се резултат разликује од сачуваног, приказује поруку о грешци „Р Тапе лоадинг еррор“. Строго говорећи, рачунар може да изда ову поруку раније ако при читању не може да препозна пулс (пропуштен или његово трајање не одговара одређеним границама)

Дакле, да видимо како изгледа непознати сигнал:

Ово је пилот тон. Облик сигнала је значајно другачији, али је јасно да се сигнал састоји од понављања кратких импулса одређене фреквенције. На фреквенцији узорковања од 44100 Хз, растојање између „пикова“ је приближно 48 узорака (што одговара фреквенцији од ~918 Хз). Сетимо се ове бројке.

Погледајмо сада фрагмент података:

Ако измеримо растојање између појединачних импулса, испоставља се да је растојање између „дугих“ импулса и даље ~48 узорака, а између кратких ~24. Гледајући мало унапред, рећи ћу да се на крају испоставило да „референтни“ импулси са фреквенцијом од 918 Хз следе непрекидно, од почетка до краја датотеке. Може се претпоставити да приликом преноса података, ако се наиђе на додатни импулс између референтних импулса, сматрамо га битом 1, иначе 0.

Шта је са синхронизационим пулсом? Погледајмо почетак података:

Пилот тон се завршава и подаци почињу одмах. Нешто касније, након анализе неколико различитих аудио записа, успели смо да откријемо да је први бајт података увек исти (10100101б, А5х). Рачунар може почети да чита податке након што их прими.

Такође можете обратити пажњу на померање првог референтног импулса одмах након последњег 1. у бајту за синхронизацију. Откривено је много касније у процесу развоја програма за препознавање података, када подаци на почетку датотеке нису могли стабилно да се читају.

Покушајмо сада да опишемо алгоритам који ће обрадити аудио датотеку и учитати податке.

Учитавање података

Прво, погледајмо неколико претпоставки да би алгоритам био једноставан:

1. Размотрићемо само датотеке у ВАВ формату;
2. Аудио датотека мора да почиње пилот тоном и не сме да садржи тишину на почетку
3. Изворна датотека мора имати брзину узорковања од 44100 Хз. У овом случају, растојање између референтних импулса од 48 узорака је већ одређено и не треба га програмски израчунавати;
4. Формат узорка може бити било који (8/16 бита/покретни зарез) – пошто га приликом читања можемо конвертовати у жељени;
5. Претпостављамо да је изворни фајл нормализован амплитудом, што би требало да стабилизује резултат;

Алгоритам читања ће бити следећи:

1. Читамо датотеку у меморију, истовремено претварајући формат узорка у 8 бита;
2. Одредите позицију првог импулса у аудио подацима. Да бисте то урадили, потребно је да израчунате број узорка са максималном амплитудом. Ради једноставности, израчунаћемо га једном ручно. Хајде да га сачувамо у променљивој прев_пос;
3. Додајте 48 на позицију последњег импулса (поз := прев_пос + 48)
4. Пошто повећање позиције за 48 не гарантује да ћемо доћи до позиције следећег референтног импулса (дефекти траке, нестабилан рад механизма траке итд.), потребно је да прилагодимо позицију поз импулса. Да бисте то урадили, узмите мали део података (пос-8;пос+8) и пронађите максималну вредност амплитуде на њему. Положај који одговара максимуму биће сачуван у поз. Овде је 8 = 48/6 експериментално добијена константа, која гарантује да ћемо одредити тачан максимум и да неће утицати на друге импулсе који могу бити у близини. У веома лошим случајевима, када је растојање између импулса много мање или веће од 48, можете применити принудну претрагу импулса, али у оквиру чланка то нећу описивати у алгоритму;
5. У претходном кораку такође би било потребно проверити да ли је референтни пулс уопште пронађен. То јест, ако једноставно тражите максимум, то не гарантује да је импулс присутан у овом сегменту. У својој најновијој имплементацији програма за читање, проверавам разлику између максималне и минималне вредности амплитуде на сегменту, а ако пређе одређену границу, рачунам присуство импулса. Питање је и шта учинити ако се референтни пулс не пронађе. Постоје 2 опције: или су подаци завршени и следи тишина, или ово треба сматрати грешком читања. Међутим, ово ћемо изоставити да бисмо поједноставили алгоритам;
6. У следећем кораку треба да утврдимо присуство импулса података (бит 0 или 1), за то узимамо средину сегмента (прев_пос;пос) миддле_пос једнаку миддле_пос := (прев_пос+пос)/2 и у неком суседству средњег положаја на сегменту (миддле_пос-8;миддле_пос +8) израчунајмо максималну и минималну амплитуду. Ако је разлика између њих већа од 10, у резултат уписујемо бит 1, у супротном 0. 10 је константа добијена експериментално;
7. Сачувајте тренутну позицију у прев_пос (прев_пос := пос)
8. Поновите почевши од корака 3 док не прочитамо целу датотеку;
9. Добијени низ битова мора бити сачуван као скуп бајтова. Пошто при читању нисмо узели у обзир синхронизациони бајт, број битова можда није вишеструки од 8, а такође је непознат и потребан помак бита. У првој имплементацији алгоритма, нисам знао за постојање бајта за синхронизацију и стога сам једноставно сачувао 8 датотека са различитим бројем битова померања. Један од њих је садржао тачне податке. У коначном алгоритму, једноставно уклањам све битове до А5х, што ми омогућава да одмах добијем исправну излазну датотеку

Алгоритам у Рубију, за заинтересоване
Одабрао сам Руби као језик за писање програма, јер... Већину времена програмирам на њему. Опција није високих перформанси, али задатак да убрзате читање што је брже могуће није вредан тога.

# Используем 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*")

Резултат

Испробавши неколико варијанти алгоритма и константи, имао сам среће да добијем нешто изузетно занимљиво:

Дакле, судећи по низовима карактера, имамо програм за цртање графикона. Међутим, у тексту програма нема кључних речи. Све кључне речи су кодиране као бајтови (свака вредност > 80х). Сада треба да сазнамо који рачунар из 80-их је могао да чува програме у овом формату.

У ствари, веома је сличан БАСИЦ програму. Рачунар ЗКС Спецтрум складишти програме у приближно истом формату у меморији и чува програме на траци. За сваки случај, проверио сам кључне речи сто. Међутим, резултат је очигледно био негативан.

Проверио сам и БАСИЦ кључне речи популарног Атари, Цоммодоре 64 и неколико других рачунара тог времена, за које сам успео да пронађем документацију, али безуспешно – показало се да моје знање о врстама ретро рачунара није тако широко.

Онда сам одлучио да идем листа, а онда ми је поглед пао на назив произвођача Радио Схацк и рачунар ТРС-80. Ово су имена која су исписана на етикетама касета које су лежале на мом столу! Раније нисам знао ова имена и нисам био упознат са рачунаром ТРС-80, па ми се чинило да је Радио Схацк произвођач аудио касета као што су БАСФ, Сони или ТДК, а ТРС-80 је био време репродукције. Што да не?

Цомпутер Танди/Радио Схацк ТРС-80

Врло је вероватно да је дотични аудио снимак, који сам навео као пример на почетку чланка, направљен на рачунару овако:

Испоставило се да су овај рачунар и његове варијанте (Модел И/Модел ИИИ/Модел ИВ, итд.) у једном тренутку били веома популарни (наравно, не у Русији). Важно је напоменути да је процесор који су користили такође З80. За овај рачунар можете пронаћи на Интернету много информација. Осамдесетих година, компјутерске информације су дистрибуиране у часописи. Тренутно их има неколико емулатори рачунари за различите платформе.

Преузео сам емулатор трс80гп и први пут сам могао да видим како овај рачунар ради. Наравно, рачунар није подржавао излаз у боји; резолуција екрана је била само 128к48 пиксела, али је било много проширења и модификација које су могле повећати резолуцију екрана. Постојале су и многе опције за оперативне системе за овај рачунар и опције за имплементацију БАСИЦ језика (који, за разлику од ЗКС Спецтрума, у неким моделима није био ни „флешован“ у РОМ и било која опција се могла учитати са дискете, као што сам ОС)

такође сам нашао корисност да конвертујем аудио записе у ЦАС формат, који подржавају емулатори, али из неког разлога није било могуће читати снимке са мојих касета помоћу њих.

Пошто сам схватио формат ЦАС датотеке (за који се испоставило да је само бит-по-бит копија података са траке коју сам већ имао при руци, осим заглавља са присуством бајта за синхронизацију), направио сам неколико измена у мом програму и успео сам да избацим радну ЦАС датотеку која је радила у емулатору (ТРС-80 Модел ИИИ):

Дизајнирао сам најновију верзију услужног програма за конверзију са аутоматским одређивањем првог импулса и удаљености између референтних импулса као ГЕМ пакет, изворни код је доступан на Гитхуб.

Закључак

Пут који смо прешли показао се као фасцинантно путовање у прошлост и драго ми је што сам на крају пронашао одговор. Између осталог, ја:

• Схватио сам формат за чување података у ЗКС Спецтруму и проучио уграђене РОМ рутине за чување/читање података са аудио касета
• Упознао сам се са рачунаром ТРС-80 и његовим варијантама, проучавао оперативни систем, погледао узорке програма и чак сам имао прилику да отклањам грешке у машинским кодовима (на крају крајева, све мнемонике З80 су ми познате)
• Написао је пуноправни услужни програм за претварање аудио записа у ЦАС формат, који може читати податке које "званични" услужни програм не препознаје

Извор: ввв.хабр.цом