কিভাবে আমি চৌম্বকীয় টেপ থেকে একটি অজানা বিন্যাসে ডেটা পুনরুদ্ধার করেছি

প্রাগঐতিহাসিক

রেট্রো হার্ডওয়্যারের প্রেমিক হওয়ার কারণে, আমি একবার যুক্তরাজ্যের একজন বিক্রেতার কাছ থেকে ZX Spectrum+ কিনেছিলাম। কম্পিউটারের সাথেই অন্তর্ভুক্ত, আমি গেম সহ বেশ কয়েকটি অডিও ক্যাসেট পেয়েছি (নির্দেশ সহ মূল প্যাকেজিংয়ে), সেইসাথে বিশেষ চিহ্ন ছাড়াই ক্যাসেটে রেকর্ড করা প্রোগ্রামগুলি। আশ্চর্যজনকভাবে, 40 বছর বয়সী ক্যাসেটগুলি থেকে ডেটা ভালভাবে পাঠযোগ্য ছিল এবং আমি সেগুলি থেকে প্রায় সমস্ত গেম এবং প্রোগ্রাম ডাউনলোড করতে সক্ষম হয়েছিলাম।

যাইহোক, কিছু ক্যাসেটে আমি রেকর্ডিং পেয়েছি যা স্পষ্টতই ZX স্পেকট্রাম কম্পিউটার দ্বারা তৈরি করা হয়নি। তারা সম্পূর্ণ ভিন্ন শোনাচ্ছে এবং উল্লিখিত কম্পিউটারের রেকর্ডিংয়ের বিপরীতে, তারা একটি ছোট বেসিক বুটলোডার দিয়ে শুরু করেনি, যা সাধারণত সমস্ত প্রোগ্রাম এবং গেমের রেকর্ডিংয়ে উপস্থিত থাকে।

কিছু সময়ের জন্য এটি আমাকে তাড়িত করেছিল - আমি সত্যিই তাদের মধ্যে কী লুকিয়ে ছিল তা খুঁজে বের করতে চেয়েছিলাম। আপনি যদি বাইটের ক্রম হিসাবে অডিও সিগন্যালটি পড়তে পারেন, আপনি অক্ষর বা সংকেতের উত্স নির্দেশ করে এমন কিছু সন্ধান করতে পারেন। এক ধরনের রেট্রো-প্রত্নতত্ত্ব।

এখন যেহেতু আমি সমস্ত পথ চলে এসেছি এবং নিজেরাই ক্যাসেটের লেবেলগুলি দেখেছি, আমি হাসছি কারণ

উত্তর সব বরাবর আমার চোখের সামনে ছিল
বাম ক্যাসেটের লেবেলে TRS-80 কম্পিউটারের নাম এবং নির্মাতার নামের ঠিক নীচে: "মার্কিন যুক্তরাষ্ট্রে রেডিও শ্যাক দ্বারা নির্মিত"

(যদি আপনি শেষ পর্যন্ত ষড়যন্ত্র রাখতে চান তবে স্পয়লারের নীচে যাবেন না)

অডিও সংকেত তুলনা

প্রথমত, অডিও রেকর্ডিংগুলোকে ডিজিটাইজ করা যাক। আপনি এটির মত শুনতে পারেন:

এবং যথারীতি জেডএক্স স্পেকট্রাম কম্পিউটার থেকে রেকর্ডিং শোনাচ্ছে:

উভয় ক্ষেত্রেই, রেকর্ডিংয়ের শুরুতে একটি তথাকথিত রয়েছে পাইলট টোন - একই কম্পাঙ্কের একটি শব্দ (প্রথম রেকর্ডিংয়ে এটি খুব ছোট <1 সেকেন্ড, তবে আলাদা করা যায়)। পাইলট টোন কম্পিউটারকে ডেটা গ্রহণের জন্য প্রস্তুত করার সংকেত দেয়। একটি নিয়ম হিসাবে, প্রতিটি কম্পিউটার সিগন্যালের আকার এবং এর ফ্রিকোয়েন্সি দ্বারা শুধুমাত্র তার "নিজের" পাইলট টোনকে স্বীকৃতি দেয়।

সংকেত আকার সম্পর্কে কিছু বলা প্রয়োজন। উদাহরণস্বরূপ, ZX স্পেকট্রামে এর আকৃতি আয়তক্ষেত্রাকার:

