Расширяя горизонты возможностей ВГ75

petrenko · Post by **petrenko** » 12 Mar 2015 02:01

Есть те, кому сие интересно и нужно - Ваши старания вполне полезны - даже не сомневайтесь. !

Будем весьма рады узреть и код и даже изходник ( ну то есть дизассемблер у нас почти у всех есть - вся ценность в комментариях ..

)

Stan · Post by **Stan** » 12 Mar 2015 06:35

Paguo-86PK wrote:Я понимаю, что опубликованная "классика" лучше новодела. Но, раз уж на то пошло, я уже написал код, потратив неделю....

А я не давал никаких оценок типа "лучше"... "хуже"... я просто помню, что игрался в эти "окна" на "Микроше",
но при 32К памяти признал тогда эту идею несколько расточительной.
Поэтому меня и удивила несколько фраза:"до дампа речи не дошло".
А тут неожиданно и статья с кодом попались.

Так что я всего лишь сообщил и Вам, и всем, кто читает форум, что код там был и привел ссылки.

А если Вы выложите исходники, то, думаю, это будет интересно, поскольку сейчас всяк может поэкспериментировать
на эмуляторах и прочувствовать откуда есть пошла библиотека CodeVision...

Paguo-86PK · Post by **Paguo-86PK** » 12 Mar 2015 13:13

Stan wrote:
Paguo-86PK wrote:Я понимаю, что опубликованная "классика" лучше новодела. Но, раз уж на то пошло, я уже написал код, потратив неделю....
А я не давал никаких оценок типа "лучше"... "хуже"... я просто помню, что игрался в эти "окна" на "Микроше",
но при 32К памяти признал тогда эту идею несколько расточительной.
Поэтому меня и удивила несколько фраза:"до дампа речи не дошло".
А тут неожиданно и статья с кодом попались.

Так что я всего лишь сообщил и Вам, и всем, кто читает форум, что код там был и привел ссылки.

А если Вы выложите исходники, то, думаю, это будет интересно, поскольку сейчас всяк может поэкспериментировать
на эмуляторах и прочувствовать откуда есть пошла библиотека CodeVision...

Я вспомнил эту статью. Во-первых, с моими 16кб это реализовывать тогда было достаточно нереально. Тем более, вызывать из Бейсика.
Во-вторых, лень было в уме транслировать с ассемблера в машинный код - ассемблер "Микрон" тоже память занимал же.

petrenko wrote:Есть те, кому сие интересно и нужно - Ваши старания вполне полезны - даже не сомневайтесь. !

Будем весьма рады узреть и код и даже изходник ( ну то есть дизассемблер у нас почти у всех есть - вся ценность в комментариях .. )

Тестирую здесь, но встроенный ассемблер заменил. Т.е. исходный текст на инструкциях x86-синтаксиса, а выходной код - i8080. Поэтому, здесь он будет бесполезен (я думаю) и исходник выложить не могу.
В этом же ассемблере пропатчил "Монитор" (эмулятор это позволяет). Выбросил директивы U и X. Так как вместо "X"-кода у меня патч экрана (обработчик табуляции, звонка и Esc-команд: Открытие окна и смещение окна) в зоне 0xFF52..0xFFDC.

Сейчас пишу код 16-битного деления. Вроде бы делит и выводит на экран десятичное число. Использует стек для таблицы.
Делилка входит в библиотеку Esc-кодов: Выводит десятичное значение позиции курсора и остатка памяти в буфере текущего окна.
Вот дизассемблер:

Делитель DX на BX. выход: DX - частное, CX - остаток

