РАДИО-86РК на Z80

[barsik]

я написал чёрно-белую оболочку, а потом и раскрасил её

Посмотрел скрин-шот Вашей цветной оболочки для ДОС. Цвет на РК86 очень впечатляет. Увы у меня никогда цвета на РК не было (т.к монитор был монохром). А атрибут инверсии (по журналу 'Радиолюбитель' 1993) использовал. Но в итоге отказался от использования атрибутов, в пользу более простого решения, которое не только более удобно для программиста даёт инверсию, но и даёт нормальную псевдографику, что не менее важно. У меня тоже есть оболочка для квазидиска в 64К (из 2-х 62256, подключенных через ППА), причём с рамочками и окнами. И всё достигнуто благодаря наличию альтернативного фонта (расход деталей - кусок проволоки 10 см). А атрибут инверсии RVV выгодно использовать для переключения фонтов. Трёх остальных атрибутов (HLGT,GPA1,GPA2) хватает на 8 цветов.

В Вашей оболочке желательно было бы изменить режим дисплея, точнее изменить число линий растра на символьную строку. Сделать 8 линий растра вместо 10. Это позволяет выводить вертикальные линии без разрывов. При этом, при числе строк в 25, экран на 20% плющится по вертикали, но зато тогда можно выводить 28 строк и они будут видны. Чтобы избавиться от 2-х пустых линий между строками, есть и другое решение. Можно прошить в ПЗУ вместо фонта 6*8, фонт 6*10, что надо было сделать еще в 1988.

Можно сделать вывод и в 32 строки, но тогда экранную область придётся перенести в иное место. Если оставить экран в вершине ОЗУ, то бОльший размер экрана затрёт служебные ячейки ROM-BIOS (в области 7600) и подпрограмами ПЗУ нельзя будет пользоваться. В этом случае придётся в программе иметь копию стандартных подпрограмм ПЗУ F800 в области ОЗУ. И это выгоднее, чем делать как делают графические РК- игры, которые переносят экран ниже служебных ячеек 7500 (оставляя 7500...7600 для стека). Выгоднее потому-что для оболочки тогда остается всё ОЗУ за вычетом большого экрана и размера стандартных п/п-мм ПЗУ (это менее 1 кб кода). А в случае переноса экрана ради сохранения ячеек 7600 и возможности вызывать стандартные п/п-мы ПЗУ, свободное ОЗУ оказывается на 2 кб меньше. Что сокращает буфер копирования, который и так при размере оболочки в 7 кб (10 кб в случае CP/M и RK-DOS) маленький, что сокращает скорость копирования.

Для меня таких проблем не было, т.к на РК86 я всегда имел самую разумную доработку РК - дополнительное ОЗУ в области 8400...BFFF, т.е 15 кб. В котором прокачивались две страницы доп.ОЗУ по 15К (это ОЗУ просто открывается при РУ5-тых, а при РУ3-тьих ставится 1 корпус 62256). Без этого нельзя иметь ни пригодную к использованию CP/M, ни РК-ДОС с размером более 4К. Поэтому, если надо расширить экран в НОРТОН-е, то его выгоднее перенести в верхнее ОЗУ, где экран не мешает ни служебным ячейкам и не сокращает ОЗУ для буферов НОРТОНА.

Извиняюсь, что чуть не по теме, но хочу рассказать о моём представлении идеальной архитектуры для РК86, реализуемой на базовой плате за 1.5 часа работы паяльником (у меня почти всё это на плате уже давно реализовано)

Планирую иметь на своём РК86 Z80 и ОЗУ 94/124К следующим образом. Две пол-банки по 32К в адресах 0...7FFF на РУ5-тых и еще 30К на 62256 в окне 8400...BFFF. Но надеюсь, что мой РК86 потянет целых 2 штуки 62256 (или W24257) напаянные в 2 этажа. В РК86 всякая доп.нагрузка шины чревата большими проблемами с надёжностью. Но т.к дисковода у меня уже нет (все сдохли), то и РК-КНГМД подключать не надо, за счёт чего я поставлю 62256 (она уже ранее стояла на моей плате РК86 и панелька 28-ног распаяна).

