🥇 میں نے مقناطیسی ٹیپ سے نامعلوم فارمیٹ میں ڈیٹا کیسے بازیافت کیا

پس منظر

ریٹرو ہارڈویئر کے عاشق ہونے کے ناطے، میں نے ایک بار UK میں ایک بیچنے والے سے ZX Spectrum+ خریدا تھا۔ کمپیوٹر کے ساتھ ہی، میں نے گیمز کے ساتھ کئی آڈیو کیسٹس حاصل کیں (ہدایات کے ساتھ اصل پیکیجنگ میں) اور ساتھ ہی خصوصی نشانات کے بغیر کیسٹوں پر ریکارڈ کیے گئے پروگرام۔ حیرت کی بات یہ ہے کہ 40 سال پرانی کیسٹس کا ڈیٹا اچھی طرح سے پڑھنے کے قابل تھا اور میں ان سے تقریباً تمام گیمز اور پروگرامز ڈاؤن لوڈ کرنے میں کامیاب رہا۔

تاہم، کچھ کیسٹوں پر مجھے ایسی ریکارڈنگ ملی جو واضح طور پر ZX Spectrum کمپیوٹر کے ذریعے نہیں بنائی گئی تھیں۔ وہ بالکل مختلف لگ رہے تھے اور، مذکورہ کمپیوٹر سے ریکارڈنگ کے برعکس، انہوں نے ایک مختصر BASIC بوٹ لوڈر کے ساتھ شروع نہیں کیا، جو عام طور پر تمام پروگراموں اور گیمز کی ریکارڈنگ میں موجود ہوتا ہے۔

کچھ وقت کے لئے اس نے مجھے پریشان کیا - میں واقعی میں یہ جاننا چاہتا تھا کہ ان میں کیا چھپا ہوا ہے۔ اگر آپ آڈیو سگنل کو بائٹس کی ترتیب کے طور پر پڑھ سکتے ہیں، تو آپ حروف یا کوئی بھی چیز تلاش کر سکتے ہیں جو سگنل کی اصل کی نشاندہی کرتا ہو۔ ریٹرو آثار قدیمہ کی ایک قسم۔

اب جب کہ میں تمام راستے پر چلا گیا ہوں اور خود کیسٹوں کے لیبلز کو دیکھتا ہوں، میں مسکراتا ہوں کیونکہ

جواب بالکل میری آنکھوں کے سامنے تھا۔
بائیں کیسٹ کے لیبل پر TRS-80 کمپیوٹر کا نام ہے، اور مینوفیکچرر کے نام کے بالکل نیچے: "ریڈیو شیک امریکہ میں تیار کردہ"

(اگر آپ سازش کو آخر تک برقرار رکھنا چاہتے ہیں تو، بگاڑنے والے کے نیچے نہ جائیں)

آڈیو سگنلز کا موازنہ

سب سے پہلے، آڈیو ریکارڈنگ کو ڈیجیٹائز کرتے ہیں۔ آپ سن سکتے ہیں کہ یہ کیسا لگتا ہے:

اور ہمیشہ کی طرح ZX سپیکٹرم کمپیوٹر سے ریکارڈنگ کی آوازیں آتی ہیں:

دونوں صورتوں میں، ریکارڈنگ کے آغاز میں ایک نام نہاد ہے پائلٹ ٹون - ایک ہی فریکوئنسی کی آواز (پہلی ریکارڈنگ میں یہ بہت مختصر ہے <1 سیکنڈ، لیکن قابل امتیاز ہے)۔ پائلٹ ٹون کمپیوٹر کو ڈیٹا حاصل کرنے کے لیے تیار ہونے کا اشارہ دیتا ہے۔ ایک اصول کے طور پر، ہر کمپیوٹر سگنل کی شکل اور اس کی فریکوئنسی سے صرف اپنے "اپنی" پائلٹ ٹون کو پہچانتا ہے۔

سگنل کی شکل ہی کے بارے میں کچھ کہنا ضروری ہے۔ مثال کے طور پر، ZX سپیکٹرم پر اس کی شکل مستطیل ہے:

جب پائلٹ ٹون کا پتہ چلتا ہے، ZX سپیکٹرم اسکرین کے بارڈر پر باری باری سرخ اور نیلے رنگ کی سلاخوں کو دکھاتا ہے تاکہ یہ اشارہ کیا جا سکے کہ سگنل کو تسلیم کر لیا گیا ہے۔ پائلٹ ٹون ختم ہوتا ہے۔ synchro نبض، جو کمپیوٹر کو ڈیٹا وصول کرنا شروع کرنے کا اشارہ کرتا ہے۔ اس کی خصوصیت ایک مختصر دورانیے سے ہوتی ہے (پائلٹ ٹون اور اس کے بعد کے ڈیٹا کے مقابلے) (شکل دیکھیں)

مطابقت پذیری کی نبض موصول ہونے کے بعد، کمپیوٹر اس کی مدت کی پیمائش کرتے ہوئے، سگنل کے ہر عروج/زوال کو ریکارڈ کرتا ہے۔ اگر دورانیہ ایک خاص حد سے کم ہے تو، بٹ 1 میموری پر لکھا جاتا ہے، بصورت دیگر 0۔ بٹس کو بائٹس میں جمع کیا جاتا ہے اور عمل کو دہرایا جاتا ہے جب تک کہ N بائٹس موصول نہ ہوں۔ نمبر N عام طور پر ڈاؤن لوڈ فائل کے ہیڈر سے لیا جاتا ہے۔ لوڈنگ کی ترتیب مندرجہ ذیل ہے:

پائلٹ ٹون
ہیڈر (مقررہ لمبائی)، ڈاؤن لوڈ کردہ ڈیٹا کا سائز (N)، فائل کا نام اور قسم پر مشتمل ہے۔
پائلٹ ٹون
ڈیٹا خود

اس بات کو یقینی بنانے کے لیے کہ ڈیٹا کو صحیح طریقے سے لوڈ کیا گیا ہے، ZX سپیکٹرم نام نہاد پڑھتا ہے۔ برابری بائٹ (پیریٹی بائٹ)، جو تحریری ڈیٹا کے تمام بائٹس کو XOR کرکے فائل کو محفوظ کرتے وقت شمار کیا جاتا ہے۔ کسی فائل کو پڑھتے وقت، کمپیوٹر موصول ہونے والے ڈیٹا سے برابری بائٹ کا حساب لگاتا ہے اور، اگر نتیجہ محفوظ کردہ سے مختلف ہو، تو غلطی کا پیغام "R Tape loading error" دکھاتا ہے۔ سخت الفاظ میں، کمپیوٹر اس پیغام کو پہلے جاری کر سکتا ہے اگر، پڑھتے وقت، وہ نبض کو نہیں پہچان سکتا (چھوٹ گیا یا اس کا دورانیہ مخصوص حدود کے مطابق نہیں ہے)

تو، اب دیکھتے ہیں کہ ایک نامعلوم سگنل کیسا لگتا ہے:

یہ پائلٹ ٹون ہے۔ سگنل کی شکل نمایاں طور پر مختلف ہے، لیکن یہ واضح ہے کہ سگنل ایک مخصوص فریکوئنسی کی چھوٹی دھڑکنوں کو دہرانے پر مشتمل ہوتا ہے۔ 44100 ہرٹز کے نمونے لینے کی فریکوئنسی پر، "چوٹیوں" کے درمیان فاصلہ تقریباً 48 نمونے ہے (جو ~918 ہرٹز کی فریکوئنسی کے مساوی ہے)۔ آئیے اس اعداد و شمار کو یاد رکھیں۔

آئیے اب ڈیٹا کے ٹکڑے کو دیکھتے ہیں:

اگر ہم انفرادی دالوں کے درمیان فاصلے کی پیمائش کرتے ہیں، تو یہ پتہ چلتا ہے کہ "لمبی" دالوں کے درمیان فاصلہ اب بھی ~ 48 نمونوں، اور چھوٹی دالوں کے درمیان ~ 24 ہے۔ تھوڑا سا آگے دیکھتے ہوئے، میں یہ کہوں گا کہ آخر میں یہ پتہ چلا کہ 918 ہرٹز کی فریکوئنسی والی "حوالہ" دالیں فائل کے شروع سے آخر تک مسلسل چلتی ہیں۔ یہ فرض کیا جا سکتا ہے کہ ڈیٹا کو منتقل کرتے وقت، اگر حوالہ دال کے درمیان ایک اضافی نبض کا سامنا ہوتا ہے، تو ہم اسے بٹ 1 سمجھتے ہیں، ورنہ 0۔

