ПО. ПЭВМ "Ириша". Программирование для ИРИШИ на ассемблере.

Хотя раздел о программах для ИРИШИ, но перед тем как программы появляются, чтобы их можно было уже обсуждать на форуме, требуется чтобы эти программы кто-то написал. Потому логично в этом разделе обсуждать и то как писать программы для ИРИШИ.

Точнее, как писать программы в общем смысле и так многие знают, - это делается путём нажатия клавиш клавиатуры в определённом порядке, чтобы в итоге набрался исходный текст программы на каком нибудь языке программирования. После чего полученный исходник транслируется соответствующим компилятором и получается новая программа для ИРИШИ.

Но ИРИША имеет специфические архитектурные особенности (в частности, в отличие от всех других отечественных ЭВМ, ROM-BIOS ИРИШИ отстутствует в адресном пространстве программ, отчего для вызова стандартных входов ПЗУ приходится аппаратно переключать архитектуру). Программирование на разных ЯВУ имеет тоже свои особенности (применительно к ОС и архитектуре ИРИШИ).

Вот такие и подобные нюансы можно обсудить в этой теме, что может помочь программистам начать заниматься творчеством для ИРИШИ. Для начала рассмотрим как в программах использовать подпрограммы ПЗУ ИРИШИ.

Те программы ИРИШИ, которым не надо много ОЗУ обычно работают с адреса $4000. Такие программы при старте однократно и навсегда включают карту памяти 0, отчего в области 0...3FFF оказывается ПЗУ, и в дальнейшем уже не требуется коммутация карт памяти (т.к ОЗУ ниже $4000 не используется и ПЗУ включённое здесь не мешает).

ROM-BIOS ИРИШИ для отладки таких программ специально сделан так, чтобы отладчик мог работать и при включённом ПЗУ. После включения карты 0, архитектура напоминает ZX-Spectrum (там тоже ПЗУ до 4000), только экран в ИРИШЕ в старших адресах, а не над ПЗУ.

Т.о программы, которым весь объём сплошной памяти не нужен, удобно размещать с 4000. Тогда при старте программы включаем карту 0, отчего на адресах 0...3FFF появляется ROM-BIOS и становится доступным без коммутации архитектуры.

Вообще для работы программ требуется только ПЗУ CONOUT стоящее на 2000...3FFF. Т.к клавиатура аппаратная, то процедура её обслуживания предельно проста и ПЗУ BOOTM на адресах 0...1FFF совсем не нужно. Это позволяет в локальную магистраль включить крошечную платку расширения ОЗУ со статикой, которое коммутируется в окне 0...1FFF, но включено только в карте 0 вместо ненужного для программ ПЗУ BOOTM.

Ещё от МИКРО-80 повелось так, что программы для отечественных ЭВМ на КР580 используют стандартные входы в ROM-BIOS на адресах F803...F838 с шагом 3. Это позволяло обеспечить совместимость корректных программ для разных ЭВМ. К сожалению, авторы игр для ЮТ88, РК86 и МИКРО-80, сдуру для упрощения программирования, делали игры некорректными, работая с экраном и клавиатурой по железу. Потому впоследствии перенести на другие машины удалось лишь чисто системные железо-независимые программы типа редактор, ассемблер, отладчик, DOS и частично бейсик.

Тем не менее, все программисты для любительских 8-ми разрядок уже привыкли к такому набору подпрограмм в ROM-BIOS и этот же набор подпрограмм необходим для адаптации чисто системных программ от РК86 на ИРИШУ. Особой пользы от адаптации системных программ РК нет, но полезно для массовости, например, наличие на ИРИШЕ бейсика РК86, позволяет увидеть все 30 убогих бейсиковых РК-программ на ИРИШЕ.

Несколько бОльший интерес представляют игры от РК86 и других текстовых машин. К сожалению, буквально единицы игр РК являются корректными, т.е 95-ти процентам игр РК наличие совместимых входов не поможет.

Итак, для того, чтобы на ИРИШЕ смогла заработать какая-нибудь корректная программа от РК86 надо поиметь в ОЗУ набор подпрограмм (не обязательно по адресам на F800) аналогичный тем, что имеется в ПЗУ РК86.

Для некоторых программ и этого недостаточно, а надо имитировать ещё рабочие ячейки ПЗУ РК86. А именно, для некоторых наглых программ п/п-мма COUTC должна после каждого вывода менять экранные координаты в ячейках 7600/7602 (т.к программы их читают), а при выводе делать вывод по экранным координатам из этих ячеек (т.к есть наглые программы, что вместо стандартного метода смены координат курсора искейп-кодом 1B,59 нагло сами подставляют в эти ячейки экранные координаты курсора).

Этот набор подпрограмм невелик по объёму и подключение его к каждой адаптируемой программе не создаст больших потерь памяти и дискетного пространства. Однако всё-же выгоднее и этот набор РК-подобных подпрограмм переместить в ПЗУ. В ПЗУ ИРИШИ есть почти 2 кб пустоты, а точнее $7C0 байтов (а после выкидыша из ПЗУ разного ненужного хлама типа загрузки из сети, с двух дисководов, из ROM-дисков, поддержки запасных клавиатур и т.п, освобождается ещё полкило).

Тогда имея исходник любой корректной РК-программы, лишь только поменяв адреса стандартных подпрограмм в строках EQU можно без труда получить версию РК-программы пригодную для ИРИШИ. Понятно, что это работает только для корректных чисто текстовых программ. Игры практически все так не адаптировать, их надо существенно модернизировать или эмулировать.

По вышеуказанным причинам связанным с архитектурой ИРИШИ удобно программы РК перетранслировать на адрес 4000. Это имеет преимуществом то, что, как указано выше, тогда подпрограммы эмулирующие стандартные РК-входы можно прошить в ПЗУ ИРИШИ и не трахаться с подключением к каждой игре своего набора РК-подпрограмм.

Для программиста пишущего программу, стандартные входы - по функциям те же самые, что и на РК86, только они стоят не на F800, а в ПЗУ ИРИШИ (т.е ниже 4000). И тогда программисту даже знать об извращённой архитектуре ИРИШИ ничего не требуется. Т.е пишешь и отлаживаешь программу на РК86, а закончив меняешь ключ условной трансляции и второй раз транслируешь уже версию для ИРИШИ.

Кое-кто наглый, но очень сообразительный, возразит, что для РК-программ, что используют команды RST перетрансляция на адрес 4000 отличный от 0 невозможна. Это так, но авторы ПЗУ ИРИШИ были достаточно умны, чтобы оставить ячейки 0008...003A в ПЗУ пустыми. Хотя ума у них всё-же не хватило, чтобы заполнить эти ячейки кодом FF, а не нулями (из-за этого нельзя ПЗУ допрошить). Так вот прошив в ПЗУ на адреса 8, 10, 18... 38 джампы на адреса 4008, 4010, 4018... 4038, наличие в программе команд RST не помешает переносу на 4000.

Понятно, что есть программы, которые чтобы иметь максимальное свободное ОЗУ выгодно загружать с 0 (для чего ПЗУ ИРИШИ д.быть отключено из адресного пространства). Тогда для связи с иришиным ROM-BIOS надо размещать модуль связи выше RAMTOP.

