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