Точность эмуляции Радио 86РК

[DDp]

Как оказалось (спасибо b2m) процедура загрузки не столь критична к скорости загрузки (чего я больше опасался). Одним из ключевых элементов защиты была привязка к особенностям схемы Микроши. А конкретно, программа проверяет "пустое" пространство по адресам 8000h-BFFFh. В Микроше по этим адресам считывается значение 82h. Это слово состояние (status word) процессора, выдаваемое им на шину данных в начале каждого машинного цикла.
b2m подсказал, что нужно сделать, что бы запустить эти игры на его эмуляторе.
В текущей версии достаточно просто выключить торможение от ПДП. В файле Mikrosha (cas).cfg убрать строку hrq=CPU.hold и запустить эмулятор в этой(Mikrosha (cas)) конфигурации.
Загрузка второй половины Loader-а сопровождается надписью "check summ error", не обращайте внимания (на реале в этом месте картинка "surius software.bmp").

[Paguo-86PK]

Обнаружились(нашлись) игрушки для Микроши заслуживающие внимания в плане более точной эмуляции.
...
Я был шокирован тем, что во время загрузки не отключается дисплей.
Оказалось, что контроллер дисплея настраивается на более короткий пакет DMA запросов, и процессор "тормозится" чаще и на более короткий промежуток времени. Таким образом достигается более равномерная скорость работы процессора...

Я чуть не прослезился! Вот ведь как получается, что не весь потенциал РК был использован. Автор оригинального МОНИТОРа что-то упустил, раз можно было ввод-вывод без отключения ПДП производить. Не говоря уж о Музыкальной системы, портированной с Sol20.

Я вот о чём подумал.
Была у меня идейка...

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

Тогда я вспомнил про свой РК!
Взял эмулятор и попытался забить код.
Если РУ3 - матрица 128x128, можно первые 16 байт выделить под сам код программы, остальные 112 - будут разрушаться. Утилиту нужно программировать примерно так:

Code: Select all

     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000 31 90 3F .. .. .. .. .. .. .. .. .. .. C3 80 00 <- Иницируем стек размером в 16 байт
0080 .. .. .. .. .. .. .. .. .. .. .. .. .. C3 00 01 <- Перенастраиваем ПДП на отображение
0100 .. .. .. .. .. .. .. .. .. .. .. .. .. C3 80 01 <- буфера экрана по 16 символов.
0180 .. .. .. .. .. .. .. .. .. .. .. .. .. C3 00 02 <- Вот такая свистопляска...

Т.е. имеем в распоряжении огромную программу из фрагментов по 16 байт, где 13 байт - полезный код.

Суть такова: Перенастроить ПДП на адрес 0x3F00 по 0x3F0F. Чтобы экран не залился мозайкой, отлавливаем моменты и вставляем байт гашения строки в начале кадра. Ждём от ВГ75 нужное число раз и не гасим строку в нужный момент. Далее, вставляем байт гашения до конца кадра. После чего, имеем уйму времени на другие расчёты.
В частности, опрашиваем несколько клавиш смены режима. Обновляем текст статуса в буфере экрана. Собираем статистику обрушения данных в каждых 112 байтах...
Ждём конца кадра в статусе ВГ75 и повторяем процесс...

Код начал писать в эмуляторе. Так как реальный РК лежит в шкафу и вполне готов работать, если чуточку попотеть...
Но, забросил я это дело уже через пару часов. Так как программировать с такой грануляльностью достаточно утомительно. И многое подзабыто. В частности, ячейки ПДП и ВГ75...

А идея всё из ума не выходит. В справочниках говорится, что на биты в памяти влияет куча факторов: от температуры до альфа-частиц...
Помнится, в 80-х ещё умельцы удаляли у тех микросхем ОЗУ защитный экран и получали видеоматрицу 128x128 через LPT, а частотой опроса управляли фотоэкспозицией...

А теперь, прочитав про ввод-вывод на ленту, просто тронуло до слёз! Сколько до сих пор не сделано на РК! И ни на каком эмуляторе это не воспроизведёшь ведь! В частности, обрушение памяти - не математический процесс, а чисто физический. И зависил от чистоты материалов, фильтрации по питанию, прогрева и кучи других факторов...
В общем, не просто РК, а целая лаборатория...

[Pyk]

Не сохранился ли у кого-нибудь случайно тест, с которого начиналась эта тема?

[Shaos]

Не сохранился ли у кого-нибудь случайно тест, с которого начиналась эта тема?

Я наверное скачивал, но у меня тот комп сдох...

[DDp]

Не сохранился ли у кого-нибудь случайно тест, с которого начиналась эта тема?

Ссылки в этой же теме на второй странице viewtopic.php?p=82342#p82342
А тут в мнемониках i8080 viewtopic.php?p=76421#p76421

[Pyk]

О, спасибо! (не заметил сразу скромную ссылку на второй странице)
Жаль, что оригинальные видео не сохранились, а РК мой, еще недавно работавший, начал виснуть через считанные секунды после включения. Ну да ладно, есть в наличии Партнер с Апогеем - попробую для них адаптировать недостающий тест.

P.S. Хотя в недостающем тесте все равно ничего не понять толком - мельтешение одно.
А в целом очень похоже получилось. Прерывистое подчеркивание еще что ли сделать?..

[DDp]

Жаль, что оригинальные видео не сохранились

Хех, а я нашёл оригинальные архивы с видео у себя "вдальнемуглу" на старом винте. см. test*.rar по ссылке

[xintrea]

Обнаружились(нашлись) игрушки для Микроши заслуживающие внимания в плане более точной эмуляции. ( games hit-parade N 1)
На данный момент не удалось загрузить эти игрушки ни в одном эмуляторе (из поддерживающих WAV я знаю только MESS и Башкирия2М)

Games Integrator - это эпичная система, я про нее себе такую записульку сделал:

Игровой набор Games Integrator (Hit parade 1) для ПЭВМ "Микроша"

В эмуляторе Пыхонина Интегратор и его игры нормально загружаются, если Виктор примет мои пулл-реквесты 86ec2a1 и 3c762ef. Проверялось в Linux, но думаю под Виндой то же самое.