Электроника Д3-28 (Вопросы по этому "Калькулятору с кассетой")

[dk_spb]

Попались 4 неизвестные кассеты, точнее 5

Приноси. Оцифрую - верну.

[sanders]

Приноси. Оцифрую - верну.

Хорошо. Не знал, что ты и это умеешь.

[Mixa]

Расскажу свою историю. 15ВСМ-5 и Д3-28 это самые первые машины, с которыми познакомился вживую, и которые в то время только усилили желание разобраться и понять, как все-таки ЭВМ устроены и как их придумывают и делают. Со временем, конечно, и разобрался, и понял, но то давнишнее желание никуда не исчезло. То, что есть полные схемы принципиальные Д3-28, техническое описание и снятое содержимое управляющего ПЗУ - это просто клад оказался. По ним на питоне изобразил функциональную модель, которая ходит по упр. ПЗУ и интерпретирует его. Пока со схемой разбирался, в голове и осциллограф выстроил, осциллограммами мысленными насладился вдоволь, как и канифолью от мысленного паяльника тоже надышался.
Модель делалась не ради модели, а чтобы посмотреть, как Д3-28 устроена, и что и как внутри у нее по шинам и регистрам бегает.

Да, я что-то слышал про Wang, что он прототип, но в ту сторону сильно не смотрел и в тему не углублялся. До тех пор, пока не приспичило разобраться, что такое есть 15ВСМ-5. А вот с этой машинкой все гораздо сложнее, документации нет, реверса никакого нет, что внутри - загадка, экземпляров живых под рукой нет. Подумал, вдруг Wang чем-то поможет. И там, и там ферритовое ОЗУ 1К, команды в целом совпадают, Д3-28 с очевидностью развитие 15ВСМ-5, вдруг какой-то намек на что-то будет, как сделать шаг назад к 15ВСМ-5. В сети нашел схемы Wang700, снятые содержимые их управляющих ПЗУ. При сравнении оказалось, что формат управляющего слова (набор полей, их назначение, длина, расположение) в 43 бита идентичен формату Д3-28, по всем 13-и полям. 44-й бит у Д3-28 добавлен как еще один адресный разряд uROM, для удвоения его размера. Использован 44-й бит, который у Wang помечен как Not Used. Кодировка полей изменена у 4 полей, по остальным 9-и кодировка идентична, как и функционал их исполнительных узлов.

Дальше сделал следующее. В модели Д3-28 убрал отсутствующие у Wang регистры, изменил поведение 2-х мультиплексоров и 2-ч дешифраторов (для тех 4-х не полностью совпадающих полей) под логику кодирования и исполнения у Wang, изменил поведение ОЗУ. Потому что ОЗУ ферритовое, при чтении ячейки очищаются. Изменение логики исполнительных узлов сделало их описание более компактным и менее запутанным.

После изменений подключил к модели uROM от Wang, модель заработала.
Теперь я в задумчивости, модель чего у меня вышла. Обрезанная от отсутствующих в 15ВСМ-5 регистров Д3-28, и возвращенные к изначальному виду два мультиплексора и два декодера - наверное, такая и была 15ВСМ-5 ? То есть, у меня модель 15ВСМ-5 ?

Если у Д3-28 убрать регистры A1 A2 A3 A4 УК М , "выпрямить" логику работы мультиплексоров, управляемых сигналами групп 1w 2w 8w 10w, подключить ОЗУ со свойством очистки ячейки при чтении и подключить uROM от Wang как есть без изменения, то получится рабочая машинка!

Отображение фиксированная запятая - плавающий формат на индикаторах X и Y у Wang тоже определяются битами с перевернутыми друг относительно друга значениями для X и Y. Для X семантика одна, для Y обратная. Когда строил модель Д3-28, это была одна из ошибок, и чтобы поправить отображение XY углублялся в схему, с недоумением, зачем так сделано. Вот у Wang то же самое. Ну и у 15ВСМ-5 скорее всего.

Где бы снять содержимое упр. ПЗУ от 15ВСМ-5 ??

