Paguo-86PK - XXI BEK

[Paguo-86PK]

Переписaл подпрограммы работы со строками:

Code: Select all

        ORG  0F8DEH
TXT_BCK:OR   H              ; Если H < 10000000
        JP   P,TXT_ASC
        DEC  H
        DEC  L
        DEC  DE
        CALL MSG_PC
        DEFB 008H,020H,088H ; Инлайн-текст токен-вида
        JP   TXT_ASC
TXT_GET:LD   HL,03FF0H      ; Точка входа:          H=00111111 L=-16
TXT_RET:LD   DE,07633H      ; Точка выхода
        ADD  HL,HL          ; CF=0 если буфер чист: H=01111111 L=-32
        RET  Z              ; Возврат, если нажат <ВК>
TXT_ASC:CALL 0FE63H
        CP   02EH  ; 01BH
        JZ   0F86CH
        CP   008H
        JP   Z,TXT_BCK
        CP   07FH
        JP   Z,TXT_BCK
        LD   (DE),A
        CP   00DH
        CALL 0FCB9H
        JP   Z,TXT_RET
        INR  H
        INR  L
        JP   Z,0FAAEH
        INC  DE
        JP   TXT_ASC
MSG_PC: EX   HL,(SP); В сэкономленные 7 байтов
        CALL 0F922H ; теперь уместилась
        INC  HL     ; подпрограмма печати текста
        EX   HL,(SP); инлайн-методом
        RET
MSG_HLI:INC  HL    ; Вспомогательная точка инкремента
MSG_HL: LD   A,(HL); Реальная точка вызова F922
        OR   A
        RET  Z     ; Возврат, если нуль-терминатор
        CALL 0FCB9H
        RET  M     ; Возврат, если токен-терминатор
        JMP  MSG_HLI

Вот основные из искейп-команд самого-самого нижнего уровня, что нужны для организации оконности. Это именно на это Вы замахнулись объявляя, что вводите оконность в драйвер вывода.

Эx… Вот будто брезгуете моим кодом!
У меня Escape-последовательность постфиксная: Сначала аргументы (десятичные), а потом - буква. Как в ANSI.
В моих исходниках (понимаю, Intel-мнемоника - мусор), тем не менее, драйвер так и работает:

Code: Select all

; Установка общего вьюпорта:
; Левый край - 8 колонок
; Верхний край - 3 строки
; Ширина - 64 символа
; Высота - 25 строк
    DEFB    01BH,'8 3 64 25V'
; Установка дочерного вьюпорта
; внутри родительского
; по принципу "матрёшки"
; Абсолютные параметры получатся следующие
; Левый край - 10 колонок (8 + 2)
; Верхний край - 8 строки (3 + 5)
; Правый край - 26 символ (10 + 16)
; Нижний край - 16 строка (8 + 8)
    DEFB    01BH,'2 5 16 8Q'
; Запомнить вьюпорт в стеке
    DEFB    01BH,'S'
; Восстановить вьюпорт из стека
    DEFB    01BH,'R'
; Помимо прочего, аргументы - целый числа
    DEFB    01BH,'-1-2-3+4' ; Запомнит (255,254,253,4)

Конечно, из списка мало что реализовано, так как я прощупывал способ задания параметров…
Десятичный - удобный для ручного ввода или Бейсиком: «PRINT CHR$(27);"+56 -76 8,15W"»
Но сложен для прикладных программ на уровне ассемблера, так как необходимо выдавать именно десятичный величины текстом, где вместо «PRINT CHR$(27);"Y";CHR$(32+Y);CHR$(32+X);» нужно выдать «PRINT CHR$(27);X;" ";Y;"X";»…
Отчего прогресс застрял…

[barsik]

Текст на ассемблере с цифровыми адресами переходов не намного информативнее дампа. Никто не держит в голове HEX-адреса внутренних точек ПЗУ РК. Вот представление подпрограммы ввода строки из последнего поста в более понятном виде.

Code: Select all

ZABOJ:  OR      H              ; Если H < 1000.0000B
        JP      P,GTLLOO
        DEC     H
        DEC     L
        DEC     DE
        CALL    MSG_PC
        defb    8,32,8+128
        JP      GTLLOO

GETLIN: LD      HL,03FF0H      ; Точка входа:          H=0011.1111B L=-16
TXT_RET:LD      DE,07633H      ; Точка выхода
        ADD     HL,HL          ; CY=0 если буфер чист: H=0111.1111B L=-32
        RET     Z              ; Возврат, если нажат <ВК>
GTLLOO: CALL    CONIN
        CP      '.'
        JP      Z,WARMST
        CP      8
        JP      Z,ZABOJ
        CP      7FH
        JP      Z,ZABOJ
        LD      (DE),A
        CALL    COUT_A
        CP      13
        JP      Z,TXT_RET
        INC     H
        INC     L
        JP      Z,ERROR
        INC     DE
        JP      GTLLOO

