nedoPC.org

Угу…
После того «ADD HL,HL - 4 такта» я уже себе не доверяю!
Хотя, сейчас прикинул и получил формулу прожорливости своего алгоритма прокрутки - (45*Y+66)*X+132…3832.
Если подставить параметры экрана 78×30, получим (45*30+66)*78+242 ≈ 110690 тактов + ещё прелюдия-обвёртка самой COUT_C и тот STATUS…

И получается, что при частоте 1777777 Гц получится примерно 16 кадров в секунду и 32 полных кадра в минуту - 112 секунд на те же 44 кадра…
Эмулятор не такой уж обманщик! Кaк губка я впитывал все публикации со страниц РАДИО в память РК.
В интернете заметка про автозапуск где-то попадалась, но самой статьи - нет. Нужно качать журналы целиком…

Но свою пародию, ради демонстрации, я накидал…
Это - не ремейк, а мой собственный код с потолка.
В оригинале была маленькая утилита, которая спрашивала адрес начала файла, адрес конца и точку запуска, затем выводя два файла на ленту.
Но я её быстро доработал и добавил возможность задавать имя файла.

Данная здесь моя версия умеет искать файлы, если нажать «Home» и через пробел набрать имя файла, потом через точку уже задать «I».
Естественно, всё работает только на оригинальном Мониторе!

К сожалению, данный код стряпал впопыхах и где-то допустил ошибку: Экран упрямо не выравнивается.
Но всё работает: Сначала даёте файл «Part-1.rkr», а затем - «Part-2.rkr»…
A незачем извиняться
Тема - не будка исповеди!

Напротив, интересно услышать самые разные мнения

А зачем при ролике двигать 30 строк, Вы же используете режим с 25-ю видимыми строками (из-за того, что в режиме с 32 видимыми строками п/п-мами ПЗУ пользоваться нельзя, т.к тогда из-за чрезмерного объёма экрана или рабочие ячейки затёрты или экран установлен вне стандартной экранной области 76D0).

Я тоже посчитал число маш.тактов для трёх нестековых алгоритмов ролика экрана (для Z80, т.к у меня в наличии только числа тактов для Z80). Получилось, что для КР580 наиболее выгодным является программный сдвиг только видимой области с двумя петлями. Вероятно и такой алгоритм можно улучшить.

Интересно посчитать и алгоритм сдвига стеком. Увы, готовый он мне не попадался, придётся его написать (т.к в текстовом редакторе, чем быстрее ролики экрана вверх и вниз, а главное, чем быстрее сдвижка и раздвижка текста в буфере, тем лучше).


Я тоже вот это и вот это читал, но это не стало для меня открытием, т.к уже за 5 лет до этого я встречал многоблочные программы для Специалиста и потому умел делать перехват при МГ-вводе (это использовалось на Специалисте и на на ОРИОНЕ).

Но я имел в виду то, что автостартующих программ не встречается в реальности, а есть только информация как это сделать. Это из-за того, что эта информация стала известна лишь в 1993 году, когда РК86 в пользовании у населения был практически вытеснен Синклером, уже для РК никто не писал программ. И, соответственно, кассет с автостартующими играми, используя эту статью, никто не создавал и не распространял, хотя торгующих программами для бытовых ЭВМ, в том числе и для РК86, мелких предпринимателей и частников в то время было тысячи.

К тому же автозапуск необходим только для многоблочных программ, что в свою очередь нужно для изготовления защищищённых от копирования программ. А т.к защищать от копирования в 1993 году было уже нечего (всё что было из ПО уже давно разошлось без защит), то и распространения такая методика не получила. Кстати, в мониторах некоторых ГДР-овских компьютеров был флаг автозапуска (в запись на ленте включалось не только имя файла, но и дата, автор и флаг автозапуска).

Хотя польза от этого нулевая. Т.к хорошая защита от копирования делается лишь с использованием другого формата записи, т.к даже при модификации стандартного двухфазного формата (например сменой констант, вводом огромного числа мелких блоков, что утомляет пирата, и т.п.) это копируется без труда программой SP-Copy Специалиста (она сама тоже защищена и в эмуляторы не грузится, а без эмулятора её не кракнуть). А чтобы применить на РК другие форматы МГ-записи нужно их адаптировать (введя в алгоритм регенерацию ОЗУ) и долго трахаться отлаживая.
Точно, ни хрена не заработало с ПЗУ где стек на 76D0.
Идея оперативной загрузки фонта приближает возможности РК к Денди. Тогда графика в РК-играх была бы как в графической машине, программирование проще, а скорость движения спрайтов намного выше, чем в полноценно графической машине.

То что эта идея "не идёт" уже почти 10 лет (с момента разработки схемы Alex_LG) виноваты разработчики фотошаблонов печ.плат и производители плат новоделов РК86. Они ни за что не хотели вводить никакие, даже самые очевидные, доработки, что не стоят даже деталей (а лишь дополнительного печатного проводка). А главное, - нечем возразить на неопровержимый довод: "Если Вам нужна графика, то делайте Специалист, он проще, чем РК с прибамбасами" (к тому же Специалист намного быстрее и без захватов шины ПДП ).

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

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

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

Я тоже когда-то нарисовал свой вариант доработки для загрузки фонта. На 565РУ2 (т.к, чтобы не требовалась коммутация нужны раздельные входы и выходы у ОЗУ) и на другом принципе, чем в двух уже опубликованных вариантах. А именно, - с загрузкой ОЗУ фонта через запасное ППА D14. При этом коррекции на плате РК не нужны, устройство не грузит шины, свободные области памяти и чип-селекты не занимаются. Платка втыкается в разъём ROM-диска и от неё идёт коса с разъёмом DIP-24 втыкаемым в панельку ПЗУ 573РФ1 знакогенератора. При этом, если использовать готовый отрезок платы с смонтированными ОЗУ 565РУ2, то монтажа меньше, чем в других вариантах.



В РК86 неудобно не знать идёт ли ввод или синхробайт не "схватился" и компьютер висит. Экран погашен и не выводятся даже цветные полосы на бордюр по каждому биту, как в ZX. Если в подпрограмму загрузки массива в ПЗУ РК86 вставить те строки, что помечены жёлтым в вышеприведённом фрагменте, то при МГ-вводе появится индикация светодиодом РУС/ЛАТ (что стоит на PC3 порта клавиатуры). Здесь бит A6 адреса куда с ленты загружается текущий байт выводится в светодиод. Для этого бит D6 из младшего байта адреса с помощью трёх команд сдвига сдвигается на бит D3 и выводится в порт C ППА клавиатуры.

После того как будет отловлен синхробайт и начнётся ввод байтов блока, светодиод РУС/ЛАТ начнёт моргать с частотой ~0.85 ГЦ. Это потому, что скорость МГ-ввода в РК примерно 150 байт в секунду, а светодиод будет отображать бит D6 адреса загрузки.

Отмеченные жёлтым команды добавляют в период ввода последнего бита байта более 20 маш.тактов, потому для компенсации в п/п-мме LDBYTE надо пересчитать компенсирующую константу 0EH или уточнить её опытным путём. Это можно отладить только в реале с реальным магнитофоном. Если будут проблемы, то число сдвигов можно уменьшить или совсем их убрать, что одновременно с сокращением задержки увеличит частоту мерцаний светодиода.