Иметь все 18 подпрограмм из ПЗУ РК не требуется. Основной набор п/п-мм, что надо иметь для разработки в стиле РК и адаптации включает лишь следующие подпрограммы:

CONIN   F803
COUT_C  F809
STATUS  F812
HEX_A   F815
MSSG    F818
XF81B   F81B
ASKCUR  F81E
RD_SCR  F821
CHKSUM  F82A

Причём п/п-ммы запроса координат и чтения с экрана (ASKCUR и RD_SCR) почти никогда не используются (не видел таких игр), т.к проще посмотреть координаты прямо в раб.ячейках 7602 и считать байт из адреса, что хранится в ячейке 7600. Также удобно добавить сюда подпрограммы для управления режимами ИРИШИ и цветами, а также (полезные для отладки) подпрограммы вывода дампа и содержимого регистров.

Таким образом при наличии модуля РК-интерфейса (в ПЗУ или в ОЗУ без разницы) программирование текстовых программ для ИРИШИ не отличается от программирования корректных программ для РК86 (т.е таких программ, что не лезут нагло в экран и в матрицу клавиш).

Т.к мне тоже непривычен ROM-BIOS ИРИШИ, - ниже реальный модуль, что я использую при написании программ для ИРИШИ с адреса 4000, а также для перетрансляции на ИРИШУ корректных программ от других любительских компьютеров. Этот простейший модуль размером в 300 байт включается в программу с помощью INCLUDE или отдельно транслируется и добавляется при линковке.

Сюда добавлены некоторые нужные в работе подпрограммы. Например, подпрограмма вывода дампа. Со входа DUMPX она настраивается на ширину экрана текущего режима ИРИШИ (т.е в 40-ка символьном режиме выводит дамп по 8 байтов в ряду, а в 80-ти символьном по 16), а со входа DUMPIN можно задать размер дампируемой области (чтобы не заполнять весь экран, если надо посмотреть лишь несколько байт).

Подпрограммы для включения режимов MODEx можно усовершенствовать за счёт экзотических возможностей макро генерации, что есть в М80 (и нет в написанных любителями ассемблерах для Windows). Т.е можно создать макро команду с передаваемыми параметрами - N видео режима, число строк экрана (20 или 25), страница экрана и общеэкранный цвет. Тогда макрокоманда будет из параметров формировать нужные байты и подставлять в нужных местах управляющих строк.

Кстати, подобные развитые макро команды особенно удобны при цветном оконном драйвере. Тогда например для вывода окна с титрами, рамками и сообщением в нём (все разными цветами), в исходнике пишешь всего одну макрокоманду, указывая в ней более десятка оконных параметров, а она заменяется при генерации полсотней строк кода, что здорово экономит время программиста.

блок эмуляции стандартных РК-входов:

Вот выведенное приведённой подпрограммой дампа содержимое файла управления в режиме 3:

Для начала, необходимо поиметь CP/M или другую DOS. Т.к любой программе, будь то текстов редактор, граф.редактор, конвертор или редактор спрайтов надо куда-то писать выходные данные. Потому и нужна DOS.

Можно странслировать для ИРИШИ и иные DOS, чьи исходники есть. К сожалению, архитектура ИРИШИ даёт лишь 64 кб доп.ОЗУ, и если на реал ещё можно как-то извратившись, ОЗУ прибавить, то в чужой эмулятор уже ничего не прибавишь. В принципе задача эмулятора только проверка и отладка, для этого надеюсь, даже такого крошечного эл.диска в 64 кб хватит.

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

Несмотря на рекламированную прогрессивность диспетчера памяти ИРИШИ, на практике он не очень удобен для реальных задач.  Впрочем, приспособившись особых неудобств при программировании тоже не возникает. Более существенный минус в том, что его концепция изначально рассчитана всего лишь на 128 кб.

Прошивка карты в ИРИШЕ для данного диспетчера, похоже, выбрана как раз оптимальной. Впрочем, изменить прошивку 155РЕ3 карты памяти, даже если так можно было бы что-то улучшить, мы всё-равно не можем, - утратится совместимость.

Точнее прошивку можно изменить, но не по идее, а в том какое ОЗУ включено в конкретных окнах. Экран и ПЗУ мы передвинуть не можем, а вот все остальные 16-ти килобайтовые сегменты можно переключать на любую присутствующую в системе память. Программе без разницы откуда физически читается память сегментов, т.е нет препятствий тому, чтобы в каких либо или даже во всех сегментах памяти, кроме B2:C000 (где экран) включить вместо медленной вейтованной памяти быструю безвэйтовую.

Диспетчер памяти ИРИШИ поддерживает всего 128 кб ОЗУ - 64 кб базовой (целиком заполняющей карту 2) плюс ещё 64 кб дополнительной памяти, распределённой в картах 1 и 3). 128 кб с избытком достаточно для программ, но мало для электронного диска. Рассмотрим какие есть другие варианты по использованию имеющегося диспетчера ОЗУ.

В базовой ИРИШЕ есть 4 дырки в адресном пространстве. Каждая дырка занимает 16 кб в картах 1 и 3 в адресах с $4000 и с $C000. Что желательно поиметь?

Во-первых, желательно поиметь сплошное ОЗУ в 64 кб, т.е нужна одна карта памяти в которой нет ни ПЗУ, ни экранной области. Пусть это будет карта 1. Сплошные 64 кб нужны чтобы поиметь CP/M с высоким TPA. Высокий TPA позволяет запускать все программы для CP/M, в том числе и те компиляторы, что хотят иметь не менее 52 кб. Хотя читал, что есть компиляторы, которые хотят иметь TPA аж в 62 кб. Это, конечно, возможно лишь когда весь прогоняемый код CP/M перенесён в другую банку (или включается в окне), а в банке для программ оставлены только входы в BDOS и BIOS.

С другой стороны, сейчас уже не средневековье, потому на самой 8-ми разрядке программы разрабатывают только самые фанатичные, да и то, если им хватает быстродействия, есть удобная клавиатура и качественный дисплей. Остальные предпочитают набирать и транслировать тексты на IBM PC, т.к, как бы ни были хороши апп.возможности 8-ми разрядки, у IBM PC они на порядки лучше.

А главное отлаживать намного удобнее в эмуляторе. Тут 8-ми разрядка, даже если в ней реальный такт 10 МГЦ и экран VGA не может предложить ничего похожего. При этом правда есть один минус - для проверки надо программы пересылать на реал, что хлопотно. И ещё возникает проблема, что когда эмулятор чужой, то он не отражает конкретный реал.

Потому требование иметь высокий TPA сейчас не очень весомо. Т.к компилировать на ИРИШЕ вряд-ли кто будет. Сами подумайте, программа на ассемблере с исходником всего в 100 кб транслируется и линкуется на медленном дисководе 3-5 минут (причём при сильном износе дискет). С эл.диском - чуть веселее, в несколько раз быстрее. А компиляторы ЯВУ при большом исходнике компилируют ещё раза в 2-3 дольше. Тогда как на PC это происходит мгновенно.