Вообще-то, я думал, будь у меня под рукой программатор, прошил бы ПЗУ и проверил бы на реальном "РК".
Родственники удивляются, почему я часами торчу в дампах. И никогда не играю. Вернее поиграл в SimCity месяц и две недели в Angry Birds (это за последние 12 лет!). И снова провалился в дамп.
А ведь очень увлекательно отвоёвывать каждый байт! Я с гигантским трудом уложил свой код в зону FCBA..FE00! Написал за сутки, а вот утрамбовываю до сих пор!
Потому и вылез он в те FF52..0xFFDC.
Причём, старт Монитора происходит там же: Экран не очищается, а маскируется (0x7F), прописываются рабочие точки входа и т.д.
В общем, Монитор несколько изменён уже и на старте. Ничего не поделаешь...

Stan · Post by **Stan** » 12 Mar 2015 16:32

Paguo-86PK wrote:Родственники удивляются, почему я часами торчу в дампах. И никогда не играю. Вернее поиграл в SimCity месяц и две недели в Angry Birds (это за последние 12 лет!). И снова провалился в дамп....

А программирование и уж тем более на ассемблере - само по себе увлекательнейшая и азартная игра.

И самое приятное, что это не бесполезно потерянное время!

Paguo-86PK · Post by **Paguo-86PK** » 13 Mar 2015 12:45

Stan wrote:А программирование и уж тем более на ассемблере - само по себе увлекательнейшая и азартная игра.
И самое приятное, что это не бесполезно потерянное время!

©СНЛ wrote:Программирование, как процесс упорядочивания хаотической информации, разрушает карму

Очень приятно, когда код получается компактным и стабильным, как монолит.
Однако, есть и неприятные вещи...
Во-первых, в оригинале, экранные переменные располагаются по векторам:
7600 - WORD: Cursor Address
7602 - WORD: Cursor Position
7603 - BYTE: Esc+Y Sequency
Итого, 5 байт. У меня же, как минимум, 12:
-0x1 BYTE[]: Буфер Escape-стека (как минимум, 5 байтов).
+0x0 BYTE: Режим приёма потока.
+0x1 BYTE: Байт выравнивания. Временные данные.
+0x2 BYTE: Байт кода очищения скроллинга экрана.
+0x3 BYTE: Байт индекса кодовой страницы.
+0x4 WORD: Cursor Position - Позиция X,Y курсора относительно окна. Начиная с 0,0.
+0x6 WORD: Viewport Size - Ограничение окна по ширине и высоте.
+0x8 WORD: Viewport Offset - Позиция X,Y окна относительно всего экрана.
+0xA WORD: Viewport Buffer - Адрес буфера экрана.

Тем самым, слишком много переменных. Пришлось уменьшить буфер ввода и посадить их по вектору 0x7644.

Вот выкладываю (64кб) памяти.

8080dump.zip

Вставить в ассемблер эмулятора, закачать в память, нажать кнопку сброса, набрать <G>...

Интерфейс:
Три окна. У основного - линейка. Причём, нумерация строк также указывает на индекс параметров в Esc-стеке, которые выводятся столбиком в самом начале экрана.
Во втором и третьем окнах - графические линии. Назатием Забоя можно очищать буфер окна или изменять параметры. В частности, координаты вывода линий...
Управление:
Табуляция в режиме РУС/лат работает за табуляцию в окне. В режиме рус/ЛАТ - переключает окна.
Двойное нажатие Home прокручивает весь стек окон.

Так как онлайн эмулятор поддерживает вывод строчных символов с кодами >128, в Окнах можно переключаться через Esc<128>P или Esc<0>P. Он же определяет, каким символом будет зачищаться окно по 1F.
Указав Esc<Код>C, скроллинг будет заполнять последнюю строку этим кодом.
Причём, этот же код будет служить старшим байтом для вывода десятичного числа.
Так, Esc<n>D выводит n десятичных цифр. Выводимое число должно указываться в байте временных данных и кода скроллинга экрана.
Доступ к этим ячейкам достигается через Esc<Src>;<Dst>M. Где Dst/Src - приёмник/источник. Все числа вводятся относительно байта режима приёма потока. Так:
Esc<4>;<1>M копирует координату X-курсора во Временный байт.
Esc<9>;<255>M копирует координату Y позиции окна в -1 байт - буфер Escape-стека.

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