Чтобы понять логику загрузки регистров по выходу из п/п-мы GETLIN надо прогонять отладчиком и разбираться. Тут уж слишком хитроумно. За такое программистов увольняют. Требуется не изощрённость, а понятность, чтобы другой программист смог быстро понять. Где так наворочено со значениями регистров комментарием нужно пояснять алгоритм.

Такую п/п GETLIN нельзя вызвать имея флаг Z=1, это потеря универсальности. Сейчас это помнится, а вскоре забудется. GETLIN используется программами, и как раз чаще всего эту п/п-мму и вызывают с флагом Z=1 (т.к сразу после CALL MSSG для печати приглашения). Уж настолько ради экономии байтов извращаться не стоит.

Во фрагменте есть две идеи - чтобы с'экономить на PUSH-POP-е для HL нужном перед CALL MSSG, указателем по строчному буферу использован DE. А чтобы не грузить DE началом строчного буфера по выходу - вход делается выходом.

Смена HL на DE в GETLIN не нужна при использовании для вывода текста п/п-ммы MSG_PC, т.к там регистр HL как раз сохраняется. Я применю лишь MSG_PC (я привык это называть RST_18), а вот извращение с входом = выходом с использованием флага Z - нет, т.к это нарушит совместимость.

Вот основные из искейп-команд...

брезгуете моим кодом!

Зачем такие выражения? Я смотрю, что могу. Я лишь напомнил, что DOS и ЯВУ управляют выводом стандартными искейп-командами (там чисто текстовые последовательности стандартны из VT52, а оконные взяты из драйверов разных авторов из разных источников и по большей части также могут считаться стандартными, хотя стандартов на это нет).

Если же Вы придумываете нестандандартный интерфейс, то это будет интерфейс только для Вас. Но я приводил искейп-коды не ради самих кодов (кроме кодов VT52 они м.быть иными), а чтобы в очередной раз указать, что суть не в задании границ окон, а в сохранении исходного содержимого при открытии и его восстановлении при закрытии окна.

Сначала аргументы (десятичные), а потом - буква. Как в ANSI.

Это возможно лишь когда параметры задаются ASCII, а не байтами. И это неудачно. Абсолютно нестандартно для 8-ми разрядок и по времени дольше. При байтовой передаче параметров так нельзя. Иначе как тогда драйвер разберётся, если параметр и буква команды совпадают? Ведь длины всех искейп-последовательностей разные и драйвер не знает где команда, а где параметр.

дочернего вьюпорта

Слово окно всем понятно, а какой-то вьюпорт это что-то непонятное и абсолютно ненужное. Зачем засорять русский язык англиканизмами?

; Правый край - 26 символ (10 + 16)
; Нижний край - 16 строка (8 + 8 )

Обычно задают X,Y и дельта X и дельта Y. Т.е левый вехний угол окна и ширину и высоту. Особенно это разумно для РК86, где и само поле вывода является видимым окном в полном экране (3 сверху, 2 снизу, 8 слева, 8 справа)

; Запомнить вьюпорт в стеке
; Восстановить вьюпорт из стека

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

где вместо «PRINT CHR$(27);"Y";CHR$(32+Y);CHR$(32+X);» нужно выдать «PRINT CHR$(27);X;" ";Y;"X";»…

Добавляют к X,Y код 20H потому, что коды менее 20H не проходят сквозь CONOUT. А строки с нулём не пропускает MSSG.

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

EX HL,(SP)

Вместо INR лучше писать INC, а вместо EX HL,(SP) ---> EX (SP),HL. Иначе ни хрена не ассемблируется.

PS. Оконный драйвер должен возвращать параметры программе (и не с CONIN, как принято в некоторых терминалах) !

[Paguo-86PK]

Тут уж слишком хитроумно. За такое программистов увольняют.

Тo есть, будь я программистом - уволили бы с должности за безобразия?
А мы здесь какую цель, кстати, преследуем?
Ужать МОНИТОР или сделать его яснее?
Разве наш(?) труд - не забава матёрых?

Такую п/п GETLIN нельзя вызвать имея флаг Z=1, это потеря универсальности. Сейчас это помнится, а вскоре забудется. GETLIN используется программами, откуда уверенность, что нет вызовов при Z=1? Уж настолько ради экономии байтов извращаться не стоит.

В 7 байтов резерва я сунул MSG_PC. Если её удалить, можно, как в Орионе, вставить туда вместо ERROR и WARMST переходы на адреса из служебных ячеек…

Не ясна терминология. И не указано о чём речь? Что за дурной вьюпорт, нет такого слова.