CP/M с низким TPA получаем в базовой основной карте памяти 2, где область C000...FFFF уже занимает экран. Т.е уже изначально получается CP/M на 48 кб. Если подкачку делать из ПЗУ (например из иришкиного ROM-диска), то можно поиметь CP/M с уровнем TPA в 40...42 кб. Не особо много программ с размером более 40 кб, хотя для серъёзной программы всего 40 кб памяти это стеснительно.

Итак банку 1 отдали для программ желающих иметь 64 кб. Остаётся банка 3, тоже с двумя дырками. Разумно дырку с C000 отдать под различное дополнительное железо (например, здесь можно включать экранный буфер платы текстового адаптера или буфер быстрого КНГМД с ПДП). А  дырку 4000...7FFF разумно использовать как окно, через которое будет прокачиваться большое ОЗУ, например 1 мб. На котором и будет организован эл.диск на реале. Так (в сегменте K3:4000...7FFF) можно поставить в ИРИШУ SIMM-30 на 1 мб. Быстродействие этой памяти не особо важно, т.е оно может быть тормозным и непрозрачным без особо неприятных последствий.

В эмуляторе мне доступно всего 128 кб. Это позволило получить CP/M с эл.диском из ОЗУ с размером ровно 64 кб. Но контрольные суммы секторов и код подкачки пришлось хранить в банке CP/M, отчего уровень TPA получился всего $9600 (38.5 кб). Этого пока достаточно, т.к пока нет программ большего размера.

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

Кстати, по тому, что в качестве управляющих битов диспетчера ОЗУ выбрали биты D3,D2, а не D1,D0 сразу ясно, что разработку железа ИРИШИ вели не программисты. Это заставляет тратить время, сдвигать биты, сохранять регистры... А в итоге, т.к переключение карты делается побайтово, т.е для каждого байта читаемого из эл.диска делается переключение карты памяти, то возникает торможение. Пока я просто использовал старые исходники от ОРИОНА, где обмен с банками побайтовый.

А в ИРИШЕ п/п-мма чтения записи байта из эл.диска получается раза в 3 дольше, сама ИРИША в 3.5 раза тормознее, чем ОРИОН на Z80. В итоге скорость обмена с эл.диском получается в 10 раз медленнее, чем на ОРИОНЕ. Впоследствии я смогу это ускорить раза в 2-3, заменив побайтовый обмен на посекторный. Тогда сектор 128 байт будет читаться в буфер, на что понадобится всего 2 коммутации карты. Но потеря всё-равно возникнет из-за необходимости пересылки сектора из буфера на DMA.

Пока сделал только стартовый вариант CP/M с TPA $9600. Да и это лишь для эмулятора получилось столько сравнительно много TPA. Потому что для эмулятора не надо поддерживать ни винчестер, ни РК-КНГМД, потому для эл.диска CPM-BIOS имеет крошечный размер всего в $400. А когда в него (строкой INCLUDE) добавить подпрограммы для винчестера, дисковода, дисковый буфер равный размеру физ.сектора (что 512 байт для винта и РК-КНГМД и 1 кб для КНГМД на ВГ93), то TPA ещё усохнет где-то до всего лишь ~34 кб.

Это из-за подкачки CCP+BDOS из ОЗУ этой же карты я теряю впустую $1600. Потому чуть позже, убрав буфер подкачки и буфер КС, смогу поднять TPA в карте 2 ещё на ~6 кб. Но пока просто нет смысла. Т.к из-за идиотического монитора ИРИШИ, не могу загрузить с МГ-ленты файл размером более $5000 (т.е сейчас CP/M-программу или исходник размером более 20 кб просто не загрузить в эмулятор, а даже крошечный MBASIC имеет бОльший размер). Приходится программы размером более 20 кб разбивать на половинки, грузить по частям в эмулятор, а там склеивать их на адресе $100.

Это потому что идиотский иришин монитор ниже $4000 не грузит, а выше $9000 тоже загрузить нельзя, т.к на $9000 располагается сам этот монитор (полученный из DDT). По этим же соображениям, а также из-за мизерности ОЗУ, не нужна CP/M с высоким TPA, - т.к тогда при общем ОЗУ всего в 128 кб эл.диск станет совсем крошечным.

Вообще, теоретически максимальный TPA в карте 2 для только эл.диска возможно рассчитать так. CP/M-BIOS займет порядка $600, а CP/M-BDOS имеет размер в $E00. Итого, отнимаем эти цифры от RAMTOP= $C000 и получаем $AC00, т.е ровно 43 кб. С учётом того, что TPA начинается с $0100 и запаса на расширение искейп-кодов получаем TPA в 42 кб.

Это теоретически максимальный TPA, что можно поиметь в карте 2. Но в реале подпрограммы винта или флопа, а также буфер чтения физического сектора отнимут ещё как минимум 2 кб. Так и получается, что CP/M ИРИШИ в карте 2 для реала будет иметь TPA в 40 кб. Для Паскаля это кажется не хватит, для BDS C точно не хватит. Хватит только для PL/M и ассемблера.

Ещё есть какой-то форт (техно-форт для CP/M одного ленинградского кооператива из 1991), но хрен поймёшь, как им пользоваться (он сложный, даёт объём кода слишком большой, потому нет смысла с ним связываться, хотя некоторые программы ИРИШИ были написаны на форте, в частности обслуга прошивателя РПЗУ). Но всё что я знаю про форт, это то, что по команде WORDS выдаётся список слов-определений, а выход из форта командой BYE.

В качестве исходного листинга для CP/M взял самый древний исходник, что нашёл. Т.к в более свежих пришлось бы трахаться с отковыриванием Z80 команд. А Z80-команды удобно отковыривать только в EMU80, а в EMU неудобно (да и с EMU80 я трахался 3 дня пока отчистил от Z80-кодов CP/M для Специалиста).

В EMU даже по команде HALT нет вылета в отладчик эмулятора, как сделано в EMU80, что удручает. Также содержимое памяти в других сегментах не посмотришь. В общем с отладчиком EMU отлаживать программы ИРИШИ работающие на несколько банок не очень удобно. А приличные программные отладчики только для Z80.

Для ИРИШИ полезно написать свой программный отладчик изначально ориентированный на отладку программ на ИРИШЕ в карте 2. Его основной код будет в карте 1, а в карте 2, где отлаживаемая программа, останется только ловушка по RST и модуль связи. Это позволит отлаживать программы рассчитанные на полное использование TPA.

Неудобство заключается в том, что все эмуляторы (кроме моих) не рассчитаны на удобство работы с эмулированным дисководом. Потому в них существует неудобство попадания программ в эмулятор, чтобы заполнить ими эл.диск или эмулируемую дискету. Одно дело загрузить и тут же запустить игрушку, чтобы посмотреть, а другое дело всякий раз вручную командами грузить и вручную командами сохранять на диске целый пакет. Пока делал это через магнитофон и ROM-диск. Проблема, что в чужой эмулятор никак не добавить доп.ОЗУ более 64 кб, а для RAM-диска этого очень мало. Может для ОКЕАНА в 1985 году и для ОРИОНА в 1990 этого хватало, но для хоть какой-то практической работы этого явно мало.

