Орион-ПРО. Софтверные дела

[Error404]

С методами программирования по портам Орион-Про не взлетит.
Это какое-то зх-спектрумский подход к делу. Все по железу

- - - Добавлено - - -

Зачем мне нужно под каждую хотелку код программы переделывать?)

Там проблема в быстродействии что по-другому не получается.
По сути, работа с портами допустима (конечно, при этом программа сразу из разряда классических проваливается в "демы"), но нужен некий софтверный БИОС, который определяет возможен или не возможен доступ к порту или какому-то участку памяти в данном инстансе ОС (т.е. по факту на данном клоне).
Чтобы пользовательсяка программа перед тем как лезть по железке в ОЗУ элементарно проверила - а не занято ли уже это ОЗУ каким-то другим процессом, как уже выставлены порты (чтобы не порушить чего или "неожиданно" не сесть на область перекрытую диспетчером). Чтобы не как сейчас оно пропиливало "наудачу" и после проигрывания вешалось. Я например об этом подумал сразу как начал писать многостраничные программы (и для этого сделал соответствующие механизмы в ОС). К сожалению, делалалось это еще в 95г., когда в наших деревнях был информационный вакуум, и хотя я все сделал довольно удобно (например, когда я уже в 2015 стал портировать Юзикс, а это очень большой проект полностью утилизирующий все ресурсы Ориона128 до последнего байта и такта, все очень удачно легло на те архитектурные решения). Но получилось это несовместимо с например CPM3 (где тоже есть программные обвязки для маппера памяти). И нет там никаких проблем с портами, порт FB например используется только один раз при старте для включения прерываний (как и на ПРО, только на ПРО его программируют неграмотно - не учитывая что в порту FB на "классике" есть еще функции). Благодаря этому, ОС работает даже на плате Z80 от Орион-Сервиса (тот убогий вариант где вместо прерываний эмулируется звук по ei/di и 8-битные порты), и на ПРО чтобы ее запустить мне было достаточно только в экранном драйвере (т.е. даже не в самом когде ОС) тупо переключать при запуске в
режим "Орион-128", ну и пара коррекций для прерываний (которые авторы могли сделеать совместимо с лениградцами, но таки не сделали ибо "сделано не нами").

- - - Добавлено - - -

На первый взгляд какая-то фигня На самом деле исполнение "лишних" команд CALL/RET вносит достаточную задержку между обращениями к таймеру и он надёжно программируется.

Странно все это. Как и неуспевающий контроллер клавиатуры. Ведь именно чтобы этого не было (насколько я понял мысл создателей) на ПРО они и сделали узел на D87, формирующий /WAIT при IORQ (ну и до кучи и при MREQ). ТМ8 там последовательно переписывает из одного триггера в другой, и смотря сколько триггеров в цепочке получается разная длительность /WAIT, причем для портов и для памяти эта длительность отличается, и еще есть свободный триггер, т.е. можно попробовать как удлиннить так и укоротить /WAIT.

Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.

[Denn]

Странно все это. Как и неуспевающий контроллер клавиатуры. Ведь именно чтобы этого не было (насколько я понял мысл создателей) на ПРО они и сделали узел на D87, формирующий /WAIT при IORQ (ну и до кучи и при MREQ). ТМ8 там последовательно переписывает из одного триггера в другой, и смотря сколько триггеров в цепочке получается разная длительность /WAIT, причем для портов и для памяти эта длительность отличается

Тем не менее. Самое смешное, что даже на Орионе-128 с ВМ80А и клоком 2,5 МГц те же самые проблемы с программированием ВИ53, просто они проявляются черезвычайно редко. В итоге пришлось и в ПО для О-128 делать аналогичные задержки.

К примеру, такой код:

MVI A,12
STA PT_TM1
XRA A; здесь нужен 0 и для сокращения кода обнуление сделано одной командой
STA PT_TM1

нифига не работает с ВИ53, даже на О-128@2,5МГц. Видимо, слишком быстро прилетает второй конфигурационный байт,
а ВИ53 ещё первый не "скушала".


А вот это уже работает (но в ~99% случаев):

MVI A,12
STA PT_TM1
MVI A,0
STA PT_TM1

И только через CALL/RET работает 100%

Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.

У такого решения есть минус - написанное и отлаженное ПО вероятно будет криво работать у других юзеров со стандартной платформой /-)
Если выкидывание WAIT'ов при обращении к портам даёт катастрофический прирост скорости, то это конечно может быть оправдано, но тогда придётся писать транспаранты крупными буквами, что для работы с ПО требуется доработка. А лучше делать автодетект имеющегося оборудования и подстраиваться программно, но это не всегда возможно (

[OrionExt]

По сути, работа с портами допустима (конечно, при этом программа сразу из разряда классических проваливается в "демы"), но нужен некий софтверный БИОС, который определяет возможен или не возможен доступ к порту или какому-то участку памяти в данном инстансе ОС (т.е. по факту на данном клоне).
Чтобы пользовательсяка программа перед тем как лезть по железке в ОЗУ элементарно проверила - а не занято ли уже это ОЗУ каким-то другим процессом, как уже выставлены порты (чтобы не порушить чего или "неожиданно" не сесть на область перекрытую диспетчером). Чтобы не как сейчас оно пропиливало "наудачу" и после проигрывания вешалось.

Вот и я об этом хотел сказать.

Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.

