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

[Error404]

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

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

[Advertiser]

[OrionExt]

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

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

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

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

[Denn]

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

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

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

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

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

[Error404]

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

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

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

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

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

[ivagor]

Дополнение к тесту быстродействия. Дмитрий прогнал тест еще и в режиме 5 МГц. В этом режиме все просто - каждое обращение к памяти или порту +1 такт.
Пара слов про ВИ53 - раньше у Дмитрия была установлена советская микросхема, она при включенной турбе нестабильно программировалась и читалась. Теперь он заменил на зарубежный аналог и стало возможно работать с таймером не выключая турбу.

[Denn]

Пара слов про ВИ53 - раньше у Дмитрия была установлена советская микросхема, она при включенной турбе нестабильно программировалась и читалась.

Есть такая фигня. Я у себя в коде решил вопрос так.

Вместо простого и логичного обращения: OUT PT_TM1

Пишу так:

CALL Sv8253
...
Sv8253:
OUT PT_TM1
RET

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

[ivagor]

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

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

[Denn]

А я просто выключал турбу, писал/читал таймер, включал турбу.

Мне приходится на два фронта работать (О-128 и О-ПРО), поэтому проще и логичнее по возможности использовать универсальное решение проблемы для обеих платформ.

П.С. "писал/читал таймер, включал турбу" - а если комп уже по каким-то причинам работает не в турбе?

[ivagor]

Error404, этот вариант работает хорошо, так и с ohi стало можно работать.
Насчет 512 Кб - пробовал старые векторовские cp/mы, орионовские - в них это ограничение есть. В новых векторовских досах это ограничение, насколько могу судить, убрали, по крайней мере в рамках дискеты файлы можно не разбивать.

Black Cat / Era CG, мне было лень разбираться в своих старых исходниках вывода bmp на экран вектора и пошел легким путем - палитра+картинка по плоскостям. Не думаю, что где-то еще стоит делать поддержку такого формата.

Denn, причина проблем, как я понимаю, в том, что обычные ВИ53 были официально рассчитаны максимум на 2 МГц, а в орионах работали/работают на 2,5. Некоторые экземпляры это переносят, некоторые нет. 2,5 официально поддерживает ВИ53Д.
Насчет того как бороться - вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия). Если придется - может сделаю "тормозное" обращение к таймеру. Но имхо в идеале на про нужно использовать микросхемы стабильно работающие даже в турбе, не говоря уже про 2,5 МГц.

[OrionExt]

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