A как тогда узнать пиковую производительность на максимальном разрешении?
Нет, хотя 78×30 - не максимум и можно сделать альтернативный фонт под 78×60 с псевдографикой.
Причём, вывод 3 от ВГ75 использовать для переключения знакогенератора: Если настройки ВГ75 не выходят за 4 линии, на выводе 3 всегда «0» и знакогенератор работает в режиме 6×4 с псевдо-графикой 3×2.
Например, 155ТМ2 сбрасывать выводом 8 ВГ75 (вторую половинку ТМ2 использовать за инвертор), а стробировать загрузку «1» выводом 3…
Тогда знакогенератор явно переключать не надо, а лишь устанавливать нужный режим ВГ75.

Вот интересно: Бит 7 байта #4 в настройке ВГ75 управляет сдвигом линии знакогенератора на 1 позицию…
То есть, линия 0000 гарантировано никогда вылазить не будет ни при ССИ, ни при КСИ?
Если так, то это тоже можно использовать опционально: Включать альтернативный знакогенератор по линии 0000.
Если бы почитали описание моей утилиты у глянули бы на её код - критики было бы гораздо больше!
Её я гружу прямо в область рабочих ячеек Монитора и без директивы «X» она не работает!
Оказывается, оригинальный Монитор по Сбросу трёт не все свои ячейки и мою утилиту можно было бы хранить там…

Кстати, есть идея директиву «X» сделать реальным Иксом: Запускать пользовательский код с передачей ему всех аргументов. То есть, тот же «G», но адрес хранится в специальных ячейках…
Когда брат с другом пытались паять мигалку на ЛА3 на велосипед по схеме из книжки, не могли понять, почему на схеме указаны одни ножки, а я им говорю гнуть и спаивать другие ножки (чтобы обойтись без лишних перемычек)…
Молодёжь привыкла сейчас работать по шаблону и не включая голову!
Я поступал круче: Сам ВТ57 настраивал на ячейку 8002 и пытался устроить аппаратную визуализацию сигнала с магнитофона… Не пришло ли время обсудить «Супер-РФ1»‽
По тому же принципу: Запись через чтение.
То есть чтобы перезаписать какой-то символ в знакогенераторе, просто на экране выводится особая последовательность кодов.
И никаких шлейфов к ППА не требуется!

ВГ75 - не самый удачный кристалл от инженеров Intel: Эту критику можно часто видеть, в частности, здесь на форуме…
Вот что мешало инженерам сделать не программирование позиции курсора через порт ввода-вывода, а считывать позицию курсора в самом начале кадра тем же циклом ПДП?
То есть, в РАДИО-86РК ячейками 76D0:76D1 хранилась бы позиция курсора и форма, а сам экран был бы по 76D2…7FF5.
И те же X:Y-курсора - всего 13 бит. Оставшиеся 3 бита могли бы и форму задавать, и частоту мерцания.
То есть, имели бы два бита частоты (1/64, 1/32, 1/16 и без мерцания) и бит Блок/Подчёркивание…
――――――――――――――――――――――――――――――――
Чуток подправил кодик:Но, теперь все точки, обращающиеся к F922 нужно корректировать, иначе возникают существенные проблемы!

К тому же, Вы зря сравниваете прокрутку экрана в РЛК «Специалист» и «Орион», где видеопамять, для упрощения дешифрации, идёт «по-китайски»: Сверху-вниз и слева-направо.
Там, при выводе символов/спрайтов, достаточно исполнять «INC L» и «INC H», тогда как в РК без «ADD HL,…» не обойтись

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

INC R - 4 такта, а INC RR - 6 тактов - разница в два такта "погоды не делает". Если цикл 100...200 тактов, - отличие в нескольких командах на 2 такта навредит не фатально. И как раз экран РК для сдвига стеком выгоднее, т.к там применяют два цикла - один на 250, второй на 48, а здесь только один цикл на 195. Для графических машин ролик (и очистка) стеком важны, т.к там сдвигается (или заполняется) более, чем в 6 раз больший массив байтов.

Вот исходник ролика для РК86 стеком по невыгодному алгоритму LDIR (написано из головы, без проверки, сейчас просто нет времени проверять, но думаю всё верно).


Если я не ошибся в арифметике или программировании, то это более, чем вдвое быстрее, чем сдвиг программной реализации команды LDIR (которой у процессора КР580 не оказалось). В программной реализации (см.предыдущие мои посты) число тактов - 97530. А сдвиг 25-ю циклами по 64 байта будет ещё быстрее. Так что Вы очень неправы, считая, что стековые команды для сдвигов и очисток малополезны. Об этом даже в Википедии написано.

Bсё точно у меня.
Вы не так прочитали:Не «INC R» и «INC HL», а именно «INC L» и «INC H».
В «Специалисте»/«Орионе» для смещения по столбцам следует использовать «INC H», а для смещения по строкам - «INC L». Так же, как и в «ZX-Spectrum», где для вывода одного символа достаточно использовать «INC H» и на форумах это много обсуждалось, так как ZX изначально разрабатывался для учебных целей с быстрым выводом текста, а не спрайтов.
Именно про это я и говорю.

А вот в РАДИО-86РК прокрутка, лично меня, интересует именно оконная, а не полноэкранная.
Именно ради окошек я и взялся за переделку COUT!
Иначе, я бы никогда не занялся переписыванием всего ПЗУ!
Это нужно учитывать в первую очередь

Если Вы настаиваете внедрить в код прокрутку экрана целиком через стек, тогда мне не останется ничего, кроме как просто выбросить весь свой код в мусорку и ничем не заниматься!

P.S.: «Окошки» мотивировали меня

Какая разница как именно организован экран? Чтобы можно было использовать стек для работы с экраном достаточно, чтобы экранные байты шли подряд и окно по координате, где экр.байты впритык, имело ширину кратную 2. И тут без разницы, экран инкрементируется по горизонтали или по вертикали.

В Специалисте, ОРИОНЕ и Векторе экран инкрементируется по вертикали, а в ИРИШЕ экран инкрементируется по горизонтали, но с помощью того же стека это не помешало получить там быстрый ролик, причём при очень тормозном процессоре и огромном экране в 16 кб.
При оконности для стековой процедуры не очень удобно, что ширина окна может быть нечётной, т.е не кратной двойке. Вот в 6502 и 6800 это бы не стало препятствием, т.к у них стековые команды читают/пишут по одному байту.

А при двухбайтовом стеке придётся существенно усложнять процедуру при нечётной ширине окна. Если устраивает, что все окна должны быть с шириной кратной двойке, то проблем для использования стека для ролика нет. Только для ролика в окне не годится ролик по алгоритму LDIR, т.к он сдвигает только весь экран целиком. А нужно использовать второй вариант с двумя циклами. В первом цикле в окне сдвигается одна строка, затем нач.адрес строки увеличивается на 78 и всё это повторяется столько раз сколько строк в окне минус 1. И последняя строка очищается.
Кто я такой, чтобы настаивать? Я же не заказчик и в этой теме я даже не заинтересованное лицо, а просто делюсь своим мнением, чтобы был всё-же форум, а не монолог.

У меня по РК совсем другая тема. Например, как раз сегодня я начал писать простейшую DOS с размером в ~2.5 кб, причём резидентную в ПЗУ, в которой в качестве CCP DOS используется командный процессор монитора (что экономит 0.5 кб кода). Т.е необходимо, чтобы DOS уместилась в добавленное вот по такой схеме ПЗУ РФ2 с размером в 2 кб на адресе F000 плюс ещё 0.5 кб из ПЗУ F800.

Это д.быть аналог, а по возможности даже немного лучше, чем дискетная Хамелеон-ДОС от Львова, что имеет рекордный размер из всех дискетных DOS всего в 2 кб. Для РК задача уместить весь код, т.е ROM-BIOS и DOS, в одну микросхему ПЗУ 2732 с размером 4 кб. Уже потратил сегодня на написание этой DOS 5 часов труда и написал ~1 килобайт.

