b2m, отличная новость! Проверил - работает. Спасибо.
П.С. для тех, кто не в теме про ДосБокс (таких, как я :)) вот ссылка - http://old-game.org/emulyator-ms-dos-dosbox-0-74.html
Вид для печати
b2m, отличная новость! Проверил - работает. Спасибо.
П.С. для тех, кто не в теме про ДосБокс (таких, как я :)) вот ссылка - http://old-game.org/emulyator-ms-dos-dosbox-0-74.html
давно не работал с ДосБокс....
А у меня до вчерашнего дня была версия от 2007 года :)Цитата:
Сообщение от Stampmaker
---------- Post added at 14:02 ---------- Previous post was at 14:00 ----------
Вообще-то есть официальный сайт: http://www.dosbox.com/download.php?main=1Цитата:
Сообщение от Denn
2 b2m. Я уже сделал программный коннект на двух компах и заметил странность: при передаче файла в Орион (эумлятор) всё прекрасно, а при обратной передаче из эмулятора в DOSbox, в конце процесса обмена Орион рапортует об ошибке "Потеря связи!", но при этом под DOSbox'ом файл успешно получен. Как я понимаю, куда-то "зажёвывается" последний байт от писюка к Ориону, который последнему сообщает об успехе приёма данных, и Орион отваливается по тайм-ауту. При настоящем ("железном") линкере такого не происходит.
А попробуй последнюю версию (от 18.10.2015). Я в связи с добавлением поддержки перенаправления на реальный СОМ-порт кое какие вещи кардинально изменил. Хочется верить, что ничего не сломал.
По поводу "зажёвывается": может таймаут маловат? Возможен вариант, когда мой эмулятор быстрее передаёт, чем принимает DOSbox. Сокет честно накопит данные в буфере и скормит по одному, но на другой стороне в этот момент начинает отсчитываться таймаут. А короткие файлы тоже с такими-же симптомами передаются?
Я на двух компах не тестировал, только с localhost :)
Я тоже тестил локально, на одном компе эмуль+досбокс. И аналогично на компе в другом месте. А не коннектил два писюка друг с другом ))Цитата:
Сообщение от b2m
В продолжении темы линковки ПРК Орион с IBM-PC.
Во-первых, обнаружился загадочный и странный баг. В программе LINK$ криво установлены два параметра: конфигурация таймера КР580ВИ53 и константа делителя этого таймера, задающая скорость обмена (9600 Бод).
Первый параметр вместо положенных 36h записывает в таймер 3Eh, что соответствует несуществующему режиму ВИ53 (такого нет ни в одной доке).
Второй параметр вместо расчётного 0Dh имеет значение на единицу меньше - 0Ch.
ПО было написано и отлажено 17 лет назад, поэтому вспомнить какие-либо подробности, почему именно так, не представляется возможным. Тем не менее, 17 лет работало без проблем, и баг-репортов от юзеров не было. В т.ч. работает и в эмуляторе :)
С проблемой столкнулся камрад Stampmaker при коннекте через USB-реализацию COM-порта на ноутбуке - у него работает только с правильными значениями вышеуказанных параметров.
Что ещё более удивительно, с правильным значением константы, задающей скорость протокола, у меня с IBM-PC c трушным хардварным COM-портом не работает! При этом если через терминалку гонять байты с писи на Орион и обратно, то наоборот, корректная передача данных возможна только с верным параметром константы делителя. В общем, чудеса какие-то.
Во-вторых, выяснилось, что если задать константу делителя 09h, то оказывается КР580ВВ51 совершенно замечательно работает с IBM-PC по асинхронному протоколу на скорости 14400 Бод! Это в 1,5 раза быстрее, чем на 9600. Что, в общем-то, - профит.
В два раза быстрее (на 19200 Бод) увы, не получается, т.к. невозможно задать дробную константу (0Dh/2). Для 28800 Бод аналогично - требуется невозможная константа 09h/2.
В настоящий момент ведутся эксперименты по небольшой аппартаной доработке RS-232 на Орионе для возможности работы на больших скоростях (до 56 кБод) - вместо таймера ВИ53, тактирование ВВ51 от отдельного кварцевого генератора.
А пока, предлагаю желающим протестировать на своём железе возможность работы на скорости 14400, и если эксперимент пройдёт успешно, то пересоберу образ ROM-диска с ускоренным в 1,5 раза линкером.
Это программа для тестирования порта RS-232 со стороны Ориона - http://www.denn.ru/8bit/oriserv/testcom.ori
А это ответная часть для IBM-PC - http://www.denn.ru/8bit/oriserv/com-test.exe
Некоторые пояснения. По-умолчанию в обеих программах выбрана скорость обмена 9600 Бод. Для проверки на скорости 14400 Бод необходимо на Орионе задать константу делителя - 09h, а на IBM-PC по кнопке "Настройка" выбрать соотв. скорость. При отправке в Орион строки более, чем из одного символа, необходимо на Орионе включить режим "Дамп" (клавишей F3). В режиме "Дамп" Орион принимает в буфер строку символов произвольной длины (окончание посылки определяется отваливанием по тайм-ауту), после приёма выводит её на экран. По нажатию любой клавиши, Орион выдаёт содержимое буфера в порт RS-232. В режиме "Терм" возможны одновременно приём/отображение одиночных символов из порта и передача кодов нажатых клавиш в порт.
схема COM-порта для Ориона была опубликована в журнале Радио 1995г, №9, стр.37
кто не смог найти публикацию, вот ссылка на статью
файлы большого размера, по 20 МБ каждая
https://yadi.sk/d/si4mgh7rk9hdW
P.S. это самое лучшее качество сканов, которое я смог найти
Некоторые символы не разобрать.Цитата:
Сообщение от Stampmaker
Другого, увы, нет.Цитата:
Сообщение от Eagle
Есть ещё перерисовка от Denn
https://yadi.sk/i/Qae7dHUokA5FE
Выкладываю чуть с опозданием: релиз DSDOS v3.71r от 05.11.2015
Образ ROM/RAM-диска тут - http://denn.ru/orion/dsdos/dsdos371.zip
Что нового:
+ Автоинициализация (форматирование) квазидиска при включении ПРК;
+ Запуск оболочки (DC$) при первом включении ПРК;
+ Скорость обмена с IBM-PC увеличена до 14400 Бод (утилита LINK$);
+ Доработка авторского программатора ПЗУ (PROG$);
+ Изменение алгоритма определения текущего диска при запуске утилит из ROM/RAM-диска;
+ Добавлена утилита программирования ПЗУ Winbond 27C512;
+ Добавлены утилиты тестирования портов ВВ51 и ВВ55.
Подробнее.
При первом включении и при "холодном" рестарте ПРК, производится автоматическая инициализация квазидиска, т.о. пользователь больше не увидит "мусор" на диске "B:".
Алгоритм инициализации интеллектуальный, т.е. он не отформатирует квазидиск при "холодной" перезагрузке, если там есть файлы и структура данных корректна.
При первом включении ПРК, после появления заставки ОС DSDOS, если нажать на клавишу [F4] или [АР2], вместо поиска на квазидиске файла "EXT$", производится поиск на диске "A:" программы оболочки ОС (DC$) и передача ей управления. Дальнейшие перезагрузки инициируют старт файла "EXT$", который создаёт оболочка или какая-либо другая программа пользователя.
Т.о. если нам требуется оболочка, то после первой загрузки ОС достаточно нажать [F4]. В противном случае, мы не нажимаем [F4], а запускаем другое ПО, и механизм автостарта DC$ больше не будет срабатывать.
Два вышеописанных нововведения позволили отказаться от файла "R%" и, соответственно, от лишних телодвижений при запуске.
Далее. Эксперимент с обменом на скорости 14400 Бод прошёл успешно, в связи с этим были доработаны соответствующие утилиты: LINK$ на Орионе (входит в сборку ROM/RAM-диска) и LINK.EXE на IBM-PC (ссылка для скачивания - http://denn.ru/8bit/orion/soft/dsdos/link/link14400.rar ).
На всякий случай, в LINK$ предусмотрена возможность работы на прежней скорости 9600 Бод, для этого необходимо при запуске утилиты удерживать клавишу [НР] (Shift), при этом для информации на экране будет отображена надпись "BR=9600".
В авторском программаторе ППЗУ РФ2/РФ4 (PROG$) не работал вызов утилит "M128$" и "EDMEM$". Проблема была в том, что в авторской ОС ORDOS имена "M128" и "M128$" считаются равнозначными, и в программе были прописаны сокращённые версии "M128" и "EDMEM", без "$".
в ОС DSDOS "M128" и "M128$" - это строго разные файлы. Имена в программе исправлены, утилиты вызываются. А также, попутно, сделаны следующие доработки:
+ добавлена возможность подгрузки файла прошивки;
+ добавлена команда подсчёта и отображения контрольной суммы данных в буфере программатора;
+ добавлена команда сохранения содержимого буфера в файл на диск;
+ некоторые косметические доработки интерфейса;
+ для отмены операции программирования продублирована клавиша [АР2] (Esc).
Некоторые пояснения по доработкам.
Для подгрузки файла необходимо при запуске в командной строке добавить его полное имя (диск:имя_файла). Диск можно опустить, тогда поиск файла будет осуществлён на текущем устройстве (кроме запуска программатора из ROM/RAM-диска, см. ниже). Размер файла должен чётко соответствовать прошиваемой ПЗУ (2 Кб для РФ2 и 8 Кб для РФ4). Если размер некорректен, то программа "вывалится" с ошибкой. Программа в соответствии с размером файла прошивки сама выберет тип ППЗУ, что будет отображено в верхней строке крупным текстом. После типа ППЗУ будет отображено имя файла прошивки. Файл загружается в буфер №0 программатора и дальнейшая работа - в обычном режиме, как и ранее. После каких-либо изменений информации в буфере (чтение из ПЗУ или ROM/RAM-диска), вместо имени файла появляется сообщение "БУФЕР #0", которое говорит о том, что информация в буфере уже может не соответствовать файлу! Это же сообщение будет при загрузке программатора в обычном режиме - без параметров.
Отображение контрольной суммы данных в буфере производится по команде "K", подсчёт кол-ва байт ведётся в зависимости от выбранного типа микросхемы ППЗУ. Также вывод к/суммы происходит после операций чтения данных из ППЗУ или из ROM/RAM-диска.
Сохранение содержимого буфера производится по команде "S", данные записываются на текущий (или принудительно указанный при запуске в командной строке) диск, в файл с именем "ROM_DATA". Запись производится "поверх", без запросов на удаление прежнего файла с аналогичным именем.
Про утилиту программирования ПЗУ Winbond 27C512 напишу позже, вместе с описанием хардварной части программатора.
Утилиты тестирования портов ВВ51 и ВВ55 представлены файлами "TESTCOM$" и "PORT#F6$", соответственно. Первая позволяет обмениваться символами и дампами с хостом (или самой с собой при наличии перемычек между Rx-Tx и RTS-CTS) в терминальном режиме (например, программа HyperTerminal на IBM-PC), а вторая позволяет программировать линии порта пользователя (#F600) на ввод/вывод, анализировать содержимое и в различных вариациях выставлять отдельные биты.
Претерпел небольшие изменения алгоритм определения текущего диска в утилитах. При запуске утилиты из ROM/RAM-диска, в качестве текущего выбирается по-умолчанию диск "B:", а не реальный текущий "A:". При запуске с любых других дисков (В, С... и т.д.), текущим считается реальный текущий диск. Это позволило упростить работу, т.к. рабочие файлы не могут находиться в ROM/RAM-диске, откуда обычно запускаются утилиты, а чаще всего находятся на квазидиске, т.о. можно опускать указание диска при задании параметров в командной строке.
Теперь бы еще набраться времени изучить эту ОСьку хоть немножко, а лучше - попробовать... Так и не читал до сих пор про нее.
- - - Добавлено - - -
Не дозвониться до твоего сайта.Цитата:
Сообщение от Denn
Прям щас из "Теремка" по вафле ткнул - скачалось.Цитата:
Сообщение от Ewgeny7
Сейчас - скачалось, спасибо! Пойду изучать "пакет из штаба".Цитата:
Сообщение от Denn
И вновь продолжение темы соединения ПРК "Орион" с IBM-PC по RS-232. Некоторые неудобства, связанные с запуском MSDOS-версии ПО линкера под ОС Windows были решены с помощью разработки Win32-приложения, поддерживающего протокол орионовской утилиты LINK$. Сразу оговорюсь, что данное приложение создано ради поддержки другого протокола, который позволит прозрачную работу из ОС DSDOS с ORI-файлами, хранящимися на IBM-PC, а также на удалённом ресурсе в сети Интернет. Но в качестве "бонуса" приложение поддерживает и протокол утилиты LINK$. Т.е. им можно полноценно пользоваться для приёма и отправки файлов *.ORI, вместо MSDOS'овской утилиты LINK.EXE.
Приложение представляет из себя единственный исполняемый файл "oriserv.exe", который можно скачать тут - http://www.denn.ru/8bit/oriserv/oriserv.exe
Файл нужно поместить в любую удобную папку программ, например в "C:\Program Files\ORI", создать ярлык на рабочем столе для запуска, и приложение готово к работе.
Интерфейс программы простой и интуитивно понятный, все элементы управления имеют всплывающие подсказки на русском языке.
https://forum-img.guitarplayer.ru/2024/02/11/1j92y.png
альт.ссылка
После первого запуска, приложение пытается открыть порт COM1 и настроить его на параметры, аналогичные последней версии программы LINK$ (14400,N,8,1). Если процесс инициализации прошёл успешно, то приложение немедленно готово к приёму/отправке файлов *.ORI. Если в системе несколько COM-портов и для связи с Орионом используется не COM1, то с помощью нажатия на кнопку с изображением инструментов:
https://forum-img.guitarplayer.ru/2024/02/11/1jV1h.png
альт.ссылка
в открывшемся окне можно выбрать и настроить соответствующий COM-порт. Выбранный порт отображается в левой части строки состояния внизу окна приложения.
Также с помощью соответствующей клавиши можно выбрать каталог, в котором содержатся рабочие файлы *.ORI:
https://forum-img.guitarplayer.ru/2024/02/11/1js0P.png
альт.ссылка
После выхода из приложения, путь к выбранному каталогу запоминается в конфигурационном файле "oriserv.ini" в каталоге приложения. По-умолчанию, при первом запуске, в качестве текущего каталога выбран каталог, откуда было запущено приложение.
Если в текущем каталоге есть файлы *.ORI, то они появятся в списке в основном поле приложения. Обновление списка происходит автоматически при каких-либо изменениях в каталоге, т.е. не важно каким способом попал файл в рабочий каталог (загружен по RS-232 самим приложением или скопирован с помощью средств ОС Windows), если его содержимое соответствует формату *.ORI, то он немедленно отобразится в списке.
Приём файлов от ПРК "Орион"
Запущенное приложение всегда находится в режиме приёма данных из текущего активного порта. При получении запроса на приём файла, в правой части строки состояния внизу приложения отобразится заголовок передаваемого файла в формате ОС DSDOS и будет происходить процесс приёма файла, по окончании которого данные будут сохранены в текущий рабочий каталог в формате *.ORI и в списке появится соответствующий новый файл. Если файл с таким же именем уже есть в списке, то он будет перезаписан поверх!
Отправка файлов в ПРК "Орион"
Для отправки файла, необходимо его выделить (мышью или клавишами курсора) и нажать Ctrl+S. Также отправка возможна по двойному щелчку мышью на выбранном файле в списке или через контекстное меню:
https://forum-img.guitarplayer.ru/2024/02/11/1j7pO.png
альт.ссылка
При выделении файла в списке, в правой части строки статуса выводится заголовок в формате ОС DSDOS. После отправки в статус выводится сообщение об успешном завершении процесса передачи по RS-232. В силу ограничений протокола, приложение не имеет возможности узнать о возможных ошибках при попытке ПРК "Орион" сохранить принятый файл, поэтому отчёт об успешности касается только процесса отправки по RS-232.
Если имеются какие-то проблемы с линией связи или на ПРК "Орион" не запущена в режиме приёма утилита LINK$, то при попытке отправить файл приложение выдаст сообщение об ошибке:
https://forum-img.guitarplayer.ru/2024/02/11/1jFaT.png
альт.ссылка
Приложение можно свернуть (в трей), оно при этом будет продолжать принимать файлы в невидимом режиме. Развернуть можно двойным щелчком по значку приложения в трее или через соответствующее контекстное меню:
https://forum-img.guitarplayer.ru/2024/02/11/1jKOo.png
альт.ссылка
В файле конфигурации также запоминается положение окна приложения на рабочем столе.
П.С. Отдельное спасибо Сергею (ака Stampmaker) за полезные советы при создании приложения =)
П.П.С. Ещё одним бонусом добавлена поддержка файлов *.BRU (только для выгрузки в ПРК "Орион")
После некоторых небольших "косметических" доработок, под окончание года, выкладываю сборку-релиз DSDOS v3.72r от 09.12.2015
Образ стандартного орионовского 64-килобайтного ROM-диска с ОС и набором утилит доступен по ссылке - http://denn.ru/orion/dsdos/dsdos372.rar
Для всех утилит, использующих подгрузку рабочих файлов через параметр командной строки, доработан механизм определения текущего диска при запуске утилиты с диска "A:" - диском по-умолчанию считается квазидиск, а точнее диск, определённый в системной переменной 3F51h (Диск файла EXT$).
Также доработана утилита LINK$. Изменения коснулись настройки скорости обмена. Выбранный ранее алгоритм пресетного изменения скорости обмена на 9600 Бод с помощью удержания клавиши НР (Shift) при старте, на практике оказался неудобным и маловариативным. Теперь, как и ранее, по-умолчанию скорость обмена 14400 Бод, но её можно изменить практически на любую, которую позволяет сгенерировать таймер (КР580ВИ53) задающего генератора тактовой частоты. Изменение производится с помощью следующего вызова утилиты:
L LINK$ /ss
где ss - значение [2..99] константы делителя частоты (КР580ВИ53) в десятичной системе.
Для скорости 2400 Бод ss=52, для 4800 Бод ss=26, для 9600 Бод ss=13, для 14400 Бод ss=9.
Скорость 14400 Бод является предельной устойчиво работоспособной для схемы на КР580ВИ53+КР580ВВ51А.
При изменении частоты задающего генератора с 2 МГц на 1,8432 МГц появляется возможность работать на скорости 19200 Бод (ss=6), а более высокие скорости уже не "тянет" КР580ВВ51А :(
При правильно указанных параметрах, новое значение константы делителя записывается в файл LINK.INI (на диске "B:"), и при последующих запусках утилиты LINK$ в режимах приёма/передачи используется это значение. Если утилита запускается не из ROM-диска, а, например, с дискеты, то файл конфигурации сохраняется на текущем устройстве, т.о. скорость достаточно задать один раз.
Теперь несколько слов о планах дальнейшего развития.
Концепция DSDOS развивает идеологию ORDOS: хранение всех необходимых утилит и программ на ROM-диске, и к сожалению, на данном этапе стало чётко понятно, что 64 Килобайт стандартного ROM-диска ПРК Орион не достаточно. В связи с этим, данный релиз ОС как раз является завершающим для стандартного железа, а именно 64 Кб ROM-диска, поэтому я назвал её 16-битной версией.
На данный момент уже есть рабочая версия (3.73r) с т.н. 20-битной адресацией ROM-диска, которая поддерживает ПЗУ объёмом до 512 Кб (скриншот). Программно адресация линейная, т.е. в системе ROM-диск по-прежнему видится, как диск "A:", но его объём в 8 раз больше стандартного авторского диска ПРК Орион. Аппаратно в схемотехнике стандартного ROM-диска добавлена "надстройка" в виде регистра-защёлки старшей части адреса на микросхеме 1533ТМ8 (или ТМ9), запись в этот регистр стробируется через неиспользуемую линию C2 порта клавиатуры (на плате кинут провод от линии C2 порта #F4 на контакт B10 разъёма порта #F5). Четыре бита старшей части адреса берутся с линий C1..C4 порта #F5. Функционально аналогичная схемотехника уже реализована в Гибридном Электронном Диске, т.о. ROM-часть уже имеет программную поддержку в ОС DSDOS v3.73r. Схему ROM-диска, как отдельного самостоятельного устройства я отрисую и выложу чуть позже.
Дальнейшие версии ОС DSDOS будут рассчитаны на расширенный, 20-битный вариант ROM-диска, а образ соответственно будет занимать объём более 64 Кб. Но поддержка ROM-диска с классической 16-битной схемотехникой всегда будет автоматической!
Идеологически, по концепции ORDOS расположение файлов в ROM-диске линейное, а признаком конца является байт FFh в имени следующего файла. И если при сканировании каталога ОС встречает признак конца в пределах 64 Кб, то аппаратная реализация ROM-диска не имеет значения. Т.о. в варианте расширенного ROM-диска возможна установка микросхем ПЗУ любого требуемого размера в пределах 512 Кб. На самом деле программно поддерживается адресация до 1024 Кб ПЗУ, но объём более 512 Кб не имеет смысла, поэтому введено условное ограничение в 512 Кб. Т.е. если каким-то образом удастся "впихнуть" файлы общим объёмом более 512 Кб, то ОС их увидит и успешно прочитает. Тут скорее ограничивающим фактором будет лимит по количеству: не более 255 файлов на диске.
В настоящий момент ведётся работа по программной реализации виртуального диска (зарезервировано имя - "G:"), который обеспечит "прозрачную" работу с удалённым накопителем по интерфейсу RS-232. В качестве удалённого накопителя предполагается использование IBM-PC совместимого ПК, а в последствии возможно специализированного сетевого устройства расширения. На IBM-PC делается интерфейс к облачному хранилищу, например к Google-Drive, и т.о. в ОС DSDOS на ПРК Орион становится доступным глобальный сетевой диск, доступ к которому полностью аналогичен, как и к любым другим дискам в ОС.
По началу, реализация виртуального диска будет в виде надстройки - устанавливаемого драйвера. А затем, по мере развития, будет интегрирован в ОС. Также на начальном этапе будет использован родной RS-232 на связке КР580ВИ53+КР580ВВ51А со скоростью обмена 14400 Бод. Впоследствии будет сделана аппаратная доработка: порт COM2 на микросхеме 16C550, с возможностью работы на скорости 115200 Бод.
Планируется поддержка RAM-диска на статическом ОЗУ объёмом 1..4 Мб (зарезервировано имя - "E:"), как альтернатива дисководу в качестве TEMP-диска. А для бэкапа (непосредственная альтернатива дискетам) планируется поддержка карт SDHC (зарезервировано имя - "F:"). Если хватит "запала", то возможно будет организована поддержка винчестеров (зарезервировано имя - "H:"), хотя большого смысла для Ориона в них честно говоря не вижу.
Примерно как-то так :)
Дэн, будь другом, начни с SDHC. :)
А то никак руки не доходят допилить (запалу нет чота последнее время)
Error404, в приоритете виртуальный диск и "метровая рама", после - SDHC. Есть подозрение, что код поддержки флэшек займёт очень много места (я пытался начинать курить "Simplified Specification", было "очень страшно", если честно :)), и придётся "что-то думать": либо отказываться например от поддержки дискет, либо выдумывать хитрости для изыскания ресурсов ОЗУ. К тому же хочется придумать несложный аппаратный ускоритель, ибо побитная работа через ВВ55 скорее всего будет слишком печальна. В общем, SD'шки не настолько насущны пока что. Но доберусь обязательно! Запас 2-гиговых флэшек "для опытов" прикупил, интерфейс спаян уже давно.
Может лучше CompactFlash использовать в режиме IDE, 4Gb пока ещё можно достать. По моему это самый лучший и быстрый вариант для Ориона...
P.S. Схему контроллера я приводил здесь на форуме, можно и её использовать...
Даже не представляю где можно достать. Год назад я с трудом вылавливал 2-х гиговые SDHC. Прогресс и маркетинг неумолимы..Цитата:
Сообщение от alx32
Я на Ali заказывал CompactFlash по 512М CF. С ними проще, насколько я понял они используются в оборудовании, поэтому до сих пор всплывают. А вот с микро SD не повезло - пришел откровенный брак, пришлось делать возврат денег.
У меня год назад хату обнесли, воры в числе прочего унесли все SD-карты, что нашли, а CF не взяли - видимо не поняли что это такое. :)
Просто воры хорошо осведомлены что можно быстро и эффективно слить, а что нет. Орион, наверное, тоже не взяли? ;)
Не взяли. :)
подскажите пожалуйста если сейчас покупать CF карты то какого лучше объема 128 or 512mb
по другому есть ли сейчас девайсы для ретро ПК которые требуют небольших CF карт
я использую DIVide для zx для него всеравно 128 or 512, а для Ориона или РК ?
Попытался запустить последнюю версию на v512, не вышло. На экране проскакивают заставка с версией DSDOS, список дисков. А через секунду жёлто-голубой мусор на экране. После сброса только заставка с дисками и зависон, ни на одну клавишу не реагирует...
Варианты тут возможны только по части ЦПУ (если Z80), версии ПЗУ Монитора, работы с портами (с Z80 по питерской схеме не проходит малополезный хак с 16-битным OUT 8-битной командой)Цитата:
Сообщение от alx32
Монитор3 под Z80 к стати у меня стоит. Может из-за него глюки... А может и из-за Z80Card...
Попробую обратно 580-й воткнуть...
У меня была точно такая же фигня при попытке взлёта с ПЗУ "МОНИТОР-4". Как показало расследование, в М4 вместо подпрограмм записи/чтения верхней границы ОЗУ пользователя (F830h и F833h), там зачем-то повесили нечто на тему записи данных в произвольную страницу ОЗУ... DSDOS при загрузке обращается к этим подпрограммам МОНИТОРа по прямому назначению - для установки верхней границы ОЗУ пользователя, в результате с М4 получается полный трэш ((Цитата:
Сообщение от alx32
С "МОНТИОР-3" (под ВМ80) я проверял в эмуляторе - там полёт нормальный.
П.С. DSDOS пока умеет работать только с клавиатурой РК-86, под 7007-ю не затачивал, т.к. нет таковой железной - не на чем проверить ((
- - - Добавлено - - -
Попробуйте в момент загрузки зажать любую клавишу и не отпускать, это приостановит экран загрузки и там можно будет спокойно всё прочитать. Если таким образом не улетим в мусор, то 99,9% проблема в неправильной работе вышеуказанных подпрограмм ПЗУ Монитора.Цитата:
Сообщение от alx32
Тип процессора точно не имеет значения, т.к. код DSDOS написан полностью на ассемблере ВМ80, который, как известно, совместим с Z80. Адресация портов как памяти - да, используется (при работе с ВВ55), а также используется и адресация через IN/OUT (порты #F8 и #F9).
- - - Добавлено - - -
Можно посмотреть EDMEM'ом что делает подпрограмма "Монитор" по адресу F833h. Там должен быть следующий код: C3 xx F9, а по адресу F9xx что-то типа того: 22 yy F3 2A yy F3 C9.
Ещё DSDOS при старте обращается к подпрограмме распаковки внутреннего знакогенератора "Монитора" - F82Dh.
В Мониторах-3/Z80 код оптимизирован на предмет лишнего, я помнится сразу обратил внимание на то, как там обрабатывается RAMTOP:Цитата:
Сообщение от Denn
:DКод:AF830: LD HL,0BFFFH ; get ramtop
AF833: RET ; set ramtop (not used)
Что в-общем не нашло у меня осуждений, т.к. сам сроду не понимал покой хрен этот RAMTOP вообще был придуман, да еще с отдельными подпрограммами Монитора (а не как все остальное аналогичное - через константу в ячейке памяти).
Собственно, к этому же очевидному выводу и авторы М4 явно пришли.
Лично я привык всё делать по правилам. К тому же моя ОС активно юзает эту фичу, позволяя программно защитить область резидентных программ, эмулятора ORDOS и знакогенератора МОНИТОРа.Цитата:
Сообщение от Error404
Вышеуказанный код-заглушка этих подпрограмм не может быть причиной глюков при запуске DSDOS, он может лишь привести к некорректной работе программ, использующих "API" МОНИТОРа, и то лишь в некоторых ситуациях.
- - - Добавлено - - -
Проверил ещё раз M31RK - работает.
Вот видео - https://www.youtube.com/watch?v=-fvFnIhNaxQ
Так то эмулятор, а я на железе пробовал...
Может проблема в той фиче с форматированием квазидиска?
CP/M от Error404 работает без проблем с ROM-диска на 27С081.
А ранние версии без "этой фичи" на данном железе работали?Цитата:
Сообщение от alx32
Не пробовал, проверял только 3.71 и 3.72.
alx32, старт с удерживанием любой символьной клавиши не улетает в мусор? Квазидиск определяется?
При удержании какой-то клавиши выскакивает выбор загрузки с ROM и (второй не точно помню) по моему FDD.
При выборе ROM снова заставка и список дисков... и зависон...
Ближе к вечеру доберусь до Ориона и попробую версию 3.6.
В принципе - неудивительно. Кроме того, что M31RK написан в коде для 8080, он еще и самый совместимымый с Монитором-2 (AFAIK - полностью совместимый) не смотря на то, что в M31RK много чего добавлено. Классический Монитор от Ивинских. Но в нем нет внешних загрузчиков. А в остальных М3 загрузчики есть (во многих), и чтобы их туда добавлять, питерцы (уже другие авторы) урезали то, что посчитали "нигде не используется".Цитата:
Сообщение от Denn
Поэтому для тех, кто использует Ордос я всегда рекомендую M31RK: совместимость максимальная. А загрузчик можно запустить и из-под Ордос.
Это при удержании SHIFT'а ("НР" в терминах клавиатуры РК-86).Цитата:
Сообщение от alx32
Для нашего эксперимента нужно зажать любую символьную клавишу.
Версии 3.6 не было, была 3.5, а потом 3.7r. Но смысла пробовать старые версии не вижу, т.к. в плане использования ресурсов ПК ничего не изменилось.Цитата:
Сообщение от alx32
Квазидиск, если он присутствует и определяется системой, будет работать корректно в любом случае, т.к. это просто ОЗУ, и оно никак не зависит от типа процессора, адресации портов и вообще каких-либо модов Ориона.
Если зажатие символьной клавиши остановит процесс загрузки и мы не улетим в мусор, то это означает, что адресация портов клавиатуры и ROM-диска отработала корректно, все модули ОС загрузились (файловая система установилась и отработала правильно), тест доступного оборудования прошёл успешно.
- - - Добавлено - - -
Посмотрел я исходник загрузчика и вот что ещё заметил. Используется запись константы тона звукового сигнала в документированную авторами ячейку 0F3E7h. Эту константу "Монитор" использует для озвучки нажатия клавиш и биппера при выводе кода 07h. В варианте Ориона с ВМ80 звук организован через вкл/выкл прерываний, а в варианте на Z80 как-то иначе, и как использует эту ячейку "Монитор-Z80" я не знаю. Может тут собака порылась?Цитата:
Сообщение от Error404
Отсюда вопрос к alx32: перед тем, как начинается "глюконат", проигрывается "журчащая мелодия" в финале загрузки или нет?
Да, есть такой факт. Иногда в эмуляторе работает то, что на железе никак не хочет работать. Эмулятор - это такой сферический конь в вакууме :)Цитата:
Сообщение от alx32
Denn, я звук не подключал, поэтому не могу сказать "журчит" оно или нет...