Потому для CP/M предназначенной для отладки программ в эмуляторе возможно будет такая концепция. По сбросу будет стартовать программа загрузчик CP/M из ROM-BIOS-а (размером до 2 кб, т.к там свободно именно столько). Этот загрузчик будет грузить CP/M из ROM-диска. В этой CP/M будет два привода. Привод A: - это 64К RAM-диск, и ещё ~50 кб будет R/O-привод B: (на базе ROM-диска), в котором будут храниться резидентные CP/M-программы (например, компилятор PLMX, т.к он работает только в реальной CP/M, не работает в CP/M-эмуляторе на MSDOS). А также резидентно надо хранить какое-то программное средство, чтобы грузить файлы ( откуда-то) и нортон.

Но лучше всё-же придумать способ как обойти ограничения схемотехники ИРИШИ и расширить ОЗУ выше 128 кб. Не обязательно в виде ОЗУ в самом адресном пространстве, можно и в виде блоков ОЗУ из статики, читаемых через ППА (для эл.диска это без разницы).

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

Хотелось бы знать как эмулятор поддерживает ROM-диск, а точнее можно ли ему подсунуть файл с размером больше, чем 64 кб. Т.е, что он выдаст после 65535 считываний из порта $14. Если указатель (что заменяет счётчики 155ИЕ7 на плате реала) обнуляется после $FFFF, то объём более 64К ROM-диска эмулятор не поддерживает. Если не обнуляется, то можно R/O привод B: сделать большИм, 128 кб или даже аж 256 кб.

А вообще и в реале ROM-диск разумно расширить до 128 кб. В реале это просто получить, если напаять на иришином ROM-диске где-то вторым этажом триггер, чтобы на нём вырабатывался адрес ПЗУ A16. В 128 кб уже можно что-то полезное уместить. Даже компилятор какой-нибудь убогинький.

Например, пакет BASCOM без документации умещается всего в 150 кб. Но бейсик даже компилятор - это нехорошо для ИРИШИ, т.к BASCOM даёт в 1.5 раза более массивный код и во столько же тормознее, чем Паскаль или Си. А лучше всего для ИРИШИ, конечно, PLMX, т.к код из под него в несколько раз быстрее кода от всех остальных ЯВУ.

Но PLMX для работы тоже требует эл.диска, минимум, 150 кб. Вскоре собираюсь заняться PL/M, хотя, входное сопротивление мозга сильно увеличилось, даже еле-еле Паскаль сумел вспомнить, а уж на освоение чего-то нового серых клеточек может хватит (тем более что не нашёл хоть каких-то учебников, есть только описания языка и примеры программ).

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

Приличного нортона для CP/M тоже пока нет. На импортных сайтах видел один корректный нортон, но он написан для высокого TPA и Z80. А нортон DS.COM из 1991, хоть и корректный, но почти убожество, хотя на безрыбье я в 1992 году был и ему рад.

Собираюсь написать, но вряд-ли корректный нортон (т.е, что пригоден для любой CP/M с TPA ~38...40 кб). Он будет некорректным, - хотя бы потому, что рамы придётся чертить по железу, иначе на скоростях ИРИШИ будет медленно. В эмуляторе ИРИШИ я задаю скорость 5 МГЦ, т.е на базовой ИРИШЕ будет примерно в 5 раз медленнее. Может быть даже объединю написание нортона с изучением PL/M, - начну писать нортон на PL/M.

Написание CP/M-нортона на ассемблере с нуля и без опыта - это ~месяц (по крайней мере так было у меня, у кого-то быстрее). А если есть где взять процедуры для всех операций, то делать заново надо только интерфейс, а это работа на 15...20 часов. Так много потому, что я давно не занимался подобными делами, а главное некоторые процедуры придётся отдирать от глюкала другой графической машины, написанного для грамотного оконного драйвера, т.е по сути придётся писать оконный интерфейс. Впрочем в ИРИШЕ уже есть неплохой драйвер, почти всё нужное даёт, даже нет смысла писать свой драйвер.

https://yadi.sk/d/nHNYFCMLQf6p_Q Вот скриншоты из эмулятора, чтобы было ясно как утомительны эмуляторы не поддерживающие автозагрузку файлов в приводы разных DOS. Понятно, что эмулятор не может знать устройство привода конкретной DOS или даже хотя-бы формат диска. Поэтому грамотный эмулятор предоставляет самой DOS 8-ми разрядки загрузить свой привод файлами при старте DOS. Для этого эмулятор имеет функции, - входы доступные для вызова из программы 8-ми разрядки.

В частности в моих эмуляторах ОРИОНА программа передаёт эмулятору порядковый номер файла, номер банки, адрес куда грузить и вершину до которой можно грузить файл. И чтобы в привод загрузились нужные программы, пользователю достаточно просто поместить их в отдельный каталог, т.е папку на винчестере PC и после запуска DOS в эмуляторе все файлы оттуда автоматически окажутся внутри эмулятора в эмулируемом диске DOS. После старта они окажутся загруженными. http://ipic.su/img/img7/fs/CPMORIONA.1556178170.png

А эмуляторы EMU и EMU80 ничего подобного не делают, а поддерживают только магнитофон и образ CP/M-диска. С магнитофоном можно повеситься пока загрузишь по одному файлу, а образ диска замучишься вручную компоновавши всякий раз, когда надо с диска взять или поместить туда другой файл. И к тому же DOS не одна, а много. Да и зачем хранить миллионы образов дисков (причём взглядом даже не видно их содержимое), если в архиве достаточно хранить всего одну копию файла. Потому моя концепция позволяет реально пользоваться любыми DOS в эмуляторе, а концепции чужих DOS пригодны только для запуска в эмуляторе игрушек отдельными файлами.

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

Т.к загрузка файлов через магнитофон затрахала и при отладке это сжирает много времени (т.к при разработке я делаю перетрансляции как можно чаще), стОило бы заняться ROM-диском. Хотя сначала ещё решаю в каком формате ему лучше быть.

Идеально было бы прямо в формате CP/M, но тогда надо иметь компоновщик, что из отдельных файлов компонует то, что прошивается в ROM-диск. А главное, CP/M читает не массивом, а посекторно, а с учётом долгой процедуры позиционирования на нужное место в ROM-диске это тормознёт. Кстати, ROM-диск в другом формате (т.е не в формате меню ИРИШИ) не вызывает конфликта с встроенной в ИРИШУ его поддержкой, достаточно первый байт ROM-диска оставить $FF и ИРИША решает, что ROM-диска в системе нет.

Можно использовать формат ORDOS. Это позволит удобно компоновать файлы для прошивки и грузиться это бутет не посекторно, а целым файлом (что важно, если ROM-диск существенно будет расширен до 128 кб). Тогда CP/M-нортон должен выполнять функции LORD, т.е иметь возможность копировать файлы из ROM-диска на диск CP/M (или другой DOS) и в DOS запускать программы прямо из ROM-диска.

