nedoPC.org

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

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

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

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

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

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



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

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

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

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

Очень приятно, когда код получается компактным и стабильным, как монолит.
Однако, есть и неприятные вещи...
Во-первых, в оригинале, экранные переменные располагаются по векторам:
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кб) памяти.

Вставить в ассемблер эмулятора, закачать в память, нажать кнопку сброса, набрать <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-кодов.
Если отключить вывод отладочной информации, скорость возрастёт.

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

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


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

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

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

или

Кст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?

Н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!

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

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

ZX81 же?

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

А в схеме ZX81 был аналог ВГ75?
Что-то я его не вижу на схеме ZX81...

Очень просто не получится, но, если я верно понимаю работу ВГ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 МГЦ, то реальное быстродействие будет почти нулевым.

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

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

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

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

Вопрос был насчёт можно ли избавиться от ПДП, а не от ВГ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, то что мешает ему сразу писать экранный байт в выходной сдвиговый регистр.