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

праисторијата

Бидејќи сум љубител на ретро хардвер, еднаш купив ZX Spectrum+ од продавач во ОК. Вклучени со самиот компјутер, добив неколку аудио касети со игри (во оригиналното пакување со упатства), како и програми снимени на касети без посебни ознаки. Изненадувачки, податоците од касетите стари 40 години беа добро читливи и можев да ги преземам скоро сите игри и програми од нив.

Сепак, на некои касети најдов снимки кои очигледно не се направени од компјутерот ZX Spectrum. Звучеле сосема поинаку и за разлика од снимките од споменатиот компјутер, не започнувале со краток BASIC подигнувач, кој вообичаено го има во снимките на сите програми и игри.

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

Сега кога го поминав целиот пат и ги погледнав етикетите на самите касети, се насмевнувам затоа што

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

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

Споредба на аудио сигнали

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

И како и обично звучи снимката од компјутерот ZX Spectrum:

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

Неопходно е да се каже нешто за самата форма на сигналот. На пример, на ZX Spectrum неговата форма е правоаголна:

Кога ќе се открие пилот-тон, ZX Spectrum прикажува наизменични црвени и сини ленти на границата на екранот за да покаже дека сигналот е препознаен. Пилотскиот тон завршува синхрон пулс, што му сигнализира на компјутерот да почне да прима податоци. Се карактеризира со пократко времетраење (во споредба со тонот на пилотот и последователните податоци) (види слика)

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

1. пилотски тон
2. заглавие (фиксна должина), ја содржи големината на преземените податоци (N), името и типот на датотеката
3. пилотски тон
4. самите податоци

За да се увери дека податоците се правилно вчитани, ZX Spectrum го чита т.н бајт за паритет (бајт за паритет), кој се пресметува при зачувување на датотека со XOR-имање на сите бајти од запишаните податоци. При читање датотека, компјутерот го пресметува бајтот на паритет од примените податоци и, доколку резултатот се разликува од зачуваниот, ја прикажува пораката за грешка „R Tape loading error“. Строго кажано, компјутерот може да ја издаде оваа порака порано ако, при читање, не може да препознае пулс (промашен или неговото времетраење не одговара на одредени ограничувања)

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

Ова е пилотскиот тон. Обликот на сигналот е значително различен, но јасно е дека сигналот се состои од повторување на кратки импулси со одредена фреквенција. При фреквенција на земање примероци од 44100 Hz, растојанието помеѓу „врвовите“ е приближно 48 примероци (што одговара на фреквенција од ~ 918 Hz). Да се ​​потсетиме на оваа бројка.

Ајде сега да го погледнеме фрагментот со податоци:

Ако го измериме растојанието помеѓу поединечните импулси, излегува дека растојанието помеѓу „долгите“ импулси е сè уште ~ 48 примероци, а помеѓу кратките - ~ 24. Гледајќи малку напред, ќе кажам дека на крајот се покажа дека „референтните“ импулси со фреквенција од 918 Hz следат континуирано, од почетокот до крајот на датотеката. Може да се претпостави дека при пренос на податоци, доколку се сретне дополнителен импулс помеѓу референтните импулси, го сметаме за бит 1, во спротивно 0.

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

Пилотскиот тон завршува и податоците почнуваат веднаш. Малку подоцна, откако анализиравме неколку различни аудио снимки, успеавме да откриеме дека првиот бајт на податоци е секогаш ист (10100101b, A5h). Компјутерот може да почне да чита податоци откако ќе ги прими.

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

Сега да се обидеме да опишеме алгоритам што ќе обработи аудио датотека и ќе вчита податоци.

Се вчитуваат податоци

Прво, да погледнеме неколку претпоставки за да го одржиме алгоритмот едноставен:

1. Ќе ги разгледаме само датотеките во формат WAV;
2. Аудиодатотеката мора да започне со пилот тон и не смее да содржи тишина на почетокот
3. Изворната датотека мора да има брзина на земање примероци од 44100 Hz. Во овој случај, растојанието помеѓу референтните импулси од 48 примероци е веќе одредено и не треба да го пресметуваме програмски;
4. Форматот на примерокот може да биде кој било (8/16 бита/подвижна точка) - бидејќи при читање можеме да го претвориме во саканиот;
5. Претпоставуваме дека изворната датотека е нормализирана по амплитуда, што треба да го стабилизира резултатот;

Алгоритмот за читање ќе биде како што следува:

1. Ја читаме датотеката во меморија, истовремено претворајќи го форматот на примерокот во 8 бита;
2. Одредете ја позицијата на првиот пулс во аудио податоците. За да го направите ова, треба да го пресметате бројот на примерокот со максимална амплитуда. За едноставност, ќе го пресметаме еднаш рачно. Да го зачуваме во променливата prev_pos;
3. Додадете 48 на позицијата на последниот пулс (pos := prev_pos + 48)
4. Бидејќи зголемувањето на положбата за 48 не гарантира дека ќе дојдеме до позицијата на следниот референтен пулс (дефекти на лентата, нестабилно функционирање на механизмот за погон на лента, итн.), треба да ја прилагодиме положбата на пулсот на пози. За да го направите ова, земете мал дел од податоците (pos-8;pos+8) и пронајдете ја максималната вредност на амплитудата на неа. Позицијата што одговара на максимумот ќе се зачува во поз. Овде 8 = 48/6 е експериментално добиена константа, која гарантира дека ќе го одредиме точниот максимум и нема да влијае на другите импулси кои можеби се во близина. Во многу лоши случаи, кога растојанието помеѓу импулсите е многу помало или поголемо од 48, можете да спроведете принудно пребарување за пулс, но во рамките на написот нема да го опишам ова во алгоритмот;
5. На претходниот чекор, исто така, ќе биде неопходно да се провери дали референтниот пулс воопшто е пронајден. Односно, ако едноставно го барате максимумот, тоа не гарантира дека импулсот е присутен во овој сегмент. Во мојата последна имплементација на програмата за читање, ја проверувам разликата помеѓу максималните и минималните вредности на амплитудата на еден сегмент и ако надмине одредена граница, го бројам присуството на импулс. Прашањето е, исто така, што да се прави ако референтниот пулс не е пронајден. Има 2 опции: или податоците се завршени и следи тишина, или ова треба да се смета за грешка при читањето. Сепак, ќе го испуштиме ова за да го поедноставиме алгоритмот;
6. На следниот чекор, треба да го одредиме присуството на пулс на податоци (бит 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 е константа добиена експериментално;
7. Зачувајте ја моменталната позиција во prev_pos (prev_pos := pos)
8. Повторете почнувајќи од чекор 3 додека не ја прочитаме целата датотека;
9. Добиената битна низа мора да се зачува како збир од бајти. Бидејќи не го земавме предвид бајтот за синхронизација при читање, бројот на битови може да не е множител на 8, а потребната битска поместување исто така е непозната. Во првата имплементација на алгоритмот, не знаев за постоењето на синхронизираниот бајт и затоа едноставно зачував 8 датотеки со различен број на битови за офсет. Еден од нив содржел точни податоци. Во последниот алгоритам, едноставно ги отстранувам сите битови до A5h, што ми овозможува веднаш да ја добијам точната излезна датотека

Алгоритам во Руби, за заинтересираните
Го избрав 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*")

Резултира

Откако пробав неколку варијанти на алгоритам и константи, имав среќа да добијам нешто исклучително интересно:

Значи, судејќи според низите на знаци, имаме програма за исцртување графикони. Сепак, нема клучни зборови во текстот на програмата. Сите клучни зборови се кодирани како бајти (секоја вредност > 80h). Сега треба да откриеме кој компјутер од 80-тите може да зачувува програми во овој формат.

Всушност, таа е многу слична на BASIC програма. Компјутерот ZX Spectrum складира програми во приближно ист формат во меморијата и ги зачувува програмите на лента. За секој случај, ги проверив клучните зборови против маса. Сепак, резултатот беше очигледно негативен.

Ги проверив и ОСНОВните клучни зборови на популарните Atari, Commodore 64 и неколку други од тоа време компјутери, за кои успеав да најдам документација, но безуспешно - моето знаење за видовите ретро компјутери се покажа дека не е толку широко.

Тогаш решив да одам листата, а потоа погледот ми падна на името на производителот Radio Shack и компјутерот TRS-80. Ова се имињата што беа испишани на етикетите на касетите што лежеа на мојата маса! Претходно не ги знаев овие имиња и не бев запознаен со компјутерот TRS-80, па ми се чинеше дека Radio Shack е производител на аудио касети како што се BASF, Sony или TDK, а TRS-80 беше времето за репродукција. Зошто да не?

Компјутер Tandy/Radio Shack TRS-80

Многу е веројатно дека предметната аудио снимка, која ја наведов како пример на почетокот на статијата, е направена на ваков компјутер:

Се испостави дека овој компјутер и неговите сорти (Модел I / Модел III / Модел IV, итн.) биле многу популарни едно време (се разбира, не во Русија). Вреди да се одбележи дека процесорот што го користеа исто така беше Z80. За овој компјутер можете да најдете на Интернет многу информации. Во 80-тите, компјутерските информации беа дистрибуирани во списанија. Во моментов има неколку емулатори компјутери за различни платформи.

Го симнав емулаторот trs80gp и за прв пат можев да видам како функционира овој компјутер. Се разбира, компјутерот не поддржуваше излез во боја, резолуцијата на екранот беше само 128x48 пиксели, но имаше многу екстензии и модификации кои можеа да ја зголемат резолуцијата на екранот. Имаше и многу опции за оперативни системи за овој компјутер и опции за имплементација на јазикот BASIC (кој, за разлика од ZX Spectrum, кај некои модели не беше ни „флешуван“ во ROM и секоја опција можеше да се вчита од флопи диск, исто како самиот ОС)

Најдов и јас алатка да конвертирам аудио снимки во CAS формат, кој е поддржан од емулатори, но поради некоја причина не беше можно да се читаат снимките од моите касети користејќи ги.

Откако го сфатив форматот на датотеката CAS (кој се испостави дека е само копија по малку од податоците од лентата што веќе ја имав при рака, освен заглавието со присуство на бајт за синхронизација), направив неколку промени во мојата програма и можев да излезам работна CAS-датотека што работеше во емулаторот (TRS-80 Model III):

Ја дизајнирав најновата верзија на алатката за конверзија со автоматско одредување на првиот пулс и растојанието помеѓу референтните импулси како GEM пакет, изворниот код е достапен на Github.

Заклучок

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

• Го сфатив форматот за зачувување податоци во ZX Spectrum и ги проучував вградените ROM рутини за зачувување/читање податоци од аудио касети
• Се запознав со компјутерот TRS-80 и неговите сорти, го проучував оперативниот систем, погледнав примероци на програми и дури имав можност да направам дебагирање во машинските кодови (на крајот на краиштата, сите мнемоници на Z80 ми се познати)
• Напиша целосна алатка за конвертирање аудио снимки во формат CAS, кој може да чита податоци што не се препознаваат од „официјалната“ алатка

Извор: www.habr.com