[RadioKing]

Знакомый оцифровал кассету, передаю сюда. Кажется, от Д3-28, но я не уверен.
На стороне 1 данные начинаются после 17 минут, до этого музыка.
https://disk.yandex.ru/d/lyx_zzQCwhi1lQ

Sinus, посмотрите, если несложно

[Sinus]

Кажется, от Д3-28, но я не уверен.

Да, кассета от Д3-28. В файле 2.wav много копий одного и того же Бейсика для Д3-28, но вся запись искажена паразитным сигналом с частотой примерно 1.5 кГц. В файле 1.wav после музыки идут две копии пользовательской бейсик-программки с именем FORSO. Её раскодировка и pdf с информацией об оцифровке здесь: https://disk.yandex.ru/d/brgcMcejvUNwwA (файл forso_bas.zip).

[RadioKing]

Огромное спасибо и за оперативность, и за качество!
Так понимаю, запись велась через SAVE R, и на сегодня иных методов распознавания кроме маткадовского метода не существует?
И ещё вопрос, где бегло можно почитать про формат txt файлов для эмулятора? Так понимаю, это просто восьмеричные числа друг за другом?

[Sinus]

RadioKing, я ответил Вам подробно, но вышло длинно, поэтому спрятал текст:

► Показать

Так понимаю, запись велась через SAVE R

Да, бейсик-программка записывается Бейсиком автоматически в цикле машинных команд SAVE R.

Пользователь Д3-28 с Бейсиком просто на клавиатуре терминала печатает Бейсику команду SAVE'имя_программы' и нажимает клавишу ПС, т.е. "Перевод Строки". А Бейсик уже сам управляет магнитофоном и делает запись в виде 256-байтных блоков с 4-кратным дублированием каждого блока. В такой записи на магнитной ленте между дублями блоков виден некий маркерный импульс на фоне короткой паузы, а между разными блоками видна более длинная пауза.