Если нажать кнопку Сброса эмулятора, экран очистится не весь. И все директивы монитора будут выводится какбы внутри окна. Там можно посмотреть на "полную скорость", без всяких перехватчиков и фокусов. Загрузить и прогнать игры - Цирк и Вулкан не тормозят.

Собственно, ассемблер (вместо встроенного в онлайн-эмулятор) с несколькими листингами и сам мой код Монитора и Окон.

i8080asm.zip

P.S.: Кстати, доработал код:
1. Множитель на 78 можно подменить своим (перспектива смены режимов ВГ75);
2. Тональность звонка (07) можно изменять и Esc+Y - передаётся в Escape-обработчик;
3. Можно указать количество удаляемых из печати символов (аналог Mid$(n) Бейсика) до 240 (тем самым, ограничив Esc-стек до 12). Можно использовать для пропуска незначащих десятичных цифр.
Таким образом, подменив множитель на свой, можно направить поток печатуемых в любое место в памяти.

Paguo-86PK · Post by **Paguo-86PK** » 14 May 2015 13:30

Досадно, но из меня программист какой-то поршивый получается, если вдуматься, что 20 лет ушло на осознание одной фишки...

Оказалось, что если в ПЗУ МОНИТОРа последние 16 байтов заполнить кодом FF, посадить на 0038h соответствующую функцию, то в Бейсиках функцией usr(-1)..usr(-16) можно вызывать всех популярных API МОНИТОРа (F803..F821). Например:

Code: Select all

0038 E1       POP  H
0039 7D       MOV  A,L
003A E6 0F    ANI  0Fh
003C 6F       MOV  L,A
003D 87       ADD  A
003E 85       ADD  L
003F 6F       MOV  L,A
0040 26 F8    MOV  H,0F8h
0041 E9       PCHL

или

Code: Select all

0038 E1       POP  H
0039 7D       MOV  A,L
003A 87       ADD  A
003B 85       ADD  L
003C 2F       CMA
003D 3C       INR  A
003E 26 F8    MOV  H,0F8h
0040 6F       MOV  L,A
0041 E9       PCHL

Paguo-86PK · Post by **Paguo-86PK** » 07 Apr 2017 20:20

Кстaти…
Существовали ли игры, использующие "сбойный" скроллинг ВТ57/ВГ75 как полезную фишку?
В своё время я даже пытался как-то скроллить экран таким образом, дожидаясь статуса конца кадра.
И "презентацию" делал с двумя мерцающими кадрами: ВГ75 настроен так же на 78x30, тогда как ВТ57 - на 78x60. Получилось нечто типа полутонов. Прорисовал свою эмблему в основном кадре, а во второй - её частично копировал, чтобы был эффект "блеска"…

P.S.: Вот реальной машины под рукой нет (в шкафу она с дохлым БП), а новые идеи и вопросы - мучают…

Мои мысли - мои скакуны…

P.P.S.: Кстати, знатоки схемотехники…
Не будет ли "очень плохо", если вывод 8 D3 подтянуть к выводу 16 D2, при этом выводы 15 и 21 от D2 подтянуть к выводам 11 и 12 внешнего 155ТМ2, вывод 9 которого через 680Ω подать на базу VT2?

Paguo-86PK · Post by **Paguo-86PK** » 15 Dec 2019 13:18

Нe поверите!
Написал Windows'86 за неделю…

В общем, подошёл к вопросу более аккуратнее, как настоящий Спартанец!

Переписал подпрограммы вывода символа на экран под изменяемый вьюпорт и всё втиснул в ПЗУ без вреда его функциональности - директива «X» работает.