যখন একটি পাইলট টোন সনাক্ত করা হয়, তখন ZX স্পেকট্রাম স্ক্রীনের সীমানায় পর্যায়ক্রমে লাল এবং নীল বার প্রদর্শন করে যে সংকেতটি স্বীকৃত হয়েছে। পাইলট টোন শেষ সিঙ্ক্রো পালস, যা কম্পিউটারকে ডেটা গ্রহণ শুরু করার জন্য সংকেত দেয়। এটি একটি সংক্ষিপ্ত সময়কাল দ্বারা চিহ্নিত করা হয় (পাইলট টোন এবং পরবর্তী ডেটার তুলনায়) (চিত্র দেখুন)

সিঙ্ক পালস পাওয়ার পর, কম্পিউটার তার সময়কাল পরিমাপ করে সিগন্যালের প্রতিটি উত্থান/পতন রেকর্ড করে। সময়কাল একটি নির্দিষ্ট সীমার চেয়ে কম হলে, বিট 1 মেমরিতে লেখা হয়, অন্যথায় 0। বিটগুলি বাইটে সংগ্রহ করা হয় এবং N বাইট না পাওয়া পর্যন্ত প্রক্রিয়াটি পুনরাবৃত্তি করা হয়। N সংখ্যাটি সাধারণত ডাউনলোড করা ফাইলের হেডার থেকে নেওয়া হয়। লোডিং ক্রম নিম্নরূপ:

1. পাইলট টোন
2. শিরোনাম (নির্দিষ্ট দৈর্ঘ্য), ডাউনলোড করা ডেটার আকার (N), ফাইলের নাম এবং প্রকার রয়েছে
3. পাইলট টোন
4. ডেটা নিজেই

ডেটা সঠিকভাবে লোড হয়েছে তা নিশ্চিত করতে, ZX স্পেকট্রাম তথাকথিত পড়ে সমতা বাইট (প্যারিটি বাইট), যা লিখিত ডেটার সমস্ত বাইট XOR করে ফাইল সংরক্ষণ করার সময় গণনা করা হয়। একটি ফাইল পড়ার সময়, কম্পিউটার প্রাপ্ত ডেটা থেকে প্যারিটি বাইট গণনা করে এবং, যদি ফলাফলটি সংরক্ষিত একটি থেকে ভিন্ন হয়, তাহলে "আর টেপ লোডিং ত্রুটি" ত্রুটি বার্তা প্রদর্শন করে। কঠোরভাবে বলতে গেলে, কম্পিউটারটি আগে এই বার্তাটি ইস্যু করতে পারে যদি, পড়ার সময়, এটি একটি পালস চিনতে না পারে (মিস হয় বা এর সময়কাল নির্দিষ্ট সীমার সাথে সামঞ্জস্যপূর্ণ না হয়)

তো, এখন দেখা যাক একটি অজানা সংকেত কেমন দেখায়:

এটি পাইলট টোন। সংকেতের আকৃতি উল্লেখযোগ্যভাবে ভিন্ন, তবে এটি স্পষ্ট যে সংকেতটিতে একটি নির্দিষ্ট ফ্রিকোয়েন্সির সংক্ষিপ্ত স্পন্দন পুনরাবৃত্তি হয়। 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) এবং এটিতে সর্বাধিক প্রশস্ততার মান খুঁজুন। সর্বাধিক অনুরূপ অবস্থান pos সংরক্ষণ করা হবে. এখানে 8 = 48/6 হল একটি পরীক্ষামূলকভাবে প্রাপ্ত ধ্রুবক, যা গ্যারান্টি দেয় যে আমরা সঠিক সর্বোচ্চ নির্ধারণ করব এবং কাছাকাছি থাকা অন্যান্য আবেগকে প্রভাবিত করব না। খুব খারাপ ক্ষেত্রে, যখন ডালের মধ্যে দূরত্ব 48 এর চেয়ে অনেক কম বা তার বেশি হয়, তখন একটি নাড়ির জন্য একটি জোরপূর্বক অনুসন্ধান প্রয়োগ করা যেতে পারে, তবে নিবন্ধের সুযোগের মধ্যে আমি অ্যালগরিদমে এটি বর্ণনা করব না;
5. পূর্ববর্তী ধাপে, রেফারেন্স পালসটি আদৌ পাওয়া গেছে কিনা তাও পরীক্ষা করা প্রয়োজন। অর্থাৎ, আপনি যদি কেবলমাত্র সর্বাধিক সন্ধান করেন, তবে এটি গ্যারান্টি দেয় না যে এই সেগমেন্টে আবেগ উপস্থিত রয়েছে। রিডিং প্রোগ্রামের আমার সর্বশেষ বাস্তবায়নে, আমি একটি বিভাগে সর্বোচ্চ এবং সর্বনিম্ন প্রশস্ততার মানগুলির মধ্যে পার্থক্য পরীক্ষা করি এবং যদি এটি একটি নির্দিষ্ট সীমা অতিক্রম করে তবে আমি একটি আবেগের উপস্থিতি গণনা করি। রেফারেন্স পালস না পাওয়া গেলে কী করবেন তাও প্রশ্ন। 2টি বিকল্প রয়েছে: হয় ডেটা শেষ হয়ে গেছে এবং নীরবতা অনুসরণ করা হয়েছে, অথবা এটি একটি পড়ার ত্রুটি হিসাবে বিবেচিত হওয়া উচিত। যাইহোক, আমরা অ্যালগরিদম সহজ করার জন্য এটি বাদ দেব;
6. পরবর্তী ধাপে, আমাদের একটি ডেটা পালস (বিট 0 বা 1) এর উপস্থিতি নির্ধারণ করতে হবে, এর জন্য আমরা সেগমেন্টের মাঝামাঝি (prev_pos;pos) মিডল_পোস সমান মিডল_পোস := (prev_pos+pos)/2 এবং সেগমেন্টে (middle_pos-8;middle_pos +8) এর কিছু আশেপাশে সর্বাধিক এবং সর্বনিম্ন প্রশস্ততা গণনা করা যাক। যদি তাদের মধ্যে পার্থক্য 10 এর বেশি হয়, আমরা ফলাফলে বিট 1 লিখি, অন্যথায় 0. 10 পরীক্ষামূলকভাবে প্রাপ্ত একটি ধ্রুবক;
7. বর্তমান অবস্থানটি prev_pos এ সংরক্ষণ করুন (prev_pos := pos)
8. আমরা সম্পূর্ণ ফাইল না পড়া পর্যন্ত ধাপ 3 থেকে শুরু করে পুনরাবৃত্তি করুন;
9. ফলস্বরূপ বিট অ্যারে বাইটের সেট হিসাবে সংরক্ষণ করা আবশ্যক। যেহেতু আমরা পড়ার সময় সিঙ্ক বাইট বিবেচনা করিনি, তাই বিটের সংখ্যা 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 এর দশকের কোন কম্পিউটার এই বিন্যাসে প্রোগ্রামগুলি সংরক্ষণ করতে পারে।

আসলে, এটি একটি বেসিক প্রোগ্রামের অনুরূপ। জেডএক্স স্পেকট্রাম কম্পিউটার প্রোগ্রামগুলিকে প্রায় একই বিন্যাসে মেমরিতে সংরক্ষণ করে এবং প্রোগ্রামগুলিকে টেপে সংরক্ষণ করে। শুধু ক্ষেত্রে, আমি বিরুদ্ধে কীওয়ার্ড চেক টেবিল. তবে, ফলাফল স্পষ্টতই নেতিবাচক ছিল।

আমি সেই সময়ের জনপ্রিয় আটারি, কমোডোর 64 এবং অন্যান্য বেশ কয়েকটি কম্পিউটারের বেসিক কীওয়ার্ডগুলিও পরীক্ষা করেছিলাম, যার জন্য আমি ডকুমেন্টেশন খুঁজে পেতে সক্ষম হয়েছিলাম, কিন্তু সাফল্য ছাড়াই - রেট্রো কম্পিউটারের প্রকারগুলি সম্পর্কে আমার জ্ঞান এত বিস্তৃত ছিল না।

তারপর আমি যাওয়ার সিদ্ধান্ত নিলাম ক্রমতালিকা, এবং তারপরে আমার দৃষ্টি প্রস্তুতকারক রেডিও শ্যাক এবং TRS-80 কম্পিউটারের নামে পড়েছিল। আমার টেবিলে পড়ে থাকা ক্যাসেটের লেবেলে লেখা এই নামগুলো! আমি এই নামগুলি আগে জানতাম না এবং TRS-80 কম্পিউটারের সাথে পরিচিত ছিলাম না, তাই আমার কাছে মনে হয়েছিল যে রেডিও শ্যাক একটি অডিও ক্যাসেট প্রস্তুতকারক যেমন BASF, Sony বা TDK, এবং TRS-80 ছিল প্লেব্যাকের সময়৷ কেন না?

কম্পিউটার ট্যান্ডি/রেডিও শ্যাক TRS-80

এটি খুব সম্ভবত যে প্রশ্নে অডিও রেকর্ডিং, যা আমি নিবন্ধের শুরুতে একটি উদাহরণ হিসাবে দিয়েছিলাম, এটির মতো একটি কম্পিউটারে তৈরি করা হয়েছিল:

দেখা গেল যে এই কম্পিউটার এবং এর জাতগুলি (মডেল I/Model III/Model IV, ইত্যাদি) এক সময়ে খুব জনপ্রিয় ছিল (অবশ্যই, রাশিয়ায় নয়)। এটি উল্লেখযোগ্য যে তারা যে প্রসেসর ব্যবহার করেছিল সেটিও ছিল Z80। এই কম্পিউটারের জন্য আপনি ইন্টারনেটে খুঁজে পেতে পারেন অনেক তথ্য. 80 এর দশকে, কম্পিউটার তথ্য বিতরণ করা হয়েছিল পত্রিকা. এই মুহূর্তে বেশ কিছু আছে অনুকরণকারী বিভিন্ন প্ল্যাটফর্মের জন্য কম্পিউটার।

আমি এমুলেটর ডাউনলোড করেছি trs80gp এবং প্রথমবারের মতো আমি দেখতে সক্ষম হয়েছিলাম কিভাবে এই কম্পিউটার কাজ করে। অবশ্যই, কম্পিউটারটি রঙের আউটপুট সমর্থন করে না; স্ক্রীন রেজোলিউশনটি শুধুমাত্র 128x48 পিক্সেল ছিল, তবে অনেক এক্সটেনশন এবং পরিবর্তন ছিল যা স্ক্রীন রেজোলিউশন বাড়াতে পারে। এই কম্পিউটারের জন্য অপারেটিং সিস্টেমের জন্য অনেকগুলি বিকল্প এবং বেসিক ভাষা বাস্তবায়নের জন্য বিকল্পগুলিও ছিল (যা, ZX স্পেকট্রামের বিপরীতে, কিছু মডেলগুলিতে রমে "ফ্ল্যাশ"ও করা হয়নি এবং যে কোনও বিকল্প ফ্লপি ডিস্ক থেকে লোড করা যেতে পারে, ঠিক যেমন ওএস নিজেই)

আমিও খুঁজে পেয়েছি উপযোগ অডিও রেকর্ডিংগুলিকে CAS ফরম্যাটে রূপান্তর করতে, যা এমুলেটর দ্বারা সমর্থিত, কিন্তু কিছু কারণে সেগুলি ব্যবহার করে আমার ক্যাসেটগুলি থেকে রেকর্ডিং পড়া সম্ভব হয়নি।

CAS ফাইলের বিন্যাসটি বের করার পরে (যা আমার হাতে ইতিমধ্যেই থাকা টেপ থেকে ডেটার একটি বিটওয়াইজ কপি বলে প্রমাণিত হয়েছে, একটি সিঙ্ক বাইটের উপস্থিতি সহ হেডার ব্যতীত), আমি আমার কিছু পরিবর্তন করেছি প্রোগ্রাম এবং একটি কার্যকরী CAS ফাইল আউটপুট করতে সক্ষম হয়েছিল যা এমুলেটরে কাজ করেছিল (TRS-80 মডেল III):

আমি প্রথম পালসের স্বয়ংক্রিয় সংকল্প এবং একটি জিইএম প্যাকেজ হিসাবে রেফারেন্স ডালের মধ্যে দূরত্ব সহ রূপান্তর ইউটিলিটির সর্বশেষ সংস্করণটি ডিজাইন করেছি, উত্স কোড এখানে উপলব্ধ গিটহাব.

উপসংহার

আমরা যে পথটি ভ্রমণ করেছি তা অতীতে একটি আকর্ষণীয় যাত্রায় পরিণত হয়েছে এবং আমি আনন্দিত যে শেষ পর্যন্ত আমি উত্তরটি খুঁজে পেয়েছি। অন্যান্য জিনিসের মধ্যে, আমি:

• আমি ZX স্পেকট্রামে ডেটা সংরক্ষণের বিন্যাসটি বের করেছি এবং অডিও ক্যাসেট থেকে ডেটা সংরক্ষণ/পড়ার জন্য বিল্ট-ইন রম রুটিনগুলি অধ্যয়ন করেছি
• আমি TRS-80 কম্পিউটার এবং এর বৈচিত্র্যের সাথে পরিচিত হয়েছি, অপারেটিং সিস্টেম অধ্যয়ন করেছি, নমুনা প্রোগ্রামগুলি দেখেছি এবং এমনকি মেশিন কোডগুলিতে ডিবাগিং করার সুযোগ পেয়েছি (সর্বশেষে, সমস্ত Z80 স্মৃতিবিদ্যা আমার কাছে পরিচিত)
• অডিও রেকর্ডিংগুলিকে CAS ফর্ম্যাটে রূপান্তর করার জন্য একটি পূর্ণাঙ্গ ইউটিলিটি লিখেছেন, যা "অফিসিয়াল" ইউটিলিটি দ্বারা স্বীকৃত নয় এমন ডেটা পড়তে পারে

উত্স: www.habr.com