«Окно» в XXI веке подразумевает полноценное окно с событиями и сообщениями. А вьюпорт - лишь область, ограниченную прямоугольником.
У меня до ОКОН ещё очень далеко (сама CONIN должна отлавливать нажатие клавиши TAB и переключать контексты - в планах у меня)…

Речь о сохранении в стеке 4-х байтов параметров окна? Или о сохранении в оконном буфере содержимого окна и его параметров?

Только параметры окна…
Под указатель стека окон я использую служебные ячейки Монитора, где директива «X» хранит регистр SP…

[barsik]

Исходно в уплющенном ПЗУ было свободно 224 байта. Загон адреса точки ERROR в стек (чтобы вылетать туда по команде RET вместо JMP) в п/п-ме GET_HL дало не 4, а 3 байта, но ещё один байт дала вставка ниббла из A в HL по OR L вместо ADD HL,BC. Итого GET_HL сократилась на 4 байта (стало свободно 228 байтов).

А вот применение для вывода текстов RST_18 (MSG_PC) на четырёх текстах (TITR, PROMPT, TZABOJ и TRIGH4) дало экономию в 10 байтов. Итого сейчас странслировал версию ПЗУ РК, где свободно аж 238 байтов. Директивы монитора работают, но всё равно надо погонять с сист.программами и играми, проверить на совместимость.

Раз уж экономия приближается к полезным величинам, то думаю п/п-мму RIGHT4 упразднить (заменю на возврат каретки), что с'экономит ещё 3 байта (т.к там я уже и так убрал 1 байт, чтобы дамп был вровень с промптом) . Сдвиг применен, чтобы сдвигать дампы и сообщения вправо на 4 позиции и это не особо надо. Если картинка отцентрована на телевизоре правильно, то и самая левая колонка должна быть видна.

[Paguo-86PK]

A не думали ли про унификацию точки возврата?
Чтобы возврат по точке или по ошибке шёл не на F86C, а на значение слова из 76CD, так как там и так это значение. Приложения и так сами устанавливают стек, а в 76CD могли бы занести точку возврата на себя.
Тогда бы операции с магнитофоном, в случае ошибки, в том же ассемблере/Бейсике не выкидывали бы в промпт Монитора…

Code: Select all

    ORG  0F87CH
    LD   HL,0F86CH
    PUSH HL
    CALL 0F8EEH
    ...

; Теперь все ссылки на F86C нужно перенаправить на
; подобный код
    LD   HL,(076CDH)
    JMP  HL

Эти 4 ячейки можно добыть так:

Code: Select all

    ORG  0F830H
    LD   HL,(07631H)
    ORG  0FF52H
    LD   HL,(076CDH)
    JMP  HL

Директивы монитора работают, но всё равно надо погонять с сист.программами и играми, проверить на совместимость.

Простo Вы увлекли меня в гонку вооружений замечанием про «Третий Закон Ньютона» с формулой «Call+Ret = Jmp», что меня задело
И дало сильный стимул развернуться по полной программе…

P.S.: Спасибо!

[barsik]

Спасибо!

Это Вам спасибо. Без ваших идей по оптимизации, я бы не вернулся вновь к оптимизации ПЗУ РК, и не отыграл бы еще почти 40 ячеек (недостающее место пришлось бы выигрывать выкинув неактуальные директивы).

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

[Paguo-86PK]

Это Вам спасибо.

A не думали ли про унификацию точки возврата?
Чтобы возврат по точке или по ошибке шёл не на F86C, а на значение слова из 76CD, так как там и так это значение. Приложения и так сами устанавливают стек, а в 76CD могли бы занести точку возврата на себя.
Тогда бы операции с магнитофоном, в случае ошибки, в том же ассемблере/Бейсике не выкидывали бы в промпт Монитора…

Code: Select all

    ORG  0F87CH
    LD   HL,0F86CH
    PUSH HL
    CALL 0F8EEH
    ...

; Теперь все ссылки на F86C нужно перенаправить на
; подобный код
    LD   HL,(076CDH)
    JP   (HL)

Эти 4 ячейки можно добыть так:

Code: Select all

    ORG  0F830H
    LD   HL,(07631H)
    ORG  0FF52H
    LD   HL,(076CDH)
    JP   (HL)

 Пример кода

Code: Select all

    ORG  0
    LD   SP,075FFH
    LD   HL,MY_ERR
    LD   (076CDH),HL
    LD   HL,TRAP1
    LD   (RES+1),HL
    LD   HL,MSG1
    CALL 0F818H
    CALL 0F8EEH
TRAP1:
    LD   HL,TRAP2
    LD   (RES+1),HL
    LD   HL,MSG2
    CALL 0F818H
    CALL 0F806H
TRAP2:
    LD   HL,MSG3
    JP   0F86CH