Прежде всего, устранил некоторые вольности авторов РК.
А именно, заменил JMP по адресам F830/F833 на LHLD/SHLD, как это сделано в другом РЛК (Орион?), чем отвоевал 8 байтов по FF52…FF59. Пришлось переработать код холодного старта и втиснуть его в F83D…F86B, сделав частью сообщения промпта (такое бывает, сами знаете)…
Немало головной боли доставила подпрограмма «бипа» по FD27…FD37, так как её и перемещать нельзя из-за совместимости, и мой код она несколько неудобно рассекала и приходилось вставлять NOP, пока не переработал размещение отдельных подпрограмм.

Так как МОНИТОР не использует некоторые ячейки служебной области, я задействовал их под:

7610 - X1 вьюпорта
7611 - Y1 вьюпорта
7612 - X2 вьюпорта (регистр C)
7613 - Y2 вьюпорта (регистр B)

И регистры BC хранят границы, которые не должна пересекать позиция DE. А так как C хранит код символа и A хранит Escape-статус, пришлось немало попотеть, чтобы и границы считать, и статус проверить, и код в A перенести. Без XTHL не обошлось!
А так как МОНИТОР при старте выполняет очистку экрана кодом 1F и не подозревает про мой вьюпорт, то пришлось позаботиться и об инициации…

А как же «Вулкан», «Ксоникс», «Питон», «Тетрис» и «Цирк»?
«Питон» работает нормально…
Кое-что работает некоторое время, а потом - всё виснет и дохнет…
Так, «Ксоникс» самовольно перезаписывает адрес символа по 7600, из-за чего моя подпрограмма по коду «1F» не может его восстановить и очистить экран, так как думает, что курсор и так в нулевой позиции! Это очень неприятный и неустранимый баг, так как нельзя нарушать позиционирование…

В общем, все мои потуги - коту под хвост!

Тем не менее…
Если кому интересно - вот мой вариант…
Вставляете листинг из архива в эмулятор и прошиваете ПЗУ, после чего жмёте «RESET».
При этом, в ОЗУ помещается мой «менеджер окон» и запускается по:

«G0»: Режим максимального окна - 78×30. Довольно любопытно посмотреть, как работают некоторые директивы МОНИТОРа в этом режиме
«G1»: Стандартное окошечко - 64×25. Просто это должно быть встроенным
«G2»: Вывод содержимого памяти ASCII-дампом
«G3»: Среднее окошечко
«G4»: Маленький менеджер окон… Нажатием TAB переключает окна; Курсорные клавиши двигают окна; Пробелом выбирается опция в окне с вопросом; «ВК» подтверждает опцию; Другие клавиши - переход в режим МОНИТОРа

Естественно, защиты от дурака нет и нужно быть аккуратным при перемещениях «окошек».
(Именно из-за этого игры и гонят: Снизу экрана начинают расти сталагмиты! И это - не стек…)
Тем самым, я убедился лично сам, что и 30 лет тому назад МОНИТОР можно было изначально спроектировать с более гибкой подпрограммой вывода символа на экран с произвольной активной областью!

P.S.: В отличии от программирования на всяких Java/Perl, реально мозги работают именно над кодом i8080/z80!

Lavr · Post by **Lavr** » 16 Dec 2019 10:10

А вот такой скромный вопрос к знатокам ВГ75 (кажется, мы его где-то обсуждали...)

ВГ75 можно как-либо подключить в схему без контроллера ПДП?

Paguo-86PK · Post by **Paguo-86PK** » 16 Dec 2019 12:13

Lavr wrote:А вот такой скромный вопрос к знатокам ВГ75 (кажется, мы его где-то обсуждали...)

ВГ75 можно как-либо подключить в схему без контроллера ПДП?

ZX81 же?

Разве через ВГ75 сложнее просто считывать в цикле буфер?
Хотя, одна ВТ57 куда проще, чем ИЕ19+КП11 и т.п…

Lavr · Post by **Lavr** » 16 Dec 2019 13:03

Paguo-86PK wrote:
Lavr wrote:ВГ75 можно как-либо подключить в схему без контроллера ПДП?
ZX81 же?