Для этого я и освобождал место в ПЗУ, т.к даже в 3 кб тяжело уложиться. Точнее, совсем примитивную DOS, без повторного использования места от удалённых файлов (как это в примитивной Хамелеон-ДОС) я могу уместить в те же 2 кб, но нужно лучше, хотя бы с повторным использованием места удалённых файлов (без опасной процедуры SQEEZE как было в ОС-ДВК).

В примитивных DOS (к которым, кстати, относится и популярная TR-DOS) новые файлы пишутся в конец занятой части диска, а чтобы вернуть для использования место занимаемое ранее удалённым файлом выполняется опасная (отдельная) программа SQEEZE (на английском языке означает "сжатие"), которая схлопывает последующие файлы на освободившееся место. Отчего позиция в конце диска, куда будут записываться новые файлы также сдвигается увеличивая доступный объём.

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

Разницa не такая уж маленькая!
Вот в том и дело, что в «Специалисте»/«Орионе» два байта - это уже блок 8×2
Когда я писал вьювер графики с игры от Специалиста на РК, то понял, «японская грамота» в организации экрана сильно упрощает жизнь.
И при прокрутке стеком сразу двигаются 2 строки блоком 8×2.
А Ириша - вообще любопытное решение на 8-битном процессоре использовать графику IBM PC-XT с CGA-графикой.
У 6502 стек жёстко аппаратно закреплён в регионе 0100…01FF и экран не прокрутишь с этим…
В тех же «Специалист»/«Орион» ограничение на чётную высоту окошка - вообще не проблема. Так как минимальное оконце - 8×2 в таком случае…
Для РК это сложный вопрос, так как реально «оконных» программ - нету. Задача в том, чтобы хоть что-то было уже на уровне Монитора, а не внешними костылями с кучей «но…».
И здесь важно - уложиться в ПЗУ, а не оптимизировать под игры-прыгалку!
Вот, сами подтверждаете, что алгоритм будет слишком разбухший. Причём, сомнительными методами…
Как уже заметили, наверное, у меня очистка происходит сразу. Так как прокрутка достигается не копированием сверху-вниз, а вставкой пробела снизу-вверх. Это экономит кучу кода на самом деле. И позволяет сделать петлю: Самую верхнюю строку прокрутить и вывести в самом низу - для игр это очень полезно!
К сожалению, в СУБД я - ноль.
Потому и вожусь только с визуальной частью, так как буфер экрана, как Вы и подчеркнули выше про экранный редактор, тот же файл.
Можно сказать, окна - и есть фрагментированные файлы, а экран - БД в целом… Друг некогда приглашал на работу помочь написать им БД, но я с ходу отказался. Так как мало расписать план, как хранить пакеты данных. Так ещё от взлома уберечь и защиту от краха продумать…

P.S.: Дорабатываю свой Монитор по мелочам…
Директива «M» теперь радактирует дамп по 16 байтов в строке - пришлось множество мелочей проделать в разных местах.
Сейчас пытаюсь понять суть подпрограммы ввода байта…
Напрягает избыток кусков инициации ВТ57/ВГ75. Думаю, нужно всё это дело выбросить куда-то…
Например, как у Вас: «Рус/Lat» меняет форму курсора. Так как РК - ЭВМ с клавиатурным терминалом и больший период находится в опросе клавиатуры, думаю, ничего страшного не произойдёт, если именно при опросе клавиатуры будет восстанавливаться экран (ячейки 760D/760E хранят адрес стека при вводе (добавить и в вывод следует) - можно использовать как «флажок» к восстановлению), а так же добавить ячейки пользовательской предустановки, чтобы ВТ57/ВГ75 приложения не сами программировали, а просили Монитор…
Правда, огорчают Ваши замечания про эмуляторы…
Так, если PUSK_VG занимает 47 байтов, то ввод/вывод байта - по 26 = 52 байта: Нужна унификация самой PUSK_VG…

Сейчaс закончил очередную правку кода и пока не знаю, на сколько критической окажется всё это…

• Стек установлен на 76D0, верхушка памяти пользователя - на 7600, аварийный адрес (F836) - 76CE
• Директива «B» - предустановка к директиве «R,7F»
• Директива «F» - предустановка к директиве «T»
• Так как директивы «D»+«L» и «M» занимали 43 и 39 ячеек, удалось их совместить в одну унифицированную «D»-директиву, проверяющую флаг ячейки 762D: «D<адрес>» работает как «M», «D<начало>,<конец>» выдаёт дамп с текстом
• Директива «J» - пользовательская, хранящаяся в ячейках 7650…769F с четырьмя аргументами «J<HL>,<DE>,<BC>,<A>», для чего уменьшен буфер ввода и упразднена очистка рабочей области
• Директивы «C»,«I»,«O»,«S»,«X» работают как обычно
• Директивы «L» и «M» исключены
• Директива «E» передаёт управление на адрес E000 с четырьмя аргументами
• Любая другая ошибочная директива переходит на адрес F000 без аргуметов

Дизассемблировать не советую, так как ничего существенного там не обнаружите.

• «Холодным стартом» Монитора область служебных ячеек не очищается, из-за чего флаг «РУС/LAT» клавиатуры не определён, а COUT может повести себя крайне непредсказуемо, если ESCAPE-статус не сброшен: Несколько 1F-кодов не очень защищают от этого
• Подпрограмма GETLIN защищена от ошибочного возврата при вызове с ZF и буфер ввода уменьшен на четыре символа ради «J»
• Подпрограмма MSG_PC врезается в MSGH, которая слегка перестроена
• Подпрограмма HEX_A не портит регистр C
• Подпрограмма COUT_A является трюковой пристройкой к COUT_C с подавлением команд «PUSH AF»+«LD A,C» посредством «SCF»+«JP NC», потому обходится без «PUSH/POP BC» и «LD C,A»
• Магнитофонные константы исправлены
• Директивы «D» и «I» прерываются клавишей Esc, а не нажатием «УС+C»

Для проверки примера директивы «J» загрузите файл «Dir_Jay.rkr» и выполните «J1234,5678,9ABC,DE». Директива не боится Сброса и может храниться бесконечно долго при штатном режиме работы и использования…



Кстати: Вы зря «СКРОЛЛИНГ» записываете во вредные жаргонизмы англицизма и советуете использовать вместо этого германизм «РОЛИК». Русский язык и так изобилует германизмами в самых неожиданных местах!
Так-как «Ролик Экрана» понятие не очень стабильное и длинное, тогда как «СКРОЛЛИНГ» - более ясное в узких кругах. А вообще, не забудем, что «СКРОЛЛ» означает «СВИТОК».
А так как ни «Свиток Экрана», ни «Ролик Экрана» не могут восприниматься однозначно и требуют пояснений, то лучше использовать именно «Скроллинг», так как понятие это более однозначно во всей индустрии.
Тем более, в медицине на термин «скрининг новорожденных» ещё никто не жаловался.
К чему тогда подозрительно относиться к «скроллингу» в сфере техники?

Побочные эффекты:

1. Если вместо директивы нажать Esc и Точку, произойдёт прокрутка области над курсором.
   С одной стороны это - баг. С другой стороны позволяет минимальными усилиями увидеть одну из «плюшек» моего экранного кода.
2. Если набрать «D7600» и просто жать «ВК», то на ячейке 763F процесс прервётся. Эффект неожиданный и непонятный, но не смертельный и связан с особенностью самой директивы в цикле печати КОИ7 справа от дампа, которая и прерывается на ячейке 7633 именно при редактировании. Причём, при «D7634» сбоев не наблюдается…

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

