nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 06:44



Reply to topic  [ 204 posts ]  Go to page 1, 2, 3, 4, 5 ... 14  Next
Paguo-86PK - XXI BEK 
Author Message
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Тaк уж получилось, что 3 месяца я не мог пользоваться ни ПК, ни интернетом: Из системника в декабре начал издаваться стабильный гироскопический звук. Так как он нарастал очень медленно в течении недели, никто этого не заметил. Только мне стало как-то не уютно находиться сначала рядом, потом в комнате, а затем - в квартире вообще. И только через несколько дней я стал подозревать наихудшее - дохнет хард! Ведь мой компьютер - дежурный DVR с режимом 24/7/365. Пришлось наплевать на камеры и всё отключить. Настроение было разбитое…
Стал копить на новый хард. В день покупки оказалось, что на 3Тб нет в наличии у них и купил на 2Тб за $150. Воткнул его и обнаружил, что он так же звенит! Что делать?
Снял БП и тестером проверил напряжения. Оказалось, все напряжения плавают с размахом в 2В и периодичностью раз 10 в минуту. Стал копить на новый БП, а пока поставил из компа сестры, мощностью чуть меньше. Он хоть и старее, но не так износился и выдаёт стабильные напряжения. Но, всё равно, оба винта звенят и всё!
В результате, отключил комп и только вчера купил на 850W за $90. Хотел было киловаттники, но они все брендовые под майнинг и стоят от $170-210 и выше…
Вставил его, включил - снова звон! Испугался, неужели винты оба загубились плавающим напряжением??? Жесть!
Стал основательнее прислушиваться. Но, почему-то в кейсе такой звуковой эффект, что ухом к кулеру даже толку нет: Всё звенит!
Ну, начал пальцем все кулера притормаживать: Оказалось, звенит кулер с радиатором на GeForce 8500. Вот этот гад три месяца не позволял мне включить компьютер!!!
Все три месяца родня пилила меня, мол, купи себе уже всё, что надо! Ведь, пока дома никого не бывало, я от скуки взломал Smart-телевизор, изучая инженерное меню. Подключил 4 тюнера и организовал тем самым мини кабельное ТВ во все комнаты. Понакидал несколько кабелей на крышу к СТВ и поставил полускрытую камеру на кухню (она на видном месте, но всем лень поднять голову на градус выше). В сети, через свой мобильник сидел и долго выгугливал разные автоматические прелести: трансмиттеры, Smart-розетки и дверные видеоглазки: После двух краж со взломом я без камер чувствую себя кротом! :-?
Жутко хотелось программировать, а Мобиль-Бейсик с моим экранчиком на сотке - жуть!

Итaк, мобильник мой имеет разрешение экрана почти такое же, как и у РЛК - 128x128. Только вот 65536 цветов на пиксел. А так, когда гуглишь и выходят обравки из сайтов чёрным на белом, начинаешь задумываться, что с таким же успехом можно было бы гуглить и на РК с его псевдографикой! Тем более, если пользоваться стандартным шрифтом, то 64x25 у РК - огромная фора, против 24x7 на моём мобильнике. Бр-ррр!
И я подумал, что если бы лет 30 тому назад в СССР были бы развиты информационные сети, то даже 16кб памяти хватило бы, чтобы облачно загружать любые файлы, не имея даже НГМД в распоряжении. А я всё завидовал, дурачок, графике Специалиста и Ориона! :roll:

Появилась идея снова изобрести РАДИО-86РК под новые реалии.
А именно:
  • Несколько ВГ75: Три, каждый со своим знакогенератором и в связке с LM1881 для наложения текста прямо на сигнал СТВ-тюнера и выводом на экран телевизора
  • Все 64Кб памяти без классического страничного переключения
  • И т.д.

P.S.: Подробности ниже…


Last edited by Paguo-86PK on 20 Feb 2020 04:27, edited 1 time in total.



18 Mar 2018 10:30
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Память
В отличии от классического РЛК или ZX, механизмы памяти работают несколько иначе.
Так как у Z80 имеется сигнал M1 и у i8080 он стробируется через D5, можно легко организовать переключение верхних 32кб, аналогично, как верхние 2Гб Windows.
Если процессор пытается прочитать инструкцию по диапазону 8000..FFFF, значит прикладной код обращается к API ПЗУ и триггер переключает адреса 0000..FFFF на ПЗУ. Тем самым, прикладная программа в своём распоряжении абсолютно все 64кб для чтения/записи, но при прыжке программы на любой верхний адрес, память переключается на 64Кб ПЗУ. В этом режиме само API может читать данные из ОЗУ либо через стек (стробируемый D2), либо через ПДП. Когда функция API в ПЗУ завершила свои действия, она выполняет инструкцию RET по адресу FFFF, чем сбрасывает триггер и включаются снова 64кб ОЗУ…

При старте системы включается режим «S» и конфигурация адресного пространства принимает следующий вид:
Code:
┌───────────────────────┐ ┌───────────────────────┐    ┌───────────────────────┐ ┌───────────────────────┐
│Чтение команды M1-цикла│ │Чтение данных из памяти│    │ Стековые R/W-операции │ │Запись данных в память │
╞═══════════════════════╡ ╞═══════════════════════╡FFFF╞═══════════════════════╡ ╞═══════════════════════╡
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│       Страница        │ │       Страница        │    │       Страница        │ │       Страница        │
│          ROM          │ │          ROM          │    │          RAM          │ │          RAM          │
│          «A»          │ │          «A»          │    │          «H»          │ │          «U»          │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
├───────────────────────┤ ├───────────────────────┤8000├───────────────────────┤ ├───────────────────────┤
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│       Страница        │ │       Страница        │    │       Страница        │ │       Страница        │
│          ROM          │ │        RAM/ROM        │    │        RAM/ROM        │ │          RAM          │
│          «B»          │ │          «C»          │    │          «L»          │ │          «D»          │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
└───────────────────────┘ └───────────────────────┘0000└───────────────────────┘ └───────────────────────┘

Если управление получил прикладной код, конфигурация адресного пространства в режиме «U» имеет следующий вид:
Code:
┌───────────────────────┐ ┌───────────────────────┐    ┌───────────────────────┐ ┌───────────────────────┐
│Чтение команды M1-цикла│ │Чтение данных из памяти│    │ Стековые R/W-операции │ │Запись данных в память │
╞═══════════════════════╡ ╞═══════════════════════╡FFFF╞═══════════════════════╡ ╞═══════════════════════╡
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│       Страница        │ │       Страница        │    │       Страница        │ │       Страница        │
│          ROM          │ │          RAM          │    │          RAM          │ │          RAM          │
│          «A»          │ │          «U»          │    │          «H»          │ │          «U»          │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
├───────────────────────┤ ├───────────────────────┤8000├───────────────────────┤ ├───────────────────────┤
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│       Страница        │ │       Страница        │    │       Страница        │ │       Страница        │
│          RAM          │ │          RAM          │    │          RAM          │ │          RAM          │
│          «C»          │ │          «C»          │    │          «L»          │ │          «D»          │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
│                       │ │                       │    │                       │ │                       │
└───────────────────────┘ └───────────────────────┘0000└───────────────────────┘ └───────────────────────┘


Last edited by Paguo-86PK on 20 Mar 2018 04:15, edited 5 times in total.



18 Mar 2018 10:31
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Все три канала ПДП используются тремя ВГ75.

Основной ВГ75 выводит текст с аппаратным переключением между строчными и заглавными символами.
Коды 00..1F графически дублируют символы 20..2F, но переключают флаг ЗАГЛАВНЫЕ/строчные символы. Тем самым, таким простым приёмом легко формировать абсолютно нормальный текст. Так как старшие биты знакогенератора не участвуют в формировании графического символа, на кодах 00..1F они установлены так, чтобы переключать тот флаг.
Управляющие коды для управления атрибутами тоже используются, но они переключают стили начертания символов (курсив, жир и т.д.)