Такой вариант мне пока нравится больше, т.к проще, быстрее работает и более универсален, чем непосредственно формат CP/M в ROM-диске. А для начала можно нацарапать что-то типа 'ROM-Service' для Специалиста. Это то же стартовое меню, по типу иришиного, т.е просто запускалка файлов, только с рамкой и указателем на программу балкой подсветки. Это имеет смысл, т.к тогда можно запускать файлы из ROM-диска не имея CP/M, что и имеет место, когда в ИРИШЕ всего 64 кб и нет даже дисковода и ценно, что такую простую запускалку можно уместить в 2 кб, что свободны в первом ПЗУ ИРИШИ.

Конечно, удобнее всего было бы иметь в эмуляторе, как и в реале, страничное расширение резидентного на плате ЦП ПЗУ, управляемое портом $18, куда можно уместить любые загрузчики и DOS-ы, но увы, в чужом эмуляторе ничего не изменишь.

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

Пока нет удобной оперативной компоновки ROM-диска (типа того, что в BAT-файле которым делается компиляция разрабатываемой программы последней строкой вызывается компоновщик ROM-диска, который автоматически вставляет только что странслированную отлаживаемую программу в ROM-диск), т.е пока нет никакого сервиса для программиста, приходится вводить файлы в эмулятор через магнитофон. Это паршиво, потому, что в мониторе ИРИШИ формат ввода идиотский (не передать имя файла и надо помнить адреса ввода и длину блока).

Потому, пока в качестве вспомогательной меры себе, переделал отладчик ИРИШИ, чтобы стал удобнее, а также добавил в него несколько новых директив. Теперь отладчик работает только в режиме 80 символов в строке и выводит флаги и регистры в одну строку, что удобнее при трассировке и нагляднее при отладке.

Кроме того, я переместил отладчик под вершину RAMTOP карты 2, т.е на адрес $B000. А в оригинале было $9000, что ни то ни сё, практически посередине памяти и впустую терялись верхние 8 кб (A000...BFFF), а главное это ограничивало максимальный размер вводимого МГ-файла в 20 кб, что глупо, имея, как минимум, 48 кб доступные для программ. Теперь ограничение на размер файла поднялось до $4000...$B000 (это 28 кб, хотя на самом деле чуть меньше, т.к служ.ячейки и стек я поместил сразу под $B000, выше-то места нет).

Также ввёл директиву 'K', аналогичную директиве Специалиста. Она считает контрольную сумму по стандарту РК86. Что мне было надо при отладке эл.диска, чтобы убедиться, что файл записываемый на эл.диск и считанный с него идентичны. А теперь для облегчения себе ввода CP/M-файлов с магнитофона ввёл директиву 'Y'. Эта директива позволяет вводить файлы в ОЗУ ниже $4000. Конечно не напрямую, т.к это в ИРИШЕ невозможно.

Потому-что в ИРИШЕ ввод с ленты может делать только программа в ПЗУ, т.к программа в ОЗУ тормозится непредсказуемым образом, в то время как программа в ПЗУ прогоняется на полной скорости в 1.77 МГЦ. Отчего МГ-ввод происходит в карте 0 программой в ПЗУ, которое стоит в адресах 0...3FFF. Потому-то ввод напрямую в ОЗУ ниже $4000 невозможен.

Из-за этого пришлось извращаться. Директива Y имеет один параметр - размер файла. Это то же самое число, что вводится вторым параметром в директиве R. Первый параметр директивы R, т.е адрес загрузки для директивы Y не нужен. Она всегда вводит блок на адрес $4000. По окончании ввода, директива просто перекидывает файл с адреса $4000 на адрес $100, чтобы затем загрузив CP/M можно было сделать 'SAVE nnn FILNAM.TYP' на диск. С оригинальным отладчиком мне приходилось пересылку на $100 делать вручную директивой пересылки блоков по ОЗУ.

Попозже я ещё подумаю и возможно автоматизирую и набор команды SAVE (используя AUTOEXEC.SUB, что естественно есть во всех моих версиях CP/M с 1992). Тогда сразу по вводу CP/M введённая с ленты программа автоматически сама запишется на диск.

Директива Y это конечно полумера, но на безрыбье... даже такая фигня облегчает мне немного жизнь, экономит время. Вскоре сделаю программу TAPE для CP/M, которая будет читать с МГ-ленты файл и по окончании ввода записывать его на CP/M диск. Причём, если это файл в специальном формате (что определяется по сигнатуре в начале), то запись на диск будет автоматической, причём в цикле (т.е файл за файлом без участия оператора). Если введён просто блок, то имя файла запрашивается, а если по сигнатуре выяснено, что это специальный формат для CP/M, то имя файла для записи на диск берётся из самого блока и оператору не надо его вводить.

Понятно, что в эмуляторе (по крайней мере в эмуляторе EMU) полная автоматизация не получится, т.к и поддержка ленты в виде одного многофайлового массива в этом эмуляторе отсутствует. Потому всякий раз будет открываться окно и запрашиваться имя очередного файла для ввода с винчестера IBM PC.

К сожалению, подобные магнитофонные эмуляторы, не рассчитанные на поддержку DOS, не могут передать 8-ми разрядной программе имя считанного файла или получить от неё имя файла подлежащего загрузке, отчего эмулятор не может полноценно эмулировать дисковую систему, а вынужден эмулировать образ диска, что не только дико неудобно, но даже возможно сложнее в реализации (особенно, если извращаться до полного предела и эмулировать времянки дискового устройства).

В саму CP/M (точнее в CCP CP/M) возможно введу ещё одну команду LDX, она будет читать с МГ-ленты на адрес $100 файл жёстко фиксированного размера (16 кб) и сразу по окончании ввода стартовать его. Это позволит запускать компилятор не из эл.диска, а как бы из другого диска, что оставляет весь объём эл.диска для исходника.

Я пользуюсь эмулятором ИРИШИ с заданным в нём процессором Z80 на такте 4 МГЦ, потому уже исковеркал ROM-BIOS ИРИШИ под свои нужны (виртуальное ПЗУ менять не проблема). И всё конечно было переписано на Z80. И отладчик естественно был на Z80. По счастью я не использую индексные и альтернативные регистры Z80 (чтобы когда понадобится легко было переделать под КР580). Потому, по крайней мере от отладчика, сумел отскоблить Z80-команды (и то пришлось трахаться 2 часа, EMU сдуру не позволяет определять недопустимые коды и просто виснет, приходится долго трассировать, чтобы вычислить пропущенную Z80-команду).

Правильно в эмуляторе давать возможность пользователю выбрать прогонять-ли недопустимые команды как в реале или останавливать прогон с выходом в отладчик эмулятора. Иначе придётся писать специальную программу трассер позволяющую находить недопустимые команды.

Хотя в отладчике JR-команды я ставил лишь там, где сразу было очевидно, что переход недалеко и не оптимизировал, но и то замена лишь JR на JP увеличила объём кода на 170 байт. Из-за чего объём кода версии для КР580 превысил $FF0, что есть в ИРИШЕ для отладчика. Потому пришлось убрать директиву R с автозапуском (сейчас уже уплющил отладчик и влезло, теперь по R без параметров грузится и стартует лишь одна конкретная CP/M - на $7000 с размером $1D80, или любая другая программа того же размера на тех же адресах)