Кстати, писать программы для 8-ми разрядок в наше время лучше на ЯВУ, т.к в Википедии пишут, что на ЯВУ программировать и легче и эффективнее, чем на ассемблере. А ЯВУ теперь как раз стали доступными (CP/M-компиляторы Паскаля, Фортрана, Си, PL1 и PL/M работают в Windows XP), что было недоступно отечественным программистам любителям 80-тых и начала 90-тых годов, когда 8-ми разрядки и были в пользовании у населения. Можно даже альтернативный РК-монитор написать на PL/M, он вполне влезет в 4 кб (т.к PL/M даёт компактный код), а соблюдать внутренние точки в альтернативном варианте не надо.
Теперь по директиве L сообщение ERROR не выдаётся, а по директиве M - просто происходит улёт. Это происходит из-за того, что в эмуляторах неточный конфиг и из-за вот этого:
В базовом РК86 ПЗУ F800 дублируется 4 раза по адресам E000, E800, F000 и F800. Потому команда JMP F000 введённая автором журнального ПЗУ РК86 для расширения директив не приводила к краху. Крах начинал происходить только после установки РК-КНГМД без замены в ПЗУ команды JMP F000 на JMP F86C (о чём авторы RK-DOS забыли написать в своих статьях, т.к вероятно и не знали эксплуатируя РК86 не в среде монитора, а в среде RK-DOS).

Тем более, что делать JMP F000 ни Вам, ни даже авторам, вообще было нельзя, т.к на F000 при ПЗУ в 4 кб должен стоять JMP F836, а не процедура расширения CCP (иначе не сработает СБРОС). Так что JMP F000 и в оригинальном ПЗУ РК86 и у Вас - грубая ошибка. Видимо авторы РК86 этим показывали, как надо расширять директивами монитор, а Вы не думая просто скопировали эту ошибку. Чтобы команда JMP F000 имела смысл требуется аппаратная переделка идеологии старта по кнопке СБРОС (например, использование "теневого ПЗУ с 0" делающего по сбросу JMP F800).

А в эмуляторах в конфигах как раз реализован РК-КНГМД, который стоит на F000, а ПЗУ с RK-DOS включается на адресах E000...EFFF. И какой смысл Вам делать JMP F000, если Вы используете ПЗУ с окном не 4 кб, а всего 2 кб - F800...FFFF, ведь ради этого Вы и изобрели метод переключения страниц ПЗУ по чтению из адресов FFF0...FFFF?

Для отладки кода ПЗУ в реале, а также, чтобы JMP F000 работал, Вам будет удобно применить псевдо-ПЗУ. Применив конфиг реализующий эту идею, можно будет отлаживать ПЗУ программным отладчиком (например DDT на адресе 9000), т.е даже не пользуясь неудобным графическим отладчиком эмулятора. Код в ПЗУ нельзя отлаживать программным отладчиком , т.к в ПЗУ не записывается код команды RST в стоп-точке.
В принципе идея (для пропуска прогона двух последующих байтов) очень хорошая, дающая выигрыш аж 5 байтов. Проблема в том, что при этом меняется порядок ПУШ-ей. А в уплющенном мной варианте ПЗУ, в отличие от вашего варианта и журнального оригинала, лишь один вариант PUSH-POP-ов, - общепринятый порядок HL, DE, BC, что позволяет иметь всего один экземпляр процедуры POP-ов (т.к расточительно иметь два варианта POPREG). На этом я уже ранее выиграл 3 байта. Мешает перестановка PUSH AF. Но подумаю, может где-то ещё такой трюк подойдёт. Кстати, такой трюк впервые применил Билл Гейтс в своём 4-х килобайтовом бейсике.
Ролик это не только рекламный ролик на телевидении, цилиндр с осевым отверстием или колесо с торцевым пропилом для пассика. Ролик не как что-то овеществлённое, а как процесс, это - всё, что прокручивается.

Ролик экрана точно отражает суть. Всяко лучше, чем слова прокрутка, сдвижка, панорамирование экрана. А "скроллинг" вообще ничего не отражает, неинформативен и непрофессионалу не знакомому с этим термином непонятен (лучше уж писать "скроллинг экрана"). В то время как термин ролик экрана понятен и обезъяне.

Слово "скролинг" придумал какой-то слабоумный в начале 90-тых, а другие идиоты подхватили, т.к считают очень крутым всё иностранное. В технических книгах 80-тых и 90-тых ещё не встретишь этого мерзкого слова, а вот насчёт более поздних книг - не уверен. Хотя слово scrolling пока ещё переводится грамотными переводчиками правильно, как прокрутка, а скроллинг всё ещё считается жаргоном. Но враги из пятой колонны, щедро оплачиваемые ЦРУ, уже забили слово "скроллинг" в Википедию, как якобы технический термин. Мерзкие англиканизмы, уголовный жаргон и детский сленг повсюду побеждают. Например, некоторые школьники с пониженным IQ сдуру называют DIP-панельку кроваткой (непонятно почему не диванчиком).

Как раз тем, что слова не от балды, а информативные, русский язык и превосходит убогий английский. Потому англоговорящим так необходим словарь Вебстера (и детские конкурсы на правописание), - большинство их слов не имеют однокоренных, а надёрганы отовсюду. А нам толковый словарь вообще не нужен, т.к в русском языке слов не 1.5 миллиона, а менее 100 тысяч и подавляющее большинство слов производные, имеют понятные корни, что облегчает запоминание и понимание. В свободолюбивых странах внедрение англиканизмов преследуется по закону.

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

Переписaл экранную подпрограмму…
Теперь коды 0C и 1F работают как и положено. Тем самым, без драйвера очистить часть экрана в окне уже нельзя. Только прокрутить область 64×25…

Метки я именовал на свой лад: Первые символы метки жёстко привязаны к основе подпрограммы. Остальные же отражают обрабатываемый код либо действие…

Отнюдь!
Энергии не так много, как может показаться со стороны: На бинари РК я трачу не остаточную энергию трудовых будней, а основную энергию. Потому и кажется многое, чего нет…
А Специалиста я знаю лишь по публикациям журнала «Моделист-Конструктор», так как у отца не хватило ресурсов до полной его сборки…
И РК я знаю вдоль и поперёк, на сколько мне хватает компетентности. Других - я знаю намного хуже…
Разве прокачивать Монитор РК - бесполезное занятие‽

Можно, но интереснее самому писать оптимизированный код: Мозги напрягаются сильнее…
А пользоваться компилятором можно ради изучения принципов самой их компиляции…
Меня это тоже бесит: Вместо «D<адрес>» жму рефлекторно «M» и - привет!
Обезьяничать никто не запрещал. А я уже сказал, что прощупываю почву и оцениваю, насколько компактно можно утрамбовать полный функционал.
По дампу это я и наблюдаю…
Буду иметь в виду про правку «U»…
Да какая разница, если моя версия - полный утиль.
На практике пользуюсь либо оригинальным Монитором, либо Вашим. Так как у моей версии подводных камней уйма. А так как устранить пока их не могу, сильно раздражает недоработанность своего продукта.
А Ваши, в частности, недоработки вызывают лишь ухмылку и ожидание очередной версии…
Изобрёл?
Ни одна из предложенных мною схем не выполняет поставленную функцию!
Какое это изобретение без наглядного практического результата?
Даже плагин к онлайн-эмулятору сильно гонит при активации этой самой страничности.
Идея сырая и, боюсь, плесенью попахивает! До этого дело не дойдёт по независящим от меня причинам… Да, обилие ПУШистиков и их ПОПочек не даёт покоя. И поделать с этим ничего нельзя абсолютно!Выше говорили, что прыгать внутрь подпрограммы - не очень хорошо! А сами - грешите этим!
А за что его ругать, раз он умело пользовался всем потенциалом процессора
Так уж измена‽
Вот кто-то в будущем ковырнёт мой исходник Монитор и воскликнет «Сталина на них нет!»…