Второй ВГ75 выводит символы псевдографики. Здесь ПЗУ имеет 64 псевдографических символов Кода Брайля для рисования псевдографики 128x75, а также 64 дополнительных иконок.

Третий ВГ75 не имеет знакогенератора, а формирует лишь 128 различных атрибутов. Где 3 бита под RGB точек символа/графики двух первых ВГ75, ещё 3 бита под цвет фона…

Тем самым, программируя каждый из ВГ75 можно достаточно гибко управлять всеми слоями видео или организовывать скроллинг, программируя каналы ПДП.


Last edited by Paguo-86PK on 18 Mar 2018 11:51, edited 1 time in total.



18 Mar 2018 10:32
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Пробные наброски:
  1. Запустите ЭМУЛЯТОР
  2. Скопируйте листинг отсюда в «Intel 8080 assembler» и загрузите в память…
  3. Используйте директиву «G1»-МОНИТОРа для запуска тест-кода…
Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; API - альфа-версия пробных набросков. Тестируется в
; эмуляторе http://rk86.ru
; Из-за существенных различий концепций архитектур, не
; всё из задуманного так легко решить
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
JMR     EQU     0D7h    ; JuMp Relative: $- label ^255
DBG     EQU     0DFh    ; Debug Function
CFN     EQU     0F7h    ; Call FuNction relative
RFN     EQU     0FFh    ; Return fron FuNction
BCC     EQU     0C7h    ; Branch on Carry Clear
BCS     EQU     0CFh    ; Branch on Carry Set
BNE     EQU     0E7h    ; Branch on Not Equal
BEQ     EQU     0EFh    ; Branch on EQual (ZF set)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
        ORG     00000h
ROMem:  DB      255,255,255,255,255,255,255,255 ; BCC
        DB      255,255,255,255,255,255,255,255 ; BCS
        DB      255,255,255,255,255,255,255,255 ; JMR
        DB      255,255,255,255,255,255,255,255 ; DBG
        DB      255,255,255,255,255,255,255,255 ; BNE
        DB      255,255,255,255,255,255,255,255 ; BEQ
        DB      255,255,255,255,255,255,255,255 ; CFN
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
        ORG     00038h
        XTHL
        DCX     HL
        PUSH    PSW
        PUSH    DE
        MOV     A,H
        XCHG
        LXI     HL,Lower
        ORA     A
        JZ      @API
        LXI     HL,Upper
        INR     A
        JZ      @API
        XCHG
        POP     DE
        POP     PSW
        INX     SP
        INX     SP
        RET
@API:   XCHG
        XRA     A
        MOV     H,A
        DAD     HL
        DAD     DE
        MOV     A,M
        INX     HL
        MOV     H,M
        MOV     L,A
@APIR:  POP     DE
        POP     PSW
        XTHL
        RET
@BCC:   JNC     @JMR
        JMP     @Next
@BCS:   JC      @JMR
        JMP     @Next
@BNE:   JNZ     @JMR
        JMP     @Next
@BEQ:   JZ      @JMR
@Next:  XTHL
        INX     HL
        XTHL
        RET
@JMR:   XTHL
@JMRA:  PUSH    PSW
        MOV     A,M
        CPI     0FFh
        JZ      @RET
        PUSH    DE
        INX     HL
        MOV     E,A
        ADD     A
        SBB     A
        MOV     D,A
        DAD     DE
        JMP     @APIR
@RET:   POP     PSW
        POP     HL
        RET
@CFN:   XTHL
        INX     HL
        PUSH    HL
        POP     HL
        XTHL
        DCX     SP
        DCX     SP
        XTHL
        DCX     HL
        JMP     @JMRA
@DBG:   PUSH    PSW
        PUSH    BC
        PUSH    DE
        PUSH    HL
        LXI     DE,@@pairs
        MVI     B,5
@@loop: POP     HL
        CALL    0FB78h
        LDAX    DE
        INX     DE
        CALL    0FCB9h
        LDAX    DE
        INX     DE
        CALL    0FCB9h
        DCR     B
        JNZ     @@loop
        JMP     0F86Ch
@@pairs:DB      "HLDEBCAFPC"

; Здесь расположена таблица подпрограмм для быстрого
; перехода директивами G1..G7, а также возможного
; вызова различных системных функций из-под БЕЙСИКа
; посредством функции USR(1)..USR(55)
Lower:  DW      @BCC ; C7 - RST 0; USR(1..7)
        DW      1000h,2000h,3000h,4000h,5000h,6000h,7000h
        DW      @BCS ; CF - RST 1; USR(9..15)
        DW      0F809h,0F815h,0F81Bh,0F86Ch,0F82Dh,0F800h,0
        DW      @JMR ; D7 - RST 2; USR(17..23)
        DW      0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch
        DW      @DBG ; DF - RST 3; USR(25..31)
        DW      0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch
        DW      @BNE ; E7 - RST 4; USR(33..39)
        DW      0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch
        DW      @BEQ ; EF - RST 5; USR(41..47)
        DW      0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch
        DW      @CFN ; F7 - RST 6; USR(49..55)
        DW      0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch,0F86Ch
Upper:  DW      0

;;;;;;;;;;;;;;;;;;;;
        ORG     1000h
Tester:
        MVI     H,20
LapY:   MVI     L,48
LapX:   MOV     A,H
        XRA     L
        RRC
        SBB     A
        ANI     '*'
        MOV     C,A
        CALL    9
        DCR     L
     DB BNE,$-  LapX ^255
        MVI     C,0Dh
        CALL    9
        MVI     C,0Ah
        CALL    9
        DCR     H
     DB BNE,$-  LapY ^255
        JMP     0Ch


Last edited by Paguo-86PK on 21 Mar 2018 04:25, edited 4 times in total.



18 Mar 2018 10:32
Profile WWW
Maniac

Joined: 18 Nov 2013 15:15
Posts: 209
Location: все оттуда ;)
Reply with quote
Paguo-86PK wrote:
можно легко организовать переключение верхних 32кб, аналогично, как верхние 2Гб Windows.
Кто такие "верхние 2Гб Windows" ???
Не путаешься в архитектуре процессоров x86, у которых стартовый адрес начинается не с 0000h как у 8080 ?


19 Mar 2018 14:49
Profile
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
VGrad wrote:
Paguo-86PK wrote:
можно легко организовать переключение верхних 32кб, аналогично, как верхние 2Гб Windows.
Кто такие "верхние 2Гб Windows" ???
Не путаешься в архитектуре процессоров x86, у которых стартовый адрес начинается не с 0000h как у 8080 ?
Нeт, не путаюсь. «Процессы и адресные пространства»:
Quote:
В конфигурации Windows по умолчанию 2 гигабайта (ГБ) этого виртуального адресного пространства выделены каждому процессу для частного использования, а другие 2 ГБ совместно применяются всеми процессами и операционной системой. Обычно приложения (например, Блокнот, Word, Excel и Acrobat Reader) используют только часть из 2 ГБ частного адресного пространства. Операционная система назначает рамки страниц ОЗУ только используемым страницам виртуальной памяти.
В «Радио-86РК» схожая организация адресного пространства: Нижние 32кб и верхние 32кб…
Мною лишь рассматривается идея, что все 64кб полностью могут быть как ОЗУ, так и ПЗУ.
Наверное, меня не так поняли?


20 Mar 2018 01:21
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Eсли кому-нибудь ещё интересно.

На досуге немного продвинулся в архитектуре этой «Идеальной Микро-ЭВМ»… :ebiggrin:

HINT
  • «A»: «Application» - Страница ОЗУ приложения
  • «B»: «BIOS» - Страница ОЗУ Операционной Системы
  • «C»: «Code» - Страница кода
  • «D»: «Data» - Страница данных
  • «E»: «Extra» - ПЗУ загрузчика (32 байта)