MY_ERR:
    LD   HL,ERR_M
    CALL 0F818H
RES:LD   HL,0F86CH ; Resume After Break
    JP   (HL)
MSG1:DB  13,10,'* prowerka wwoda konsoli *',13,10,0
MSG2:DB  13,10,'* prowerka o{ibki fajla *',13,10,0
MSG3:DB  13,10,'* test okon~en... *',0
ERR_M:DB 13,10,'--- o{ibka ---',13,10,0

И будет практически как в Орионе!

• 0F3D8H — ячейка, содержащая адрес возврата из подпрограммы чтения байта (OF806H) при „зависании“ или выпадании сигнала. МОНИТОР заносит в эту ячейку адрес „теплого старта“. Программа пользователя должна заносить в эту ячейку свой адрес возврата, в противном случае при невозможности чтения байта программа осуществит возврат в МОНИТОР.

P.S.: Сам РАДИО-86РК уникален и ценен тем, что у его владельцев мозги не проржавеют
(Лопатить - не перелопатить его чудный МОНИТОР!)

[barsik]

про унификацию точки возврата? Чтобы возврат по точке или по ошибке шёл не на F86C, а на значение слова из 76CD... Тогда бы операции с магнитофоном, в случае ошибки, в том же текст.редакторе и Бейсике не выкидывали бы в промпт Монитора

Это не точка возврата. Это Warm Start, горячий рестарт монитора играющего роль ОС. И засылка в стек адреса WARMST служит сразу для двух целей: возврат по RET в CCP после отработки директивы и для того, чтобы запуск по <G> был вызовом по CALL. Т.е, чтобы из программ РК (как это сделано и в программах CP/M) возврат в ОС был возможен по RET.

Кстати, в ОРИОНЕ, т.к там есть потребность перезагружать ОС из ROM-диска (что делается по WARMST), там точки WARMST и вход в CCP не совпадают - по WARMST грузится ОС из ROM-диска, а на вход CCP идёт возврат по отработке директив.

Насчёт точки ERR_MG в ОРИОНЕ. Да в ОРИОНЕ есть место где хранится адрес, куда делается вылет в случае обрыва сигнала с магнитофона. Но вылет туда происходит не по программной ошибке (типа неверна КС), а по тайм-ауту сигнала.

Для этого в ОРИОНЕ - специальная подпрограмма LDBYTE с контролем наличия фронтов (которая при этом в М3 в 2 раза короче, чем в РК). В ней если более 16/32 циклов опроса сигнал на выходе компаратора не меняется, т.е не приходит очередного фронта с МГ-ленты, вот тогда и происходит аборт МГ-ввода по тайм-ауту. Тогда и делается переход по адресу из ячеек F3D8/D9, куда кстати, при работе монитора загружен адрес вх.точки ERROR (а не адрес "тёплого старта", как Вы написали). А в оболочках и в многоблочных защитах от копирования там помещают другое число, отчего там выводится другое сообщение в окне.

Потому, если при вводе с МГ-ленты в ОРИОН звук обрывается досрочно до окончания ввода, то сразу возникает ошибка. А РК86 так и будет продолжать вводить с МГ-ленты до окончания электричества.

Так что не надо приравнивать стандартную точку WARMST (она стандартная потому, что на неё выходят по завершению очень многие программы) к адресу вылета по тайм-аут при вводе с МГ-ленты, тем более, что в РК нет не только точки вылета по тайм-аут, но и сам тайм-аут не контроллируется, а вместо этого делается регенерация ОЗУ.

Лопатить - не перелопатить его чудный МОНИТОР!

Не согласен, что монитор чудной. Очень неплохо написанный, тем более с учётом 1985 года за окном. Для сравнения, родной ROM-BIOS Специалиста из той же эпохи написан на более слабом уровне (как факт, не имеет даже ролика экрана, курсор из последней строки переходит в первую). А ПЗУ ОРИОНА намного более сложное, чем ПЗУ РК86.

Сам "Радио-86РК" уникален и ценен тем, что у его владельцев мозги не проржавеют

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

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

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

Потому, по сути, Вы занялись не тем. Без разницы насколько крутой ROM-BIOS у компьютера, если он выводит тошнотворную картинку. Потому гораздо более актуальна и полезна для фанатов РК была бы деятельность по улучшению изобразительных возможностей РК86. Т.е нужны не программисты, а аппаратчики и изготовители плат, которые могут создать доработанный РК86 имеющий кучу фонтов, цвет, ну и заодно побольше ОЗУ, ПЗУ и ROM-диск прямо на плате. А имея КОИ-8, тайлы для игр, инверсию, цвет и псевдографику 192*102 уже можно подумать о окнах.

[Paguo-86PK]

Это не точка возврата. Это Warm Start, горячий рестарт монитора играющего роль ОС.