Во-первых, «там» тоже проявляют хоть какой-то интерес к технологиям СССР. Ну и пусть мои исходники будут более понятны «им»…
Во-вторых, некоторые тексты от VRML меня удивили комментариями на Кириллице, что сразу сигнализировало, чьи мозги там работали. Было приятно изучать, да…
В-третьих, «1С-Бухгалтерия» критикуется и за то, что разработчики переусердствовали тем, что отруссифицировали больше, чем надо. И пользователям MS-Excel пришлось доучиваться под 1С…

Более 30 лет понадобилось, чтобы кто-то из изготовителей плат наконец сообразил, что иметь второй фонт это хорошо.

Кстати, если уж атрибуты наконец пошли в дело, то стоило задействовать 3 атрибута, чтобы поиметь 8 фонтов, а атрибут RVV (ReVerse Video) отдать на инверсию знакомест. Всё равно от резервирования атрибутов на цвет толку нет. Их резервировали для цвета, но увы, - никто за 28 лет так и не удосужился сделать печ.плату цветного РК. Если бы развели и выпустили такую платку хотя бы лет 15...20 назад, то может и был бы сейчас десяток цветных РК-программ. А так как теперь время упущено и ясно, что ни плат цветного РК, ни цветных РК-программ уже не будет, то вполне разумно получить от атрибутов "хотя бы шерсти клок", т.е отдать их на коммутацию фонтов.

Но увы, программно поддержать даже всего два фонта не получится, в эмуляторах это не поддерживается.
Сразу заимствовал у Вас подпрограмму CLS, что с'экономило в ПЗУ 5 байтов (теперь свободно 285 ячеек). В ответ дам Вам для этой процедуры COUT_C подсказку на три байта. Если заметить, что коды 18, 19, 1A и 1B отличаются на единицу, то если поставить их в цепочке сравнения подряд и последними, то команды CP 18/19/1A/1B можно заменить на DEC A и выиграть 3 байта.


Этого более, чем достаточно, даже с избытком. Достаточно лишь знать организацию экрана и можно начинать писать "Принц Персии" или "Doom" для Специалиста. Подпрограммы C8xx те же, что и в РК86 на F8xx. Специалист даже проще, чем РК, быстрее и экран удобнее. А главное, экран графический. Это значит, что можно написать любую программу. А РК86 пригоден только, чтобы обкатывать системные программы, предназначенные для Специалиста или тренироваться в написании программ на Паскале или Си. Игры для РК писать бессмысленно.

Чтобы программировать для Специалиста иметь работающий Специалист не обязательно. Имеющиеся эмуляторы вполне точные. В отличие от РК для Специалиста нет программ, что не работают в эмуляторе.
Тогда объясните мне за счёт чего гаснет экран в 9-той и 10-той линиях знакоместа.
Дорабатывать монитор совместимо, добавляя новые возможности, что-то дающие пользователю, - полезно, а несовместимо - это занятие только для себя. Вы ведь так и не отвечаете на сколько больше программ станет доступно пользователю РК, если он заменит ПЗУ на ваше. Или как улучшится удобство пользования РК?

Но для меня эта тема полезна. Без неё я бы не вернулся к уплющиванию ПЗУ РК, т.к РК из-за отсутствия графики мне неинтересен (осталось бы всего 200 свободных байт, а в них поддержка ROM-диска не умещалась). Не считая заимствований кодов, важнее моральная поддержка. Что и ценно в первую очередь на тематических форумах.
А чего принципы компиляции изучать? Я Вам и без изучения скажу, что написать компилятор ЯВУ очень сложно. На это уйдут годы. Дело неблагодарное и сейчас нет смысла, т.к лучше, чем имеющиеся фирменные компиляторы ЯВУ (написанные целыми коллективами профессионалов) за разумный срок не напишешь. Лучше этими компиляторами ЯВУ пользоваться.
А вот это уже интересно. О каких версиях идёт речь? Я только чуть оптимизировал код ПЗУ, чтобы выиграть место. На это выигранное место удалось вставить и улучшенные директивы М и D и запуск программ из ROM-диска, но и их я не писал, а взял из ПЗУ других 8-ми разрядок. Существенно менять код ПЗУ РК я даже не брался. Так что, если недоработки есть, то не мои, а Дмитрия Горшкова. Именно он конвертирова монитор Микро-80 в монитор РК согласно воспоминаниям С.Попова, а монитор Микро-80 неизвестно кто написал.
Это совсем разное. Зачем дублировать абсолютно один и тот же код несколько раз?

PS. Нашёл в Интернете дизассемблированный монитор Микро-80, - неумело дизассемблированный и с комментариями там, где они абсолютно не нужны, т.е для полных идиотов. Попытался отредактировать, но понял, что из этого выйдет хуже, чем дизассемблировать самому. Для дизассемблирования ретро CPU современные версии IDA неудобны, я использую версию IDA из середины 90-тых. Всего за 20 минут с помощью IDA получил приличный исходник.

Кстати, в мониторе Микро-80 подпрограмма COUT_A делает все четыре PUSH-а, это значит, что это Д.Горшков зачем-то убрал PUSH AF оттуда. И PUSH HL BC DE в COUT-ах и PUSH-и в другом порядке в CONIN и МГ-п/п "пошёл" из монитора Микро-80, это не исправил Д.Горшков.

Любопытно, что взятие HEX-параметров из командной строки делается не один раз, как после ввода командной строки в мониторе РК, а в каждой директиве стоит свой вызов CALL GETPRM (отчего она вызывается аж 14 раз). Т.о целых 13 трёх байтовых CALL-ей лишние, их выирал Д.Горшков при конверсии под РК. Также там две процедуры ввода строки. Код в этом ПЗУ вообще не самый оптимальный (также полно LD A,0 ; RET после CALL и т.п.). Оптимизацией можно выиграть много байтов. Если заскучаю, то может быть займусь.

Вoт именно!
Какие-то недоделки - из-за чего? Излишняя осторожность из-за обратной совместимости?
Если хотя бы механический тумблер или JP-перемычку внедрить для переключения режимов поддержки…
Как говорится, пока тело способно сохранять личность индивидуума - никогда не поздно!
Было бы желание и желающие…
Эмуляторы - не молекулы графена: Электронный микроскоп или адронный коллайдер не требуется - переписать/дописать можно на уровне клавиш клавиатуры…
Неужели код столь уникален?
А Вы не заметили, что регистры B и C хранят границы текущего окна? Никак нельзя уже код символа считать из C…
Это место меня всегда напрягало и даже пытался таблицу использовать, так как все ключевые куски кода находятся в одном 256-байтовом пространстве и адресовать их можно одним байтом с использованием трюка с маскированием директив. Но код получался ещё толще…
Тем не менее, сейчас удалось те же 3 байта выиграть.
Спасибо!
Правда, тупо - «SUB 1AH + … + ADD A,18H». Всегда задавался вопросом в таких случаях: Стоит ли?
Да уж… От «Принца» до «Думы» - рукой подать!
Всегда задавался вопросом: А что мешало Волкову ПЗУ разместить как в РК? Было бы совсем всё просто!
Я уже высказывался на этот счёт: Все 90-е я в тетрадках малевал схемки собственных синхрогенераторов, изучая книжку Овечкина про телевизионные игры Хоккей и Скачки…
Если бы РК имел бы графику, я совсем не разбирался бы в основах формирования телевизионного матраца.
Как раз РК тем и привлекателен, что графики в нём - нет. А узел формирования видео не занимает половину схемы.
Можно сказать РК - не хитрее отладочного стенда в этом смысле, где вместо тумблеров и индикаторов - нормальный терминал.