Каждая копия самого Бейсика записана не блоками, а "одним куском", машинной командой SAVE X. В упомянутом файле 2.wav в одной из копий я попробовал самодельной прогой отфильтровать помеху. Вроде получился Бейсик с тем же количеством байт (11344), как у двух уже известных Бейсиков (с контрольными суммами 157107 и 157057), но с контрольной суммой 157069 - такая версия тоже запустилась в имитаторе, но раньше мне не встречалась. Надо будет для проверки ещё хотя бы одну копию записи раскодировать. А ещё лучше бы заранее знать правильную контрольную сумму - из надписей на кассете, если они там есть. Различие в Бейсиках может быть связано с тем, что они для разных дисплейных терминалов как-то оптимизированы.
---
UPD 18.01.2026:
Раскодировкой ещё одной копии Бейсика из файла 2.wav подтвердилась правильность раскодировки с контрольной суммой 157069. Результат помещён в папку D3-28 (https://yadi.sk/d/lyMwL58zuExSD ) в файл:

Basic_D3-28_3a_KP-157069_N-11343.txt (с комментарием в конце)
https://disk.yandex.ru/d/c9DH3rZryQVvFQ

Удобный для раскодирования блок с пониженной частотой дискретизации помещён в папку D3-28_wav (https://yadi.sk/d/299-xaj_3NLszF ) в wav-файл:

Basic_157069_8kHz_1block.wav (3.5 мегабайт)
https://disk.yandex.ru/d/fc-rm4lB916wVw
---

на сегодня иных методов распознавания кроме маткадовского метода не существует?

Маткад необязателен. Раскодирование заключается просто в выявлении очерёдности резких перепадов (т.е. "фронтов" и "спадов") сигналов в двух каналах записи; последовательность всех таких перепадов есть битовый поток - нули и единицы, из которых образуется последовательность байтов. В.В. Колесник (создатель сайта d3-28.ru) пытался автоматизировать такую раскодировку в Python. Но не удаётся избежать действий "глазами и руками". Потому, что:

. Wav-запись сначала надо правильно порезать на фрагменты (на 256-байтные блоки, если запись типа SAVE R или на одиночные куски-копии, если запись типа SAVE X). И переписать для раскодирования каждый новый фрагмент в отдельный файл, без дублей.

. Надо суметь определить, какой из двух каналов wav-записи есть "канал нулей", а какой "канал единиц". И, если надо, то сместить во времени один относительно другого, так как почему-то нередко в wav-записи сигналы с потоками нулей и единиц бывают неверно синхронизированы друг с другом.

. Главная проблема, не преодолимая автоматически: почти во всякой записи обнаруживаются "провалы" - местами такое резкое уменьшение уровня сигнала, что приходится глазами просматривать график waveform и руками восстанавливать биты в дефектных перепадах.

У меня так "исторически сложилось", что я стал делать всё это в Маткаде и к нему привык. О принципе и деталях раскодирования подробно написано в pdf-ках, ссылки есть где-то в этой ветке и на сайте d3-28.ru. Думаю, люди, умеющие программировать на современных языках, могут при необходимости сделать себе подходящие программки вместо маткадовских для раскодирования.

И ещё вопрос, где бегло можно почитать про формат txt файлов для эмулятора?

Про этот формат вроде нигде не написано, но там и писать-то особенно нечего, всё можно увидеть на готовых примерах. Главное:

. В начале файла не должно быть ничего лишнего - никаких комментариев, заголовков и т.п. Допустимы одна-две пустые строки, но эмулятору они не нужны. В самом конце файла после нескольких пустых строк можно, и наверное даже желательно, написать комментарии: что за программки в этом файле, как запускаются, и т.п. Эмулятору такие пояснения не нужны, а пользователю помогут не запутаться, если он любой программой-просмотрщиком в своём компьютере прочитает такой поясняющий текст.

. Каждый 256-байтный блок записи типа "SAVE R" начинается и заканчивается строкой с 15 символами нижнего подчёркивания с нажатием Enter на 16-ом месте. Пустых строк между блоками единой блочной программки не должно быть. В строках между указанными подчёркиваниями пишутся байт-коды. Единая не блочная запись, т.е. типа "SAVE X" вся состоит из байт-кодов - без всяких подчёркиваний, без пустых строк.

. Каждый байт из совокупности байт-кодов, представляющей собой блок типа "SAVE R" или "SAVE X", пишется в отдельной строке и завершается нажатием Enter. Перед байтом в его строке допустимы несколько пробелов (но эмулятору они не нужны; просто у меня так сложилось исторически: Маткад делал файлы с пробелами в начале строк). При этом между строками с байтами не должно быть пустых строк.

. Если txt-файл содержит несколько программ, то они должны быть отделены друг от друга несколькими пустыми строками: обычно двумя или тремя. Так же пустыми строками отделяются загрузчики и всякие служебные фрагменты (Фортран и Выстра записывают программки по-хитрому - с несколькими служебными файлами-заголовками).

. Каждый байт в байт-коде пишется как 16-ричное число в "тетрадно-десятичной" форме, близкой к стандарту, принятому в документации по Д3-28. Несколько примеров:

В один байт можно записать любое десятичное число от 0 до 255. Например, десятичное число 255=15·16+15·1 в известном hex-формате представляется как байт FF. Здесь F и F это тетрады с десятичным значением 15 каждая. В стандарте Д3-28 между тетрадами принято писать пробел, т.е. байт FF запишется как 15 15. В txt-файлах для эмулятора пробел между тетрадами не пишется, т.е. байт FF пишется как 1515.

Ещё пример. В hex-форме байт 0A это тетрады 0 и A с десятичными значениями 00 и 10. В стандарте Д3-28 это байт 00 10. В файле для эмулятора этот байт можно записать как 0010 или просто 10, т.е. нули в начале числа можно не писать.

Ещё пример: в hex-форме байт 00 это дэтришкин байт 00 00. В файле для эмулятора его можно записать как 0000 или просто 0, так как нули в начале числа можно не писать.

[RadioKing]

Огромное спасибо за столь развёрнутый ответ!