Что имеется ввиду?Цитата:
Сообщение от Копейкин
Вид для печати
Что имеется ввиду?Цитата:
Сообщение от Копейкин
А чем вызвана неприятная полосатость строки команд Нортона и прерывистость бордюра?Цитата:
Сообщение от Tronix
Ваши скриншоты на первой странице этой темы.
Тем, что у Поиска шрифт, фактически, 7x8 а не 8x8 как у нормальных людей. Ну то есть формально то он 8x8 конечно, да вот только первый бит (или последний, смотря откуда смотреть) отвечает за цветовой признак - либо белые пиксели, либо лиловые (зеленые). Например возьмем черточку (минус):Цитата:
Сообщение от Копейкин
00000000
00000000
00000000
01111111
01111111
00000000
00000000
00000000
Вот она в таком виде - белая. В таком:
00000000
00000000
00000000
11111111
11111111
00000000
00000000
00000000
- лиловая. И если в шрифте она так и записана, то белой она уже не станет. Будет всегда лиловой.
Спасибо за детальное изложение, я так глубоко видеоконтроллер Поиска не копал.
Чтобы полностью всё осознать, Вы не расскажете - это аппаратно реализовано?
Или можно программно привести в соответствие?
Ведь в видеорежиме 3 отдельно коды символов, отдельно атрибуты должны быть...
Я то же не копал. Все время как хочу - вылазят столько нюансов, что я опять запутываюсь и все по новой. Поэтому все что дальше - мое имхо. Поиск работает всегда в графическом режиме, текстового у него нет. При этом в графическом режиме высокого разрешения 640x200 он может работать в двух вариантах: 1) когда каждый байт раскладывается на 8 бит и каждый бит трактуется как черный или белый. То есть обычный графический ч/б режим. И второй вариант - когда каждый байт трактуется как первый бит - наличие дополнительного цвета за последующими 7 битами. Таким образом в этом режиме может быть отображено 3 различных цвета (черный,белый,лиловый), но с потерей каждого первого бита в каждом байте. Это аппаратно так.Цитата:
Сообщение от Копейкин
Как-то так.
Поборол лень и впилил все-таки дизассемблерные обработчики int 10h, int 9h, scanint и int16h из биос 91-ого года. Да, в BIOS 91 года отличия большие, по сравнению с имеющимися сорцами...
Клава - они полностью переписали обработчик scanint (который сканирует клаву). int 9h - почти байт-в-байт совпал с имеющимися сорцами BIOS от Поиск-2. Таблицу перекодировки русских букв вынесли из scanint в int 16h. И теперь это стало реально таблицей маленьких и больших букв, а раньше была маленькая табличка плюс куча условий в scanint. Меняют при нажатии на правый ctrl фон на синий, в 89 этого нет. Короче изменения внушают.
Видео - тоже они здорово переделали int 10h. Обработчики не совпадают, поэтому просто подгонял дизассемблерный листинг с правкой констант. Теперь курсор вменяем. NMI добавил чуть-чуть чтения портов, Принц персии стартует. Остальное надо проверять и доделать чуть-чуть.
Так что основные фишки из 91-ого биоса перенесены. Потестирую, если все ок, оставлю...
Спасибо Вам огромное.
А в этом варианте БИОСа поддерживается клавиатура 89 или 91 года?
Там вроде по разному было сделано.
В этом варианте клавиатура 91-ого года теперь (раньше была 89-ого).Цитата:
Сообщение от Копейкин
Вообше, немного подоптимизировал NMI, int 10h... Скорость видео с оригинальным процессором 1810ВМ88 я показывал на первой странице, но вот еще раз:
http://hsto.org/storage3/2e8/28d/440...b36099600e.jpg
А это скорость видео с оптимизацией обработчика NMI и функций вывода символов из int 10h (табличное умножение). Процессор тот же - 1810ВМ88:
http://habrastorage.org/files/21b/c3...6b49e59409.JPG
В обработчике NMI есть деление, а оно, как известно, происходит долго. Ради эксперимента попробовал заменить деление табличкой, но жертвуя 4 Кб оперативной памяти. То есть, если у Поиска 480Кб - будет 476Кб, если 96Кб - будет 92Кб соответственно. Это задается дефайном OPTIMIZE_DIV в BIOS.ASM. Вот с включенной оптимизацией на родном проце 1810ВМ88:
http://habrastorage.org/files/eca/f7...024249f39c.JPG
Что касается NEC V20 - то скорости тоже пропорционально возросли.
Всем добрый день!
В документации на "поиск" встретил упоминание, что процессор для доступа к памяти получает только 8 тактов из 16, и при частоте 15МГц это даёт скорость доступа 937500 операций в секунду. Не знаю, успевает ли он за эти 8 тактов прочитать или записать два байта или только один, но очевидно, что скорость памяти является главным тормозом. То есть, чем меньше читается кода и обращений к памяти, тем лучше. При дальнейшем развитии данной мысли, был написан обработчик NMI, который сначала жил в загрузочном секторе, а когда стало очевидно, что для разных текстовых режимов желательно иметь разные обработчики, переселился в COM-файл. Для ускорения рисования обе половины шрифта были положены рядом, чтобы не работать с указателями. Для режима 80 символов обрабатываются 2 бита атрибутов - инверсия и альтернативный цвет, они преобразуются в XOR-маску, это не совсем то, что делает биос, но его логику я не особо уловил, да и можно сделать преобразование по таблице и без проблем добавить третий признак - подчеркивание в альтернативном цвете, что позволит выводить на экране 8 различных начертаний символов. Для режима 40 символов вывод в режиме XOR отсутствует, что с ним делать в текстовом режиме не особо ясно, а графические режимы я не делал. Основная идея оптимизации была в том, чтобы снизить расход времени в NMI на сохранение регистров, для этого строки экрана были поделены на блоки по 8 или 16 символов. Обработчик NMI сохраняет регистр AX, читает куда записан символ, и если это тот же блок, то ничего не делает. Рисование блока будет произведено целиком, когда символы начнут выводиться в новый блок. Хорошо бы еще учитывать какие реально символы выводились, а незаконченный блок рисовать в обработчике прерывания от таймера, но пока этого не сделано. Для режима 80 символов блоки рисуются по 2 символа сразу. Для режима 40 символов сначала была добавлена табличка на 512 байт, для конвертирования шрифта, потом был сделан конвертированный шрифт в 4К, ну а в fast_nmi в целях эксперимента было сделано 12 копий шрифта для всех несовпадающих комбинаций цвета символа и фона. Еще был сделан resident, который должен ускорить рисование символов в других программах, но это относится только к программам, пишут напрямую в память. В NC при нажатии Ctrl+O, панельки скрываются вроде бы быстрей, а вот обратно видимо перечитывается список файлов с дискеты. Checkit зачем-то перехватывает int2, и реальную скорость рисования символов занижает раза в полтора, resident востанавливает int2 по таймеру, но checkit не работает в эмуляторе, поэтому, если у кого есть возможность - просьба проверить на реальном железе. Результаты в эмуляторе такие:
bios vs fast_nmi vs resident
268 vs 3406 vs 2909
1284 vs 4091
Если вернуться к варианту с таблицей в 512 байт, то в режиме 25x40 скорость упадёт раза в два, это тоже существенно быстрее, но упихать такую таблицу в ПЗУ будет не просто. А пока образ дискеты с тестовыми версиями:
Вложение 55014
Вы учтите такой момент, что процессор Поиск-1 работает на частоте 5МГц, причём цикл обращения к шине, если не было wait stat'тов, занимает 4 такта. Поэтому регенерация/вывод на экран должны быть "прозрачны" для процессора. Другое дело, что программная эмуляция режимов адаптера занимает много времени, это да.Цитата:
В документации на "поиск" встретил упоминание, что процессор для доступа к памяти получает только 8 тактов из 16, и при частоте 15МГц это даёт скорость доступа 937500 операций в секунду.