Если этот терминал на базе ВГ75 оставить в покое и не изощряться с оконностью, то его более, чем достаточно, чтобы нагло подключить контроллер от Денди и начать разрабатывать игры с графикой и цветом. Получим систему покруче того же Сюбора с двумя дисплеями и с возможностью портировать игры 1 в 1 графикой, но уже с CISC-кодом против RISC
Ещё в 90-е я поглядывал на Денди с искушением её PPU подключить к D14 и попытаться его программировать…
Хотя, если внедрить несколько ВГ75 с разными каналами ПДП, можно как в том же Atari/Commodore чередовать текст и графику, если КСИ первого ВГ75 запускает тактирование второго ВГ75, который, в свою очередь, своим КСИ запустит третий ВГ75 - своеобразная карусель. И у каждого ВГ75 свои настройки развёртки.
Или теми же атрибутами основного ВГ75 организовать селективное тактирование вспомогательных ВГ75. Тогда в одной строке основного знакоместа можно разместить 2…4 строки вспомогательных знакомест и даже добиться подобия спрайтов…
Быстро проверить код - нету онлайн-эмуляторов.
Приходится запускать VMware и там уже возиться.
К тому же, в Специалисте нету директивы «M» и дамп травится как в «Микро-80» - очень резко, без прокрутки.
А так как я привык к плюшкам (да, плюшкам!) РК, для меня такая среда очень непривычно и всё для меня дико!
Подчёркиваю: 99% кода своего написал и отладил именно тут, так как в промежутках между пролистыванием форумов и новостных сайтов, если в голову пришла мысль - достаточно кликнуть на закладку.
Кстати, когда питомец запрыгивает на стол - сразу открываю страницу КСОНИКСА. Чем и призывает меня дорабатывать свои идеи!
Какой из эмуляторов ПК исполнен так минималистически просто и гениально‽
Именно в нём я и перелопатил весь Монитор, так как в случае краха достаточно нажать «Refresh» браузера. Тогда как другие эмуляторы принуждают создавать резервные копии файлов и возиться с их перекопировкой.
Практически 100% rom-файлов и 99% rkr-файлов моих здесь сгенерировано именно им: Мой Chrome-плагин (выложил ниже, если интересно) перехватывает точки вывода файла и по «OF800,FFFF» сохраняет rom-файл автоматически, а также и «световое перо» симулирует… То есть, я его превратил в настоящий инструмент, удобный именно мне. Причём, сейчас в нём же сгенерировал rkr-файл с прокруткой экрана стеком под ОРИОН-128 для Emu80 - всё работает.
(Хотя, вот сейчас нашёл онлайн ОРИОН-128. Но эмулятор - демонстрационный и инструментально на нём мало чего добиться можно…)

Вот и ZX-Spectrum я пытался за-РК'шить, вымыв его Бейсик и написать МОНИТОР. Но дальше той подпрограммы с выводом полноценного дампа и символами 6×8 дело не дошло из-за слишком неудобного редактора встроенного ассемблера. Из-за чего сообщество Спектрумистов обозлилось на меня и послали меня писать свой эмулятор, заявив, что в 8-битных технологиях я ничего не смыслю со своими PHP и JavaScript.
Из-за чего я и ушёл в подполье и стал проверять, правда ли мои мозги с этими PHP/JS/SVG совсем расплавились и не способны решать базовые задачи на реальных ЭВМ пост-апокалипсиса?
И всплыл именно здесь со своей «оконной подпрограммой» для РК как пародия на современные технологии.
В том и суть, что Вы свой Монитор переделываете со знанием своего дела.
А я лишь, в отместку сторонников Спектрума, с головой ушёл в РК.
Так как тот же Commodore/Atari - технологии соседнего континента, ZX-Spectrum - технологии Европы. А вот РК - наш, родной. Да и самый первый из доступных.
Он - как пластилин, как ядро, на которое можно навесить всё, что угодно!

В схеме D13 по LTEN сбрасывает ИР13 по-видимому…
Выше я тоже задавался вопросом:
Прежде всего, я проверяю свои мозги!
Не принципы, а выходной код.
На форумах часто сравнивают разные компиляторы и обсуждают, от чего тот или иной компилятор так или иначе чудит в таких-то случаях…
Всегда свой Бейсик хотел написать, но спотыкался на редакторе строки. А к арифметике вещественной вообще не знал, как подойти!
Сейчас - опыт какой-никакой имеется. Выше я делилки/умножалки свои показал. Осталось их допилить до вещества…
А экранный редактор мне в Atari-XE (он у меня в шкафу лежит с двумя дисководами) нравится, но дискет под него нет.
(Вот жалею, что не додумался 20 лет назад выкупить Atari-ST у одного, когда тот мне на тест его принёс на месяц с кучей дискет с играми. На Бейсике я там быстро разобрался и пищать/трещать удалось. Да потом дети хозяина его куда-то дели или разобрали в хлам, так как не смогли с мышкой разобраться и с телевизором.)

Кое-что…
Тут подумал, что в MS-DOS имелся FIFO-буфер клавиатуры. В РК любопытно было бы это тоже попытаться сделать, чтобы во время вывода долгого дампа можно было бы не одну букву нажать, а десяток.
В таком случае, в том же Бейсике, можно вызывать COUT, CHSUMM и WRBYTE через PRINT с параметрами…

Вообще-то…
В самом начале темы я прикидывал, как бы в РК сделать ОЗУ 128 Кб, где 64 Кб - системное и 64 Кб - пользовательское.
В отличии от остальных РЛК типа Ориона и Специалиста, в РК 128 Кб сделать, в каком-то смысле, легче…
Именно оттуда и вытекла идея переключать страницы по FF00…FFFF. Правда, если Вы внимательны, там - всего две страницы / банка по 64 Кб. Причём, память 128 Кб - лишь для одновременного доступа. А так, она может быть и в 1 Мб из 16 банков, лишь два банка доступны в один момент. А для доступа к соседним страницам не обязательно обращаться к подпрограмме Монитора, как в Орионе…
Тем более, сама микросхема ПДП прозрачно сигнализирует о своём доступе к памяти: Можно 1 Мб ОЗУ иметь и под экран подставить именно нужную страницу из 16.
Потому, именно РК привлекателен тем, что в нём нет ничего лишнего - ни теневого регенератора ОЗУ, ни рассыпухи под графический экран

Это Вы опоздали ровно на десятилетие. Это надо было делать в 80-тые годы, тогда это было актуально.
Я узнал о 64 МКС строчного периода, когда ускорял свой Специалист до 2.5 МГЦ. Как раз именно в Специалисте понятно как формируется растр, тогда как ВГ75 это "таинственный чёрный ящик" дающий видео.
Как же? Я свой РК86 настраивал пару месяцев. А первый Специалист спаял и настроил за два дня. Там искать ошибки на порядок проще, т.к работает экран.
Идея внешнего граф.адаптера. Только зачем для этого плата тормозного РК, - лучше любое МП-ядро, например, скоростное на Z80H. Это будет уже не РК и чем этот тормозной монстр с внешним видеоадаптером имеющий ноль программ превзойдёт Специалист?