В итоге странслировал версию ПЗУ для КР580. Она полностью идентична журнальной прошивке из МПСС (я пользуюсь только родной прошивкой, не краснокнижной, она не нужна), но отладчик в ней, что прошит в ПЗУ-0 на адресах $800...$1800 - другой, тот, что выше описан. Работает на КР580. Отличие лишь в том, что отладчик чуть изменён - всё переделано под режим 80 символов (флаги сделаны более наглядно), все имеющиеся директивы те же самые. Добавлены ещё две вышеупомянутые директивы K, Y и директива R без параметров грузит CP/M для карты 2 (где возможна лишь CP/M с низким TPA).

Вот такое ПЗУ https://yadi.sk/d/1jhv5JLkgfju7g. Его просто кладёте в каталог IRISHA вместо имеющегося файла с ROM-BIOS или прошиваете в реальное ПЗУ.

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

Для пользования CP/M программами я в качестве расширения к файлам (в каталоге откуда эмулятор грузит CP/M-программы) приписал их длину в байтах, чтобы сразу видеть их длину. Для загрузки в эл.диск, например повера для КР580 PW.COM (есть и повер, что только для Z80) пишем Y3A00<ВК> (т.к длина файла PW.COM равна $3A00) и в открывшемся окне эмулятора для загрузки файла выбираем PW.COM. Затем для запуска CP/M вводим R<ВК> и для загрузки выбираем файл CPM.DAT (это CP/M стартующая на $7000, после старта она перекидывает себя под вершину ОЗУ, сразу туда загрузить нельзя, т.к там расположен монитор, который и делает загрузку с ленты). После чего оказываемся в CP/M. Если эл.диск ещё не форматирован, то он форматируется. После выхода на промпт, для записи PW.COM на диск пришем SAVE 58 PW.COM. После чего повер уже можно запускать на исполнение.

Чтобы воспользоваться CP/M на реальной ИРИШЕ или в эмуляторе EMU сначала ознакомьтесь с литературой по предмету вот здесь https://yadi.sk/d/_0QoRc_wkH_BUA.

Затем скачиваете всё вот отсюда https://yadi.sk/d/JmiL1xBjGyzjGg. Файлы из подкаталов копируете в те каталоги, что указано в каталог эмулятора EMU (файлы из config в config и т.д). Файлы из каталога PROG копируете туда, откуда вы привыкли обычно грузить в эмуляторе, но удобнее всего скопировать целиком каталог PROG в папку 'irisha'. Оттуда и будете грузить CP/M-файлы директивой Ynnnn монитора (nnnn это размер файла, его всегда надо указывать, так уж сделан эмулятор, он перехватывает только подпрограмму МГ-ввода на $0040). В папке PROG лишь некоторые обычные CP/M-файлы, что я проверил на то, что им хватает низкого TPA.

В этой CP/M, как обычно, поддерживается AUTOEXEC.SUB и есть RST-входы, как и во всех моих версиях CP/M для ОРИОНА. RST-входы упрощают программирование.

Например, RST 18H выводит текст, что стоИт сразу после команды RST. Стоп байт - 0 или символ с выставленным старшим битом (потому RST 18 не позволит Вам выводить КОИ-8, но если надо, то не проблема, забиваете один бит в одном месте и можете выводить КОИ-8 ). Т.е это аналог MSSGH в фирменных программах CP/M (грамотные вражеские ассемблеры позволяют задавать ASCII-строки с выставленным старшим битом в последнем символе строки). Кому надо, тот сам зыркнет отладчиком входы 0008/0010/0018.../0038 или можно почитать описание ACP/M V1.60 из 1994.

Недавно сообразил, как расширить ОЗУ совместимым способом. Причем не только так, что реализуемо в реале, но, главное таким способом, что то же самое можно поиметь и в эмуляторе EMU (без его переделки, лишь изменением конфига в редакторе). Пусть вариант и не идельный, но зато уже вскоре сделаю версию CP/M с эл.диском в 256 кб, этого хватит для всех компиляторов. И при этом уже можно будет сделать версию CP/M с высоким TPA, отчего будут работать все компиляторы ЯВУ и другие программы, что нуждаются в TPA в 56 кб.

Спойлер:

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

Программы для базовой ИРИШИ работают в карте 2. При этом, естественно, для вызова стандартных подпрограмм эпизодически включается и карта 0. Карта 0 отличается от карты 2 всего лишь тем, что в ней в участке памяти 0...3FFF включено не ОЗУ, а ПЗУ содержащее ROM-BIOS. Как указано выше, иногда, если память ниже 4000 не нужна, то программа может включить карту 0 на-постоянно и работать в ней, - это проще, отпадает коммутация карт памяти при вызове стандартных подпрограмм ПЗУ.

В карте 2 для программ есть 48 кб (0...BFFF), а область выше C000 занята экраном. Если кто-то знаком с радиолюбительским компьютером ОРИОН-128 (он был опубликован в ж.РАДИО и имел большую популярность у сельских жителей СССР), тот может заметить, что его архитектура в банке 0, для пользовательской программы идентична. Там тоже для программ остаётся только 48 кб памяти ниже C000.

99.9 % программ для ОРИОНА как-раз работают в банке 0 (в банке 1 работает только монохромная CP/M, которой надо 60 кб). Без CP/M остальные банки ОРИОНА используются в виде так называемых квази-дисков по 60 кб ОС ORDOS, которая изначально имеет предельно порочную концепцию (набор функций), ограничивающую размер диска в 64 кб (что мешает иметь один сплошной квазидиск на 180 кб или более).

И почти всё системное ПО ОРИОНА использует квазидиски по 60 кб из доп.банок ОЗУ. Увы, ни у кого не хватило ума придумать способ, как обойти ограничения ORDOS и сделать совместимую с ней ОС, но имеющую бОльшие диски (а это реально можно было сделать). Кстати, были, как минимум четыре ОС, которые были сделаны в то время для ОРИОНА и давали квазидиск в 180 кб, но эти DOS были никак не совместимы с ORDOS.

Таким образом на базовую ИРИШУ, у которой кроме базовых 48 кб нет другого ОЗУ, не имеет никакого смысла адаптировать системное ПО от ОРИОНА, т.к не из чего организовать квазидиск (если не добавлять какой-нибудь внешний эл.диск). Хотя системное ПО для ORDOS не представляет большого практического интереса в плане адаптации на ИРИШУ, но на безрыбье и рак рыба. К сожалению, корректными являются очень небольшое число программ ОРИОНА.

Из-за отсутствия в ROM-BIOS ОРИОНА нормального драйвера для графической машины, большинство даже системных программ ОРИОНА нагло лезет в экран ОРИОНА. А т.к поддержки цвета в ROM-BIOS там вообще нет (что явная глупость для цветного компьютера), то и для вывода в цвете, в программах ОРИОНА используется прямая работа по "железу". Потому ни одну программу ОРИОНА, выводящую рамки или использующую цвет нельзя без кардинальной переделки её 70 процентов кода адаптировать для другого компьютера. Т.е ОРИОН в качестве донора программ плохо подходит.