В режиме «B» конфигурация адресного пространства приобретает следующий вид:
Code:
┌───────────────────────┐    ┌───────────────────────┐ ┌───────────────────────┐
│Чтение команды M1-цикла│    │Чтение данных из памяти│ │Запись данных в память │
╞═══════════════════════╡FFFF╞═══════════════════════╡ ╞═══════════════════════╡
│       Страница        │    │       Страница        │ │       Страница        │
│        RAM «B»        │    │        RAM «C»        │ │        RAM «D»        │
├───────────────────────┤FFF0├───────────────────────┤ ├───────────────────────┤
│        Триггер        │    │       Страница        │ │       Страница        │
│       RAM «B/A»       │    │        RAM «B»        │ │        RAM «D»        │
├───────────────────────┤FF00├───────────────────────┤ ├───────────────────────┤
│       Страница        │    │       Страница        │ │       Страница        │
│        RAM «B»        │    │        RAM «B»        │ │        RAM «D»        │
└───────────────────────┘0000└───────────────────────┘ └───────────────────────┘

Если управление получил прикладной код, конфигурация адресного пространства в режиме «A» имеет следующий вид:
Code:
┌───────────────────────┐    ┌───────────────────────┐ ┌───────────────────────┐
│Чтение команды M1-цикла│    │Чтение данных из памяти│ │Запись данных в память │
╞═══════════════════════╡FFFF╞═══════════════════════╡ ╞═══════════════════════╡
│       Страница        │    │       Страница        │ │       Страница        │
│        RAM «A»        │    │        RAM «C»        │ │        RAM «D»        │
├───────────────────────┤FFF0├───────────────────────┤ ├───────────────────────┤
│        Триггер        │    │       Страница        │ │       Страница        │
│       RAM «A/B»       │    │        RAM «A»        │ │        RAM «D»        │
├───────────────────────┤FF00├───────────────────────┤ ├───────────────────────┤
│       Страница        │    │       Страница        │ │       Страница        │
│        RAM «A»        │    │        RAM «A»        │ │        RAM «D»        │
└───────────────────────┘0000└───────────────────────┘ └───────────────────────┘

Если нужно скопировать данные между страницами, существует маленькое окно однобайтовых команд:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FFF0 1A 77 13 23 0B 78 B1 C8 E3 2B 2B 2B E3 C9 .. .. ; Копирует данные из «C» в «D»

Тем самым…
Для приложения всё адресное пространство (0000…FFFF) представляет ОЗУ и у пользователя имеется все 64 Кб в распоряжении без исключения.
Самые последние 240 байт пространства (FF00…FFEF) доступны только для чтения/записи данных.
Чтением команды циклом «M1» из области FF00…FFEF процессор всегда считывает код FF инструкции «RST 7», но при этом происходит также переключение страниц памяти триггером «A/B» для переключения между прикладным и базовым кодом.

В качестве иллюстрации прилагаю схему.


Attachments:
File comment: Слева - Сигналы от Z80: A0-A15, MREQ, READ, WRITE, M1
Справа - Селектор страниц памяти

App_BIOS.png
App_BIOS.png [ 47.7 KiB | Viewed 11269 times ]
01 Dec 2019 10:35
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote


07 Dec 2019 14:05
Profile WWW
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
B общем, строгое следование дисциплине с соблюдением правил большинства форумов, наставляющих перед созданием очередной темы обязательно воспользоваться поиском с обсуждением схожей задачи, сослужило мне дурную привычку врезаться в чужие темы с обильным представлением соображений от себя и незаметным переходом в оффтоп…
Поэтому, вот это переношу (логически) сюда…

Археология
Так как средства онлайн-эмулятора предоставляют ассемблер, консоль с отладчиком и возможность прошивки ПЗУ, то это вполне достаточно для бывалых! :roll:

Так как программу МОНИТОР автор написал не очень оптимально, то я занялся его оптимизацией.
В первую очередь, я освободил 8 байтов:
Было
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F830 C3 52 FF C3 56 FF .. .. .. .. .. .. .. .. .. ..
FF52 .. .. 2A 31 76 C9 22 31 76 C9 .. .. .. .. .. ..
стало
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F830 2A 31 76 22 31 76 C9 .. .. .. .. .. .. .. .. ..
FF52 .. .. <- -- -- -- -- -- -- -> .. .. .. .. .. .. <-- 8 байтов себе в карман
Хотя, где-то это я уже видел. По-моему, в дампах для ОРИОНа…
Но, из-за этого необходимо подкорректировать стартовый код МОНИТОРа:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F830 2A 31 76 22 31 76 C9 3A 8A 32 03 80 31 CF 76 CD
F840 CE FA 21 00 76 11 5F 76 4D .. .. .. .. .. .. .. <-- меняем MVI E,0 на MOV E,L
Но я решил не останавливаться и взяться за оптимизацию головой, переосмысливая весь код…
В итоге я переработал его сначала так:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F800 C3 40 F8 .. .. .. .. .. .. .. .. .. .. .. .. ..
F830 2A 31 76 22 31 76 C9 <- -- -- -- -- -- -- -- -> <-- 9 байтов себе в карман
F840 21 03 80 36 8A AF 2B 77-7C FE 75 C2 45 F8 22 31
F850 76 21 1D 22 22 2F 76 2A-6D F8 22 1C 76 F9 CD CE
F860 FA 21 5A FF CD 22 F9 3E-C3 32 26 76 .. .. .. ..
Но потом доработал до
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F800 C3 40 F8 .. .. .. .. .. .. .. .. .. .. .. .. ..
F830 2A 31 76 22 31 76 C9 <- -- -- -- -- -> 21 03 80 <-- 6 байтов после уступок
F840 0D 0A 2D 2D 3E 00 2B 77-7C FE 75 C2 44 F8 22 31 <-- но вклинил текст прямо в код
F850 76 21 1D 22 22 2F 76 2A-6D F8 22 1C 76 F9 CD CE
F860 FA 21 5A FF CD 22 F9 3E-C3 32 26 76 31 CF 76 21
F870 F8 40 .. .. .. .. .. .. .. .. .. .. .. .. .. .. <-- и здесь подкорректировал адрес
FF60 .. .. .. .. .. .. <- -- -- -- -- -> .. .. .. .. <-- 6 байтов ещё освободив этим
Изучая код дальше, обнаружил ещё одно безобразие:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F950 .. .. .. .. .. .. .. .. .. .. 21 00 00 1A 13 FE
F960 0A CA 8E F9 FE 2C C8 FE 20 CA 5D FD D6 30 FA AE <-- ссылка на STC-безобразие
F970 FA FE 0A FA 82 F9 FE 11 FA AE FA FE 17 F2 AE FA <-- слишком много FAAE
F980 D6 07 4F 29 29 29 29 DA AE FA 09 C3 5D F9 37 C9 <-- STC-безобразие
И переписал это дело как:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F950 .. .. .. .. .. .. .. .. .. .. 21 00 00 1A 13 FE
F960 0D 37 C8 FE 2C C8 FE 20-CA 5D F9 01 AE FA C5 D6 <-- STC отлично вписывается!
F970 30 F8 FE 0A FA 7F F9 FE-11 F8 FE 17 F0 D6 07 4F <-- и FAAE теперь в стеке
F980 29 29 29 29 D8 06 00 09-C1 C3 5D F9 <- -- -- -> <-- освободили 4 байта
И теперь освобождённое пространство стало больше:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
F8E0 .. .. .. 21 8C F9 .. .. .. .. .. .. .. .. .. .. <-- корректируем
F950 .. .. .. .. .. .. .. .. .. .. 21 00 00 1A 13 FE
F960 0D 37 C8 FE 2C C8 FE 20-CA 5D F9 01 AE FA C5 D6 <-- STC отлично вписывается!
F970 30 F8 FE 0A FA 7F F9 FE-11 F8 FE 17 F0 D6 07 4F <-- и FAAE теперь в стеке
F980 29 29 29 29 D8 06 00 09-C1 C3 5D F9 08 20 08 00 <-- переносим
FF90 .. .. .. .. .. .. .. .. .. .. .. .. .. .. <- -- <-- освобождаем 4 байта
FFA0 -- -> .. .. .. .. .. .. .. .. .. .. .. .. .. ..
Ну, в общем, Вы поняли… :)))
Увлёкся процессом и ушёл в него с головой на все выходные! :egeek:

Ещё мне всегда не нравилось, что по «G<start>,<break>» в отладочных целях, у программы портились ячейки 0038…003A.
Для «PC/M-80» это не проблема, а вот в РАДИО-86РК такой приём - не очень красивый!
И я это также подкорректировал и МОНИТОР за собой подчищает хорошо, используя вместо четырёх байтов «RST+JMP» в разных точках, всего три байта «CALL» в точке отладки…
А так же, теперь директивой «G» можно вызывать подпрограммы. То есть, директивой «X» можно изменить регистр «C» и затем вбить «GF809»: На экране напечатается указанный символ и управление вернётся в МОНИТОР, а не просто зависнет невесть где… :roll:

Затем я вспомнил журнальные статьи «Моделист-Конструктор» - "Монитор открывает окна" для ПК "Специалист".
А потом ещё и журнал РАДИО с «Оконным Менеджером» для РАДИО-86РК.
И подумал. ведь всё - костыльно!

Нельзя ли саму подпрограмму вывода символа в ПЗУ переписать так, чтобы она поддерживала вьюпорт произвольного размера?

И я тут написал…

WINDOWS'86
Большинство игровых программ эмулятора работает…
Но…
  • Вулкан сильно гонет из-за неправильной ESC-последовательности: Вместо «ESC+Y» почему-то попадаются «ESC+A». Может с ленты считан с ошибками?
  • Ксоникс выводит статусную строку в самой нижней части экран методом хака - переписывая служебные ячейки монитора 7600…7601. Моя подпрограмма в ПЗУ утрамбована максимально и защиты от дурака не имеет в этом плане. Легче подпилить сам КСОНИКС…
  • Цирк практически работает, но отрисовка рамок глючит…
В остальном, всё работает…
И, как вы уже поняли, МОНИТОР поддерживает и произвольную ESCAPE-последовательность, передавая управление по адресу 7620 код, отличный от «Esc+Y». Именно потому Вулкан глючит и я вычислил - почему, но ещё не раскручивал стек до выяснения проблемного места в программе…

Ниже прилагаю исходный листинг на ассемблере, который следует вставить на сайте эмулятора в ассемблер и залить в память, после чего нажать кнопку «RESET», чтобы увидеть в углу мой текст…
Естественно, в ОЗУ загружается моя пробная библиотека с Escape-драйвером.
В отличии от ANSI.SYS с его «Esc+[n;m…БУКВА», у меня просто - «Esc+n,m…БУКВА».
Но, аргументы можно разделять символом ПРОБЕЛа или «+», а также и символом «-» для отрицательных величин.
Да, они поддерживаются! То есть нельзя писать «Esc+255X», так как нужно «Esc-1X»…
[list][*]Esc+S(ave) - сохраняет окно в оконный стек
[*]ESC+R(estore) - восстанавливает окно из оконного стека
[*]Esc+left+top+width+height+V - изменяет текущий вьюпорт под параметры
[*]Esc+offset_x+offset_y+width+height+Q - организует дочерний вьюпорт внутри текущего. Можно вкладывать окошки друг в друга, предварительно сохраняя родителей в стек
[*]Esc+hor+ver+T - рисует рамку вокруг текущей области, где hor/ver - коды символов для боковых краёв и горизонтальных границ соответственно. Имеется слабая защита: Если окно касается краёв экрана, в тех границах ничего не рисуется[/list]

В общем, можете запустить всё это дело одним из следующих способов:
  • «G0»: Режим максимального окна - 78×30. Довольно любопытно посмотреть, как работают некоторые директивы МОНИТОРа в этом режиме
  • «G1»: Стандартное окошечко - 64×25. Просто это должно быть встроенным
  • «G2»: Вывод содержимого памяти ASCII-дампом
  • «G3»: Среднее окошечко
  • «G4»: Маленький менеджер окон… Нажатием TAB переключает окна; Курсорные клавиши двигают окна; Пробелом выбирается опция в окне с вопросом; «ВК» подтверждает опцию; Другие клавиши - переход в режим МОНИТОРа
  • «G5»: Тестер Escape-последовательностей. Так как в эмуляторе клавиша Esc выполняет функцию «Рус/Lat», чтобы не мучаться пальцами, клавиша «Забой» (BkSp) и отправляет код 1B на вывод. А в нижнем правом краю экрана выходит подсказка из нескольких ячеек Escape-параметров…

Теперь я задумался над тем, что в наши дни вывод файлов на магнитную ленту посредством самого РК - крайне редкое и непопулярное явление. Тем самым, пространство ПЗУ можно немножечко зачистить:
Code:
FB3D..FB77 - <O>...   - 58 BYTES
FB86..FB8F - OUT FILE - 10 BYTES
FB90..FB97 - OUT ADDR -  8 BYTES
FC46..FCA4 - OUT BYTE - 95 BYTES
================================
                       171 BYTES
И это пространство в размере 171 байта - настоящая Пещера Аладдина! :esurprised:
Туда можно вписать всё, что душе угодно!
  • Можно разместить «защиту от дурака» для моей подпрограммы вывода символа во вьюпорт
  • Можно добавить поддержку ANSI ESC-последовательностей
  • Можно вставить поддержку чтения USB-накопителя
  • Или организовать переключатель между несколькими процессами в стиле первых Windows, чтобы подпрограмма опроса клавиатуры опционально по нажатию клавиши «ТАБ» сохраняла стек текущего процесса и переключала на стек следующего
  • Так как ВГ75 аппаратно поддерживает световое перо, можно разгуляться с окнами уже на сенсорном уровне

В общем, интересно было бы в перспективе разработать адекватную прошивку нового МОНИТОРа «Windows'86» и проверить её на реальной машине… :oidea:

P.S.: А Вы как к этому относитесь? :ewink:
Мартышкин труд? :question:


Attachments:
File comment: Windows'86 - это могло быть реальностью…
Windows86.zip [4.43 KiB]
Downloaded 371 times
18 Dec 2019 13:30
Profile WWW
Doomed
User avatar

Joined: 19 Feb 2017 03:46
Posts: 584
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Reply with quote
Post 
Paguo-86PK wrote:
Нe поверите! Написал Windows'86 за неделю
Paguo-86PK wrote:
А Вы как к этому относитесь? Мартышкин труд?
Лично мне непонятна цель ваших доработок ПЗУ. И я бы не называл введение в ROM-BIOS оконных параметров, позволяющих делать вывод в окно, - Windows. Это вводит в заблуждение из-за явной параллели с ОС Windows.

В ПЗУ ОРИОНА М2 и М3 есть оконные параметры:
Code:
HISCRN  EQU     0F3CFH  ; начальный адрес экрана
WDTSCR  EQU     0F3D0H  ; ширина экрана в байтах
FRSTLN  EQU     0F3D4H  ; номер первой строки экрана
SCHIGH  EQU     0F3D5H  ; количество строк
Все мои драйверы консоли для ОРИОНА управляются этими ячейками. Это позволяет иметь экран любого размера в любом месте ОЗУ. Если не считать задачи очистки окна (т.е задал окно и выкинул на вход CONOUT код $1F), практически никто эти ячейки не использовал. Т.к, во-первых, драйвер в ПЗУ слишком примитивен и не поддерживает цвет. А оконность нужна в первую очередь в цвете. А цвет предполагает байтовый шрифт, в то время, как в ПЗУ используется тормозной небайтовый шрифт (конфликтующий в цвете с железом ОРИОНА).

Это я к тому, что для РК86 при разработке его ROM-BIOS надо было так и сделать, потому что ВГ75 позволяет задать, как и в ОРИОНЕ, экран в любом месте ОЗУ и даже менять его размер (программно). Из-за того, что это не сделано, резидентный драйвер работает только на единственный экран 76D0 с жёстко фиксированным размером в 25 строк, а граф.операторы бейсика предназначенные для вывода псевдографики не работают в псевдографическом режиме с экраном 64+30.

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

Если бы мне понадобилось ввести оконность в ПЗУ РК, то я бы не стал корректировать стандартный код драйвера вывода. Потому что игры РК: http://ruecm.forum2x2.ru/t1096-topic#13866. Из-за этого, чтобы осталась совместимость, код драйвера должен остаться тем же. Хотя сам код внутри ПЗУ вполне можно двигать (но надо знать на какие внутренние входы неграмотные РК-игры нагло лезут, их нельзя сдвигать).

Если надо доработать драйвер, то или вводят другие входы или имеющиеся входы векторизуют. Более грамотна векторизация. Это позволяет оперативно менять драйвер вывода и ввода. В РК надо (как и было сделано в ОРИОНЕ) векторизовать входы F809, F803, F81B и F812. В базовом ОРИОНЕ забыли векторизовать F81B (что мешает загрузить драйвер полностью иной физически клавиатуры). Я попытался это исправить, для чего занял 2 ячейки в системной области F3F0, но нашлись люди, которым вдруг (или из вредности) захотелось эти же ячейки использовать как рабочие для обычных программ (хотя в них для использования под раб.ячейки оставалось ещё ~48 кб ОЗУ, а ячейки F3F0 были резервированы именно для расширения ROM-BIOS).

Для вывода достаточно заменить только F809. Но для позиционирования курсора надо менять ещё и подрограммы клавиатурного ввода. Для размещения векторов есть много свободных ячеек в области раб.ячеек ПЗУ и выше экрана (7FF4...7FFF). Разумно векторизовать процедуры вывода курсора и процедуру настройки режима. Тогда можно менять не только позицию, но и форму курсора (форма курсора меняется при настройке ВГ75 подпрограммой F82D, хотя и адрес внутреннего входа п/п-ммы PUSKVG нельзя менять). Или можно ввести одну ячейку для байта параметра режима, который позволяет менять форму курсора - тонкий мигающий штрих на линии подчёркивания или мигающее знакоместо, что намного симпатичнее, в моих ПЗУ РК было так).

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