По этому пути я уже прошёл в своё время. Когда настроил РК, то убогие РК-игры меня не взволновали (т.к тогда я уже видел игры ДВК и даже графические на БК-010), а огорчило отсутствие графики. Я делал РК, чтобы на нём изучать иностранные языки. Заучивание слов на РК вместо карточек шло намного быстрее (не надо на карточках ставить галочки, когда слово не вспомнил и сортировать их). Но выяснилось, что многих французских и немецких букв в РК просто нет. И тут знающие люди подсказали мне, что чтобы иметь на экране любые буквы необходим графический компьютер.

А тут как раз в журнале RFE 10.1987 опубликовали схему внешнего граф.адаптера на 29 микросхемах на 4116 (экран точно как у Специалиста). В начале 1988 я спаял себе эту платку. Но ассемблер только начинал осваивать и не смог сразу написать полноценный драйвер. Зато в ходе экспериментов с выводом букв обнаружил, что скорость вывода графики из РК низкая. Почти одновременно я настроил плату Специалиста, и выбор между нестандартным РК с прибамбасом или стандартным Специалистом был очевиден. Позднее я превратил платку граф.адаптера в плату эл.диска на РУ5.

А Вы теперь предлагаете снова использовать РК с прибамбасом, что означает создать новую платформу. Даже если не учитывать, что сейчас невозможно создать новую платформу с массовостью более, чем в один экземпляр, то вести речь о таком можно только предлагая готовую печатную платку прибамбаса и кучу программ. А зачем нужны графические прибамбасы к РК86, если есть Специалист и его маленькие по размеру печ.платы доступны.
Это уже пошла чистая маниловщина.
А онлайн-эмуляторы вообще не нужны, это просто извращение. У Вас просто такое хобби (если не сказать мания или можно это считать экстремальным видом спорта) - мучить себя машинными кодами в онлайн-эмуляторе.

Я быстрее проверяю код странслированный ассемблером или Паскалем, чем Вы в своём онлайн-эмуляторе. После того, как я закончил редактирование и моментом, когда написанная программа начала исполняться проходит не более двух секунд. Хлоп на кнопку и через 1.5 секунды я вижу на экране прогон. BAT-файл транслирует, запускает эмулятор, а эмулятор загружает в себя программу и запускает её. В нормальном эмуляторе есть отладчик, а не только какой-то убогий "режим консоли". Нормальные эмуляторы позволяют отлаживать программы и для DOS, эмулируют ВГ93, а онлайн-эмуляторы все предельно убогие.

Использовать онлайн эмулятор и программировать в нём в маш.кодах - это мазохизм. Конечно в этом хобби (по критериям полезности) все немного сдвинутые, но настолько, чтобы мазохистки мучить себя машинными кодами - это уж чересчур. Если уж так надо программировать прямо в эмуляторе, то в нём должен быть встроен текстов редактор и компилятор (лучше Си или Паскаля), что образует IDE. В своё время у меня промелькнула мысль встроить в свой эмулятор текстов редактор и ассемблер, но разработка в самом эмуляторе не стала бы быстрее и удобнее, потому отказался от этого.

Онлайн-эмуляторы для разработки это чушь. В онлайн-эмуляторах единственный смысл (и то сомнительный) в том, что это надо для случайных людей, чтобы просто познакомиться - пользователю не нужно иметь в своём архиве прогоняемые программы и разбираться в ОС конкретной ретро ЭВМ. Т.е это средство для забавы полных чайников. Довод о том, что не надо перекачивать себе программы несостоятелен, т.к расход трафика на работу эмулятора гораздо больше, чем объём прогоняемой программы.

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

Онлайн-эмулятор это возврат в 70-тые годы, когда пользователь имел дома терминал, модем со скоростью в 300 бод и связывался с многопользовательским майн-фреймом на другом конце страны и гонял на нём программы (в том числе, кросс-ассемблер и эмулятор-отладчик процессора 8080, чтобы отлаживать программы). Это имело бы смысл, если бы на том конце стоял супер-компьютер, который иметь дома невозможно, а какой смысл дистанционно гонять эмулятор для работы которого у человека достаточно своего железа (для эмуляции достаточно компьютера 40 летней давности, а я эмулировал РК86 на ОРИОНЕ и игры шли в нормальном темпе).
Это Вы про оригинальный монитор Волкова на 8D00. Я им пользовался, но после середины 1988 уже никто им не пользуется. В ROM-BIOS А.Волкова нет ролика экрана (по ВК на последней строке экран чистится и курсор на первую строку). Это недоработка не монитора, а ROM-BIOS.

Если запустить этот монитор с ленинградским ROM-BIOS (в котором и п/п C037 исправлена и делает ролик), то длинный дамп идёт с роликом. И если уж так хочется волковский монитор с роликом, то разве проблема в нём заменить вызовы C037 на вызов п/п-ммы C809, которая делает вывод с роликом. Монитор Волкова использовали только самые первые владельцы Специалиста, а 99.9% пользователей собравших его в 1988 и позднее использовали орловский монитор.
Имеете в виду кошатину и то, что она любит наблюдать бегающих по экрану ксониксов? У меня тоже кошатина лежит перед дисплеем. Кстати, на кинескопном экране бегающие объекты её не интересуют, только на плоском.
В любом эмуляторе есть эквивалент кнопки СБРОС. Гениально - это когда всё хорошо и правильно, а не когда всё примитивно.
Вы напрасно пытаетесь восхвалять убожество онлайн-эмулятора. Какие резервные копии? Какая перекопировка?

Вы можете запускать игры командной строкой из ОС, тогда эмулятор после загрузки сразу стартует игру. Кроме как монитором по МГ-директиве в эмуляторе можете грузить из отладчика по L, восстанавливать и сохранять состояние игры (всю память, регистры и адрес возобновления).

Что Вам ещё требуется? Из программ без DOS не надо ничего записывать в файл, а разработкой программ прямо в эмуляторах никто, кроме Вас, не занимается. Да и кто мешает записать файл на эмулируемую дискету или выгрузить в виде файла RKS или WAV.
Вообще-то думаю, что фанатам Спектрума "глубоко плевать какие там цветы", иными словами всем до лампочки, чем занимаются другие, пока это не мешает их хобби.

В отместку получилось бы, если бы Вы положили бы все силы, энергию и деньги на то, чтобы для РК86 появилось бы 5 тысяч игр качеством не хуже, чем игры ZX-Spectrum и переманили бы этим на платформу РК всех синклеристов. Один человек это не сможет, потому нужно много денег, чтобы нанять 200 программистов. Но увы, без платки прибамбаса к РК86 это невозможно в силу нехватки его изобразительных возможностей.

А вот для Специалиста, даже с его всего лишь 8-ю цветами игры уровня ZX-Spectrum возможны (особенно, если в Специалисте отключением ПЗУ "открыть" ОЗУ в 62 кб, добавить прерывания и м.быть даже заменить CPU на Z80). Я уверен, что несколько человек Вашего уровня владения ассемблером в состоянии написать "Принц Персии" для Специалиста, если объединятся. Я бы этим занялся и сам, но нет нужной графики, а если рисовать самому, то выйдет убожество.
Для чисел с плавающей запятой есть библиотеки (они были у всех с ОРИОНОМ). Я написал свой целочисленный бейсик в середине 90-тых (не из потребности, а из интереса, чтобы доказать себе, что не глупее Билла Гейтса). Это заняло 3 недели, но объём кода получился 5 кб, хотя это был TINY бейсик и писал я для Z80.
Это легко (я делал на один символ), достаточно после вывода каждой строки вызывать п/п F81B.
Чем Вам не нравится прокачка доп.ОЗУ в окне размером в 8 кб (на A000...BFFF) ? Сейчас реально добавлять в РК только что-то очень простое, что каждый легко может сделать на базовой плате РК имея маленький электропаяльник. Установка статики в окне, требует кроме самого этого ОЗУ только регистр (для адресов A13 и выше).
Ну так и поднимите его своим творчеством на недосягаемую высоту сделав много программ высокого качества. А делать из РК86 новую платформу этому не способствует.
Не к тому у вас патриотизм и симпатии. Это гнилое и очень тормозное небуферизованное ядро с уродской архитектурой, к тому же не могущее работать в реальном времени. Что-то на него навешивать не имеет смысла. Есть Специалист, где есть всё что надо. Он простой и параметры приличные. И их при нужде ещё и улучшить можно простейшими доработками, которые можно сделать за полчаса имея электропаяльник.