По сути корректными по работе с экраном являются только сама ОС ORDOS, ассемблер для ORDOS, дизассемблер ORDOS и, если не использовать графические операторы, бейсик ОРИОНА. А даже текстовые редакторы ОРИОНА нагло лезут в экран, графический редактор, естественно, тоже. Хотя текстов редактор SCREEN несложно адаптировать, т.к в нём по железу работает только ролик экрана (его пришлось ввести, т.к он делается стеком, потому намного быстрее, чем п/п-мма в ПЗУ).

Адаптация корректных программ легка, достаточно отредактировать вызовы ПЗУ (добавив в конце программ код эмулирующий входы ПЗУ ОРИОНА). Но даже перечисленные программы имеет смысл адаптировать только, если в ИРИШУ добавлено доп.ОЗУ, как минимум ещё 64 кб. Тогда из этого доп.ОЗУ организуется квазидиск на 64 кб, из которого программы для ORDOS могут читать/писать файлы.

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

Если для какого-либо отечественного бытового компьютера используются его варианты оснащённые как процессором Z80, так и антикварным процессором КР580, то правильно всегда делать программы в двух версиях - одну для КР580, другую для Z80, а также встраивать во все программы для Z80 в начале кода процедуру проверки, что процессор действительно Z80.

Для программиста процессор Z80 отличается несущественно. Именно потому программы для Z80, если не считать JR-команды почти на 100% состоят из команд КР580. И именно потому игры для Z80, пусть и с утомительным электротрахом, возможно переделывать в программы для КР580. Это убедительно доказал факт переделки под КР580 более 30 ZX-игр. Причём эти работы были сделаны ещё в 80-тые годы, когда конвертирующий игру программист любитель не только не имел дисковода, но даже простейшего инструментария (он был лишён даже простейшего отладчика для Z80, и вынужден был всё делать вручную в машинных кодах).

Z80 индексные регистры в большинстве случаев не нужны (аналог без них почти всегда работает быстрее, т.к все индексные команды медленные), использование альтернативных регистров может ускорить часто используемые короткие подпрограммы (например, polling-опрос флагов), регистр I в системе без MODE 2 даёт чуть более быстрый регистр хранения (также как и R - однобитовый флаг хранения), но в целом к уникальным возможностям Z80 прибегать приходится сравнительно редко. Естественно, бывают случаи когда без индексных регистров для КР580 получается в разы более громоздко. А при написании кода для ПЗУ гораздо полезнее оказываются недокументированные команды с половинками индексных регистров, это экономит байты. Потому система команд КР580 и считается полностью самодостаточной и её нельзя существенно улучшить.

В целом, при равном клоке, Z80 лишь ускоряет работу программ в лучшем случае на 5% и на столько же сокращает объём кода. Ради этого не стоит откидывать с платформы тех пользователей, что имеют процессор КР580.

Значительно более важное и ценное преимущество Z80 заключается в том, что сам процессор Z80 более скоростной (есть даже его варианты Z280 на 33 МГЦ, причём с редуцированным числом тактов на команды). Даже повсеместно распространённый Z80B (у меня, например, их 15 штук, но нет ни одного Z80A, я их просто не покупал, не было смысла, т.к цена была одинакова) тянет клок 10 МГЦ, а если достать Z80H или КМОП Z84C00020, то можно поиметь систему с тактом в 12 МГЦ (выше не имеет смысла, сложность отладки с ростом частот быстро нарастает, да и скоростей 1533 выше уже не хватает).

Конечно, имея Z80, обидно писать программы для КР580. Но можно использовать все основные преимущества Z80, причём не откидывая владельцев РК86 ещё не имеющих процессора Z80. Я и при написании программ специально для Z80, если не было острой необходимости в индексных регистрах Z80, из Z80-команд всегда использовал только лишь JR-команды, LDIR-ы, SBC-ы и загрузки в/из ОЗУ парных регистров. Исходники таких программ легко переделать под процессор КР580.

Потому нет особых препятствий, чтобы сразу писать программу под Z80, причём так, чтобы тот же исходник без переделки транслировался и для КР580. Для этого я использую макрокоманды CP/M макроассемблера M80 от Microsoft. Тогда, когда надо странслировать вариант для КР580, достаточно поставить соответствующий ключ трансляции (т.е в заголовке д.быть строка 'Z80 EQU 0'). Тогда имеем две версии программы, причём версия для Z80 на ~3 % более компактная и чуть быстрее работает.

Из-за превышения максимального размера поста приходится переносить продолжение в другой пост.

Под спойлером приведены строки, что я вставляю в текст файла MACRO.INC, которые позволяют мне делать один исходник для КР580 и Z80. Можно писать исходник для Z80, не применяя EXAF и команд для индексных регистров. А когда надо поиметь версию для КР580, то запускается макро-команда программистского редактора (если у Вас не UltraEdit, а более примитивный редактор, Вам это недоступно), которая находит строки с Z80-командами и заменяет их на макрокоманды. Если у Вас убогий тестов редактор или Вы не умеете использовать макро-команды редактора, то можно сразу писать макрокомандами.

Спойлер:

В начале любой программы я ставлю вот такой код проверки процессора Z80 (это код из CP/M-овской CP/M-библиотеки, Z80 определяется по работе флага парити, можно определять Z80 и по коду EXAF, что в КР580 прогоняется как NOP). Подпрограмма MSSG здесь для ИРИШИ и для программы работающей в базовой карте 2 (для карты 1, т.е в доп.ОЗУ, управление портом PC иное и стек CSTACK иной). Все программы базовой ИРИШИ с базовым ПЗУ запускаются в карте 2. Естественно, для РК86 отдельная п/п-мма MSSG не нужна, для РК достаточно поставить CALL на адрес $F818.

Спойлер:

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



Эмуляторы под Windows существенно искажают графику из-за того, что они масштабируют, тогда как эмуляторы под MSDOS отображают всё точно, точка в точку. Чтобы понять о чём речь закройте вкладку слева или просто скачайте эту картинку и вы увидите, что фон выглядит совсем иначе и не имеет волнообразных колебаний яркости, что возникают при масштабировании.

Вообще, как для текста, так и для игровой графики экранный формат 640*200 неудачен. Для текста 80 символов в 20 строках, - это несуразица, - слишком длинная строка и слишком мало строк. А при 25-ти строках строки наползают друг на друга, высокие буквы слипаются, читать такой текст неудобно. Для нортона 80 символов в строке тоже очень неудобны, по крайней мере, если выводить не только имена файлов, но и размеры.

Для графики такой формат экрана также не особо удобен, т.к пиксель не квадратный. И чтобы в графике с линиями вертикальные и горизонтальные линии выглядели хотя бы примерно равной толщины, приходится вертикальные линии делать шириной в 2 точки, что фактически снижает реальное разрешение до 320 точек по горизонтали.

Если разрешение 640 это для графики не так и плохо, то вот всего 200 точек по высоте удручают. Для текста существенно лучше было бы как в ОРИОНЕ/Специалисте иметь высоту экрана в 256 точек.