А если делать серъёзную доработку ROM-BIOS РК86 (хотя я не вижу в этом необходимости) разумно ориентироваться на полный объём ПЗУ в 8 кб. Или хотя бы на те 4 кб, что заложены в ПЗУ РК изначально его разработчиками. Они заложили возможность разместить во втором ПЗУ РФ2 (F000...F7FF) код расширения монитора.

В стандартном РК-мониторе, если первая буква директивы в командной строке не является базовой командой монитора, то делается JMP на F000, где должен располагаться командный интерпретатор пользователя. Который например, может обслуживать команды DOS. Хотя и это неправильно. Расширяющий резидентный CCP командный интерпретатор пользователя должен стартовать первым и только, если он не обслужил команду, лишь тогда приходит очередь резидентного интерпретатора команд.
Paguo-86PK wrote:
В общем, интересно было бы в перспективе разработать адекватную прошивку нового МОНИТОР-а «Windows'86» и проверить её на реальной машине…
Для РК эмуляторы достаточно точные. Хотя точно эмулировать все нюансы ВГ75 им было очень сложно. Потому для РК нет разницы между реалом и эмулятором. Если не делать Демо-сцену с чтением статусного регистра ВГ75 очень точно привязанное к числу машинных команд.

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

Вот монитор РК, куда я добавил ещё две новые директивы, но всё-равно осталось ещё 153 свободные ячейки. Причём адреса всех внутренних точек куда лезут игры написанные "вредителями" сохранены (также сохранены те внутренние точки, что добавил эмулятор EMU от b2m). Макро-ассемблер М80 резко увеличивает эффективность работы, а кто пользуется другими инструментами, тот просто не ценит своё время.

Есть программы конверторы мнемоник (во вложении), в том числе для конверсии из мнемоник Z80 в мнемоники КР580 (я ей успешно пользовался в прошлом году для Паскаля МТ+, - т.к в ассемблерных вставках он понимает только мнемоники КР580, но зато я их не понимаю). Это даже не лучший исходник (какой подвернулся, у меня их десятки версий, давно в них запутался). Для последующей модификации этот исходник ценен тем, что подписаны длины подпрограмм, т.е маленьких независимых фрагментов кода. Перемещая эти кусочки кода при всех модификациях мы должны добиться, чтобы адреса внутренних точек не сдвигались.

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

Процедуры оконной коррекции это всего несколько десятков байтов. Это легко встроить. Хотя я и не понимаю, что это даёт. Какая от этого польза? Не имея альтернативного фонта дающего рамки и окна в инверсии это вообще бесполезно. К тому же, т.к это небольшой объём кода, то вывод в окно легко встраивается в любую программу. Потому нет смысла менять ПЗУ.

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

Вот смотрите, как просто реализуется оконность в программах на Паскале:

 "оконность в паскале"
Code:
procedure set_full;
begin
     WX1:=1; WX2:=SCR_HSZ; WY1:=1; WY2:=SCR_VSZ;
end;

