Просмотр полной версии : DSDOS для ПРК "Орион-128"
Попробую.
А кто у нас АР2 на писишной клаве?
А кто у нас АР2 на писишной клаве?
[Esc]
У меня результат FF
Что-то неисправно в аппаратной части. Конкретно - в узле переключения страниц.
- - - Добавлено - - -
Поясню по тестовой программе. Она делает следующее. По адресу 0000h в банк №15 записывает тестовое значение 0Fh, затем в банк №7 по тому же адресу записывает значение 07h. Далее мы читаем значение из банка №15.
Если банков всего восемь (512 Кб ОЗУ), то происходит "заворот кишок", и у нас из несуществующего банка №15 считается значение 07h. Если честно 16 банков, то считается как положено - 0Fh.
Считанное FFh говорит о том, что с переключением банков совсем беда какая-то. Это считан мусор из какого-то банка, отличного от 7-го и 15-го. Либо в 15-ый не происходит запись, только чтение. Надо разбираться с аппаратной частью.
П.С. а сколько ОЗУ определяет DSDOS ?
П.С. а сколько ОЗУ определяет DSDOS ?
512 Кб
https://i.ibb.co/GsLCJVg/C2-F87-A6-F-877-C-4666-8-E56-2-B0845-BD268-E.jpg (https://ibb.co/GsLCJVg) https://i.ibb.co/N3DZF3K/5-A889-FF2-7-E41-4-C7-F-A88-B-76-BE6713-F68-B.jpg (https://ibb.co/N3DZF3K) https://i.ibb.co/Jc8zrt9/3-D14-B5-E7-8-E14-47-BC-A6-B1-24-E6-C6-E4-C9-D5.jpg (https://ibb.co/Jc8zrt9)
512 Кб
Родной 8-банковый узел переключения работает исправно. Верхняя мегабанка недоступна.
Error404
04.02.2021, 16:58
Как вариант проверки корректности работы страниц - монитором256$ ручками записать номер страницы в какую-то ячейку памяти всех страниц, и глазами проверить где начнется расхождение записанного/ожидаемого/прочитываемого.
Denn, IMHO в файле HW_PRO.L константа PT_PRO_CLK2_M должна быть 3Bh а не 3Ch. У ВИ53 один конфигурационный порт на 3 канала.
Denn, IMHO в файле HW_PRO.L константа PT_PRO_CLK2_M должна быть 3Bh а не 3Ch. У ВИ53 один конфигурационный порт на 3 канала.
Действительно. Спасибо!
30H - регистр данных ВВ51 "COM1" (DD7)
31H - регистр управления ВВ51 "COM1" (DD7)
34H - регистр данных ВВ51 "COM2" (DD8)
35H - регистр управления ВВ51 "COM2" (DD8)
38H - счетчик 1 ВИ53 (DD6)
39H - счетчик 2 ВИ53 (DD6)
3AH - счетчик 3 ВИ53 (DD6)
3BH - регистр управления ВИ53 (DD6)
OriServer v 3.12, невозможно закрыть приложение если вытянуть девайс USB->COM (ну или вытянуть и вставить) из USB-порта.
При выходе, нужно игнорировать ошибку, которую возвращает PurgeComm. Ну и не только при выходе.
https://i.ibb.co/nj8SHDx/ori-serv-err-close.png (https://ibb.co/nj8SHDx)
Romych, к сожалению, тут ничего не могу подсказать, т.к. для работы с COM-портом использовал готовую стороннюю компоненту, и как она устроена - не ведаю. В добавок ещё и комп, где был весь проект, накрылся медным тазом(
Теперь уже, как говорится, "as is".
- - - Добавлено - - -
П.С. у коллеги периодически глючил т.н. "китайский свисток" - тоже USB-to-COM девайс. Удалённо локализовать причины так и не удалось, емнип списали на кривость дров того чуда бюджетной китайской мысли. Мой китайский "хвост" работал без проблем. Выдёргивать по-горячему, правда, не пробовал.
А описание протокола OriServer-a сохранилось хоть? А то вообще печально будет, если вы, Denn, его забудете:)
У меня несколько USB-> com на разных чипах, пару проверил, оба работают с OriServer без вопросов. Дергал на горячую, пока отлаживал плату, а так конечно этого делать не нужно.
А описание протокола OriServer-a сохранилось хоть? А то вообще печально будет, если вы, Denn, его забудете:)
Бэкапы проекта есть. Там проблема именно с этой компонентой СОМ-порта, на погибшем ПК я её с каким-то трудом (под конец уже методом научного тыка) интегрировал в Билдер и она даже работала, на других ПК мне этот фокус повторить не удалось, соответственно проект не компилится.
Я в итоге хотел переделать всё совершенно по-другому, без сторонних компонент, только с использованием WinAPI, и изменить алгоритм на "нелинейный", но тайм-слот на этот проект "закрылся" - не до этого сейчас.
Также в планах было написание OriServer под... Орион! Чтобы можно было без проблем объединять 8-битки в сеть. Но тоже - не до этого совсем(
... но тайм-слот на этот проект "закрылся" - не до этого сейчас.
Жаль. И жаль что протокол "закрыт", я бы мог попробовать написать OriServer под Linux.
жаль что протокол "закрыт", я бы мог попробовать написать OriServer под Linux.
Закрыт для бродяг. А для хорошего дела всё решаемо.
П.С. было бы шикарно, если бы под Андройд!
Я под андроид не умею:) Я под него писал последний раз 10 лет назад, забыл уже всё.
Romych,
Есть такой открытый проект XTIDE биос, так вот в нем есть сериал сервер в исходниках,
для работы с образами дисков на удаленном сервере.
А в самом биосе программы для работы с этим сервером.
Denn, добрый день! Я тут чуть копну тему. Поставил я DS-DOS на свои FPGA-поделки. Всплыли три вопроса.
Как определяется скорость процессора? У меня три режима, 2,5/5.0/10.0 Так вот утилитка SYSTEM всегда показывает 5.0. В то же время тулза СР/М верно определяет скорость процессора.
Как реализован опрос клавиатуры? У меня эмулирована РК86 через ВВ55, опрос в любую сторону, как на реале. Работает адекватно везде, даже в ZX-играх. Но тут... Видео процесса чуть ниже :)
Третий вопрос зрел давно. Если браузер Опера - то скачать образы с твоего сайта - невозможно, а вот любой другой браза - всё качает замечательно. Это дискриминация? :)
https://youtube.com/shorts/r-PhMMD6voA?feature=share
Ewgeny7, привет!
Как определяется скорость процессора? У меня три режима, 2,5/5.0/10.0 Так вот утилитка SYSTEM всегда показывает 5.0. В то же время тулза СР/М верно определяет скорость процессора.
Скорость процессора не то чтобы определяется, она скорее вангуется :) ..по имеющемуся железу, а именно - типу процессора.
Измерить скорость аппаратно без наличия прерываний в системе невозможно. Тулза СР/М скорее всего заточена на систему с Z80 и наличием прерываний, а на базовом конфиге (с ВМ80) она тупо зависнет.
У меня так: если ВМ80, то пишет 2.5 МГц, если Z80 - 5 МГц (в подавляющем большинстве случаев это будет в яблочко).
Как реализован опрос клавиатуры? У меня эмулирована РК86 через ВВ55, опрос в любую сторону, как на реале. Работает адекватно везде, даже в ZX-играх. Но тут... Видео процесса чуть ниже :)
Это последствия вангования :)
По факту скорее всего клок ЦП = 10 МГц, а система подстроила задержку автоповтора под 2,5 МГц - в итоге такая аццкая скорострельность. Активируй аппаратный клок 2,5 МГц и всё будет норм с клавой.
Третий вопрос зрел давно. Если браузер Опера - то скачать образы с твоего сайта - невозможно, а вот любой другой браза - всё качает замечательно. Это дискриминация? :)
Ни разу нет! Я сам пользуюсь только Оперой, и вот даже не проверял на других браузерах. Но ни у кого ни разу не возникало трудностей со скачиванием, т.к. это самая банальная ссылка на файл, там нечему неработать. Возможно у тебя какая-то локальная настройка запрета прямого скачивания файлов в Опере - х/з. У меня в Опере всё скачивается без вопросов.
Как проявляется невозможность скачивания?
Измерить скорость аппаратно без наличия прерываний в системе невозможно. Тулза СР/М скорее всего заточена на систему с Z80 и наличием прерываний, а на базовом конфиге (с ВМ80) она тупо зависнет.
Не претендую на оригинальность, но можно сначала определить процессор, и если z80, то считать, что прерывания есть и замерить скорость. В принципе можно и определить наличие прерываний, но это уже скорее для развлечения, вряд ли вариант установки z80 без прерываний сейчас популярен на орионе.
ivagor, пределу совершенства нет. В планах было много всевозможных улучшений, усложнений и т.п.. Вопрос - нужно ли оно кому-то?
Реального железа О-128 с Z80 у меня нет (и не будет, ибо имхо это изврат), а отлаживать определение скорости процессора "вслепую" это слишком смело :)
П.С. Для Z80 есть ОРИОН-ПРО, и там он к месту, и на ПРОшке DSDOS корректно работает с клавиатурой на 2.5 и на 10 МГц.
У меня так: если ВМ80, то пишет 2.5 МГц, если Z80 - 5 МГц
Понял, вопрос снят.
В СР/М вроде как действительно используют прерывание, замеряя "фрейм".
Активируй аппаратный клок 2,5 МГц и всё будет норм с клавой.
Ну, как бы, не паяльником единым деланные... На видео именно 2,5 стоит скорость процессора. Понять бы, что именно в "железе" так отличается, что программная часть с ума сходит. Там просто циклы задержки? Ведь Мониторы, Бейсики и прочий софт ни разу такого не отчебучивает.
Как проявляется невозможность скачивания?
Примерно так: https://youtu.be/cQZG-R_FaJU
Примерно так: https://youtu.be/cQZG-R_FaJU
Блин, проверил я... и действительно! Раньше точно работало, зуб даю))
Я совсем недавно обновил Оперу, после чего заметил, что перестал через неё работать доступ к домашнему роутеру по адресу: http://192.168.1.1/
теперь стабильно выдаёт вот это:
https://forum-img.guitarplayer.ru/2022/04/13/S0h2H.png
Прошерстил все настройки, что-то где-то превентивно подёргал туда-сюда, хоть ты тресни - не работает страничка роутера((
Через встроенные виндовый старый Эксплорер работает без проблем, на том и забил.
А тут выясняется, что ещё и прямые ссылки на старый-добрый хтмл не работают... ну, не знаю...
Я попробовал в Опере скопировать адрес ссылки по правой кнопке мыши и вставить в адресную строку в новом окне - так сработало!
Например первая ссылка: http://denn.ru/8bit/orion/soft/dsdos-128_s64.zip
Чё-то поломали в Опере однозначно. Это наверное санкции...
- - - Добавлено - - -
На видео именно 2,5 стоит скорость процессора.
Но по факту то, что я вижу на видео это явно скорость проца 10 МГц. На 2,5 МГц не будет такой автоповтор. И звук, кстати, тоже.
Понять бы, что именно в "железе" так отличается, что программная часть с ума сходит. Там просто циклы задержки?
Да, банальные программные циклы задержки.
Вот какой момент! Используется п/п опроса клавиатуры Монитора-2 (0F81Bh), с учётом её тормозов "антидребезга". Если в системе какой-то другой Монитор, в котором эта п/п работает иначе (например, без задержки антидребезга), тогда "возможны варианты"...
https://youtube.com/shorts/r-PhMMD6voA?feature=share
На моем ФПГАшном Орионе происходит все тоже самое, я грешил, что это синтезированный Z80 так работает.
На моем ФПГАшном Орионе происходит все тоже самое, я грешил, что это синтезированный Z80 так работает.
Какая версия Монитора?
П.С. также очень смущает совсем не такой звук, который воспроизводится уже другой стандартной п/п Монитора - F83Fh, и циклы задержки при его воспроизведении также участвуют в формировании таймингов автоповтора клавиатуры.
я грешил, что это синтезированный Z80 так работает
Если ты использовал версию от syd'а, как и я, то там уже всё до такта замерено и сравнено с реалом. На этом ядре демки спектрумовские идеально работают. Поэтому - вряд ли вина ядра. Но от этого понятнее не становится.
- - - Добавлено - - -
Какая версия Монитора?
У меня - М34zrk
У меня - М34zrk
Попробуй М2rk
Какая версия Монитора?
Вот с этим есть большая проблема, когда я пытался сделать так, чтобы работал и cpm и dsdos, то на мониторах из шапки словил глюк, в виде испорченного экрана при скроллинге, этот глюк повторяется и в эмуляторе. На форуме проскакивала версия биос М34zrk, где нет этой ошибки.
Если ты использовал версию от syd'а
Я использовал tv80.
Вот с этим есть большая проблема, когда я пытался сделать так...
Вопрос был: какая версия Монитора?
на мониторах из шапки словил глюк, в виде испорченного экрана при скроллинге, этот глюк повторяется и в эмуляторе.
"Монитор из шапки" это который?
Порча при скроллинге - в какой ОС?
Эмулятор какой?
Вопрос был: какая версия Монитора?
Начиная с версии 3.2 которая грузит сразу с rom-диска, например M32Zrk.bin
"Монитор из шапки" это который?
В одной из тем по Ориону на этом форуме, также те, которые в эмуляторе OrionZEm.
Порча при скроллинге - в какой ОС?
В любой,корме СР/М. Запустите OrionZEm, выбирете монитор M32Zrk.bin и файл rom-диска, например romdisk8.bin, как стартанет ось, запустите М256.2, внем DUMP и попробуйте, чтобы дамп дошел до момента скролинга экрана.
ZPilot, я ориентируюсь на родной монитор М2, он является стандартом для О-128. Если под ним что-то не будет работать или будет работать криво, то это вообще не вариант.
Последующие реинкарнации, видимо, решали какие-то локальные задачи, и их авторы не особо заботились о полной совместимости с базовым М2.
- - - Добавлено - - -
Запустите OrionZEm, выбирете монитор M32Zrk.bin
Для меня нетипичная комбинация, т.к. не пользуюсь ни тем, ни другим.
как стартанет ось, запустите М256.2, внем DUMP и попробуйте, чтобы дамп дошел до момента скролинга экрана.
Запускал под DSDOS M256$, у меня всё работало без вопросов. Скроллинг при выводе осуществляет текстовый драйвер из ПЗУ Монитора, т.е. ОС тут вообще никаким боком. Если некорректно работает M256, то все вопросы к M32Zrk. Ну или к эмулятору... тут уже надо глубоко копать эту конкретную связку.
я ориентируюсь на родной монитор М2, он является стандартом для О-128.
Так я и говорил, что были проблемы с монитором. На форуме нашел без ошибки со скролингом, хотя это не исправило проблему с:
Как реализован опрос клавиатуры? У меня эмулирована РК86 через ВВ55, опрос в любую сторону, как на реале. Работает адекватно везде, даже в ZX-играх. Но тут... Видео процесса чуть ниже
На форуме нашел без ошибки со скролингом, хотя это не исправило проблему с:
Поскольку в формировании таймингов автоповтора участвуют в т.ч. тайминги воспроизведения звука, задержки антидребезга и скорости алгоритма сканирования матрицы клавиш, то любые изменения алгоритмов соответствующих п/п монитора влекут за собой последствия.
В связи с этим мой совет - поставьте М2 и проверьте. Заодно и со скроллингом будет всё хорошо.
"Микрорасследование" по поводу процедуры опроса клавиатуры F81B. В мониторе-2 при обнаружении нажатия клавиши будет задержка примерно 37000 тактов. В m32zrk - примерно 20500 тактов. А в m34zrk задержку в этом месте совсем убрали и если вызывающая программа думает, что задержка тут есть, то она ошибается.
А в m34zrk задержку в этом месте совсем убрали и если вызывающая программа думает, что задержка тут есть, то она ошибается.
А, ну вот, тогда автоповтор будет сумасшедшим, что мы и наблюдаем на видео Жени.
Можно, кстати, наглядно продемонстрировать, что дело именно в упомянутой задержке. Берем монитор-2, уменьшаем задержку до минимума (по смещению 030B-030C меняем 00 06 на 01 00) и смотрим, насколько становится похожа работа клавиатуры на m34zrk.
Берем монитор-2, уменьшаем задержку до минимума (по смещению 030B-030C меняем 00 06 на 01 00) и смотрим, насколько становится похожа работа клавиатуры на m34zrk.
Мне больше другое интересно. Вот человек, который переделывал стандартные п/п Монитора на свой лад - он о чём думал?
На мой субъективный взгляд автор оригинальной процедуры зря сделал жесткую большую задержку, это поставило крест на использовании процедуры в динамичных игрушках. Но и автор m34zrk тоже поступил не очень хорошо, корректнее было бы выделить один-два байта в озу для возможности изменения (для совместимости инициализируем "большим" значением, а если использовать в игрушеке - меняем на маленькое). У меня подозрение, что задержка пропала из m34zrk не столько из-за собственно тонкостей опроса клавиатуры, а просто не хватало места в 2 Кб для новых фич.
На мой субъективный взгляд автор оригинальной процедуры зря сделал жесткую большую задержку, это поставило крест на использовании процедуры в динамичных игрушках.
Есть такое дело. Видимо, у автора при отладке была клавиатура на б/у кнопках от дверного звонка, и там был дребезг мама не горюй :)
В динамичных играх вообще не использовали п/п Монитора, а шарились по железу самостоятельно.
Но и автор m34zrk тоже поступил не очень хорошо, корректнее было бы выделить один-два байта в озу для возможности изменения (для совместимости инициализируем "большим" значением, а если использовать в игрушеке - меняем на маленькое).
Ну т.е. рассуждение автора нового Монитора было примерно таким: "вот я запилил крутые фишки и они стоят того, а то, что некоторое, ранее написанное ПО под базовый Монитор не будет корректно работать - это фигня.
У меня подозрение, что задержка пропала из m34zrk не столько из-за собственно тонкостей опроса клавиатуры, а просто не хватало места в 2 Кб для новых фич.
Так а её всё равно пришлось бы переносить в п/п F803h, без задержки человеческого автоповтора не будет .
Для исправления ошибки со скроллом в m32zrk надо по смещению 03A3 изменить F0 на EF.
В принципе есть 2 варианта борьбы с особенностями мониторов m3*zrk. Или хакать сами мониторы или подгружать альтернативные драйверы для нужных процедур, все же они поддерживают векторизацию процедур.
или подгружать альтернативные драйверы для нужных процедур, все же они поддерживают векторизацию процедур.
Так весь смысл пользования мониторовскими п/п в экономии памяти и, типа, в отвязке от железа..
Кто-нибудь знает, куда пропал Denn?
Страница в ВК удалена :frown:
С Денисом всё в порядке, но из-за работы совсем нет времени ни на хобби, ни на Интернет. Когда вернётся - неизвестно.
Проект, суд по всему, завис:(. И скачать прошивки уже нет возможности?
sergey_sitnik
19.03.2024, 18:04
Почему нет возможности..?
https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot/page50.html
Проект не завис. Касательно третьего поколения ОС в некотором смысле поставлена "логическая точка", т.к. всё задуманное реализовано.
Вот эта самая последняя - https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1102433&viewfull=1#post1102433
Есть некоторые мыли по небольшим доработкам, но пока только "собираю информацию".
ОС четвёртого поколения будет идейно другая, по ней работы ведутся в очень медленном режиме в виду отсутствия свободного времени.
В настоящий момент пишу подробную документацию по версии 3.95, надеюсь скоро закончу и всё выложу.
Если есть какие-то конкретные вопросы, то пишите - отвечу.
Также есть профильные группы и чаты в Telegram'е:
https://t.me/dsdos_128
https://t.me/dsdos_pro
https://t.me/dsdos3help
https://t.me/oriserver
Очень пригодился бы вариант редактора памяти, в котором запись происходит только при записи целого байта, а не при вводе каждого полубайта. Для памяти это не критично, а вот для периферии может быть очень вредно и без костылей не обойтись. Я сам на этом попадался...
Очень пригодился бы вариант редактора памяти, в котором запись происходит только при записи целого байта, а не при вводе каждого полубайта. Для памяти это не критично, а вот для периферии может быть очень вредно и без костылей не обойтись. Я сам на этом попадался...
Алексей, привет!
Какая конечная цель? Предполагаю, что для её реализации интерфейс редактора дампа всё же не самый удобный. Если речь про работу с портами, то скорее лучше сделать специальный отдельный режим, в котором будет максимально удобно решать задачу.
Как это вижу я. Обычно требуется писать в порт какой-то байт команды и смотреть реакцию по какому-то другому адресу. Редактор дампа же обновляет только текущую записанную ячейку, а остальные в дампе не обновляет. Потом, при записи байта курсор автоматом перескакивает на другую ячейку, придётся каждый раз делать возврат... Выходит, что в принципе вариант непрактичный.
Для работы с портами лучше сделать отдельный режим, по типу как у меня сделано в утилите для портов ВВ55. Тут готов к обсуждению по части такой доработки инструментального монитора.
Привет, Денис. Конечная цель - писать требуемые значения в ячейки памяти (или в устройства, расположенных в пространстве памяти) и в порты. Допустим, мне нужно записать в память (или порт, что на памяти лежит, неважно) значение 0xDF. Я нажимаю "D" и этот полубайт сразу пишется. Но другой-то полубайт ещё не введён! И, в результате, в ячейку пишется совсем не то, что мне нужно. Последствия, думаю, описывать не нужно, тем более, что количество проблем от этого может быть весьма большим. Мне видится в программе переключатель - записывать данные, когда байт введён целиком или записывать при каждом введённом полубайте. Причём, при запуске нужен режим записи по вводу полного байта. Если забудешь переключить - ничего страшного, один раз введёшь целый байт, а потом сменишь режим.
Что касается памяти или портов - думаю, было бы лучше работать с одним портом, а не выводить их в виде дампа. Во-первых, портов всё равно не так уж и много, а во-вторых - при выводе дампа порты читаются, что тоже плохо, так как это запросто может повредить работе, если какой-то из портов читать можно только при определённой ситуации - такое тоже бывает, скажем, при использовании UART, когда чтение из регистра данных приводит внутри в действие целый механизм. Так что, думаю, для портов достаточно предусмотреть какую-нибудь горячую кнопку или комбинацию. Скажем, PW<addr>,<value> - записать в порт по адресу addr значение value. Или PR<addr> - прочитать и вывести на экран значение из порта с адресом <addr>.
В остальном лично меня редактор памяти вполне устраивает. Конечно, всегда есть, что улучшить, но проблема с записью каждого вводимого полубайта и невозможность работы с портами очень сильно осложнила мне жизнь. А ведь я начал писать под DS-DOS :)
Автоинкремент адреса при вводе байта можно сделать отключаемым, как и автоперечитывание окна дампа.
Если так будет быстрее и проще - можно сделать две версии редактора. Один - с моими хотелками (извиняюсь, назову их так, так как, кроме меня, о редакторе никто не написал), один - с твоими :)
Если бы были исходники, я бы сам исправил функцию ввода байта, но копаться в коде - не, куча времени. Поэтому и вернулся на ORDOS - приходилось много работать с редактором памяти, хоть он и беден функционально.
Если так будет быстрее и проще - можно сделать две версии редактора. Один - с моими хотелками (извиняюсь, назову их так, так как, кроме меня, о редакторе никто не написал), один - с твоими :)
У тебя же собран COM-порт и работает связь с писи? Я к тому, что достаточно файла редактора или нужно делать отдельную сборку ОС для ROM-диска?
- - - Добавлено - - -
Так что, думаю, для портов достаточно предусмотреть какую-нибудь горячую кнопку или комбинацию. Скажем, PW<addr>,<value> - записать в порт по адресу addr значение value. Или PR<addr> - прочитать и вывести на экран значение из порта с адресом <addr>.
Первое что приходит мне в голову - отдельный режим "работа с портами". Там появляется окно, в котором можно добавлять порты, с которыми будем работать. Максимальное кол-во - сколько поместится в экране окна.
В каждый добавленный порт я могу прописать значение по-умолчанию (к нему можно осуществлять быстрый возврат по горячей клавише), вводить альтернативное значение или активировать только режим отображения. Все введённые параметры сохраняются, в т.ч. при выходе из редактора - в файле конфигурации, при последующих входах оказываемся в тех же портах, с теми же настройками/параметрами.
Есть режим "Слежение", при активации которого состояние всех портов сконфигурированных в режиме "Отображение" будет отражено в реальном времени. Можно дополнить небольшим "самописцем", который, например графически, будет отображать историю изменения состояния порта (фиксация только изменений).
В любой момент можно либо просто прервать слежение, либо ввести новое значение в какой-либо из портов. При выключенном слежении можно обновлять показания пошагово.
Также можно сделать вариант фиксации изменений в файл, чтобы потом можно было в офф-лайне проанализировать большое кол-во состояний.
Как-то так.
- - - Добавлено - - -
Накидал дизайн утилиты работы с портами:
https://forum-img.guitarplayer.ru/2024/03/20/9pNEY.png
У тебя же собран COM-порт и работает связь с писи? Я к тому, что достаточно файла редактора или нужно делать отдельную сборку ОС для ROM-диска?
Да, связь с РС работает, редактор можно и так загружать. Но, думаю, я могу просто засунуть его в сборку - если я правильно помню, для этого достаточно знать, в каком месте дампа ПЗУ располагается редактор, чтобы можно было в любой момент его оперативно вызвать. А загрузка с РС - лишняя привязка и зависимость, не очень удобно. Хотя, конечно, лучше уж так, чем никак :)
Первое что приходит мне в голову - отдельный режим "работа с портами". Там появляется окно, в котором можно добавлять порты, с которыми будем работать. Максимальное кол-во - сколько поместится в экране окна.
Отдельный режим - здорово! Только хорошо бы ещё добавить возможность работать не только с портами, положенными на память, но и с честными портами, которые IN/OUT. Правда, недопонял, чтобы один раз прочитать содержимое какого-то порта, что нужно сделать? Что такое [..]? И что такое "Задать по-умолчанию"? При нажатии ENTER включается постоянное чтение из всех портов на экране? Как удалить порт(ы) из списка?
Практический пример. Допустим, я подключил контроллер. В список вывел его порты, скажем, их два - порт команд/статуса (в списке номер 0) и порт данных (в списке номер 1). Остальные порты из списка нужно удалить. Можно и не удалять, но, в процессе работы они никак не должны затрагиваться, даже на чтение. Порт номер 0 используется на чтение и на запись по разному - при записи в него пишется команда для контроллера, при чтении - состояние контроллера. Я пишу команду и мне нужно далее прочитать этот порт, чтобы посмотреть состояние. Но прочитать именно тогда, когда мне это нужно. Т.е. нажал кнопку - получил значение этого (и только этого) порта. Далее - чтение данных. У контроллера есть особенность - после чтения данных его регистр данных обнуляется. Т.е. данные можно прочитать только один раз, потом будут считываться нули. В этом случае, как и в предыдущем, нужно иметь возможность прочитать данные из порта 1 и только тогда, когда это нужно, режим постоянного чтения, попросту говоря, всё испортит.
В каждый добавленный порт я могу прописать значение по-умолчанию (к нему можно осуществлять быстрый возврат по горячей клавише),
На мой взгляд - бесполезная функция. Если даже какое-то значение используется для ввода часто (я правильно понял - именно такое значение считается "по-умолчанию"?), то его легко ввести вручную - для этого потребуется на пару нажатий больше, что на оперативности, думаю, никак не скажется.
вводить альтернативное значение или активировать только режим отображения. Все введённые параметры сохраняются, в т.ч. при выходе из редактора - в файле конфигурации, при последующих входах оказываемся в тех же портах, с теми же настройками/параметрами.
Есть режим "Слежение", при активации которого состояние всех портов сконфигурированных в режиме "Отображение" будет отражено в реальном времени. Можно дополнить небольшим "самописцем", который, например графически, будет отображать историю изменения состояния порта (фиксация только изменений).
В любой момент можно либо просто прервать слежение, либо ввести новое значение в какой-либо из портов. При выключенном слежении можно обновлять показания пошагово.
Также можно сделать вариант фиксации изменений в файл, чтобы потом можно было в офф-лайне проанализировать большое кол-во состояний.
Слежение - интересная функция. Могу предложить некоторые варианты.
1. Ожидание появления на заданном порту заданного значения с последующими возможными действиями:
а) остановка слежения с выводом сообщения
б) вывод в заданный порт заданного значения с выводом сообщения
в) можно ещё что-то придумать
2. Считывание из заданного порта с наложением маски, далее - как в п.1
3. можно ещё что-то придумать
Самописец - ну, не знаю, нужен ли он реально. Я понимаю, творческим людям всегда что-то хочется улучшать, для них больше удовольствие в процессе, а не в результате :) Но я бы взвесил все варианты и отделил реально полезные функции, которые будут использоваться, от того, что называют "свистелками" и "перделками". Вообще, я за разумный минимализм :)
И вопрос: насколько я помню, в DS-DOS версии 3 всё захардкожено, т.е. драйвера в их общем понимании отсутствуют и ядро системы работает напрямую с железом. Есть ли возможность ввести в систему ещё один или два диска на не поддерживаемых системой накопителем? Если можно, то как? Если нет, то, конечно, можно просто написать оболочку, которая будет работать с этим накопителем, но хотелось бы поддержки на уровне системы.
Да, связь с РС работает, редактор можно и так загружать. Но, думаю, я могу просто засунуть его в сборку - если я правильно помню, для этого достаточно знать, в каком месте дампа ПЗУ располагается редактор
Нет, просто так новый код не "впихнуть" в образ ПЗУ ROM-диска. Он же будет другого размера. Нужно пересобирать сборку по-новой.
А загрузка с РС - лишняя привязка и зависимость, не очень удобно.
Можно загрузить один раз и закинуть на винчестер или дисковод, или в SRAM-диск, в зависимости от того, что есть из носителей.
Только хорошо бы ещё добавить возможность работать не только с портами, положенными на память, но и с честными портами, которые IN/OUT.
Вот тут у меня мыль раздваивается :)
С одной стороны хочется сделать платформо-зависимо, т.е. на О-128 автоматом будет адресация как ячеек памяти, а на Орион-ПРО - как порты по IN/OUT.
С другой стороны можно сделать универсально, но это скорее будет вводить в заблуждение пользователя. Например, если ввели только две цифры адреса, то программа интерпретирует адресацию порта по IN/OUT. Если ввели четыре цифры, то адресует как память.
Надо будет ещё раз подумать, как лучше сделать.
Правда, недопонял, чтобы один раз прочитать содержимое какого-то порта, что нужно сделать? Что такое [..]?
Нажать один раз на любую клавишу, кроме зарезервированных на спец. функции (управление портами, выход).
[..] - это из терминологии авторов Ориона, и я как увидел, то сразу понял, о чём речь. Это означает "любая клавиша, кроме тех, которые указаны дальше в списке".
И что такое "Задать по-умолчанию"?
Полагаю частой задачей будет "пулять" в порт какое-то значение (типа что-то включить), а потом откатываться на предыдущее (выключить в исходное). И так многократно.
Каждый раз вводить и то, и другое значение - задолбаешься. А так хотя бы вводить одно, а второе возвращать в один "клик". Оперативнее.
Для ввода значения надо сделать три нажатия, а для сброса в дефолтное - одно.
При нажатии ENTER включается постоянное чтение из всех портов на экране?
Из всех активированных. Неактивные не участвуют в этом процессе.
Как удалить порт(ы) из списка?
Просто деактивируем. Удалять не требуется. По-умолчанию неактивны все. Включая нужные, мы как бы добавляем порты в работу. При этом записывать значения можно в любые порты, в т.ч.в неактивные. Статус "активен" влияет только на чтение показаний из порта при нажатии "Шага" или циклический вывод в режиме слежения.
Идейно так. На экране всегда присутствуют 10 портов. В любом можно: 1) изменить адрес, 2) записать значение, 3) Читать или не читать состояние.
По-моему, так прозрачно и удобно. Любая функция по любому порту доступна в один клик!
- - - Добавлено - - -
Практический пример. Допустим, я подключил контроллер. В список вывел его порты, скажем, их два - порт команд/статуса (в списке номер 0) и порт данных (в списке номер 1). Остальные порты из списка нужно удалить. Можно и не удалять, но, в процессе работы они никак не должны затрагиваться, даже на чтение. Порт номер 0 используется на чтение и на запись по разному - при записи в него пишется команда для контроллера, при чтении - состояние контроллера. Я пишу команду и мне нужно далее прочитать этот порт, чтобы посмотреть состояние. Но прочитать именно тогда, когда мне это нужно. Т.е. нажал кнопку - получил значение этого (и только этого) порта. Далее - чтение данных. У контроллера есть особенность - после чтения данных его регистр данных обнуляется. Т.е. данные можно прочитать только один раз, потом будут считываться нули. В этом случае, как и в предыдущем, нужно иметь возможность прочитать данные из порта 1 и только тогда, когда это нужно, режим постоянного чтения, попросту говоря, всё испортит.
Те порты, которые не надо читать, их просто не активируем. Когда потребовалось прочесть - активируем, смотрим считанное, затем опять деактивируем. Записывать можно в неактивный порт, это означает, что значение в него запишется, а вычитываться не будет. Думаю, Такая схема позволит реализовать абсолютно любые варианты сценариев.
Что-то более изощрённое - это уже надо городить целый язык программирования. Тоже можно придумать, но это уже другая история.
- - - Добавлено - - -
На мой взгляд - бесполезная функция. Если даже какое-то значение используется для ввода часто (я правильно понял - именно такое значение считается "по-умолчанию"?), то его легко ввести вручную - для этого потребуется на пару нажатий больше, что на оперативности, думаю, никак не скажется.
Ввести значение - это три нажатия. Ввести заранее предопределённое значение "по-умолчанию" - одно нажатие. Есть разница. А если делать многократно, то очень большая разница!
- - - Добавлено - - -
Слежение - интересная функция. Могу предложить некоторые варианты.
1. Ожидание появления на заданном порту заданного значения с последующими возможными действиями:
а) остановка слежения с выводом сообщения
б) вывод в заданный порт заданного значения с выводом сообщения
в) можно ещё что-то придумать
2. Считывание из заданного порта с наложением маски, далее - как в п.1
3. можно ещё что-то придумать
Это уже целый язык-интерпретатор будет. Мне кажется, такие задачи проще накидать на ассме. Реально проще. Особенно на Орионе под DSDOS ;)
- - - Добавлено - - -
Самописец - ну, не знаю, нужен ли он реально. Я понимаю, творческим людям всегда что-то хочется улучшать, для них больше удовольствие в процессе, а не в результате :)
Мне реально нужно было. Постоянно пользовался распечаткой портов в экран для анализа изменений. Таким образом не имея документации на протокол RS-232 полностью изучил живой обмен и сделал эмуляцию UART на ВВ55. Изучал поток данных с магнитных карт. Сигналы с телефонной линии, модемы. Всё "ломал" только через экранный "самописец", очень удобно!
- - - Добавлено - - -
И вопрос: насколько я помню, в DS-DOS версии 3 всё захардкожено, т.е. драйвера в их общем понимании отсутствуют и ядро системы работает напрямую с железом. Есть ли возможность ввести в систему ещё один или два диска на не поддерживаемых системой накопителем? Если можно, то как? Если нет, то, конечно, можно просто написать оболочку, которая будет работать с этим накопителем, но хотелось бы поддержки на уровне системы.
Можно вводить новые диски с помощью написания и установки драйвера. Буква свободная всего одна - H. Но при желании можно "затереть" драйвер ненужного диска, например FDD, и высвободить ещё две буквы.
Нет, просто так новый код не "впихнуть" в образ ПЗУ ROM-диска. Он же будет другого размера. Нужно пересобирать сборку по-новой.
Зная структуру диска, это сделать несложно. Например, я такое делал с дисками ORDOS. Зная, где располагается начало требуемой программы и её длину, можно отделить данные до и после, а затем приклеить их в начало и конец новой программы. Главное - не превысить максимальный размер. В этом случае можно пожертвовать какой-нибудь менее нужной программой. У меня где-то даже валяется небольшая программа для РС, выводящая из дампов ROM-диска ORDOS информацию по содержащимся там файлам :)
- - - Добавлено - - -
Можно загрузить один раз и закинуть на винчестер или дисковод, или в SRAM-диск, в зависимости от того, что есть из носителей.
Можно, конечно, но ROM-диск быстрее и всегда под рукой. А если нет ни винчестера ни дисковода - что делать? У меня, например, под DS-DOS использовался только ROM-диск и линк с РС.
- - - Добавлено - - -
Вот тут у меня мыль раздваивается
С одной стороны хочется сделать платформо-зависимо, т.е. на О-128 автоматом будет адресация как ячеек памяти, а на Орион-ПРО - как порты по IN/OUT.
С другой стороны можно сделать универсально, но это скорее будет вводить в заблуждение пользователя. Например, если ввели только две цифры адреса, то программа интерпретирует адресацию порта по IN/OUT. Если ввели четыре цифры, то адресует как память.
Надо будет ещё раз подумать, как лучше сделать.
А зачем все эти усложнения? Пусть себе будет и то и другое, в т.ч. и на О-128. А адреса портов могут быть и больше 0xFF, три-четыре цифры. Ну, а что касается введения в заблуждение пользователя, об этом можно не беспокоиться, если есть нормальное описание программы/справка. В этом случае заблуждение пользователя - чисто его проблема.
- - - Добавлено - - -
Ввести значение - это три нажатия. Ввести заранее предопределённое значение "по-умолчанию" - одно нажатие. Есть разница. А если делать многократно, то очень большая разница!
Дело, конечно, хозяйское, можно и так, лишь бы оставалась возможность оперативно вводить данные вручную. Нравится - используешь предустановленные значение, не нравится - пишешь вручную. Лично по мне, так одно нажатие против трёх - очень сомнительное преимущество в оперативности, тем более, когда речь идёт об отладке, а не о скоростном наборе текста.
- - - Добавлено - - -
Можно вводить новые диски с помощью написания и установки драйвера. Буква свободная всего одна - H. Но при желании можно "затереть" драйвер ненужного диска, например FDD, и высвободить ещё две буквы.
А информация по написанию драйвера пользовательского диска есть в документации?
Зная структуру диска, это сделать несложно. Например, я такое делал с дисками ORDOS. Зная, где располагается начало требуемой программы и её длину, можно отделить данные до и после, а затем приклеить их в начало и конец новой программы.
Есть утилита сборщика ROM-диска – CRTDSK$. С её помощью всё намного проще. Но можно и руками, так наверное даже интереснее :)
А зачем все эти усложнения? Пусть себе будет и то и другое, в т.ч. и на О-128.
Не вижу смысла делать то, что не будет востребовано. На О-128 порты, которые "на память", начинаются с F400 и простираются до F7FF. Далее идут "однобайтовые" порты, которые по традиции принято адресовать с помощью команды OUT xx, но можно и через "память". На "Орион-ПРО" только "однобайтовый" вариант, эмуляция некоторых портов через "память" вроде есть, но никто ей не пользуется.
Мне кажется, так и надо делать: для О-128 адресация F400..F7FF двухбайтовая (через "память"), а при вводе первых двух цифр адреса порта от F8 и выше, автоматом работать как с честным портом; на Орион-ПРО оставить только "портовую" адресацию одним байтом.
А адреса портов могут быть и больше 0xFF, три-четыре цифры.
Это ещё что за чудо такое? Процессоры Орионов физически не умеют такое адресовать..
Ну, а что касается введения в заблуждение пользователя, об этом можно не беспокоиться, если есть нормальное описание программы/справка. В этом случае заблуждение пользователя - чисто его проблема.
Сегодня не так. Если ты не умеешь сделать программу, понятную сходу для самой тупой домохозяйки, то результаты твоей деятельности миру не нужны, и тебя как бы "нет". Всё что сложнее пары кликов - никому не интересно. "Пара кликов" и "никому" здесь условные понятия, но суть отражают максимально приближённо к жизни. Куда-то идти и что-то читать, с чем-то разбираться сегодня не будут. Либо сразу всё просто и понятно, либо нафиг. Прошли времена, когда люди пытались что-то изучать, ходили в библиотеку, гордились глубокими знаниями и т.п..
Нравится - используешь предустановленные значение, не нравится - пишешь вручную.
Именно так.
А информация по написанию драйвера пользовательского диска есть в документации?
Пока нет. В ближайшее время закончу написание руководства пользователя. Руководство по программированию буду делать позже.
В числе методов написания программы есть "Я делаю программу как для себя, так и для других" и "Я позволяю другим использовать программу, которую делал для себя". Эти методы отличаются подходом и отношением.
С некоторым опозданием добавилась документация к релизу ОС DSDOS v3.95, опубликованному ранее - тут (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1102433&viewfull=1#post1102433).
Документ в старом-добром формате MS Word '97.
Ссылка для скачивания - http://denn.ru/8bit/orion/soft/dsdos/DSDOS_3.95_User_Manual.doc
(если браузер не открывает по клику, то скопировать ссылку и вставить в адресную строку в новом окне).
И снова здравствуйте дискеты! :)
По просьбе трудящихся заморочился и запаковал существующее ПО в образы дискет. Такой вариант переноса файлов на Орион подойдёт для нежелающих по каким-либо причинам собирать COM-порт, кому проще "таскать файлы с писи дискетами".
В образе "utilites_all.odi" лежит утилита ATLAS, которую можно скопировать с дискеты в квазидиск, запустить, а потом вставив дискету в формате СР/М, уже копировать файлы с неё. В общем, для тех, кто не ищет лёгких путей.
Ссылки для скачивания архивов:
1) Для ПРК "Орион-128/512" - http://denn.ru/8bit/orion/soft/soft395@128.zip
2) Для ПРК "Орион-ПРО" - http://denn.ru/8bit/orion/soft/soft395@pro.zip
Архивы имеющие в названии "_128" или "_pro" содержат платформо-зависимое ПО, остальные - универсальное.
Некоторое ПО также представлено в виде исходного кода, что может быть полезно для понимания принципов программирования в среде ОС DSDOS.
P.S. актуально для DSDOS v3.95
кому проще "таскать файлы с писи дискетами".
Существует ли программа под DOS/Windows для создания/изменения образов дискет формата .odi?
В образе "utilites_all.odi" лежит утилита ATLAS, которую можно скопировать с дискеты в квазидиск, запустить, а потом вставив дискету в формате СР/М, уже копировать файлы с неё. В общем, для тех, кто не ищет лёгких путей.
Есть ли инструкция со скриншотами? Для таких малограмотных вроде меня, что незнакомы с термином «квазидиск».
Есть ли инструкция со скриншотами? Для таких малограмотных вроде меня, что незнакомы с термином «квазидиск».
Нет, конечно. Там проще самому разобраться, чем кому-то садиться и тратить вечер на создание инструкций.
Орионинг изначально предполагает некоторую пытливость ума) И если человек связался со сборкой Ориона, то разобраться с простецким ПО для него не представляет трудности.
И если человек связался со сборкой Ориона, то разобраться с простецким ПО для него не представляет трудности.
Всего лишь собрался портировать примитивную логическую игру на Бейсике. =)
Error404
26.11.2025, 12:42
Существует ли программа под DOS/Windows для создания/изменения образов дискет формата .odi?
Посмотрите вот это:
https://zx-pk.ru/threads/26454-steinblume-cp-m-disk-image-explorer-(ex-atm-cp-m-explorer).html
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot