Эмулятор ДВК

[form]

Обнаружилась пара тестов DL11-W в виде BIN-образов перфолент (см. приложение).

В XXDP есть разные тесты.
DL11-W к слову бывает только на UNIBUS

[form]

DL11-W... У меня их два

[hobot]

DERBY.SAV
Работает корректно, только я с клавишами управления не разбирался,
в связи с чем увидел вот такое вот почти сразу ))))))))



Ну и игровой экран конечно )))



Источник - последние диски от тов. anasana

[Patron]

DERBY.SAV Работает корректно, только я с клавишами управления не разбирался

Игра управляется единственной клавишей [0], при нажатии на которую лошадь прыгает.

[hobot]

при нажатии на которую лошадь прыгает.

Точно! Для однокнопочного игрового автомата проект ) Где тут касса с житонами? )
вываливается в конце в @

[Patron]

Обновилась текущая сборка "эмулятора ДВК": DVK_Emulator_27.12.12_18-37.

Изменения:

1. Внесены изменения терминала и консоли, описанные ЗДЕСЬ.

2. В модуль DSK_module.em добавлен объект MX, эмулирующий контроллер КНГМД ДВК с 4 подключенными приводами.
Число дорожек привода зависит от размеров подключенного DSK-образа диска. Для образов размером 225280 байт эмулируются 40 дорожек, для образов размером 450560 байт - 80 дорожек. Подключение DSK-образов любых других размеров невозможно. Для TRK-образов эмулируются только 80-дорожечные приводы.

Другие эмулируемые характеристики приводов:

- период оборота диска: ............... 200 мс;
- время шага головки: .................. 11 мс:
- время прижима головки: ............... 30 мс;
- время старта двигателя: ............. 500 мс;
- продолжительность сигнала ИНДЕКС: ..... 1 мс;

Формирование приводом сигнала запрета записи определяется атрибутом "Только чтение" подключенного образа диска.

3. В модуль Main_module.em добавлен новый тип виджета: SB_DriveButton, индицируюший работу присоединённого к виджету привода (при наличии у привода интерфейса StorageDriveInterface), а также позволяющий менять подключенные к приводу образы.

4. В комплект поставки добавлены образы MX80_System.DSK, MX40_System.DSK и MX40_User.DSK.

5. В образы HDSYS.DSK, MX80_System.DSK и MX40_System.DSK добавлен драйвер MX.SYS ( MX-HANDLER V02.2 October,1987 Потемкин М.И. ; Boot v1.0 ), пропатченный для улучшения совместимости с RT-11 и современными компактными дисководами.

6. В файл default.cfg добавлена эмуляция контроллера MX. Объект MX подключен к виджету MediaButton, позволяющему менять образы в приводах устройств HD и MX. Для переключения между устройствами HD и MX нужно использовать кнопку [>] виджета.

7. В комплект поставки добавлены файлы конфигурации ДВК-1_MX40.cfg и ДВК-1_MX80.cfg. После запуска ДВК-1_MX80.cfg загрузка с MX0 начинается автоматически ( из-за установки SEL1_Data = 0160020 ). После запуска ДВК-1_MX40.cfg - для начала загрузки операционной системы нужно ввести с клавиатуры "X0". Регистр важен - по "x0" загрузка не начнётся.

8. Ранее поставлявшаяся версия игры MARS.SAV была дефектной - теперь на дисках HDSYS.DSK и MX40_User.DSK находятся "правильные" версии MARS.SAV и MARS.DAT.

9. В комплект всех системных дисков включены Y2K 8 Bit версии мониторов без поддержки таймера и таймаутов, а также программа DAY.SAV, запускающаяся при загрузке.

[Advertiser]

[form]

А как бы еще здесь и для VT52 сделать чтобы можно было в одном конфиге все изменения держать и этот файлик не был бы частью дистрибутива и был бы опциональным?

Чтобы не исправлять каждый раз кучу конфигов после очередного обновления

[Patron]

Чтобы не исправлять каждый раз кучу конфигов после очередного обновления

Исправлять вручную кучу конфигов не обязательно - при первом же запуске со старым конфигом эмулятор это делает сам.

Важно лишь понимать, что эмулятор делает при автоматическом обновлении старых конфигов, что не делает и чем это грозит.

Ситуация такова:

1. Если для используемого параметра в старом конфиге уже задано допустимое значение - оно сохраняется неизменным.

2. Если в старом конфиге установлено значение для параметра, который больше не используется - эта строчка остаётся в конфиге и становится "мусором". Это грозит только тем, что пользователь может думать, будто данный параметр ещё на что-то влияет, тогда как это уже давно не так. При малейших сомнениях - любую строчку в любом конфиге можно ( предварительно скопировав ) смело удалять. Если такой параметр эмулятором используется, то при первом же запуске с исправленным конфигом ( или ini-файлом ) - удалённая строчка будет автоматически восстановлена со значением по умолчанию.

3. Если в старом конфиге или ini-файле отсутствует значение для только что введённого в эмулятор нового параметра ( а как оно могло бы там быть ) - эмулятор при первом же запуске, использующем такой файл - автоматически добавит строчку с установкой значения по-умолчанию для нового параметра в конец ini-файла или в конец ini-секции объекта в файле конфигурации.

...

Проще говоря - можно ничего не редактировать, а просто запустить эмулятор, загрузить свой старый конфиг, затем выйти из эмулятора и открыв изменившиеся файлы ( это легко определить по изменению даты файла ) посмотреть, какие строчки были добавлены ( и при желании - переставить их на более подходящие места в том же ini-файле или в той же ini-секции cfg-файла ).

[form]

Исправлять вручную кучу конфигов не обязательно - при первом же запуске со старым конфигом эмулятор это делает сам.

Уточню немного.
Было бы удобно быстро исправлять нужные настройки не копаясь по громадным конфигам в которых эти самые настройки живут где-то далеко внизу часто. Гораздо удобнее было бы иметь один файлик в котором не было бы ничего кроме настроек которые я для себя меняю в зависимости от потребностей.

[Patron]

Гораздо удобнее было бы иметь один файлик

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

Какой из этих двух способов лучше - нужно решать сразу, учитывая, что в дальнейшем объектов могут быть не только десятки, но и сотни, и тысячи.

...

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

У меня на 2-х компьютерах установлены несколько копий эмулятора и, поэтому, установку новых дистрибутивов в существующие специализированные инсталляции приходится выполнять регулярно.

При этом можно выделить следующие рациональные "правила поведения":

1. Исполнимый exe-файл эмулятора ( как и все файлы *.lng ) можно и нужно сразу копировать в целевой каталог взамен прежних.

2. Файлы *.ini - наоборот - копировать нужно только в самый первый раз ( когда в целевом каталоге ini-файлов ещё нет ). Если в целевом каталоге есть старые ini-файлы - новые из дистрибутива копировать не надо.

3. В новых cfg-файлах главную проблему представляют неподключенные к приводам образы, имеющиеся в целевом каталоге, и отличающиеся настройки терминала и адаптеров портов.

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

Что же до терминала и адаптеров - то тут других способов, кроме редактирования - нет. Однако, чем каждый раз заменять старый cfg-файл новым и затем редактировать - бывает выгоднее сначала выполнить их текстуальное сравнение при помощи Total Commander-а ( Файл -> Сравнить по содержимому ), быстро найти все отличия и принять правильное решение.