А в схеме ZX81 был аналог ВГ75?

Что-то я его не вижу на схеме ZX81...

ZX81 Circuit Diagram

barsik · Post by **barsik** » 16 Dec 2019 13:25

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

Для псевдо графического режима, где 8 линий растра в знакоместе, для реакции на запрос о закачке 78-ми байтов от ВГ75 есть время в 8*64= 512 МКСЕК. Если по запросу от ВГ75 процессор Z80 уйдёт в аппаратное прерывание и затем командой LDIR зальёт в ВГ75 требуемые ему 78 экранных байтов, то на это у него уйдет 21*78= 1638 машинных тактов. При клоке Z80 в 5 МГЦ период маш.такта равен 200 НСЕК. Итого 1638*0.2= 327.5 МКСЕК. И у Z80 из 512 МКСЕК останется ещё почти 200 МКСЕК на прогон программы пользователя.

Потеря в процентах составит (512-327)/512, что даёт падение эффективной скорости прогона до 36% от клока Z80. Т.о на время вывода растра программа будет прогоняться на скорости ~36% от клока. И только на время вывода строки на обр.ход луча по кадрам (когда ВГ75 ничего у ПДП не просит), которая в РК формирует КСИ на время в 512 МКСЕК Z80 оторвётся по полной, будет гнать программу на полном клоке в 5 МГЦ. Эффективный такт Z80 будет выше, чем 0.36*5.0= 1.8 МГЦ, что очень неплохо для РК86.

А для текстового режима по сбросу, когда в знакоместе 10 линий растра, ситуация ещё более радужная. Там 327 МКСЕК уже из 640 МКСЕК Z80 будет тратить на закачку ВГ75, т.е потеря скорости составит всего 51%. 49% времени процессор Z80 будет работать с пользой, а эффективный такт будет около 2.5 МГЦ, т.е будет примерно вдвое скоростнее, чем базовый РК86. Хотя при такой схемотехнике без ПДП программные звуки РК86 выдавать не сможет или они будут очень хриплыми.

При процессоре КР580 его скорости просто не хватит. Т.к у него нет команды LDIR, его надо разгонять минимум до 4.5 МГЦ. Если применить КР580 на клоке менее 4.5 МГЦ, то реальное быстродействие будет почти нулевым.

Lavr · Post by **Lavr** » 16 Dec 2019 21:45

Lavr wrote:А вот такой скромный вопрос к знатокам ВГ75 (кажется, мы его где-то обсуждали...)

Ага, мимоходом обсуждали, и Shaos сказал, что знает как...

Shaos wrote:Тогда я наверное уже знаю как выкинуть ПДП с его регистром старшей половинки адреса и сделать работу видеоконтроллера незаметной для процессора (т.е. без тормозов)...

Lavr · Post by **Lavr** » 17 Dec 2019 06:15

Paguo-86PK wrote:
Lavr wrote:ВГ75 можно как-либо подключить в схему без контроллера ПДП?
ZX81 же?

Я вобще-то намёк ваш понял - использовать сам процессор в качестве генератора адресов вместо КПДП,
как это сделано в ZX80 и ZX81.

Я такой вариант просчитывал и смоделировал и для КР580ВМ80 безо всякого ВГ75...
Но хотелось бы увидеть - с реальной ВГ75 уже так делали или нет?

Вопрос не праздный и не теоретический у меня: в начале 2000-х один мой хороший друг вдруг подарил
мне коробочку, полную этих ВГ75, да только в тот момент они были уже никому не нужны...

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

barsik · Post by **barsik** » 17 Dec 2019 22:14

Вопрос был насчёт можно ли избавиться от ПДП, а не от ВГ75.

Но раз уж речь зашла о упрощённых компьютерах на Z80, не использующих традиционного контроллера CRT, то хочу отметить, что ZX80/81 это не самый грамотный компьютер из подобных, и даже, возможно, не первый. Тут настораживает, что его разработчик не смог получить US-патент на идею визуализации экрана процессором Z80.