Тeм не менее, фишка работает - проверил…

Как раз Вам выгоднее всего перейти на Специалист, он такой же простой, а что ценно для Вас - при установке Z80 он может прогонять даже все программы РК86.

И "Специалист" отец собирал по журналу «Моделист-Конструктор», но почему-то не дособрал (панельки под ОЗУ дефицитом были) и не допаял…
Однако, многие публикации с дампами я изучал и на РК проверял, написал эмулятор графики Специалиста, чтобы увидеть картинку псевдографикой РК, скролля её клавиатурой
(Помню, чего мне стоило разобрать дамп одной из игр Специалиста, перелопатить вывод графики в буфер моих резиновых 16 кб и отобразить это средствами ВГ75: Извращение ещё то!)

Потому, по сути, Вы занялись не тем. Без разницы насколько крутой ROM-BIOS у компьютера, если он выводит тошнотворную картинку. Потому гораздо более актуальна и полезна для фанатов РК была бы деятельность по улучшению изобразительных возможностей РК86. Т.е нужны не программисты, а аппаратчики и изготовители плат, которые могут создать доработанный РК86 имеющий кучу фонтов, цвет, ну и заодно побольше ОЗУ, ПЗУ и ROM-диск прямо на плате. А имея инверсию, цвет и псевдографику 192*102 уже можно подумать о окнах.

Тем не менее, в данной теме, как минимум, две версии «Монитора» есть: Ваш и мой

P.S.: Всё равно заняться нечем. И свой x80 пока не могу продолжать разрабатывать.
А модифицирование Монитора мне нужно практически именно под x80. И на РК я практикуюсь Мониторо-писательством, так как в детстве считал, что программировать ПЗУ - удел богов от технологий!

[barsik]

Вот здесь исходник и коды стандартного монитора РК86, в котором свободно 243 байта. Если кто-нибудь знает способ как освободить ещё хотя бы один байт, пожалуйста не стесняйтесь поделиться этой идеей. По работе отличие данной версии от оригинала только в отсутствии директивы X и удалена стоп-точка для директивы G.

Тем не менее, в данной теме, как минимум, две версии «Монитора» есть: Ваш и мой.

Пока это большое преувеличение. Вашего монитора в виде 2048 байтов кода Вы пока не выложили (конечно выкладывать следует вместе с подробным описанием). А я ещё даже и не начал модификацию монитора РК, я лишь уплющил объём кода программы Попова и Зелёнко за счёт оптимизации и удаления ненужного. Хотелось бы конечно довести свободный объём до 250 байт. Ещё 3 байта выиграть легко (заменив п/п-мму RIGHT4 на CR). Теоретически ещё 4 байта легко поиметь укоротив сообщение о КС до "KS=".

Всё равно заняться нечем.

Как нечем заняться?

Если Вы уж так зациклены именно на РК86, то интересная задача сделать графическую игру для РК86 используя особый фонт с тайлами (символами фонта являющимися фрагментами фигурок и пейзажа), возможно даже не на ассемблере, а на ЯВУ. Никто ещё не написал такую игру используя идеологию Денди и никто ещё не писал игр на ЯВУ (не считая игры kakos-nonos-а на PL/M). Но если решите перейти на более приличный самодельный компьютер, то для Вас как раз есть в запасе две интересные задачи - адаптировать "Принц Персии" для Специалиста и написать файловый менеджер в стиле GUI для него.

[Paguo-86PK]

Вот здесь исходник и коды стандартного монитора РК86, в котором свободно 243 байта. Если кто-нибудь знает способ как освободить ещё хотя бы один байт, пожалуйста не стесняйтесь поделиться этой идеей. По работе отличие данной версии от оригинала только в отсутствии директивы X и удалена стоп-точка для директивы G.

Набрaл «DF800,F97F» и сразу заметил, что:

• Сместили точку «холодного старта» и упразднили чистку ячеек
• Клавиатурную таблицу сместили на F91B
• Директиву «F» вставили F8D6

Пока это большое преувеличение. Вашего монитора в виде 2048 байтов кода Вы пока не выложили

Давно же выложил

Естественно, предварительно эмулятору нужно подложить мою версию ПЗУ…

(конечно выкладывать следует вместе с подробным описанием)

Никто в журналах не выкладывал исходники в большинстве случаев - одни дампы

Если Вы уж так зациклены именно на РК86, то интересная задача сделать графическую игру для РК86…

Boulder Dash уже написали же

[barsik]

Давно же выложил

Я думал это полуфабрикат. Директива D не работает (просмотр только по одному байту). Даже знак вопроса по ошибке возникает не там. А на процессоре Z80 вообще не работает!

Boulder Dash уже написали же