procedure goto_xy(x,y: Integer);  { Здесь позиции x,y задаются от начала окна }
begin
  if WX1+x <= WX2 then cur_x:=x
     else cur_x:=WX2-WX1+1;
  if WY1+y <= WY2 then cur_y:=y
     else cur_y:=WY2-WY1+1;
    gotoxy(WX1+cur_x-1,WY1+cur_y-1);
{
    cout(#$1B); cout('Y');
    cout(chr(30+WY1+cur_y));
    cout(chr(30+WX1+cur_x));
}
end;

procedure cout(ch: char);
begin
{  if cur_x<SCR_HSZ then cur_x:=cur_x+1; }
write(ch);
end;

procedure mssgln(tx: txt_string);
begin
mssg(tx);
cur_x:=1;
      if WY1+cur_y > WY2 then
        begin
          cur_y:=WY2-WY1+1;
          cur_x:=WX2-WX1+1;
        end
      else
        begin
          cur_y:=cur_y+1;
        end;
    goto_xy(cur_x,cur_y);
end;

procedure mssg(tx: txt_string);
var
  i: Integer;
begin
  for i:=1 to length(tx) do cout(tx[i]);
end;

procedure cls_window;
var  x,y: Integer;
 begin
   for x:=WX1 to WX2 do
     begin
       for y:=WY1 to WY2 do
         begin
           gotoxy(x,y);
           if not ((x=SCR_HSZ) and (y=SCR_VSZ)) then {чтобы не случилось ролика}
           cout(#32);
         end;
     end;
end;

procedure cls;
begin
  if ((WX1=1) and (WY1=1) and (WX2>=SCR_HSZ) and (WY2>=SCR_VSZ))
     then mssg(chr($1b+$45)) else cls_window;
end;

procedure w_ramka;
var i,x,y: Integer;
Left_Up, Left_Dn, Right_Up, Right_Dn, Vert , Horiz: char;
begin
  Left_Up:=  char($A5);
  Left_Dn:=  char($AB);
  Right_Up:= char($A8); 
  Right_Dn:= char($AE); 
  Vert:=     char($A1);
  Horiz:=    char($A0);

  gotoxy(WX2,WY2); cout(#$99);
  if (WX2=SCR_HSZ) and (WY2=SCR_VSZ) then
       begin
         gotoxy(1,1); insline;
       end;
     for x:=WX1+1 to WX2-1 do
       begin
         gotoxy(x,WY1); cout(Horiz);    {верхняя горизонталь }
       end;
       gotoxy(WX2,WY1); cout(Right_Up);
     for y:=WY1+1 to WY2-1 do
       begin
         gotoxy(WX2,y); cout(Vert);   {правая вертикаль}
       end;
      gotoxy(WX2,WY2); cout(Right_Dn);    {прав.нижний угол}
     for i:=1 to WX2-WX1-1 do
       begin
         x:=WX2-i;
         gotoxy(x,WY2);
         cout(Horiz);                 {нижняя горизонталь}
       end;
       gotoxy(WX1,WY2); cout(Left_Dn);
     for i:=1 to WY2-WY1-1 do
       begin
         y:=WY2-i; gotoxy(WX1,y); cout(Vert);
       end;
     gotoxy(WX1,WY1); cout(Left_Up);
end;

procedure Mwindow(x1,y1,x2,y2: Integer; flg: byte);
begin
   if (x1>=x2-1) or (y1>=y2-1) or (y2>SCR_VSZ) or (x2>SCR_HSZ)
      then avral('Window range out');
   Inverse;
   
   WX1:=x1; WX2:=x2; WY1:=y1; WY2:=y2; cls;
   if (flg<>0) then
     begin
       w_ramka; WX1:=WX1+1; WX2:=WX2-1; WY1:=WY1+1; WY2:=WY2-1;
     end;
   cur_x:=1; cur_y:=1;

end;

procedure err_mssg(line: txt_string);
var
  x1,y1: Integer;
begin
   tmpx:=cur_x; tmpy:=cur_y;
   Inverse;
   i:=length(line)+10; if i mod 2 <>0 then i:=i+1;
   x1:=(SCR_HSZ-i) div 2;
   y1:=(SCR_VSZ - 5) div 2;
   Mwindow(x1,y1,x1+i,y1+4,0); w_ramka;
   tmplin:=' Fatal Error '; i:=(WX2-WX1+2-length(tmplin)) div 2;
   goto_xy(i,1); mssg(tmplin);
   WX1:=WX1+1; WX2:=WX2-1; WY1:=WY1+1; WY2:=WY2-1;
   goto_xy(5,2); mssg(line); gotoxy(1,1); wait;
   cur_x:=tmpx; cur_y:=tmpy; scr_out; Normal; scr_scrabled:=True;
end;

Вышеприведённый кусочек при трансляции увеличивает объём программы на ЯВУ всего на несколько сотен байт. В нём видно как я в середине 90-тых реализовал оконность в системе, в которой консольный вывод её не поддерживает. Для этого вводятся 4 параметра задающие окно координатами верхнего левого угла и правого нижнего угла окна (WX1,WY1 и WX2,WY2). После чего меняя эти 4 переменные мы можем делать вывод в окно, очищать его стандартным кодом очистки, выводить в окно рамку с титром окна и т.п.

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


Attachments:
ASM convert.rar [68.62 KiB]
Downloaded 362 times


Last edited by barsik on 19 Dec 2019 06:42, edited 2 times in total.

18 Dec 2019 15:23
Profile
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Oсмелюсь Вам возразить как программист: Ваш код расточительно расходует байт-код даже при беглом просмотре!
barsik wrote:
Code:
COUT_C: PUSH    AF
        PUSH    BC
        PUSH    DE
        PUSH    HL
        CALL    STATUS
        LD      HL,TOBACK
        PUSH    HL
        LD      HL,(POSX)
        EX      DE,HL
        LD      HL,(EK_ADR)
        LD      A,(ESC_F)
        OR      A
        JP      Z,NO_ESC
        DEC     A               ; <-- Расход!!!
        JP      Z,BYTE2         ; если второй байт ('Y')
        DEC     A               ; <-- Расход!!!
        JP      Z,AFD73         ; если третий байт
        LD      A,C             ; четвёртый байт
Просто Вы не смотрели на мой файл.
А там я пошёл тем же классическим путём автора МОНИТОРа и обошёлся одним лишь «DEC».
К тому же все регистры у меня заняты.
  • HL - адрес символа на экране
  • E - позиция X
  • D - позиция Y
  • C - параметр X_max
  • B - параметр Y_max
  • A - младшие 7 бит символа
  • SF - флаг простой печати
  • ZF - флаг Esc-префикса
  • PF - флаг Esc-координаты Y
 "Вот фрагмент моего кода"
Code:
        ORG     0FCBAH
COUT_C: PUSH    AF
        PUSH    HL
        PUSH    DE
        LD      HL,(CUR_MAX)    ; Читаем правые границы окна
        PUSH    BC
        LD      B,H             ; B = Y_max
        LD      C,L             ; C = X_max
        LD      HL,(POSX)       ; Читаем позицию курсора
        EX      DE,HL           ; E = X, D = Y
        LD      HL,(EK_ADR)     ; Читаем указатель на символ
        LD      A,(ESC_F)       ; Читаем Escape-статус
        DEC     A               ; Переводим его в флаги SF, ZF, PF
        EX      HL,(SP)         ; Читаем код символа из C в стеке
        LD      A,L             ; Заносим в аккумулятор
        RLCA                    ; Чтобы замаскировать старший бит
        SCF                     ; и не испортить наши флаги,
        CCF                     ; использовать AND нельзя
        RRA                     ; Потому прибегаем к хитрости со сдвигом
        EX      HL,(SP)         ; Возвращаем
        CALL    ESCAPE
        LD      (ESC_F),A
        LD      (EK_ADR),HL
        LD      HL,I8275_CTRL
        LD      (HL),080H
        DEC     HL
        LD      (HL),E
        LD      (LD),D
        EX      DE,HL
        CALL    KBD_HIT
        LD      (POS_X),HL
        POP     BC
        POP     DE
        POP     HL
        POP     AF
        RET
CTRL:   EX      HL,(SP)
        INC     HL              ; Кажется, здесь расход?
        INC     HL              ; Просто так дешевле,
        INC     HL              ; чем куча JP в ESCAPE
        EX      HL,(SP)
        CP      A,008H          ; Теперь обрабатываем всё штатно
        JP      Z,LEFT
Форматирование работает?
Раннее я здесь уже публиковал код, где ячейки 7FF4…7FFF использовал, в том числе, под Esc-последовательность так же. Но тот код очень медленный, с защитой, гибкий, но несколько большой и затирает подпрограмму директивы «X».

Да, Вы правы, что использовать резервные ячейки МОНИТОРа несколько опасно.
Но, с другой стороны - не МОНИТОР должен подстраивать под прихоти прикладного кода, а прикладной код должен уважать рабочую область МОНИТОРа.
И то, что 1…3 из сотни заглючат - ничего не меняет.
Легче их подогнать под новую обстановку, чем учитывать в ПЗУ особенности всего зоопарка ПО.

Конечно, в эмуляторе не весь список программ.
Но подавляющее большинство их работает вполне стабильно и с моей версией прошивки МОНИТОРа…

P.S.: За демотивацию - Спасибо!
Но при имеющихся возможностях, чем-то увлечь себя же надо!
Есть мысль заказать в перспективе здесь же у Вас ПЗУ с моей прошивкой, чтобы на своём РК и проверить… :roll:
(За WMZ, конечно!)


Last edited by Paguo-86PK on 19 Dec 2019 06:25, edited 2 times in total.



18 Dec 2019 22:27
Profile WWW
Senior
User avatar

Joined: 21 Aug 2018 07:39
Posts: 163
Location: Кемеровская обл.
Reply with quote
Исходник вполне не плохо смотрелся бы в виде приложенного файла.


19 Dec 2019 04:12
Profile
Doomed
User avatar

Joined: 19 Feb 2017 03:46
Posts: 584
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Reply with quote
Post 
Icer wrote:
Исходник вполне не плохо смотрелся бы в виде приложенного файла.
Я специально не использовал вложение. Рассчитывал через день-два просто удалить из поста ASM-исходник. Можно было бы это и не делать, но тэг {code} не имеет балки вертикальной прокрутки, а тэг {spoiler} уничтожает форматирование, что делает и саму такую выкладку бессмысленной. Изменил пост, теперь исходник не занимает место, но пришлось воспользоваться другим форумом, где я умею выкладывать исходник под спойлер. Кстати и вложение с конверторами мнемоник дополнил. Те трое, кто уже это скачал, можете перескачать.
Paguo-86PK wrote:
Oсмелюсь Вам возразить как программист: Ваш код расточительно расходует байт-код даже при беглом просмотре!
Код не мой, я даже в нём не особо разбирался, т.к изначально знал, что логику его работы менять нельзя. Это написал кто-то из авторов РК86, скорее всего Зелёнко, но м.быть Попов или Горшков. И их код очень даже хорош, тем более для 1986 года. По крайней мере он намного качественнее, чем код в ROM-BIOS МИКРОШИ.

Команда DEC на флаге ESC_FLAG это отнюдь не напрасный расход байтов, а идея хранить номер байта в принимаемой искейп-последовательности прямо во флаге ESC_FLAG - удачна, т.к позволила авторам с'экономить несколько байтов.
Paguo-86PK wrote:
тот код... затирает подпрограмму директивы «X»
Директива X совсем не нужна. Её включили по аналогии с Микро-80, т.к для него в 1982 году ещё не было отладчиков. Но в 1986 году они уже были. Да и полноценный отладчик программистом пишется всего за два дня. И, если есть доступ к CP/M (а он у авторов РК был), то оттуда без особых хлопот берётся отладчик DDT и встраивается в резидентное ПО машины (что и сделано в ИРИШЕ). Сомневаюсь, что хоть кто-то использовал директиву X и отлаживал программы на РК без нормального отладчика. И уж тем более сейчас, даже если бы не существовало отладчиков, директива X вообще бессмысленна, никто не отлаживает сейчас программы в реале.

Но убирание директивы X даёт выигрыш ~40 байтов и не может "спасти отца русской демократии", т.е позволить существенно доработать ПЗУ РК. Если надо делать существенную модификацию ПЗУ, то нет смысла надрываться и экономить байты. Архитектура РК рассчитана на расширение ПЗУ, как минимум, до 8 кб.

Если нет желания менять РФ2 на 2764 или 27256, то второе ПЗУ РФ2 можно ставить без затраты доп.логики, используя идею, что применил С.Зонов в своей плате "зона". Он использовал как третий сигнал выборки 2764 вход PGM и поданным туда адресом A13 выбирал то старшую ПЗУ 2764, то младшую (с'экономив тем самым дешифратор).

Я уже немножко соображаю в конфигах для эмуляторов EMU и EMU80. Если надо, то могу поделиться конфигом для эмуляторов РК86, где ПЗУ 8 кб (или даже куча страниц ПЗУ по 8 кб), а также, где есть ОЗУ 8400...BFFF (это ценно, хотя бы для отладчика, т.к тогда им можно отлаживать код для любых адресов) и где есть ещё 16 страниц ОЗУ в 32 кб каждая в области 0...7FFF.
Paguo-86PK wrote:
не МОНИТОР должен подстраивать[ся] под прихоти прикладного кода, а прикладной код должен уважать рабочую область МОНИТОР-а. И то, что 1…3 [программы] из сотни заглючат - ничего не меняет.
Если бы сейчас был 1986 или хотя бы 1987 год и Вы бы опубликовали доработанный монитор в журнале "Радио", то м.быть... Да и то внедрить, т.е распространить абсолютно новый ROM-BIOS всегда проблематично. Даже 100% совместимые новые ROM-BIOS-ы содержащие новые возможности почти невозможно внедрить... Вон в журнале Моделист-Конструктор опубликовали больше версий разных ROM-BIOS-ов для Специалиста, чем прикладных программ. И что толку от введённой там поддержки окон и т.п, если все программы Специалиста работают только с стандартным исходным ROM-BIOS.

А сейчас уж совсем бессмысленно. Во-первых нЕ для кого, а во-вторых, раз уже есть программы написанные "вредителями" более 30-ти лет назад, то любой новый ROM-BIOS должен с ними совмещаться. Поезд ушёл... и ещё 30 лет назад. На многих архивных сайтах, у людей уже есть такие написанные вредителями программы и удалить или заменить их уже никто не сможет.

Но я вообще не понимаю смысла в введении оконных параметров туда, где их изначально не было. Ну вот, что это даст пользователю? Хоть на одну программу у него станет больше. Или он заморочится с перепрошивкой РФ2 (м.быть даже сожгёт при этом несколько штук дефицитных РФ2), а вместо хоть в чём-то выигрыша, потеряет, думаю, с десяток РК-игр и весь остаток своей жизни ему придётся решать программа не сработала из-за несовместимости нового ROM-BIOS или она просто дохлая.

Как я уже писал, отлавливать на входе CONOUT символы и имитировать адресацию вывода в заданное окно это совсем немного байтов, так что встроить в программу, где это затребовано это вообще не проблема. Вот если бы имелась сотня игр, которые требуют именно такой ROM-BIOS... Да и тогда, если это несовместимо, надо ещё подумать, стоит ли менять "шило на мыло". Потому, если предлагается что-то несовместимое, то и обсуждать это не имеет смысла.

Но я не понимаю зачем цепляться за те ячейки, что использует оригинальный ROM-BIOS. Это можно считать драйвером низшего уровня. Напишите к нему надстройку со своими ячейками задающими оконность. И совместимость останется и весь ваш новый функционал тоже.
Icer wrote:
чем-то увлечь себя же надо!
Конечно, но Вы цель ваших модификаций ПЗУ так и не объяснили.


Last edited by barsik on 19 Dec 2019 06:46, edited 1 time in total.



19 Dec 2019 06:19
Profile
Maniac
User avatar

Joined: 12 Apr 2011 20:43
Posts: 267
Location: Tashkent
Reply with quote
Quote:
barsik wrote:
Paguo-86PK wrote:
Oсмелюсь Вам возразить как программист: Ваш код расточительно расходует байт-код даже при беглом просмотре!
Код не мой, я даже в нём не особо разбирался, т.к изначально знал, что логику его работы менять нельзя. Это написал кто-то из авторов РК86, скорее всего Зелёнко, но м.быть Попов или Горшков. И их код очень даже хорош, тем более для 1986 года. По крайней мере он намного качественнее, чем код в ROM-BIOS МИКРОШИ.
Нo я хорошо помню, что в моём КР-03 была одна DEC…
Причём…
 "Скриншот дампа эмулятора"
Attachment:
File comment: Скриншот фрагмента ПЗУ эмулятора
rk86-monitor32.png
rk86-monitor32.png [ 16.3 KiB | Viewed 9397 times ]
Совпадает с
 "Публикацией журнала тех лет"
Image

barsik wrote:
Команда DEC на флаге ESC_FLAG это отнюдь не напрасный расход байтов, а идея хранить номер байта в принимаемой искейп-последовательности прямо во флаге ESC_FLAG - удачна, т.к позволила авторам с'экономить несколько байтов.
Да, я так и делал в соседней ветке. Там даже ввёл паузу до 127 символов на Esc-флаге, чтобы до 127 символов не отправлялось на печать, а уходили в некий драйвер (принтера). И параметры задавались десятичными ASCII-символами. Но в рамках того листинга - расточительство!
barsik wrote:
Директива X совсем не нужна. Её включили по аналогии с Микро-80, т.к для него в 1982 году ещё не было отладчиков. Но в 1986 году они уже были. Да и полноценный отладчик программистом пишется всего за два дня. И, если есть доступ к CP/M (а он у авторов РК был), то оттуда без особых хлопот берётся отладчик DDT и встраивается в резидентное ПО машины (что и сделано в ИРИШЕ). Сомневаюсь, что хоть кто-то использовал директиву X и отлаживал программы на РК без нормального отладчика. И уж тем более сейчас, даже если бы не существовало отладчиков, директива X вообще бессмысленна, никто не отлаживает сейчас программы в реале.

Но убирание директивы X даёт выигрыш ~40 байтов и не может "спасти отца русской демократии", т.е позволить существенно доработать ПЗУ РК.
Вот поэтому я её и оставил, как и директиву «R»…
barsik wrote:
Если надо делать существенную модификацию ПЗУ, то нет смысла надрываться и экономить байты. Архитектура РК рассчитана на расширение ПЗУ, как минимум, до 8 кб.
Вариант с простой заменой ПЗУ РФ2 более привлекателен, если рассматривать возможность рассылки ПЗУ почтой фанатам/бета-тестерам. На сайтах с нуля собирают РК до сих пор…

barsik wrote:
Я уже немножко соображаю в конфигах для эмуляторов EMU и EMU80. Если надо, то могу поделиться конфигом для эмуляторов РК86, где ПЗУ 8 кб (или даже куча страниц ПЗУ по 8 кб), а также, где есть ОЗУ 8400...BFFF (это ценно, хотя бы для отладчика, т.к тогда им можно отлаживать код для любых адресов) и где есть ещё 16 страниц ОЗУ в 32 кб каждая в области 0...7FFF.
По-моему он у меня был. Но вот вирусный бум последних лет часто вынуждал всякие exe'шки запускать под VMware, что меня изрядно утомило и я целиком ушёл в вэб-кодинг…
И сам я писал в LCC-Win32 эмулятор РК с точной эмуляцией ВГ75, включая сколлинг из-за атрибутов. Но на моём Pentium-90MHz он чуток тормозил и я забросил.
Конфиг… Конечно высылайте!
barsik wrote:
А сейчас уж совсем бессмысленно. Во-первых нЕ для кого, а во-вторых, раз уже есть программы написанные "вредителями" более 30-ти лет назад, то любой новый ROM-BIOS должен с ними совмещаться. Поезд ушёл... и ещё 30 лет назад. На многих архивных сайтах, у людей уже есть такие написанные вредителями программы и удалить или заменить их уже никто не сможет.
На сайтах сообществ фанатов много…
barsik wrote:
Но я вообще не понимаю смысла в введении оконных параметров туда, где их изначально не было. Ну вот, что это даст пользователю? Хоть на одну программу у него станет больше. Или он заморочится с перепрошивкой РФ2 (м.быть даже сожгёт при этом несколько штук дефицитных РФ2)
Ячейки были зарезервированы. Значит, в конце-концов должна быть версия ПЗУ с их использованием… :roll:
Говорю же, что можно бизнес маленький организовать… :roll:
barsik wrote:
Но я не понимаю зачем цепляться за те ячейки, что использует оригинальный ROM-BIOS. Это можно считать драйвером низшего уровня. Напишите к нему надстройку со своими ячейками задающими оконность. И совместимость останется и весь ваш новый функционал тоже.
Раз подпрограмма - в ПЗУ, то и ячейки следует использовать из той же области.
А другие драйвера пусть используют какие хотят…
А теперь… По теме…

В самом начале темы я обозначил идею РК XXI века своей мечты… :roll:
Путаница вышла из-за названия топика.
Мною имелось ввиду, как можно было бы спроектировать РК на элементарной базе тех лет, но с опытом наших дней.
При этом, не оглядываясь на дефицит, а учитывать уже существующие технологии. То есть, в 1986 процессор i80386 уже существовал и теоретически его можно было использовать в РАДИО-86РК! :lol:
Но, я не такой энтузиаст, чтобы изучать распиновку i386… :roll:

Напомню идею…
Всем программам под чтение отдать все 65536 ячеек ОЗУ#1 и под запись ОЗУ#2.
А вот под цикл M1 для чтения кода команды самые верхние 256 ячеек сделать окном для переключений между ОЗУ с приложением и ПЗУ с БСВВ.
И тут проблема в формальностях, так как у i8080 набор команд скуднее, но есть возможность фиксить циклы доступа к стеку, а у z80 команд больше, но он сигнализирует лишь о регенерации ОЗУ и цикле M1.
Тем самым, для переключения ОЗУ/ПЗУ с i8080 стек можно аппаратно переключать с приложения на БСВВ. А вот с z80 это невозможно…
И я на этом уже споткнулся…

P.S.: От досады и впиливаю оконца в ПЗУ РК… :mrgreen:


19 Dec 2019 07:33
Profile WWW
Doomed
User avatar

Joined: 19 Feb 2017 03:46
Posts: 584
Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Reply with quote
Post 
Paguo-86PK wrote:
Нo я хорошо помню, что в моём КР-03 была одна DEC…
Тут Вы правы, память Вас не подвела. В оригинале вот такой код:
Code:
        LD      A,(ESC_F)
        DEC     A
        JP      M,NO_ESC        ; если ещё не в ESC-последовательности
        JP      Z,BYTE2         ; если второй байт ('Y')
        JP      PO,AFD73        ; если третий байт
        LD      A,C             ; четвёртый байт
Но если Вы вспомните, чем отличается Z80 от КР580, то станет ясно, что мой код правильный и эффективный, а оригинальный вариант кода от авторов РК86 работает только на КР580 и виснет на Z80. В заголовке исходника так и написано, что это совместимый с процессором Z80 вариант.
Paguo-86PK wrote:
у i8080 набор команд скуднее, но есть возможность фиксить циклы доступа к стеку, а у z80 команд больше, но он сигнализирует лишь о регенерации ОЗУ и цикле M1.
У КР580 есть кроме 12 недокументированных команд ещё штук 7 документированных, но абсолютно бесполезных команд пересылок. И КР580 позволяет легко отлавливать эти команды и переключать ими в железе всё что угодно, считая их префиксами и постфиксами.

Вот как я в 1987 году собирался эмулировать Z80 на КР580. Ставим 556РТ4 у которого 8 адресных входов, заводим на них шину данных. РТ4 служит дешифратором для отлова кодов 12-ти недопустимых команд КР580, что коды Z80. Когда код команды совпадает с одной из 12 команд Z80, то сигналом с выхода РТ4 взводится триггер и на шину данных в этом маш.такте выдаётся код CALL, а в следующих ещё 2 байта адреса перехода. Отчего процессор делает CALL FF00. Где стоит обработчик Z80 команд. Он берёт из стека адрес возврата, отнимает от него 3 (длина команды CALL) и считывает код Z80 команды. Затем уходит на процедуру эмуляции этой команды Z80.

В DEC-процессорах 1801 был такой же механизм позволяющий на слабом процессоре прогонять программы более развитого процессора TI11. Когда 1801 встречал недокументированную команду, он делал TRAP и уходил на процедуру её эмуляции. Это немного тормозит, но главное, что программа всё-же работает.

Ничто мешает так же отлавливать код бесполезных команд типа 'LD A,A' и по ним включать другие банки ОЗУ, что Вы и хотите, т.е оперативно менять архитектуру. А в макроассемблере просто добавляем макрокоманду. Я так понял, что Вы хотите аппаратно эмулировать префикс MB процессора КР580ВМ1, чтобы одна команда действовала на другую банку ОЗУ.

Отлавливая код команд можно на процессоре КР580 с'эмулировать систему команд более прогрессивного украинского процессора КР580ВМ1 (я такой CPU сдуру не купил в 1992, когда предлагали, - надо было тогда купить их пару сотен штук а сейчас продать за $100 винтажным коллекционерам, стал бы миллионером).

В украинском процессоре КР580ВМ1 есть два префикса MB (код $28) и RS (код $38), которые будучи поставленными перед некоторыми командами меняют их действие. Префикс RS (Register Set) приводит к тому, что все команды с регистрами HL относятся не к основной паре регистров HL, а к дополнительной паре HL (называемой H1L1). А префикс MB (Memory Bank) на время всего одной команды переключает текущий банк ОЗУ на второй банк (т.о второй банк можно использовать только для хранения данных). Строго говоря, теоретически есть ещё префикс CS (Carry Set), который имеет тот же код $28, что и префикс MB. Он добавляет/отнимает у результата в следующих за ним командах DSUB, DAD и DCMP флаг CY.

Но коды $28 и $38 несовместимы с Z80 (т.к в нём это JR-команды), а вот использование в качестве префиксов кодов бесполезных команд не нарушает совместимости с Z80 (точнее не лишает двух JR-команд).


Last edited by barsik on 19 Dec 2019 08:47, edited 4 times in total.



19 Dec 2019 08:21
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 204 posts ]  Go to page 1, 2, 3, 4, 5 ... 14  Next

Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.