Видеовывод в ZX80 чересчур наворочан вокруг обоих прерываний (INT и NMI) и основан на том, что Z80 выдаёт на шину адреса во время цикла регенерации RFSH на младшую половину адресов регистр R, а на старшую - регистр I. Что и позволяет использовать эти регистры как адрес ячейки экранного байта. Т.о для вывода видео на принципе ZX80 годится только процессор Z80.

Но были и другие подобные машинки, которые также обеспечивают вывод с минимальным расходом микросхем, но принцип работы у них более грамотный и не требуется обязательно процессор Z80. Для вывода текста (не графики) можно использовать любой процессор, имеющий прерывания, у которого команда NOP однобайтовая, что позволяет регистр PC внутри процессора использовать в качестве заменителя группы счётчиков видеогенератора. А Z80 благодаря наличию регистра I позволяет выводить не только символы, но и графику. Для синхронизации с видео-базой не нужны прерывания (достаточно WAIT или HOLD, отпускаемых по ССИ). Но прерывания всё-равно необходимы, чтобы прерывать программу пользователя в момент конца кадрового бордюра для ухода в процедуру визуализации экрана.

В ZX80 - 21 микросхема (в ZX81 по сути столько же, хотя большая часть их внутри ULA). В оригинале подобного немецкого компьютера BCS-3 сделанном на более древней элементной базе, чем ZX80 - 26 микросхем. Но если в нём более древнюю элементную базу (ОЗУ и ПЗУ) заменить на те же микросхемы, что применены в ZX80, то число микросхем сокращается до 17. Это замена 4 малоёмких однокилобайтовых ПЗУ на одну 2732 и 8 корпусов 565РУ2 заменяются на две 2114 (541РУ2). Деталей меньше потому, что принцип синхронизации с синхро импульсами более грамотный, чем в ZX80.

А на порядок круче другой немецкий компьютер (RFE 08.1987 стр.515), который использует тот же принцип визуализации, что и ZX80/81, т.е основан на визуализации циклом RFSH с использованием регистров R и I, но в отличие от них, он не текстовый, а полноценно графический. Причём, что удивительно, деталей в нём почти вдвое меньше, чем в ZX80 (в оригинале там стоят 565РУ5, отчего - 21 корпус, но я считаю общее число деталей уже с учётом замены 8 штук РУ5 на одну штуку 62256). Число деталей в этих компьютерах (как и в Галаксии) сокращается потому, что используется более грамотный (чем в ZX80/81) метод синхронизации с ССИ и КСИ.

Причём в этих компьютерах (как и в Галаксии) нет такого фатального недостатка, как гашение экрана при нажатии на клавишу, что имеет место в ZX80/81 и отравляет жизнь их пользователям.

Для организации видео ВГ75 в подобных самоделках бесполезен, т.к требует наличия ПДП и к тому же он символьный, а не графический. Но ВГ75 удобно применить в подобной машине для выдачи временной базы. Т.е для формирования ССИ, КСИ и кадрового бланка (кадровый бордюр в таких машинах делит процессорное время между программой и выводом видео). Применение в схемах подобных машин (таких где видео выводит сам CPU) для создания временной базы БИС ВГ75 позволяет с'экономить несколько микросхем.

В качестве заменителя БИС CRT в конце 1970-тых годов для видеовывода сэр Клайв Синклер мог бы использовать БИС ПДП типа ВТ57 или ВТ37. Они тратят на засылку одного байта в порт 4 маш.такта и легко синхронизируются импульсом ССИ. Если в РК86 ПДП пишет байты в ВГ75, то что мешает ему сразу писать экранный байт в выходной сдвиговый регистр.

Расширяя горизонты возможностей ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75

Скроллинг ВГ75 - как полезная фишка

Windows'86

Re: ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75

Re: ВГ75