Нe так я стар.
Среднюю школу только окончил тогда (25 лет назад)
ZX-Spectrum тоже дискретно построен. Однако, там специфический растр и тогда я толком не смог разобраться с ним. Изучал схемы Специалиста и Ориона, а ещё Иришу - книжку масштабных размеров изучал…

Если в чате познакомился с кем-то и нужно быстро показать предмет своих исследований - идеальнее онлайн-эмулятора не найти способа, чем парить человека инструкциями по установке чуждой ему среды…
А трафик у меня сейчас (наконец-то) - анлим за 750 рублей в месяц.
Правда, ADSL-связь - как в поганом колодце с тиной бывает временами.
Причём, в соседней комнате у сестры - оптика. Но качество и цена… Мой ADSL выгоднее…
То ли здесь, то ли на других форумах, я уже обсуждал вопрос о возврате мэйн-фреймов.
Сейчас вон Облачные технологии всюду - от простых файловых помоек, до оплачиваемых аккаунтов для аренды игровых серверов под запуск прожорливых игр, позволяющих на слабых ноутбуках гонять новейшие игры.
На том же РК игры меня интересовали, пока перебивал их на свои 16 Кб. Как перебил и, в целом, научился программировать, взялся за написание своих Тетриса и Жизни в машинном коде. А на Бейсике лишь переделывал листинги с IBM-PC Альфа-Бейсика и мечтал о графике!
Смейтесь, смейтесь!
Тут одну бы игру написать получилось бы!
В том и дело, что в РК с его ВГ75 для вывода символа на экран достаточно двух команд «LD HL…LD (HL)» в пять байтов и без стека
В том же Специалисте без организованного стека для вызова подпрограммы вывода символа на экран не обойтись!

Понимаете, в чём суть?
Сейчас маломальских электронщиков со всякими PIC/ATMEGA графика вообще не интересует.
Им главное считать сигнал с АЦП, произвести анализ и пощёлкать там реле под тёплый пол…

И вот здесь РК - идеально подходит для оттачивания 8-битных алгоритмов в условиях сильнейшего дефицита регистров.
И тут даже не в производительности дело. А в компактности кода.

P.S.: Кстати, вчера вечером начал в онлайн-эмуляторе и сейчас закончил написание/отладку сложнейщего (для меня) кода деления 24-битных чисел (пф-ффф)…
Теперь дамп (в демке) травится 24-битными целыми без знака.
Можно будет приступить и к плавающей запятой, когда пойму базовые принципы. А там - и до Бейсика не далеко…
(Написание целочисленного Бейсика, как в Правце, меня не интересует…)

P.P.S.:
В своей теме CISC-x80 я тихо продвигаюсь вперёд к своей школьной мечте - реализовать свой РК на своём процессоре. И в эмуляторе я симулирую именно экран РК, так как в том эмуляторе свой первый вариант оконной подпрограммы и прогонял, чтобы выявить баги.
ГигаТрон - тоже платформа с нулевой поддержкой готовых программ. Однако, люди как-то этим занимаются и нарабатывают.
(Эмулятор онлайн позволяет, не захламляя лишний раз свой диск, за минуту получить общее представление о платформе и понять, нужно ли скачивать вообще это или нет…)

Кстати… Будь у i8080/z80 одна единственная инструкция с реверсией порядка бит HL, это значительно бы упростило всё! Вот «ADC HL,HL» прокручивает все 16 бит влево без всяких мелких «RLC». Если бы была реверсия, то и вправо крутить можно было бы. Даже в x86 «BSWAP» просто меняет местами октеты, а не биты.
(RLD/RRD не в счёт, так как это две отдельные специфические команды…
К тому же у Z80 не всё так гладко: Инструкция BIT могла бы возвращать бит не флагом ZF, а флагом CF: ZF годен только для операций ветвления, тогда как CF позволяет без ветвлений строить линейный код - обратите внимание на мой вариант вывода байта на магнитофон, где константа 14 отнимается линейно и формируется маской…)
Будто это так сложно на кристалле сделать, перекрестив все 16 проводков. В подпрограмме деления эта реверсия здорово бы помогла!
Неужели за 50 лет этой инструкцией никто не востребовался‽
(В своём x80 я сразу эту инструкцию ввёл в систему команд, так как аппаратно она до элементарного проста и требует 4 такта, но в узких местах программы позволяет существенно упростить код…)

Если уж речь в этой теме пошла о полезных доработках ПЗУ РК86, то стОит упомянуть о двух недоработках драйвера клавиатуры.

Драйвер в ПЗУ РК надо чуть изменить, чтобы вводился так называемый "код подчёркивания" (5F), который стандартным драйвером не вводится, но код в ПЗУ знакогенератора есть. В доработанном мониторе ОРИОНА (который называется М3) добавка возможности вводить этот символ обходится всего в две команды ассемблера, но оказалась очень полезной. Благодаря этому у меня во всех ассемблерных исходниках набранных на самом ОРИОНЕ использованы символы подчёркивания (хотя лишь в 1999 году, когда закончил свой эмулятор ОРИОНА Z80 я смог набирать и отлаживать программы для ОРИОНА на PC, где символ подчёркивания есть на клавиатуре).

Кстати, хотя этот довод не актуален, ибо никто не программировал на РК86 на Си в силу полного отсутствия CP/M на базовом РК (CP/M не было на оригинальном РК и даже на РК-подобных с большим ОЗУ не было, т.к секрет подключения дисковода открылся только в 1993 году, когда в стране уже полностью прекратился выпуск РК-подобных, а популярность самого РК86 резко упала), но без символа подчёркивания не удастся на Си часть модулей делать на ассемблере или других ЯВУ, т.к компиляторы Си перед именами переменных из внешних модулей прибавляют символ подчёркивания.

Второе замечание о том, что в подпрограмму GETLIN надо добавить обслуживание кода клавиши <BAKSPC> или <ЗАБОЙ> (это код 7F). Использование вместо этого кода курсорной клавиши <ВЛЕВО> это какой-то маразм распространившийся из-за авторов Микро-80, совершенно вне общемировой практики (возможно на ранних версиях клавиатуры Микро-80 не было нужной клавиши).

Идея конечно не для ПЗУ (т.к там для этого нет места), - помню, что в каком-то моём драйвере GETLIN клавиша <ВЛЕВО> работает как положено, - перемещает курсор без забоя (и клавиша <ВПРАВО> соответственно тоже работает как положено, позволяя полноценное редактирование строки с помощью вставок/удалений символов). Вроде бы в каком-то бейсике РК редактирование строки сделано также. А у меня в этом драйвере GETLIN дополнительно ещё курсорная клавиша <ВВЕРХ> вводит на экран (и соответственно в буфер редактирования) предыдущую введённую строку введённую этой подпрограммой ввода строк (что-то типа памяти на введённые ранее строки драйвера DOSEDIT в MSDOS, что кстати, есть также при вводе команд в окне MSDOS в Win XP, но у меня это лишь на одну строку).