Желание увеличивать быстродействие всегда прямо пропорционально существующему быстродействию. Как говорится, аппетит растет во время еды. А кто потом будет гарантировать совместимость старого ПО с новым "турбо" режимом. Это какой-то неправильный путь развития.
Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО. Пример порт FB.

[Error404]

Если выкидывание WAIT'ов при обращении к портам даёт катастрофический прирост скорости, то это конечно может быть оправдано, но тогда придётся писать транспаранты крупными буквами, что для работы с ПО требуется доработка. А лучше делать автодетект имеющегося оборудования и подстраиваться программно, но это не всегда возможно (

Там при чтении сектора цикл, в котором на чтение каждого байта с IDE приходится сделать до полдюжины обращений в ВВ55. Соответственно, думаю исключение вейтов улучшит общие показатели на 15-20% . Понятно, что проверить надо будет работу в обоих режимах (вынести джампер который вейты как включает, так и выключает), на клавиатуру вейты оставить независимо ни от чего. Но в целом, программно реализованный IDE (хоть на регистрах авторского контроллера по аналогии с NemoIDE, хоть на ВВ55 где просто больше команд надо на чтение и соответственно медленнее общая скорость) и так уже зависит от частот процессора. На Орионе-128 нормально работало и на на частоте 2,5, и на 5+wait. Так что, прогноз благоприятный.

[Denn]

Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО.

Или, как вариант, предполагается самостоятельное написание ПО под свои личные нужды, без оглядки на совместимость

- - - Добавлено - - -

думаю исключение вейтов улучшит общие показатели на 15-20% .

Имхо, эти цифры не стоят того. Я бы подумал в сторону изобретения новой железки, которая увеличит скорость в разы
Пусть даже это будет примочка на МК, и пёс с ней, с "религией"!

[OrionExt]

Добавлю.
На примере платформы MSX, по идеологии среди 8-биток она наиболее приближена к «правильному» подходу к аппаратным расширением, методами написания ПО.
За все это время там никто не решился убирать аппаратные костыли того времени. Ну, разве что в частном порядке, в виде эксперимента. И это правильно. Меня как пользователя, прежде всего, интересует работа ПО, подключение аппаратных расширений. Все должно работать из коробки.

[Denn]

За все это время там никто не решился убирать аппаратные костыли того времени.

Тут ещё дело в "масштабах бедствия". Юзеров MSX (причём "тогда", т.к. я понял речь про время, когда платформа была на пике актуальности) было чуть менее, чем дофига, в связи с этим что-то менять и т.о. "кидать" кучу народу было бы действительно дико.
У нас же сейчас, как я понимаю, ситуация примерно следующая: юзеров Ориона примерно "полтора" человека, причём далеко не самых ленивых Т.е. фактически можно лепить стандарты прямо на ходу, сильно никто не пострадает

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

[Error404]

А кто потом будет гарантировать совместимость старого ПО с новым "турбо" режимом. Это какой-то неправильный путь развития.
Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО. Пример порт FB.

это не тот случай, где есть или нет какая-то совместимость или несовместимость. ПО никак же не меняется, и железка меняется тупо добавлением джампера "wait/nowait".
Ближайший аналог - это уже существующий как на 128 так и на ПРО джампер верхней чатоты процессора (тот самый "турбо"). Тупо ставишь и смотришь - если работает, то замечательно, если не работает (например, верхнюю частоту не тянет проц) - просто верни джампер в нижний режим, тебе не повезло. как то так.

- - - Добавлено - - -

Имхо, эти цифры не стоят того. Я бы подумал в сторону изобретения новой железки, которая увеличит скорость в разы
Пусть даже это будет примочка на МК, и пёс с ней, с "религией"!

Ну, одно другого же никак не отменяет. Первое - совсем малой кровью на первое время, оно просто уже есть. Второе еще надо сделать, и когда оно будет, поставил в слот и пусть работает.

[ivagor]

исполнение "лишних" команд CALL/RET вносит достаточную задержку между обращениями к таймеру и он надёжно программируется.

А я просто выключал турбу, писал/читал таймер, включал турбу. На про Дмитрия это работало. А с импортным 8253 можно и турбу не выключать.

[Error404]

Оффтоп, но раз заходила речь про большие файлы и hdd. Пользуюсь OdiWcx - работает отлично, а вот OhiWcx работет довольно странно. Файлы больше определенного размера (в районе 32 Кб) портит. Записывал большие файлы на образ hdd из под альтаира - так ошибок нет, но очень медленно и неудобно.

Да, я знаю про этот глюк. Глюк проявляется только на файловых системах CP/M размеченных с размером группы в 16кб (это максимум возможный для CP/M).......
Просто пока этим пользовался я один, трассировать и ловить баг не было стимула (есть поинтереснее чего попрограммить), я тупо пользовал разделы со старых образов. Теперь обещаю исправиться и баг изловить и изничтожить.

Поправил плагины - убрал вышеописанный глюк (новые файлы во вложении). Новых глюков вроде не наделал, но тестил мало, так что пишите если чего всплывет.
Ошибка была, как я и предполагал, в odi.wcx (там вся логика), но попутно немного поправил и ohi.wcx (функционально и косметически), так что заменить надо обе wcx.

- - - Добавлено - - -

В следующем приступе программистического энтузиазма сделаю поддержку файловых операций в партициях UZIX, тоже давно хочу, но как-то все руки не доходят: лень сильнее.