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

پس منظر

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

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

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

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

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

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

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

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

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

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

یہ خود سگنل کی شکل کا ذکر کرنے کے قابل ہے۔ مثال کے طور پر، ZX سپیکٹرم پر، اس کی شکل مستطیل ہے:

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

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

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

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

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

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

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

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

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

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

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

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

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

آئیے پہلے الگورتھم کو سادہ رکھنے کے لیے چند مفروضوں پر غور کریں:

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

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

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

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

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

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

حاصل يہ ہوا

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

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

ماخذ: www.habr.com