مطابقت پذیری کی نبض کے بارے میں کیا خیال ہے؟ آئیے اعداد و شمار کے آغاز کو دیکھتے ہیں:

پائلٹ ٹون ختم ہو جاتا ہے اور ڈیٹا فوراً شروع ہو جاتا ہے۔ تھوڑی دیر بعد، کئی مختلف آڈیو ریکارڈنگز کا تجزیہ کرنے کے بعد، ہم یہ دریافت کرنے میں کامیاب ہوئے کہ ڈیٹا کا پہلا بائٹ ہمیشہ ایک جیسا ہوتا ہے (10100101b، A5h)۔ کمپیوٹر ڈیٹا حاصل کرنے کے بعد اسے پڑھنا شروع کر سکتا ہے۔

آپ مطابقت پذیری بائٹ میں آخری 1st کے فوراً بعد پہلی حوالہ پلس کی شفٹ پر بھی توجہ دے سکتے ہیں۔ یہ ڈیٹا ریکگنیشن پروگرام تیار کرنے کے عمل میں بہت بعد میں دریافت ہوا، جب فائل کے شروع میں موجود ڈیٹا کو مستحکم طور پر نہیں پڑھا جا سکتا تھا۔

اب ہم ایک الگورتھم کو بیان کرنے کی کوشش کرتے ہیں جو آڈیو فائل پر کارروائی کرے گا اور ڈیٹا لوڈ کرے گا۔

ڈیٹا لوڈ ہو رہا ہے۔

سب سے پہلے، الگورتھم کو سادہ رکھنے کے لیے چند مفروضوں پر نظر ڈالیں:

ہم صرف WAV فارمیٹ میں فائلوں پر غور کریں گے۔
آڈیو فائل کا آغاز پائلٹ ٹون سے ہونا چاہیے اور شروع میں خاموشی نہیں ہونی چاہیے۔
سورس فائل میں نمونے لینے کی شرح 44100 ہرٹز ہونی چاہیے۔ اس صورت میں، 48 نمونوں کی حوالہ دالوں کے درمیان فاصلہ پہلے سے طے شدہ ہے اور ہمیں پروگرام کے لحاظ سے اس کا حساب لگانے کی ضرورت نہیں ہے۔
نمونہ کی شکل کوئی بھی ہو سکتی ہے (8/16 بٹس/فلوٹنگ پوائنٹ) - چونکہ پڑھتے وقت ہم اسے مطلوبہ میں تبدیل کر سکتے ہیں۔
ہم فرض کرتے ہیں کہ سورس فائل کو طول و عرض کے ذریعہ معمول بنایا گیا ہے، جس سے نتیجہ کو مستحکم کرنا چاہئے؛

پڑھنے کا الگورتھم اس طرح ہوگا:

ہم فائل کو میموری میں پڑھتے ہیں، اسی وقت سیمپل فارمیٹ کو 8 بٹس میں تبدیل کرتے ہیں۔
آڈیو ڈیٹا میں پہلی نبض کی پوزیشن کا تعین کریں۔ ایسا کرنے کے لیے، آپ کو زیادہ سے زیادہ طول و عرض کے ساتھ نمونے کی تعداد کا حساب لگانا ہوگا۔ سادگی کے لیے، ہم اسے ایک بار دستی طور پر شمار کریں گے۔ آئیے اسے متغیر میں محفوظ کریں prev_pos;
آخری نبض کی پوزیشن میں 48 شامل کریں (pos:= prev_pos + 48)
چونکہ پوزیشن کو 48 تک بڑھانا اس بات کی ضمانت نہیں دیتا ہے کہ ہم اگلے حوالہ پلس کی پوزیشن پر پہنچ جائیں گے (ٹیپ کے نقائص، ٹیپ ڈرائیو میکانزم کا غیر مستحکم آپریشن وغیرہ)، ہمیں پوز پلس کی پوزیشن کو ایڈجسٹ کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے، ڈیٹا کا ایک چھوٹا ٹکڑا لیں (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 کے کچھ پڑوس میں (midle_pos-8;middle_pos +8) آئیے زیادہ سے زیادہ اور کم از کم طول و عرض کا حساب لگاتے ہیں۔ اگر ان کے درمیان فرق 10 سے زیادہ ہے، تو ہم نتیجہ میں بٹ 1 لکھتے ہیں، بصورت دیگر 0۔ 10 تجرباتی طور پر حاصل کردہ مستقل ہے۔
موجودہ پوزیشن کو prev_pos میں محفوظ کریں (prev_pos := pos)
مرحلہ 3 سے اس وقت تک دہرائیں جب تک کہ ہم پوری فائل کو نہ پڑھ لیں۔
نتیجے میں بٹ سرنی کو بائٹس کے سیٹ کے طور پر محفوظ کیا جانا چاہیے۔ چونکہ ہم نے پڑھتے وقت مطابقت پذیری بائٹ کو مدنظر نہیں رکھا، اس لیے بٹس کی تعداد 8 کی ضرب نہیں ہو سکتی، اور مطلوبہ بٹ آفسیٹ بھی نامعلوم ہے۔ الگورتھم کے پہلے نفاذ میں، میں سنک بائٹ کے وجود کے بارے میں نہیں جانتا تھا اور اس لیے میں نے 8 فائلوں کو مختلف نمبروں کے آفسیٹ بٹس کے ساتھ محفوظ کیا۔ ان میں سے ایک درست ڈیٹا پر مشتمل تھا۔ حتمی الگورتھم میں، میں صرف A5h تک کے تمام بٹس کو ہٹا دیتا ہوں، جو مجھے فوری طور پر صحیح آؤٹ پٹ فائل حاصل کرنے کی اجازت دیتا ہے۔

دلچسپی رکھنے والوں کے لیے روبی میں الگورتھم
میں نے پروگرام لکھنے کے لیے روبی کو زبان کے طور پر چنا، کیونکہ... میں زیادہ تر وقت اس پر پروگرام کرتا ہوں۔ آپشن اعلیٰ کارکردگی کا نہیں ہے، لیکن پڑھنے کی رفتار کو جتنا ممکن ہو سکے تیز کرنے کا کام اس کے قابل نہیں ہے۔

# Используем 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 کی دہائی کا کون سا کمپیوٹر اس فارمیٹ میں پروگراموں کو محفوظ کر سکتا ہے۔

درحقیقت، یہ ایک بنیادی پروگرام سے بہت ملتا جلتا ہے۔ ZX سپیکٹرم کمپیوٹر پروگراموں کو تقریباً ایک ہی فارمیٹ میں میموری میں اسٹور کرتا ہے اور پروگراموں کو ٹیپ میں محفوظ کرتا ہے۔ صرف اس صورت میں، میں نے مطلوبہ الفاظ کے خلاف چیک کیا۔ ٹیبل. تاہم، نتیجہ واضح طور پر منفی تھا.

میں نے اس وقت کے مشہور اٹاری، کموڈور 64 اور کئی دوسرے کمپیوٹرز کے بنیادی کلیدی الفاظ بھی چیک کیے، جن کے لیے میں دستاویزات تلاش کرنے میں کامیاب رہا، لیکن کامیابی کے بغیر - ریٹرو کمپیوٹرز کی اقسام کے بارے میں میرا علم اتنا وسیع نہیں تھا۔

پھر میں نے جانے کا فیصلہ کیا۔ فہرست، اور پھر میری نظر صنعت کار ریڈیو شیک اور TRS-80 کمپیوٹر کے نام پر پڑی۔ یہ وہ نام ہیں جو میری میز پر پڑی کیسٹوں کے لیبل پر لکھے ہوئے تھے! میں ان ناموں کو پہلے نہیں جانتا تھا اور TRS-80 کمپیوٹر سے واقف نہیں تھا، اس لیے مجھے ایسا لگتا تھا کہ ریڈیو شیک ایک آڈیو کیسٹ بنانے والی کمپنی ہے جیسے BASF، Sony یا TDK، اور TRS-80 پلے بیک کا وقت تھا۔ کیوں نہیں؟

کمپیوٹر ٹینڈی/ریڈیو شیک TRS-80

یہ بہت ممکن ہے کہ زیر بحث آڈیو ریکارڈنگ، جسے میں نے مضمون کے شروع میں بطور مثال پیش کیا تھا، کمپیوٹر پر اس طرح بنایا گیا تھا:

معلوم ہوا کہ یہ کمپیوٹر اور اس کی اقسام (ماڈل I/ماڈل III/ماڈل IV وغیرہ) ایک زمانے میں بہت مشہور تھے (یقیناً روس میں نہیں)۔ قابل ذکر ہے کہ انہوں نے جو پروسیسر استعمال کیا وہ بھی Z80 تھا۔ اس کمپیوٹر کے لیے آپ انٹرنیٹ پر تلاش کر سکتے ہیں۔ بہت ساری معلومات. 80 کی دہائی میں کمپیوٹر کی معلومات تقسیم کی گئیں۔ میگزین. اس وقت کئی ہیں۔ ایمولیٹر مختلف پلیٹ فارمز کے لیے کمپیوٹر۔

میں نے ایمولیٹر ڈاؤن لوڈ کیا۔ trs80gp اور پہلی بار میں یہ دیکھنے کے قابل ہوا کہ یہ کمپیوٹر کیسے کام کرتا ہے۔ بلاشبہ، کمپیوٹر کلر آؤٹ پٹ کو سپورٹ نہیں کرتا تھا؛ اسکرین کی ریزولوشن صرف 128x48 پکسلز تھی، لیکن اس میں بہت سی ایکسٹینشنز اور ترمیمات تھیں جو اسکرین ریزولوشن کو بڑھا سکتی تھیں۔ اس کمپیوٹر کے لیے آپریٹنگ سسٹمز کے لیے بہت سے آپشنز اور بنیادی زبان کو لاگو کرنے کے لیے آپشنز بھی موجود تھے (جو ZX سپیکٹرم کے برعکس، کچھ ماڈلز میں ROM میں "فلیش" بھی نہیں تھے اور کسی بھی آپشن کو فلاپی ڈسک سے لوڈ کیا جا سکتا تھا، جیسے OS خود)

مجھے بھی مل گیا۔ افادیت آڈیو ریکارڈنگ کو CAS فارمیٹ میں تبدیل کرنے کے لیے، جو ایمولیٹرز کے ذریعے سپورٹ کیا جاتا ہے، لیکن کسی وجہ سے ان کا استعمال کرتے ہوئے میری کیسٹوں سے ریکارڈنگ پڑھنا ممکن نہیں تھا۔

CAS فائل فارمیٹ کا پتہ لگانے کے بعد (جو میرے پاس پہلے سے موجود ٹیپ سے اعداد و شمار کی تھوڑی سی کاپی نکلی، سوائے سنک بائٹ کی موجودگی والے ہیڈر کے)، میں نے ایک میرے پروگرام میں کچھ تبدیلیاں اور کام کرنے والی CAS فائل کو آؤٹ پٹ کرنے کے قابل تھا جو ایمولیٹر (TRS-80 ماڈل III) میں کام کرتی تھی:

میں نے تبادلوں کی افادیت کا تازہ ترین ورژن پہلی نبض کے خودکار تعین اور GEM پیکج کے بطور حوالہ دالوں کے درمیان فاصلے کے ساتھ ڈیزائن کیا، سورس کوڈ یہاں پر دستیاب ہے۔ Github کے.

حاصل يہ ہوا

ہم نے جس راستے پر سفر کیا ہے وہ ماضی میں ایک دلچسپ سفر ثابت ہوا، اور مجھے خوشی ہے کہ آخر میں مجھے اس کا جواب مل گیا۔ دوسری چیزوں کے علاوہ، میں:

میں نے ZX سپیکٹرم میں ڈیٹا کو محفوظ کرنے کے لیے فارمیٹ کا پتہ لگایا اور آڈیو کیسٹوں سے ڈیٹا کو محفوظ کرنے/پڑھنے کے لیے پہلے سے موجود ROM روٹینز کا مطالعہ کیا۔
میں نے TRS-80 کمپیوٹر اور اس کی اقسام سے واقفیت حاصل کی، آپریٹنگ سسٹم کا مطالعہ کیا، نمونے کے پروگراموں کو دیکھا اور یہاں تک کہ مجھے مشین کوڈز میں ڈیبگنگ کرنے کا موقع ملا (آخر کار، تمام Z80 یادداشتیں مجھ سے واقف ہیں)
آڈیو ریکارڈنگ کو CAS فارمیٹ میں تبدیل کرنے کے لیے ایک مکمل افادیت لکھی، جو اس ڈیٹا کو پڑھ سکتی ہے جسے "آفیشل" یوٹیلیٹی نے تسلیم نہیں کیا ہے۔

ماخذ: www.habr.com

میں نے مقناطیسی ٹیپ سے نامعلوم فارمیٹ میں ڈیٹا کیسے بازیافت کیا۔