По совокупности преимуществ для бытовых 8-ми разрядок идеальный формат экрана это 512*256. Потому автор Вектора Темиразов был очень прав, пойдя ради такого экрана на нарушение РТМ, а вот автор ОРИОНА был неправ, когда сделал экранчик шириной всего в 384 точки. И уж тем более это нелепо при пиксель клоке в 10 МГЦ, при котором сам напрашивается бОльший экран. В Специалисте А.Волков не имел возможность увеличить экран, т.к у него из-за тормознутости 565 РУ3 был пиксель клок всего 8 МГЦ, а при этом и 384 точки не вполне влезают в экран телевизора.

А т.к обе шины в ОРИОНЕ буферизованы, то в нём явно напрашивался и лёгкий оверклокинг до 2.75 МГЦ (кварц 11 МГЦ) или хотя бы до 2.625 МГЦ (кварц 10.5 МГЦ). У меня все ОРИОНЫ (а я их спаял более 15 штук) работали при замене кварца на 11 МГЦ. На 12 МГЦ лишь один ОРИОН сразу не потянул, пришлось емкостями подгонять задержки. При 1533 ТМ7 и ТМ8 и буферах 1533 серии работа ОРИОНА с кварцем 12 МГЦ не вызывает проблем.

Впрочем, с форматом экрана в ИРИШЕ не всё так печально. Потому, что всё-же есть тема для которой 640 точек по вертикали лучше, чем 512 или тем более жалкие 384 точки. Речь конечно о GUI, графическом интерфейсе. Т.е интерфейсе с меню и пиктограммами, где используется указатель типа "мышь". Малоинтересующиеся 8-ми разрядками конечно не знают, что GUI был первоначально написан и обкатан именно на 8-ми разрядках.

Первоначально графический интерфейс заимствованный у фирмы Xerox в конце 70-тых начали писать для 8-ми разрядного процессора 6809. Графический интерфейс и мышь были изобретены группой инженеров фирмы Xerox во главе с Аланом Кеем. Процессор 6809 на такте 2 МГЦ первоначально заложили в компьютер Apple Lisa. Однако пока 4 года разрабатывали ПО и железо Лизы, появился более скоростной процессор 68000 работающий на такте 5 МГЦ и Стив Джобс потребовал поставить в Лизу именно его.

Тем не менее, то, что мощностей даже медленной 8-ми разрядки для граф.интерфейса хватило бы, продемонстрировали файловые менеджеры Apple MouseDesk и Catalyst для Apple-IIe (где 128К) и графическая ОС GEOS для Commodore-64 (с расширенным до 128К ОЗУ). В обоих системах 6502 на такте всего 1 МГЦ (что примерно соответствует КР580 на такте 2 МГЦ). Графика у Apple-IIe 560*192, а у Commodore-64 графика вообще мизерная - 320*200.

Таким образом граф.возможностей ИРИШИ с экраном 640*200 для GUI хватает. Для GUI ИРИШЕ не хватает только скорости работы и объёма ОЗУ. А также не хватает мыши. Как только у меня на ИРИШЕ будет мышь, я займусь написанием файлового менеджера для DOS.

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

При написании программ для ИРИШИ встаёт вопрос для какой среды делать программу. По сути есть две среды, это CP/M для карты 2 на 48К при экране напрямую доступном из программы CP/M и CP/M на 64К для карты 1 (или 3), когда экран напрямую программе недоступен. Программа работающая в карте 2 и не использующая CP/M-вызовов может считаться программой для среды монитора ИРИШИ и может загружаться с магнитофона. Хотя использовать программы загружаемые с магнитофона бессмысленно и неудобно.

CP/M на 64К более полноценна как DOS (позволяет использовать фирменные программы CP/M), а CP/M на 48К имеет плюсом то, что при наличии внешнего привода может работать с базовым объёмом ОЗУ (т.е без расширения ОЗУ, как минимум до 128 кб, что необходимо для CP/M на 64К). Оказалось, что диспетчер памяти ИРИШИ вполне удобен для работы с экраном из DOS на 64К.

Работа с графикой из программ для карты 1 делается так. В графической программе (которая для CP/M 64К может иметь размер до 57 кб), процедуры работающие с экраном располагают в областях 0...3FFF или 8000...BFFF, которые не переключаются при включении карты 2 (в которой экран включен с C000 и доступен для прямой записи). Тогда при включении карты 2 в адресном пространстве находится и 32 кб кода для работы с экраном и сам экран.

В компьютерах с цельно банковой коммутацией для работы с экраном приходится из банки программы в банку где доступен экран пересылать код драйвера работающего с экраном. В ИРИШЕ благодаря грамотному диспетчеру памяти это делать не требуется, - просто включаем экран, делаем на него вывод, а затем снова отключаем, возвращая расположенный в ОЗУ выше C000 код DOS. Примерно также сделано во Львове, где экран с 4000, чтобы не мешал, тоже выключается из пространства процессора. Такая архитектура ИРИШИ позволяет иметь свободными для программы все 64К и без ухищрений работать с экраном программой написанной на ЯВУ.

Минимальная частота КР580 не известна. Про 8085 пишут, что он имеет минимальную тактовую частоту 500 кГЦ. 6502 также имеет какую-то минимальную тактовую частоту. А вот Z80 сделан на статической логике и не имеет минимальной тактовой частоты – можно замедлять его клок до очень малых значений. Так для отладки ГДР-овского компьютера AC1 в 1984 году в случае проблем отладки рекомендовалось использовалось замедление клока процессора UA880 до 2 КГЦ. Очистка экрана размером в 1024 байта при этом длится несколько минут, что полезно для выявления адресных залипов. Также это полезно тем, что на низкой скорости можно пользоваться осцилографом с низкой полосой.

Для освоения программирования под КР580 полезно почитать книжку, содержание которой приведено вот здесь. Жаль, что у меня такой книжки не было, - при программировании на ассемблере КР580/Z80 мне приходилось изобретать велосипеды. Скачать можно, например, вот здесь - качайте пока интернетные паразиты торгующие не принадлещими им книгами не перекрыли кислород. Давно забыт девиз "Интернет информация доступная всем", - теперь только для тех, кто платит. Стараниями этих гадов, всё больше и больше сайтов, где раньше можно было скачать много хороших технических книг выдают вот это:



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

Вторая книга по той же ссылке (Лэнс Левенталь "Ввведение в программирование", скан 25 Мб) тоже вроде бы интересна и полезна (точно судить не могу, глянул лишь оглавление и чуть полистал). Как учебник на мой взгляд она организована не очень удобно (т.к там смешанно, поперемнно идёт речь, то о 6800, то о 8080), но, по-крайней мере, про проектирование и организацию программирования программистом что-то ценное найти думаю можно.

Стараниями этих гадов, всё больше и больше сайтов, где раньше можно было скачать много хороших технических книг выдают вот это

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

А книжечку лучше сюда выложу, может будет сохраннее.


Программирование на языке ассемблера для микропроцессоров 8080 и 8085.

Скачать