Отчего я и надеюсь, что мой РК без КНГМД потянет на шине ещё две 62256. Конечно, при наличии буферов для РУ5-тых проблемы с перегрузкой шины отпали бы. Но увы, пока не нашлось ни одного крутого аппаратчика, который бы поставил в РК86 буфер для ОЗУ. Что собственно говоря должны были сделать сами авторы РК86, если были они не увлекались "фатальной минимизацией". Две штучки 589АП16 не намного увеличили бы стоимость РК86.

Цельно-полубанковая коммутация тоже удобна, т.к тогда программа работающая во второй пол-банке может использовать все 32К (а при дальнейшем развитии этой идеи и 64К). Экран отображается из пол-банки 0, а программа работает в пол-банке 1.

Без наличия Z80 реально поддержать такую архитектуру программой в ПЗУ нельзя, т.к там просто нет места. Но при наличии Z80 в ПЗУ освобождается 150 байт, куда без труда "засунется" всё что надо. Теоретически РК86 допускает установку второго ПЗУ на F000, но практически это неразумно, т.к нагружает шину и фатально снижает надёжность.

Как я понял, про то почему не работает предложенный ROM-BIOS для Z80 пока информации нет.

Сообщите про Вашу клавиатуру. Вдруг Вы используете ПЛИС, которые привязаны к входным точкам в ПЗУ. Такой метод подключения IBM клавиатуры тоже возможен. Тогда ПЛИС контроллирует доступ в адреса 8000...83FF и дополнительно контроллирует входные точки внутри ПЗУ.

Адреса перехвата п/п-мм ввода и вывода на МГ-ленту задаются в конфиге

Нашёл в конфиге РК86 такие строчки

cas : tape-recorder {
  biproc[FB98-FCA4]=rk
  boproc[FC46-FCA4]=rk

Как задать начальный адрес п/п-мм RDBYTE и WRBYTE из этого ясно. Но зачем указан интервал. Как я понял в этом интервале в РК86 размещаются именно эти подпрограммы (и никакой другой код с другим назначением). Но ведь указанные области перекрываются. Если перехватывать интервал, то как Вы отличаете когда ввод, а когда вывод? Я в подобном случае перехватывал только вход, а выход из процедуры (чтобы закрыть файл) делал по входу PUSK_VG (0FBCEH - это куда делается JMP из входной точки F82D).

То есть, если я делаю ROM-BIOS для Z80, то чтобы можно было его проверить в эмуляторе, я обязан полностью повторить код из ПЗУ РК86 (хотя теперь могу размещать RDBYTE и WRBYTE в любых местах ПЗУ).

Но что произойдёт, если мне надо (из экономии для JR-команд) вставить в этот интервал другую подпрограмму. Что, тогда по по входу в эту подпрограмму также произойдёт вылет в диалоговое окно выбора файла?

Интересно каким образом будет читаться звуковой WAV-файл (пусть и медленно), если я уберу эту строчку из конфига? Вероятно, тогда отлавливаются все чтения порта C (где бит магнитофона, а также биты отдельных кнопок УС, СС, РУСЛАТ), но как вы узнаёте, что читается МГ, а не спец.кнопки клавиатуры?

Автоматическое конвертирование .rk файлов в эмуляторе есть: нужно только при включении "воспроизведения" на тулбаре выбрать не .wav, а .rk.

Про возмоэность грузить реальные звуковые файлы *.WAV и даже DAT-файлы в формате файлы *.rk (это те, что почти GAM-формат Пыхонина, но без первого байта E6) я даже и не знал, т.к никакого ДОС-текста по эмулятору B2M до сих пор нет.

Я понял, что как-то эмулируется чтение с МГ (иначе как бы программы попадали в ОЗУ в бездисководном варианте), и попробовал по директиве I грузить GAM-файлы. И это получилось. Я и решил, что эмулятор поддерживает GAM-формат.

У меня есть записи программ РК86, СПЕЦИАЛИСТА и ОРИОНА в WAV-формате с частотой дискретизации 44 КГЦ. Могу ли я их загрузить в соответствующие эмуляторы B2M?