Как могли это сделать, если в РК нет фонта с тайлами. Возможно Вы имеете ввиду псевдографику 128*62. Игра по принципу Денди это иное. До введения альтернативных фонтов специально для игр или применения схемы для загрузки фонта на РК могут быть только некрасивые игры из буковок и цифр, кого это впечатлит? Потому-то никто с 1991 года больше не хочет писать игры для РК. Никому не нужны очередные такие же некрасивые игры.

Набрaл «DF800,F97F» и сразу заметил, что:

• Сместили точку «холодного старта» и упразднили чистку ячеек
• Клавиатурную таблицу сместили на F91B
• Директиву «F» вставили F8D6

Все нужные точки в моих версиях мониторов (для всех компьютеров) всегда на месте. Лучше наберите DFF00,FFFF и посмотрите сколько есть в конце ПЗУ свободного места.

Точка F836 в программах не используется, это вовсе не стандарт. Она всегда сдвигается, когда добавляются доп.подпрограммы и это никому не вредит. Все ваши пункты абсолютно мимо. Где стоИт код конкретной директивы и таблицы данных никого не волнует, никто туда никогда не лезет. Если Вы в своём ПЗУ подгоняли точки входа в директивы, то это совершенно напрасно.

Неграмотные программисты лезут внутрь ПЗУ лишь всего на адреса десятка подпрограмм. Да и то таких игр, что так делают, очень мало (т.к идиотов было мало). С моими ПЗУ будут работать, как минимум, 98 процентов игр, т.к все точки, на которые я когда-либо встречал обращения, сохранены.

В принципе, при серъёзном отношении надо не полениться, найти все РК-игры от извращенцев и исправить. Это несложно (кусочек кода в несколько команд заменяющий внутреннюю подпрограмму ПЗУ добавляется в конец программы). Таких программ немного. Хотя мне не сложно сохранять от сдвига всего десяток точек внутри ПЗУ. Кстати, если обнаружатся игры, что лезут в какую-то ещё неучтённую внутреннюю точку, то её несдвигаемость будет несложно добавить.

Например, встречал игру с автонастройкой на объём ОЗУ, что контроллировала даже сам код ПЗУ - читала в ПЗУ третий байт в команде LD SP,76CF (на F83C), и делая вывод, что объём ОЗУ 32 кб, если там число 76 и - 16 кб, если 36. Но это буквально единичные извращенцы (т.к проще посмотреть что в регистре стека, чем привязываться к коду ПЗУ). Вот именно такие горе-программисты, игнорирующие советы авторов РК и здравый смысл, и стали преградой для улучшения ПЗУ.

[Paguo-86PK]

«D0000 017F» - пробел используется вместо запятой и Esc вместо точки…
Демку не забудьте…
«G0», «G1», «G2», «G3»…
По «G4» работают стрелки, Tab и «ВК»…

Я думал это полуфабрикат.

Тaк и есть…

Директива D не работает (просмотр только по одному байту). Даже знак вопроса по ошибке возникает не там.

Говорю же, параметры разделяются пробелом, а не запятой.

Точка F836 в программах не используется, это вовсе не стандарт. Она всегда сдвигается, когда добавляются доп.подпрограммы и это никому не вредит.

То ли Slams, то ли Karate проверяет эти ячейки и воспроизводит музыку через A000, если там не байт РК (Микроша?)…

Все ваши пункты абсолютно мимо. Где стоИт код конкретной директивы и таблицы данных никого не волнует, никто туда никогда не лезет. Если Вы в своём ПЗУ подгоняли точки входа в директивы, то это совершенно напрасно.

Вообще-то мысль как-то была даже перетряхнуть всю ASCII-кодировку, так как её сделали не очень то интуитивно ясной…
Например, вот так:

my_ascii.png

Во-первых, 32 управляющих кода в XXI веке и много (интернет использует «\r», «\t», «\0»), и мало (стили и классы ими не закодируешь все)…
Во-вторых, все знаки расположены интуитивно прозрачно:

• «2» и «%» как сёстры похожи, как «7» и «?»
• «6» и «9» перевёрнуты, как «(» и «)»
• «5» очень похожа на «$», как и «8» на «&»
• «@» и «O» тоже похожи
• В ряде с цифрами «0…9» арифметическим операторам и десятичным точкам место более подходящее
• В таблице один лишь спец-символ - «Esc» с кодом «\0»

Тем самым, если под РК адаптировать таблицу (эта - под PC: У меня раскладки клавиатуры сейчас в этом режиме), то можно заглавные и строчные символы уместить легко (исключив графические повторы Кириллицы, как «А», «Е» и т.п…)
Тем самым, в качестве эксперимента локального, можно было бы не только РК перетряхнуть, но и ASCII…
(Предвосхищая вопрос про «Tab» и «Enter»: Завершение строки - всегда двойным нулём «00 00». То есть, «Esc Esc». Здесь «Tab» - «00 7F», а «CR» - «00 2F». И т.п.)
И программы уже могут выглядеть вот так примерно:

Code: Select all

for(int i = 0; i ≤ 255; i ++)
    arr[i] = i ≠ n ? i : i « 1;

[barsik]

Демку не забудьте...

Это я уже видел. Выводить 78 символов в строке возможно только в эмуляторе. С точки зрения реализации оконности пока это даже не полуфабрикат. Куда можно использовать такое ПЗУ, которое всё, что в смысле оконности умеет, - это нарисовать рамку с межстрочными разрывами и ограничить вывод текста окном?

Вообще переделывать стандарт подпрограмм ПЗУ это неблагодарная задача. Одно дело что-то добавить, улучшить, дополнить директивы, не меняя ничего из оригинального. А совсем другое дело - это поменять интерфейс и принципы работы ROM-BIOS.

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

Забытый Вами нюанс. Тот, кому нужны окна и рамки, будет использовать режим в 31 видимую строку без разрывов. Т.о ваш монитор не только не закончен, - его практически нет. Ведь никому не нужны окна с разрывом. Потому Вам разумнее оставить родной монитор для старых программ и написать альтернативный монитор под режим в 31 видимую строку, куда Вы можете встроить свои принципы интерфейса.

Или Вам надо сразу же ориентироваться на выложенную мной ранее схему на 155 ЛЛ1 для исключения межстрочных разрывов в вертикальных линиях в режиме 25 строк и усиленно пропагандировать её. Но для окон всё-же лучше больше строк.

Кстати, псевдографические РК-игры из конца 80-тых использовали 31 строку лишь потому, что в советских телевизорах видимыми было число линий не более 250 (как раз 31*8=248 и 25*10=250). А современные телевизоры показывают и 270-280 линий растра. Так что 32 строки, что занимают 32*8=256 линий вполне влезают в экран.

 область применения окон на РК

.
Есть гораздо более неприятный вопрос. Когда Вы закончите ваше ПЗУ в 4 кб и оно будет поддерживать настоящую оконность, то куда её можно применить? Проблема в том, что для РК ещё нет оконных программ (точнее работающих в окнах), как в настоящей Windows и нет полноэкранных программ использующих окна.

Вы же не собираетесь заняться встраиванием использования окон в имеющиеся программы. Даже в системных программах, где там нужны окна? В бейсике (если даже предположить, что кто-то им пользуется) где там? В текстовом редакторе, тоже где?

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

Т.о только в случае, если кто-то собирается писать нортон, ему нужно работать с окнами. Но увы, и тут пролёт, - автор нортона не захочет использовать интерфейс из альтернативного ПЗУ, а будет использовать свой оконный интерфейс. Ведь оконный интерфейс текстовой машины это менее 1 кб несложного кода.

А главное, программисты всегда стараются писать на максимальную аудиторию, потому новые программы для РК, если и будут созданы, то лишь под стандартное ПЗУ со стандартной п/п-мой F809. С учётом этого полезнее делать не новое ПЗУ F800, а версию оконного драйвера для ОЗУ - надстройку к стандартному ПЗУ, что я сразу и предлагал.

мысль как-то была даже перетряхнуть всю ASCII-кодировку

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

PS. Ещё один байтик с'экономил, теперь свободных 244. Предыдущую выкладку исходника и кодов обновил. Заодно попробовал и менять форму курсора флагом RUSLAT. Во вложении такая версия. На оперативную смену формы курсора ушло 13 байтов.

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

[Paguo-86PK]

Это я уже видел. Выводить 78 символов в строке возможно только в эмуляторе.

Пoчему это?
Ещё до первых попыток запуска собранной платы РК отец за копейки купил Электрон 703 и отремонтировал его. Он и стоял в моём углу с письменным столом, где я делал уроки.
Плата хоть и пыталась подавать признаки жизни, но не запустилась по известным (теперь) причинам: ПЗУ купил отец под 32 Кб, а память думал расширять лишь после наладки и запуска.
Пару раз синхронизация хоть и устанавливалась, что говорит о запуске Монитора, но стек сбитый выкидывал всё в тартарары!
Спустя пару лет отец просто мне купил «Электронику КР-03», как только они появились в местном магазине.
И друзья мои тоже купили… Но только я стал на путь погроммиста
И вот этот «Электрон 703» отец специально настроил мне так, чтобы весь матрац РК был на экране.
А в хорошие дни, когда телевизор был в добром расположении духа, вся строка 76D0…771D была также видна. Хотя частенько луч её просто не прорисовывал.
(Если стукнуть, можно было добиться её отображения - видимо в телевизоре где-то отходил контакт и луч не гасился: Тот самый редкий случай, когда какой-то обрыв даёт фишку!
Потому что после очередной пропайки телевизора строка наглухо исчезала!)
Так что, зря говорите, что в XXI веке 78×30 нереально
Сервис-меню в телевизорах никто не отменял…

