W_INC (with INC) значит с командами INC (HL), когда HL адресуется в порт. INC (HL) делает считывание из порта и тут же запись в него. Это работает на РК86, но не всегда работает на ОРИОНЕ, даже с тактом всего в 2.5 МГЦ. А при Z80 в ОРИОНЕ такт всегда 5 МГЦ, неважно сделана схема ТУРБО с WAIT (142%) или ТУРБО-200%. ВВ55 не любит когда два обращения в порт происходят сразу друг за другом. Нужна пауза между обращениями. Поэтому была применена условная трансляция, чтобы иметь оба варианта. По этим же соображениям многие константы были увеличены вдвое.Сообщение от Pyk
8000...83FF - ППА клавиатуры
8400...BFFF - доп.ОЗУ, переключаемое битами D0...D5 порта C доп.ППА
C000...DFFF - ВГ75
E000...EFFF - ВТ57 / ПЗУ с RK-DOS или другим кодом
F000...F0FF - РК-КНГМД (факультативно)
F100...F1FF - доп.ППА (тот что называется D14)
F200...F2FF - ВИ53 (факультативно)
F800...FFFF - ПДП/ПЗУ с ROM-BIOS
То, какое ОЗУ прокачивается в окне 8400...BFFF, зависит от физической реализации. Может быть совмещённое ОЗУ и две разных банки ОЗУ (РУ5+62256). Самый дешевый вариант это РУ5 и прокачка в окне 4-х сегментов из неё размером по 16К (хотя доступно лишь 15К из 16-ти). При этом отображаемые в окне 8400 сегменты с номерами 0 и 1 оказываются из основного ОЗУ с адресов 0400...3FFF и 4400...7FFF. Можно сделать так, чтобы при РУ5-тых было только два сегмента, т.е управление только битом D0, тогда это получается как будто есть 2 банки ОЗУ, одна - основное ОЗУ, другое - оконное, хотя физически всё в одной банке РУ5-тых. Но при РУ7-мых такой трюк не проходит, т.к 32К не являются половиной от 256К.
Но если ОЗУ - несовмещённое, т.е состоит из двух разных банок ОЗУ, то в окне 8400...BFFF никак не включить основное ОЗУ из РУ5-тых, там всегда включается ОЗУ из 62256 или W24257. Это программно может определить программа и соответственно назначить начальный адрес эл.диска, так что эл.диск не конфликтует с основным ОЗУ при любой физической конструкции.
В эмуляторе надо реализовать большое ОЗУ. А значит, это совмещённое ОЗУ в 288К с прокачкой всех 288 Кб в окне 8400...BFFF. Т.е сегменты 0 и 1 в окне 8400 должны быть совмещены с основным ОЗУ 0...7FFF. 288К, а не 256К потому что, из-за недоступности в окне в каждом куске в 16К участка в 1 кб, чтобы логически иметь 256К, физически надо иметь 288К, т.е 4 банки по 64К + ещё пол-банки 32К. А на реальном РК на РУ7-мых подпрограммами F836/39 в последней 3-тьей банке доступно лишь 48К из 64К, т.е всего 32+30*7=242К, что чуть больше, чем 241К физически доступных в ОРИОНЕ на РУ7-мых..
На реальном РК86 с РУ7 при чтении сегмента с номером 16 будет читаться кусок основного ОЗУ 0400...3FFF, т.к физически банки 4...7, 8...11, 12...15 и т.д, это тоже самое, что банки 0...3, т.к управление выбором сегмента только 4-мя битами (в КП11 всего 4 разряда).
Регистр, для пробы установленный по адресу F300, в эмуляторе B2M должен был переключать целую полубанку в адресах 0...7FFF, по принципу цельнобанковой коммутации ОРИОНА. Т.о при РУ5-тых получалось две полубанки, а при РУ7 - 8 полубанок.
Никто такого реально никогда не имел. Хотя реализация при РУ5 самая простейшая из всех доработок. Если для коммутации использовать бит PC1 ППА клавиатуры, то расход деталей - кусок проволоки. На адрес A15 у мультиплексора КП11 просто заводится бит. Сюжет заключается в том, что тогда есть доступ ко всему ОЗУ без потерь. Минусом такой архитектуры является то, что только подпрограммой из ПЗУ F800 можно читать и писать в дополнительных полубанках.
Однако иметь ОЗУ выше 8000 важнее, чем потеря ОЗУ в 6% при окне не кратном 8 Кб. Делать и окно на 8400 и цельно полу-банковую коммутацию по 32К одновременно - слишком громоздко. Хотя при наличии 62256, что включена двумя страницами в окне 8400...BFFF, имеющуюся на плате банку РУ5 разумно использовать целиком как две полубанки (т.к куска проволоки никому не жалко). Что даёт в сумме 94 (32+32+30) кб.
Атрибут RVV это ReVerseVideo и его всегда применяют для инверсии знакомест. А атрибуты HGLT, GPA1, GPA2 (General Purpose Attribute) могут использоваться произвольно. Во-первых одного атрибута для фонтов - мало. Считайте сами. Как минимум, нужен фонт для режима графики 192*100, нужен фонт с инверсией, нужен фонт КОИ-8 и базовый фонт. Поэтому управлять фонтами атрибутами не надо. Пусть атрибуты идут на цвет.
Управление инверсией атрибутом неудобно, т.к не позволяет использовать встроенный в ПЗУ драйвер вывода символов. В то время как инверсия за счёт фонта на порядок удобнее и проще. И главное позволяет иметь инверсные окна с рамками, что даёт программам совсем другой вид. Я использовал в своё время атрибут RVV для инверсии, но отказался. Но сама переделка для RVV на моём РК сделана и она ничему не мешала. И её надо иметь, потому что инверсия фонтом неполноценная и пригодна только для системных программ. Т.к число символов сокращается вдвое с 128 до 64 и остаются только латинские буквы.
У меня на реальном РК86 фонт в РФ2, т.е всего 2К. Изначально на РК с 60 кб для CP/M был фонт с матрицей 8*10 (только ASCII), но не было никакой совместимости. Впоследствии, я догадался как расширить ОЗУ в РК совместимо, вернул архитектуру РК и стал использовать фонт 8*8 с инверсией. Потому что старые игры РК рассчитаны на фонт высотой в 8 точек. Т.е при 2-х кб ПЗУ можно иметь на выбор, - или фонт 8*10 или два фонта 8*8, один из которых с инверсией. Но для эмулятора нет проблемы иметь фонт и в 4К и 8К, так что такой выбор не стоит. Иметь фонт 8*10 удобно только если в РК есть много фонтов, один из которых - базовый и высотой в 8 точек, чтобы иметь совместимость.
Фонт с инверсией у меня есть в ПЗУ реального РК, надо лишь перенести на PC, есть также где-то в виде листинга в исходнике эмулятора. Но пока нечего смотреть с фонтом с инверсией, т.к это использовано только в НОРТОН-ах, а они только для ДОС.
С трудом сделал ROM-BIOS для КР580 с подпрограммами F836/39. После выкидывания директивы X и стоп точки в директиве G, освободилось почти 90 байт. За счёт этого удалось уместить подпрограммы F836/39 и ввести 2 новые команды. Доп.информация в начале листинга. Используйте этот ROM-BIOS в эмуляторе B2M. Версию ROM-BIOS для Z80 тоже обновлю, т.к нашёл способ выиграть ещё несколько байт. Обращайте внимание на число просмотров и на дату упаковки архива, а также даты в исходниках. Если число просмотров для давно выложенного RAR-файла равно 0, значит этот архив был обновлён, т.к всё устаревшее или дохлое в выложенных ранее RAR-файлах я удаляю или заменяю.
- - - Добавлено - - -
Никто с этим спорить не может. Но "ещё не вечер"... Может быть и РК86 с дополнительным ОЗУ будет не хуже. Кстати, скажите, фонт в МИКРОШЕ более красивый 8*8 или её изготовители не додумались и оставили фонт такой же как в базовом РК - 6*8?
Люди пользуются реальной РК86, потому что её имеют. А в эмуляторе, потому что про РК86 что-то знают, а про МИКРОШУ и ПАРТНЁР никто ничего не знает, т.к это малораспространённые среди самодельщиков машины. Готовые промышленные ЭВМ покупали "отцы семейств", а радиолюбители РК86 делали себе сами. А так как на этом сайте больше радиолюбителей, то отсюда и "привязка" к РК86.
Хорошо, что Вы напомнили о МИКРОШЕ, т.к это связано с темой ПЗУ.
У меня программ от МИКРОШИ никогда не было, но в дистрибутиве EMU80 в 1999 я нашёл кучу программ от МИКРОШИ и убедился, что они не работают в моём эмуляторе РК86 на ОРИОНЕ, т.к в эмуляторе совсем иной код ПЗУ F800. Дело в том, что в МИКРОШЕ несовместимое с РК86 ПЗУ, даже по стандартным точкам. В частности WBOOT там не F86C, а F89D. Ну а внутренние точки вообще несовместимы, и также для МИКРОШИ полно глупых авторов, что лезут в нестантартные точки ПЗУ глубоко внутри ПЗУ F800. Идиотизм, ради экономии трёх байтов терять совместимсоть.
Обнаружил, что программы МИКРОШИ по большей части вообще наглые и неграмотные. Вместо того чтобы считать стек в HL и проверить старший байт, чтобы узнать ОЗУ 16К или 32К, там сдуру лезут в ПЗУ в то место где стоит команда LD SP,STACK и смотрят старший байт. Это идиотизм (что, кто-то не согласен?). Причём, т.к в РК86 и в МИКРОШЕ эти байты - в разных адресах, то сначала идиотским способом выясняется тип машины - это РК86 или МИКРОША?. Для чего смотрится куда идёт JMP с адреса F800. Если там стоит адрес F836, то это РК86, иначе - МИКРОША. Т.е программы МИКРОШИ сделанные универсальными, - "привязаны" к коду ПЗУ РК86.
Поэтому если использовать 100% совместимое, но не базовое ПЗУ F800, то программы МИКРОШИ успешно глюкаются на РК86. Исправление такой глупости конечно несложно, но неприятно. Теоретически, можно даже написать программку, которая ищет в коде программ МИКРОШИ команды которые считывают несколько популярных точек внутри ПЗУ F800, чтобы сделать вывод о том, МИКРОША это или РК86. Но вообще-то руки надо отрывать авторам таких программ. Всякий, кто "привязывается" к конкретному коду ПЗУ, - это явный "враг народа". Чтобы определить МИКРОША или РК86 надо тестировать где стоят В/У. Например, ППА легко определить. Также идентифицировать другие БИС несложно.
Ответить с цитированием