Общие вопросы эмуляции TR-DOS и ВГ93

[IanPo]

Я не вижу здесь #3D13
Точку входа #3C03 я не знаю
Работали ли ВСЕ схемы со старыми версиями ПЗУ , я тоже не знаю.
Просто в некоторых схемах контроллеров сдвиг точки входа на 1 байт вперед приводил к неработоспособности программ.
Вот пример статьи:
http://zxpress.ru/article.php?id=1858

[MetalliC]

Я не вижу здесь #3D13
Точку входа #3C03 я не знаю

у оригинальных первых версий контроллеров Beta-Disk V2, V3 и V4 окно доступа было в #3Cxx, это уже в православном V5 AKA Beta-128 его изменили на #3Dxx ради совместимости с 128ми моделями, хотя точки входа #3Cxx оставили в ПЗУ для совместимости с имеющимся софтом, плюс тумблер включающий "старое" окно.

но смысл абсолютно тот же: 3С00 (15360) делает то же что и 3D00 (15616), 3С03 то же что и 3D03.
доступ из машинного кода там совсем по-другому, да и вообще он во всех версиях разный, и видимо вообще не предполагалось что разработчики отдизасмят прошивку и будут вызывать оттуда всякое.

кстати, не поленился проверил все имеющиеся оригинальные прошивки - NOP-ы появились лишь в 5-ой версии, да и то лишь в 3Dxx, а в 3Cxx там RST#38 вместо NOP-ов.

Вот пример статьи:
http://zxpress.ru/article.php?id=1858

там в конце такое:

Наверное, заблуждение с командами выхода в DOS надуманно и,
скорее, от лукавого. Я сам с такими проблемами не сталкивался и
ничего более добавить не могу.

офигенская статья, чо

[IanPo]

Я могу лишь предположить, что NOPы как раз из-за кривых контроллеров и появились,
а старые версии TR-DOS тестировались на нормальном оборудовании, которое было у разработчиков.
А в чем вообще смысл копания в старых прошивках?

И еще момент:
для входа в TR-DOS адрес должен быть #3Dxx, #3C не пройдет аппаратно. Или так было в старых схемах?

[MetalliC]

Я могу лишь предположить, что NOPы как раз из-за кривых контроллеров и появились,
а старые версии TR-DOS тестировались на нормальном оборудовании, которое было у разработчиков.

фиг его знает почему так, зачем авторы добавили те NOP-ы и почему оно работает и без них на наших клонах.
можешь поизучать схемы оригинальных контроллеров тут http://zx-pk.ru/showpost.php?p=460139&postcount=56 или там https://cygnus.speccy.cz/popis_trdos-schema.php

если тыкать от-балды пальцем в небо - могу предположить, что D7 (буфер шины данных, 74LS245 ~аналог 555АП6, появившийся в оригинальной схеме V5 и типично отсутствующий в наших клонах), может вносить какую-то задержку выдачи данных на шину. но это не точно (с)

А в чем вообще смысл копания в старых прошивках?

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

И еще момент:
для входа в TR-DOS адрес должен быть #3Dxx, #3C не пройдет аппаратно. Или так было в старых схемах?

у каждой версии была своя схема/плата.

add: у родного Beta-128 был режим совместимости, смотри на схеме по ссылке выше, активировался переключателем S1

NOTES:
1. R8, R9, VD8 provide compatibility with software on addresses #3C00/#3C03 (15360/15363 dec.) and are not installed on some PCBs.

но в наших клонах это выпилили.

[ZXMAK]

если мне не изменяет склероз, в некоторых вариантах мейджика бывали проблемы с дребезгом кнопки и длительностью импульса, а не переключением ПЗУ.

не, меджик то отдельная тема. Там проблема встречалась именно с переключением пзу в момент когда была замаплена обычная пзу бейсика, а процессор начинал выборку из окна перехода в пзу трдос. Я этот глюк сам видел на живом спектруме.

Сейчас уже сложно сказать из-за чего именно баг происходил, но связан он был с тем что не на всех контроллерах происходило корректное чтение первого байта сразу в момент выборки пзу трдос. Может из-за того что в момент выборки сразу оба пзу (бейсик и трдос) давали свои данные на шину, может из-за длины проводников шины данных/адреса и линии выборки, или еще из-за чего. Но факт такого бага имел место быть...

Возможно из-за того, что сразу после выборки нового ПЗУ, старое оставалось ещё некоторое время выбранным и возникал конфликт двух ПЗУ на шине. Т.к. в пзу бейсика и в пзу трдос по этому адресу 0, то это не мешает работе. Но если бы в одном из пзу был не 0, то читался бы неправильный опкод.

[MetalliC]

не, меджик то отдельная тема. Там проблема встречалась именно с переключением пзу в момент когда была замаплена обычная пзу бейсика, а процессор начинал выборку из окна перехода в пзу трдос.

странненько, в оригинальных девайсах мейжик срабатывает лишь в моменты доступа процессора к ОЗУ (нажата_кнопка && /MREQ==0 && (A15|A14)). а если код выполняется в ПЗУ и ничего не читает/пишет из области >4000 - жми кнопку хоть до усрачки, никакой магии не будет

но дальше мутноватая схема на 2х одновибраторах - один генерит /NMI а другой переключает ПЗУ, почему сделано именно так - я хз.

[MetalliC]

но связан он был с тем что не на всех контроллерах происходило корректное чтение первого байта сразу в момент выборки пзу трдос.

у меня есть другая теория, более прозаичная

в схемах многих дисковых интерфейсов для спектрума с активацией при исполнении команд по определенным адресам часто используется синхронное переключение триггера "DOSEN" по переднему фронту /M1 или /MREQ (при переходе с низкого уровня в высокий, заведенному на CLK триггера и дешифрованному адресу на вход D триггера), то есть переключение происходит уже после выборки кода команды из памяти.

я бы лично поставил на то, что инженеры из TR подсмотрели реализацию у конкурентов и сперва сделали по такому же принципу, и сделали прошивку с учетом этого дела с NOP-ами, но позже упростили схему и сделали асинхронное вкл/выкл через /S и /R триггера, как оно и есть на всех известных на данный момент схемах, с "мгновенным" переключением без задержки, а уже не нужные NOP-ы так и оставили.