С точки зрения реализации оконности пока это даже не полуфабрикат. Куда можно использовать такое ПЗУ, которое всё, что в смысле оконности умеет, - это нарисовать рамку с межстрочными разрывами и ограничить вывод текста окном?

Выше я уже писал, что игра «BALL» перенастраивала ВГ75 и межстрочный разрыв устранялся. А я тот кусок кода вставлял во все свои игры.
Вот только курсор был сбит на один ряд выше и экран дрожал влево-вправо, как в кино…
А рамку ПЗУ не рисует - это делает код в ОЗУ, перехватывая «Esc+28+27T», где 27/28 - коды боковых линий и сверху/снизу. Можно любые коды использовать…

Вообще переделывать стандарт подпрограмм ПЗУ это неблагодарная задача. Одно дело что-то добавить, улучшить, дополнить директивы, не меняя ничего из оригинального. А совсем другое дело - это поменять интерфейс и принципы работы ROM-BIOS.

Согласен.
Но та же Windows - вся в заплатках…

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

Потому это - промежуточная версия: Практически оригинал, но с фишками…
И в РФ2 я потому хотел уйму страниц иметь под оригинальный Монитор, под Монитор с вьюпортом, Монитор с шагом в 1 байт в точках вызова подпрограмм и т.п…

Или Вам надо сразу же ориентироваться на выложенную мной ранее схему на 155 ЛЛ1 для исключения межстрочных разрывов в вертикальных линиях в режиме 25 строк и усиленно пропагандировать её.

Игру «Ball» найдите
Никакой ЛЛ1 не нужен

Кстати, псевдографические РК-игры из конца 80-тых использовали 31 строку лишь потому, что в советских телевизорах видимыми было число линий не более 250 (как раз 31*8=248 и 25*10=250). А современные телевизоры показывают и 270-280 линий растра. Так что 32 строки, что занимают 32*8=256 линий вполне влезают в экран.

Старый добрый ламповый Электрон 703 с обрывом рулит

Когда (ЕСЛИ) Вы закончите ваше ПЗУ в 4 кб и оно будет поддерживать настоящую оконность, то куда её можно применить? Проблема в том, что для РК ещё нет оконных программ (точнее работающих в окнах), как в настоящей Windows и нет полноэкранных программ использующих окна.
…
Т.о получается, что единственное реальное применение окон - это в нортоне. Там возможны окна сообщений, панели настроеек с чек-боксами, окна фатальных ошибок, окна запросов (имён, подтверждений), меню выбора (текущего диска, подкаталога/юзера, метода сортировки, маски и т.п). И в текстовом редакторе, работающем с файлами, который специально должен быть написан с нуля.

Об этом я думал…
Выше я уже подчеркнул - практикуюсь под свой x80, если хватит сил, знаний и времени его хоть как-то когда-нибудь реализовать…

А главное, программисты всегда стараются писать на максимальную аудиторию, потому новые программы для РК, если и будут созданы, то лишь под стандартное ПЗУ со стандартной п/п-мой F809. С учётом этого полезнее делать не новое ПЗУ F800, а версию оконного драйвера для ОЗУ - надстройку к стандартному ПЗУ, что я сразу и предлагал.

Варианты маркетологов: «Радио-86РК», «Радио-21РК», «Радио-2020РК», «Радио-1986/2020РК»…
В том смысле, что вариантов можно много предложить…
Например, с оконной фишкой - «Радио-86ОК»: COUT_C хоть и такой же, но можно управлять границами…
С комментарием: Таким мог быть РК с самой публикации…

Вот на таком принципе.

Такая фишка есть и в китайских дисплеях с поддержкой кириллицы. В тех же pdf к экранам попадаются такие таблицы, где под символ - лишь 8 бит…

Ещё один байтик с'экономил, теперь свободных 244.

Надо будет мне составить карту оригинального ПЗУ с выделением всех входов в подпрограммы, чтобы яснее понимать картину, куда мог бы залезть чужой странный код…
(Прикрепил сканер программ под это дело: Работает на оригинальном Мониторе и выявляет криминальные вызовы!)

P.S.: Вы и «U» выпилили‽

Code: Select all

F830 C3 36 F8 22 31 76 2A 31 76 C9

Можно же короче (мой дамп явно не изучали):

Code: Select all

F830 2A 31 76 22 31 76 C9

И двигать текст титульный - не очень хорошо:
Если «Супер-РФ2» всё-таки была бы, то как из-вне узнать версию Монитора?
Нужно либо FF5A оставить, либо в F853 ссылаться на неё…