nedoPC.org

Тaк как код ПРОБЕЛА после всех операций получается 5F и его нужно искусственно приводить к 20, в своём драйвере (пробном, выше) я сделал так, что при нажатии «СС/SHIFT» это преобразованием не происходит и ПРОБЕЛ выдаётся кодом ПОДЧЁРКИВАНИЯ…

В том же КР-03 с МС-7007 функциональных клавиш - пять. И мне было странно видеть в оригинальной клавиатуре четыре функциональные клавиши и дырку, тогда как в ПЗУ их - пять…

Все эти дни я возился со своими алгоритмами под вещественную арифметику.
Запарился вдоль и поперёк одним только делением на константу 10 для печати числа и три дня на её отладку убил, так как было концептуальное недопонимание сути.
Только что я победил явные баги и теперь печать дампа F800…FFFF по «G0» практически не просаживает производительность на первый взгляд.
Как уже понятно, я не подглядывал в готовые исходники и шёл своим путём проб и ошибок.
Код вырос до 1 Кб! Но там много мусора и промежуточного кода…

Если в z80 имеется теневая группа регистров, то в i8080 для реализации печати 24-битного числа пришлось здорово попотеть!
Сейчас числа печатаются по битам мантиссы в B:H:L и в C указывается экспонента. Но пока всё не очень проработано и экспонента верно отображается только от 0 до 24, так как я не совсем ещё въехал в тему и не понимаю, как печатать остальные комбинации…Тот же Бейсик РК использует лишь 16 бит мантиссы…

Вот эта штука должна помочь отцу русской демократии...
http://scicenter.online/kniga-mikroelektronika/programmyi-dlya-mikroprotsessorov-sprav.html

В версии М3 ОРИОНА для Z80 символ подчёркивания выдаётся по сочетанию <УС>+<пробел>.
В РК-мониторе не нужны числа с плавающей запятой. Или арифметические подпрограммы для РК-бейсика Вы сразу же включаете в свой ROM-BIOS ? Т.е начали сразу писать и новый РК-бейсик с развитой арифметикой (т.к целочисленная арифметика с числами до +/-32767 почему-то не устраивает)?

В бейсике не нужна очень уж точная арифметика с точностью в 38 десятичных знаков. Очень может быть, что Билл Гейтс ввёл арифметику с плавающей запятой в исходно целочисленный бейсик для Альтаир-8800 как рекламный трюк (якобы с этим бейсиком вы сможете считать свои деньги с нужной точностью). Если это и было надо, то только считать налоги и банковские проценты. Для игр столь точные расчёты не нужны.

В Apple-II тоже вначале был целочисленный бейсик и его всем хватало (подтверждением тому является много игр для Apple-II на целочисленном бейсике). А затем пришёл Билл Гейтс и втюхал им свой бейсик с числами с плавающей запятой, чтобы каждый пользователь Apple-II смог расчитать траекторию как ему умотать с этой планеты. И что, это хоть на грамм улучшило качество игр на бейсике?

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

Когда я делал свой TINY бейсик мне показался мал диапазон двухбайтовых целых чисел и я не напрягаясь просто расширил диапазон чисел до 3 байтов. Этого достаточно для игр и даже для небольших бытовых расчётов (если бейсиком считать деньги, то столько денег, что диапазона 24-х двоичных разрядов не хватит, ни у кого из владельцев РК86 нет). А уж если вдруг неожиданно понадобится рассчитать траекторию полёта на Луну или на Марс, то сейчас можно воспользоваться бейсиком на IBM PC (а если программу расчёта написанную на бейсике скомпилировать с помощью QUICK-бейсика или POWER-бейсика, то время расчёта сократится в 5 раз).
Понятно теперь откуда взялся имеющий хождение среди пользователей ОРИОНА (и даже продаваемый частными МП торгующими программами для бытовых ЭВМ) набор подпрограмм для арифметики на процессоре КР580 (что во вложении). Кто-то не поленился набрать эти подпрограммы из этой книги.

Вoт сижу и думаю, не переписать ли CONOUT снова с нуля?
Левый-верхний угол задаётся ячейками 7610:7611 и в коде при перемещении влево/вверх нужно считывать ячейки и сравнивать с D:E. Потому-что координаты - абсолютные. А если их сделать относительными, то в любом окне верхний левый угол будет 0,0. Но это нарушит работу F81E-подпрограммы, в которой нужно будет прирастить ячейки 7610:7611 и увеличить её на 7 байтов. А значит - подыскивать другое место размещения…
Но, в таком случае, в самой CONOUT код сократится до «DEC E+RET P» и курсор ВГ75 придётся опять же - приращивать…

Просто проверяю производительность выводом дампов.
Что интересно «DF800,FFFF» травит дамп 13 секунд, а мой код с 24-битными и запятой - 14 секунд…
Каким образом разница может составлять около 1 секунды‽
(2048 байтов против 512 недовещественных.)

Когда Вы сказали, что в ассемблере под метку уходит 8 байтов, 6 из которых - символы имени, я понял, что это - не экономично.
Ведь 6×8 = 48 бит - 6 символов по 8 бит, а если перевернуть их как 8×6, получим уже 8 символов метки по 6 бит. То есть, произвести компрессию…
В Бейсике переменная может обозначаться всего двумя символами - 16 бит. Но если кодировать имена символами по 5 бит, получим уже три символа - по схеме 5+6+5. То есть первая и третья могут быть только буквой, а вторая - и цифрой тоже (1…26 - буквы, 27…63 - числа от 0…36). Имя переменной уже до четырёх символов может иметь. Или схему изменить на 5+5+6 - с числом в конце…
А так как оттачивать алгоритмы распаковки/упаковки имён лучше на чём-то дельном, то я решил вещественные числа хранить так.
То есть, 4 байта на имя переменной и 4 байта на вещество. А ошибочные комбинации мантиссы принимать за опцию (строка, массив строк, массив чисел и т.п…).
Спасибо!
Пока чисто на энтузиазме пытаюсь работать. Интересно прощупать границы своей компетентности…

Когда-то я тоже думал, что синус-косинус есть только в IBM-PC. Но статья в журнале РАДИО открыла мне глаза.
В своё время я над учительницей по математике гордо издевался расчётами синусов на Бейсике РК. Сама она знала Фортран и не одобряла применения столь мощной (против калькуляторов) техники для решения школьных задач!

Вот когда(если) до этого удастся дойти, проверю себя.

На одном сайте, где мне пытались помочь с моим «x80», задались вопросом, зачем мне столь мощный восьмибитник?
Я ответил в стиле «Джентльменов удачи» с «ограблением посольства»: Своё государство объявлять буду в ООН и мне нужно соорудить ПВО с собственным машинным кодом, чтобы взломать не могли пару дней…

Вообще-то, Товарищи, Вы все тут забыли про это: Почему при мыслях модернизации сразу все думают про графику или звук?
Вместе с теми же ВИ53/ВН59 лучше подключить и i8231/i8232 с К512ВИ1.

В тот же IBM-PC этот математический сопроцессор моментально стал стандартом и вклинился в систему команд.
Хотя, знающие люди в курсе, что восемь ESCAPE-кодов в x86 имеются не только для FPU¹, а для любого сопроцессора².



Но промышленность ради рынка начала встраивать именно FPU как единственный сопроцессор и всю концепцию масштабируемости системы команд периферийниками убила!
Хотя, вместе с инструкциями математики могли бы сейчас иметь инструкции графики и звука. А так как Операционка может эмулировать всё, то и звук бы выводился ни через DirectSound, а с помощью перехвата и эмуляции Escape-команд звукового сопроцессора. Которого для x86 никогда не было и уже не будет!

Мысль хорошая, хотя несколько запоздалая во времени...
Отечественных аналогов этих сопроцессоров, насколько я знаю, не выпускали, но я с
интересом набрал в поисковике "i8231 купить" - результат можете посмотреть сами...

Для тормозных 8-ми разрядок эта идея компрессии меток может пригодиться, хотя из-за низкой скорости CPU эта идея вероятно снизит скорость трансляции. Для высоко разрядных скоростных ЭВМ проблема экономии ОЗУ путём ограничения длины меток (так же, как и проблема скорости прогона) вообще не актуальна, т.к там ОЗУ как грязи и потому десяток лишних килобайтов под таблицу меток не приведут к появлению обидного сообщения "OUT OF MEMORY".
Всем программистам возможностей CONOUT по выводу символов хватало (это если не считать отсутствия инверсии, псевдографики и КОИ-8). А не хватало программного проигрывания трёхголосной мелодии (управляемой, например, искейп-командой выкинутой на CONOUT, по типу как в ИРИШЕ, что позволяет вывод музыки из ЯВУ).

Это не так уж и сложно написать. Можно с выводом на один общий бит, а проще на три отдельных бита (т.е с аппаратным сложением). На три отдельных бита - проще и громкость намного выше. Т.к когда вывод на один общий разряд порта, приходится выдавать короткие иголки, а при трёх выходных портах - меандры. РК86 тоже может многоголосие, его музыкальная система давала специфическое (т.е слегка хриплое) многоголосие по одному биту и его MUSIC BOX также играл в несколько голосов.
Потому что арифметика с точностью в 100 знаков никому не нужна, а нужна красота - красивая картинка и красивая музыка. Интегралы на РК86 никто считать никогда не планировал и не будет. Быстрая арифметика нужна для графического компьютера, чтобы выводить 3D-графику, а применительно к РК86 даже говорить о потребностях в хорошей арифметике неуместно.

Из всех задач обычных компьютеров, которые с минимальным успехом может решить РК86 - это редактирование текста (для этого ему нужна ОС работающая на массовый привод плюс 3-4 фонта коммутируемые атрибутами). РК86 с небольшими доработками (дисковод, 64К, фонты 8*10, турбо) мог бы стать почти офисным компьютером, аналогом Роботрона-1715 и на нём мог бы даже работать Super Text. Как радиолюбительский компьютер РК годится для управления настольной железной дорогой, мультиметром на 572ПА2, тестером TTL-микросхем, приёма радиолюбительского телетайпа или медленного телевидения и т.п. любительских задач.

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

Ну это неправда. Мне как раз очень была нужна не только точная но и быстрая арифметика.
Но чего не было - того не было... Кстати, в некоторых отечественных справочных
источниках сопроцессор для 580ВМ80 упоминается, как если он был, но его не было.
И сопроцессор действительно весьма ускоряет программу с расчетами, хотя убедиться
в этом мне довелось только на 286-й машине...

Нарочнo подсчитал количество тактов, затрачиваемых COUT.
Получается, примерно:

• Нормальный вывод очередного символа в строку - 615 тактов
• Вывод символа с переводом на следующую строку - от 688 до 4213 тактов
• Обыкновенный возврат курсора - от 604 до 4129 тактов
• Вывод символа с прокруткой - от 77156 до 80681 такта

Тем самым, простой построчный вывод дампа с прокруткой затрачивает до 129881 такта
Тем самым, нельзя просто так проверять производительность печати вещественных чисел в режиме прокрутки экрана, так как она перекроет прожорливостью любые вычисления
А так, вывод 80 символов - 49200 такта + возврат каретки ≈ 53329 тактов на строку.
Вроде бы по мелочам, а печать одной строчки не так уж мало жрёт: При частоте 1,78 ≈ до 33 раз смещает строки.
То есть, штатное заполнение всего экрана без прокрутки - практически 1 секунда!
Унифицировал прокрутку, наконец-то: Теперь она работает и вверх, и вниз. Но на кадре 64×25 жрёт до 129429 тактов (против 76468 из подсчётов выше). И при частоте 1,78 ≈ лишь до 14 раз строки успевает сместить…
(За всё нужно платить!)Читaл заметки счастливчиков с ZX-Spectrum-128 про шаманство доступа ко всем 128 Кб.
И подумал сейчас, что тот же «POKE 65536,0» мог бы работать как «POKE 0,0», но уже в страницу #1.
Тем самым, если начну городить свой Бейсик, то «POKE/PEEK» будут записывать старшие 8 бит адреса в порт клавиатуры с расчётом, что A000…A7FF работает в страничном режиме…
Потому, ±32767 уже не хватит.
(В том же GW-Basic под XT костыль был - DEF SEG…)

Дa, пользовательская директива «J» здорово упрощает процесс сравнения результатов.
Сейчас сравнил данные из справочника с результатом своего алгоритма вывода числа: Где-то совпадает один-в-один. Где-то - ошибка из-за отсутствия округления…
А ещё и поддержку отрицательной экспоненты нужно вводить…

Но, сам факт, что ряд данных из книги отображает у меня верно - уже удивительно!
Выходит, мой алгоритм с потолка не такой уж кривой!
То есть, сама моя идея 6 бит экспоненты и 24 бит мантиссы - стандарт!

Зачем такие сложности? В РК-бейсике есть возможность вызова подпрограмм (функцией USR, см.здесь), - потому достаточно ввести в ПЗУ F800 п/п-ммы F836 и F839 (аналогичные таким же подпрограммам ПЗУ ОРИОНА), позволяющие читать/писать байты в запасных банках памяти.

В традиционном бейсике ввести оператор "POKE 65536,0" вряд-ли получится, т.к операнд у оператора POKE должен быть целочисленным в интервале от -32768 до +32767. А если переделать оператор так, чтобы операнд стал числом с плавающей точкой, то это резко тормознёт. Не помню про РК-бейсик, но в профессиональных бейсиках можно вводить и HEX-числа с префиксом &H (а в некоторых самодельных бейсиках - для этих же целей используют в качестве префикса только &).

И при цельнобанковой коммутации Вы никак бейсиком загруженным в ОЗУ не залезете в другую банку, - это можно сделать только подпрограммой в ПЗУ (или расположенной в некоммутируемом участке ОЗУ). А вот, если добавлять в РК дополнительное ОЗУ не цельно-банково (применительно к РК это значит страницами по 32 кб), а более грамотно, т.е в 8-ми килобайтовом окне A000...BFFF, то ничто не помешает Вам включить в этом окне нужный кусок дополнительной памяти и пикапокить его из обычного бейсика.

А если надо лазить в доп.ОЗУ новым самодельным бейсиком, то можно придумать операторы XPOKE/XPEEK у которых будет дополнительный операнд - номер страницы доп.ОЗУ (в 8 кб), а адрес ячейки будет в интервале 0...8191. Кстати, считается, что сделать свой самодельный бейсик лучше, чем бейсик Билла Гейтса (от которого и происходят бейсики РК86), обойдётся разработчику слишком дорого по трудозатратам.
Там как раз доступ к доп.ОЗУ удобный и понятный, без всякого шаманства и, как видите, даже в Spectrum-128 доступ к доп.ОЗУ сделали в окне, т.к любому ясно, что это удобнее программисту.
За написание и популяризацию бейсиков-интерпретаторов надо отрывать руки. Тем более, что Бейсиков и без того хватает, их достаточно сделали в 1975...1980, когда они имели хоть какой-то смысл. Бейсик запрещён к преподаванию в школах и ВУЗ-ах всех стран (и уже давно заменён Паскалем), т.к научно доказано, что Бейсик наносит непоправимый вред, разрушая формирования правильного программного мышления у людей. Было бы разумно даже ввести уголовное наказание за пропаганду бейсика.

Хотя у интерпретатора есть одно полезное свойство - он удобен в начала программирования новичком, т.к он по сути IDE. Если уж так хочется написать интерпретатор, то было бы интереснее, если бы Вы взялись вместо написания никому ненужного интерпретатора Бейсика за написание интерпретатора Паскаля (которые для PC уже делали).

Для РК речь конечно о урезанной версии Паскаля, что-то вроде Tiny Pascal (если не хватит 29 кб основного ОЗУ, то можно использовать и дополнительное в 1 мб прокачиваемое в окне A000...BFFF). Ясно, что интерпретатор это не конечный инструмент разработчика (окончательную версию надо компилировать). Главное то, что интерпретатор Паскаля полезен для облегчения вхождения в программирование для 8-ми разрядок на Паскале новичкам.

Кстати, первые версии Паскаля, популярные до конца 70-тых годов (в том числе и Паскаль для Apple-II, что немало способствовала успеху этого компьютера), - были как раз наполовину интерпретаторами. В отличие от бейсика они интерпретировали не сам исходник, а промежуточный P-код. Использование P-кода якобы давало независимость программ от платформы. Когда наконец выяснилось, что программы из под компиляторов транслирующих прямо в маш.код работают намного быстрее, а идея совместимости это вообще глупость (т.к железо у всех машин того времени было разное), то компиляторы транслирующие в промежуточный код для 8-ми разрядок быстро исчезли. И лишь когда в середине 90-тых годов компьютерное железо стало единым во всём мире (т.к PC-совместимое железо уничтожило все конкурирующие платформы) к идее p-кода вернулись и применили её в Python, JVA и VB.

Любители писали и даже сейчас пишут интерпретаторы Паскаля, но, к сожалению, лишь для PC (причём это даже не очень надо, т.к для PC есть компиляторы Паскаля с IDE, что в использовании ничем не отличаются от интерпретатора). Но никто не делает интерпретаторы Паскаля для компьютеров на КР580. А как раз для Паскаля под КР580 пока нет среды IDE потому такой интерпретатор Паскаля имеет смысл.

Уже многие понимают, что Паскаль это самый полезный сейчас инструмент для ретро программиста любителя. Давно пора прекратить мышиную возню с сильно трудозатратным ассемблером и начать использовать для программирования нормальные инструменты. За то же время, что некоторые люди непродуктивно растрачивают на программирование на ассемблере, на Паскале они могли бы написать для РК86 несколько уровней "DOOM"-а или закончить писать "Принца Персии".

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

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

Пока даже в реальном РК86 можно поиметь рамки только так, как это делали в старину авторы статей о дополнительных фонтах в журнале "Радио" в конце 80-тых годов, - путём установки большого тумблера переключающего адрес А10 на ПЗУ РФ2 знакогенератора. Т.о, хотя они могли бы без всяких затрат существенно увеличить возможности РК, атрибуты ВГ75 полностью и глупо впустую пропали. За 35 лет никто их так и не использовал (наличие пары цветных игр это исключение, да и то они из 2010-х годов).

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

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

Частично эту проблему программно решил vinxru за счёт использования встроенных команд (стоп-ПДП и конец строки) и сокращения числа строк с 39 до 37 (увеличив этим частоту кадров). Кстати, метод vinxru нарушает совместимость для игр, - экранные позиции изменяются. Т.е записав символ в ячейку 77C2, на экране он не только не окажется в верхнем левом углу экрана, но главное, он не попадёт на начало другой строки. Это имеет следствием, что используя такой режим для системных программ и монитора, перед запуском старой игры надо включать оригинальный видео-режим 64*25. В то время как при обсуждаемом ниже режиме, игра на 25 строк видна и в режиме 28-ми строк (хотя и сдвинуто вниз по вертикали).

Но, если быть поскромнее в желании иметь полноценные рамки, то даже не прибегая к радикальным методам от vinxru, можно подумать о увеличении числа строк и сокрашении разрывов в линиях до одной точки (что гораздо менее заметно и потому менее неприятно для глаз).

Имею в виду сокращение высоты знакоместа с 10 до 9. Тогда в экран влезут, в смысле станут видимыми 28 строк. На самом деле даже 29 строк. Но нам хватит 28 строк (т.к под 29 видимых строк может не хватить места в доступном ОЗУ 7633...7FFF). Но 29 видимых строк точно можно иметь, если часть вертикального бордюра формировать аппаратно (см.ниже) удлинением КСИ до 2-х (или даже 3-х) периодов вывода текстовых строк. Что нарушает нормы на регенерацию ОЗУ, но может сработать.

Уточняю терминологию для тех, кто не очень в курсе: строчный период - это 64 мкс - период вывода линии растра, а период вывода текстовой строки - это 10*64 мкс, т.к в строке 10 (или 9 или 8 ) линий.


Итак, у нас есть под экран ОЗУ 7633...7FFF. Буфер команд монитора и стек монитора, естественно, нет причин размещать выше 7600, на чём для нужд экрана освобождается 156 ячеек. Что удивительно удачно совпало, т.к две строки РК как раз занимают 78*2= 156 ячеек. Т.о даже не меняя строковый шаг в этом ОЗУ умещается 32 строки. А изменив строковый шаг с 78 на 76, - влезает ровно 33 строки.

Сохранив строчный период в стандартные 64 мкс, строковый шаг легко изменить, если программно задать время гашения по строкам (в РК это формирует ССИ) не в 6 знакомест, а в 8 знакомест. Если от этого синхронизация страдает, то число байтов на одну строку придётся выигрывать за счёт гашения по кадрам, увеличив КСИ до 2-х строк, что в свою очередь может сгубить регенерацию.

В принципе, можно наплевать на точное соблюдение строчного периода и задать шаг по строкам 76 (вместо 78) не выравнивая строчный период соответственным (на 2) увеличением длительности гашения по строкам. Тогда частота строк будет не 15.625 КГЦ, а выше на 1.5 процента. Наверное телевизоры имеют достаточную для этого полосу синхронизации.

33 строки это сумма числа видимых строк и числа строк затрачиваемых на программный вертикальный бордюр. В режиме с высотой знакомест в 10 линий на программный бордюр тратится 5 строк (три сверху и две снизу). Соотвественно при высоте знакоместа в 9 линий тратя те же 5 строк на вертикальный бордюр и уменьшив строковый шаг с 78 на 76, мы имеем видимыми 33-5= 29 строк. Или не меняя строковый шаг, - имеем 32-5= 28 видимых строк. 28 строк дают 28*9= 252 видимых линии растра, что прекрасно отображал даже древний советский телевизор.

Чтобы при высоте знакоместа в 9 линий соблюсти ТВ-стандарт, период кадра должен длиться время за которое выводятся 312 линий растра. Т.о полное число строк д.быть 312:9= ~34. ВГ75 в схеме РК добавляет ещё одну строку на обратный ход луча, что в схеме РК формирует КСИ. Таким образом при 33 строках в ОЗУ и одной строке на обр.ход по кадрам как раз и получаются требуемые 34 строки.

Если же место в ОЗУ под 33 строки не удастся получить, т.е не удастся сократить строчный шаг до 76 и придётся применять стандартные строки длиной по 78 байтов, отчего их в ОЗУ уместится всего 32, то всего будет полные 32+1= 33 строки, а не требуемые 34, отчего частота кадров повысится. Возникает вопрос, не нарушит ли это синхронизацию?

Как раз опыты с РК-режимами в 50 отображаемых строк (когда частота кадров задирается аж до 61 ГЦ) чётко показали, что современные телевизоры нормально синхронизируются при повышенной частоте кадров превышающей стандартные 50 ГЦ. Если телевизор держит 61 ГЦ, то в обсуждаемом режиме (т.е при 33-х строках высотой в 9 линий) синхронизация по кадрам точно не сорвётся. Тогда кадровый период: 33*9*64= 19 МСЕК, что соответствует частоте кадров 52.6 ГЦ. Это современный телевизор "переварит".

Но возможно можно, не потеряв регенерацию, увеличить КСИ до 2-х строк и получить 33+2= 35 полных строк и 29 видимых строк (при общем числе строк в 35 частота кадров понизится до 48 ГЦ). А главное, при КСИ в две текстовые строки даже всего при 32-х строках хранимых в ОЗУ в сумме получаются нужные 34 строки и, т.о для выигрыша в ОЗУ места для ещё одной строки, уже не требуется сокращать строчный шаг до 76.

Те опыты, что автор этой темы как раз сейчас проводит на форуме ZX-PK.ru и добился, что на РК есть видимая картинка при увеличении числа строк отданных на эркашный КСИ, - дают надежду. В режиме 25-ти видимых строк на КСИ выделяется одна строка, причём и её даже много, т.к тогда КСИ длится 64*10= 640 мкс, что в разы больше ТВ-стандарта на длительность КСИ.

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

Т.о при двух (или даже 3-х строках) отдаваемых на кадровое гашение остаётся решить проблему как сократить длительность КСИ, которая при отведении на обр.ход луча по кадрам вместо одной строки двух (или даже трёх) увеличится до 2*9= 18 (или даже 3*9= 27) длительностей строчного периода, т.е до 64*18= 1152 мкс (или 64*27= 1728 мкс), хотя в базовом режиме при одной строке отдаваемой на КСИ его длительность - лишь 640 мкс.

Как хорошо известно всем изучавшим в ПТУ теорию линейных цепей, для сокращения длины импульса достаточно применить CR цепочку с диодом. Естественно, подобрав постоянную времени цепочки так, чтобы из переднего фронта сигнала формировался короткий импульс точно соответствующий стандарту телевидения на длину КСИ (не помню сейчас точно, но это чуть более 100 мкс). Диод срезает просечку при заднем фронте долгого КСИ.

А более красиво приведение КСИ к стандарту можно сделать имея одну дополнительную и не очень дорогую микросхему 155ТМ2 (это кстати, как недавно выяснилось, и без того надо делать для некоторых плоских телевизоров).

Это лишь теоретические рассуждения, без проверки в реале. Но они основаны на реальных цифрах и возможностях ВГ75 и обычно подобные расчёты оправдываются. Потому у меня нет сомнений, что можно поиметь для системного режима монитора экран, по крайней мере, в 28 строк, с нормальной синхронизацией и полным сохранением рабочих ячеек ПЗУ и, соответственно, сохранением работоспособности стандартных подпрограмм РК86 и совместимости с системным ПО.

Единственным возможным препятствием ранее считалось, что отведение двух и тем более трёх строк под КСИ погубит регенерацию ОЗУ, отчего аппаратно совместимый режим в 28 строк с полным сохранением ТВ-норм реализУем только на статике или при замене 565РУ3 на 565РУ7 (а без этого вызовет заметное отклонение от ТВ стандарта, ухудшение синхронизации или по строкам или по кадрам, - как показано выше, места для одной строки в ОЗУ не хватает и выиграть его можно только изменив ССИ или КСИ). У РУ7 вдвое больший максимально допустимый период регенерации в 4 мс. А SIMM-30 пойдут ещё лучше, - у них макс.период регенерации аж 8 мс.

Потому в ходе опытов с настройкой режимов ВГ75, которые автор темы сейчас проводит на ZX-PK.ru, хотелось бы выяснить нарушается ли регенерация при 2-х...4-х строках отводимых на КСИ. И нарушается ли синхронизация, если увеличить число знакомест отдаваемых на ССИ с 6 до 8 при сокращении строчного шага с 78 до 76, а также и при стандартном базовом ССИ в 6 знакомест, но при шаге в 76 байтов. Увы, сам я сейчас это не могу сделать, т.к программы для РК86 я прогоняю на скоростном ОРИОНЕ с программным эмулятором (а те, что не идут или им не хватает скорости - с визуализатором).

А при статическом ОЗУ можно получить совместимый режим даже со строками высотой в 8 линий с рамками без разрывов

В этом случае также нужна доработка по укорочению КСИ. При этом 33 строки хранятся в ОЗУ, из них 30 видимых, 3 строки из ОЗУ под нижний бордюр и 4 строки не требующих ОЗУ задаются на гашение по кадрам, - из них по переднему фронту этого сигнала гашения аппаратно (с помощью 155ТМ2 или CR-цепочкой) формируется правильный по длительности КСИ, а за оставшиеся 3...3.5 длительностей вывода строки (8 линий строки выводятся за 8*64 мкс) формируется верхний бордюр. Полное число строк 33+4= 37. Частота кадров при полных 37 строках получается 52.8 ГЦ, что современный телевизор переварит.

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

Этoт «USR» не даёт возможности передавать параметры непосредственно в регистрах, что требует ПОКить уйму непонятного кода.
По-моему, там должны иметься механизмы проверки типа аргумента (иначе, как бы PRINT/INPUT работали бы?). Хотя, лет 25 тому назад в «Бейсик-Микрон» я как-то вносил изменения в оператор «LINE» с выводом текста, вместо графики (для игры «Поле Чудес»), но не помню где и как…
Помню лишь восторг, когда синусом/косинусом удалось через LINE вывести строки текста под разными углами, а не гадким и противным черепашьим циклом в листинге…
Тем самым, для «межбанковских транзакций» POKE/PEEK могли бы жрать «пин-код» банковской ячейки вещественным числом. И просадки по скорости будут оправданы, и штатная скорость сохранится при стандартном обращении к памяти.
Для этого можно использовать:

• Любой из остальных каналов ПДП
• Префикс «ld a,a»
• HLT - она где-нибудь используется в РК? В ZX она ждёт конца кадра
• Особую зону, где однобайтовые операции могут читать/писать данные других банков (например, ячейки 7800…7FFF), но нормальный код там никогда не отрабатывается (в самом начале темы я писал: При «CALL 08000H» отваливается D20; От «CALL 0A000H» отваливается D14; От «CALL 0C000H» отваливается ВГ75)¹

Я за вариант в 64 Кб и тема тем и начиналась…Что потребует введения новых токенов, которые будут использоваться крайне редко!
Уж лучше тогда к PEEK/POKE добавить дополнительные опциональные аргументы…
Бейсик нужен тем, кто уже освоил Паскаль и Си, чтобы на незнакомой архитектуре быстренько хоть что-то сделать (например, тут или тут).
Сам я, после «MS Visual Basic» годами переходил на «Visual C» и Win-API, с осознанием, что VB изуродовал всё понимание Windows в принципе!
Мне бы МОНИТОР свой закончить!
Застрял на подпрограммах клавиатуры и магнитофона.
Хотелось бы ввести поддержку разных раскладок. Подгружаемых…
Застрял концептуально, так как с ПДП не разобрался (выше писал: нужно совмещать отключение ПДП в подпрограммах магнитофона и восстанавливать в опросе клавиатуры и ещё унифицировать саму подпрограмму F82D).
Есть идея использовать регистры неиспользуемых каналов ПДП как служебные рабочие ячейки Монитора для хранения данных (начало экрана, формат экрана, раскладка клавиатуры и т.п…) без запуска самих циклов ПДП. Но ПДП для чтения никак не доступен без доработки схемы РК.

Сейчас доработал Монитор так, чтобы холодный старт происходил прямо в директиве отладки с сохранением всех регистров (навеяло отсюда)…
Тем самым, это ещё один весомый аргумент от меня в пользу того, что встроенные отладочные средства в Мониторе нужны!
Все директивы восстановил - «L»/«M»/«D» ссылаются на один и тот же код. Это устраняет путаницу и необходимость к дополнительному пояснению. Пользователь ими научится пользоваться стандартной документацией РК.
Директива «X» без аргументов работает как та же самая. А с аргументами - прыгает на адрес 7650.
Директива «U» и все остальные - выбрасывает в E000 и эмулятор переходит в DOS…
Очистка экрана заносит код F3 в адрес 7FF3 - навеяло отсюда, как Вы уже заметили.
Однако, в моём «оконном варианте» это сделать было крайне сложно и пришлось тупо вызывать код директивы «F76D0,7FF3,00» из недр COUT. Тем самым, экран гарантировано должен теперь стоять на месте.
Для Больших ЭВМ (что на столах/в карманах каждого) Паскаль (Дельфи) - зло несусветное!
Для микро-ЭВМ же Паскаль - необходим, как никогда. Это я только недавно стал понимать!
Это вопрос эстетики и пиксель-арта, на что, в частности, в игровой индустрии выделяется штат художников.
Я никаким боком не художник.
Хотя, давно нарисовал ПЗУ знакогенератора, где коды 08/0A/0C/0D/18/19/1A/1F и реализуют псевдографику в три бита: Вместо блоков 2×2 блок 3×1. И в режиме 78×64 можно рисовать 234×64.
Для меня главное - код. А для рамок коды 1B/1C вполне годятся, если устранить разрывы строк…
Но ВГ75 сама имеет резерв кодов C0…EF под некие рамки и схемы с логикой/ПЗУ под это дело, кажется Вы, выкладывали где-то…
Согласен. Нету механизмов более тонкой и глубокой настройки:

• Переназначения каналов ПДП
• Периферии на D14
• Симуляции краха динамического ОЗУ

Была скандальная статья в журнале РАДИО с ПДУ телевизора на ниточках.
Тумблер - для умельцев с поверхностными знаниями теории программирования. Для гуру - атрибуты ВГ75 с режимом «непрозрачных атрибутов» вполне годится: И ПДП-цикл не сорвётся, и пробел на месте атрибута умело использовать можно…Я курсы маркетолога не посещал!
Я занят кодом, а не сверкающими фантиками… Куча подводных камней и нерешённых проблем.
Поэтому сейчас я это не рассматриваю…
Проводил не я… И ничего не добились…
Для этого и годится мой осмеянный «ПСИХ» и его предшественник - «Psi-Detector», без которого не было бы ПСИХа как такового… Проводил вслепую и чужими руками…
Самому интересно.
Потому нужна версия уже с предустановленными пресетами по «Ф1»…«Ф5», чтобы не парить пользователя.
А на это требуется стимул. А так как в той теме всё затихло, то и доработку утилиты я заморозил.
(Руки не доходят до своего КР-03, так как мало его достать из шкафа. Нужно переходники ещё спаять для загрузки файлов, к карте захвата видео и БП подготовить!)Вот видите!
Любопытство всё же заставляет смотреть в сторону классического РК, так как регенерация ОЗУ - процесс ближе всего к физическому. А управляемым он может быть только в РК!

Есть предложение: Подготовьте мне разные настройки ВГ75/ВТ57 под мою утилиту и под экран в нижней половине (чтобы не затирать рабочие ячейки Монитора) - 3000…3FFF…
Экран залью шашечками…
(Настройки - вариантов 4, включая критические для осыпания регенерации ОЗУ.)
Я их вобью в код и попрошу проверить…
(Ниже - Adjust75 с предустановками по Ф1…Ф5 и скрытый тест по «Tab» (глючит местами, экран дрожит и не пойму почему…)
Самому лень сейчас математикой заниматься (по-моему, на ногах переболел Коронычем ещё в январе…)

P.S.: Прикрепил очередной вариант Монитора с мелкими доработками.
(F3 по 7FF3, холодный старт в «X-зоне», пользовательская директива через «X<аргумент1>…<аргумент4>» (работает после подгрузки «Dir_Jay»), алиасы «D»/«L»/«M»…)
(«Adjust75» потребовал концентрации и свои Монитор/Калькуляцию я сбился делать…)

Это вряд-ли. В январе эта зараза ещё не вышла за пределы Уханя. Это был грипп или простуда. Если бы это было не так, Вы бы заметили, что люди из вашего окружения вдруг начали попадать в больницу и даже умирать.
Чего тут непонятного? Если надо передавать данное в ассемблерную подпрограмму, то с помощью POKE кладём данное в ячейку из которой ассемблерная процедура его возъмёт. А возврат одного данного из ассемблерной подпрограммы USR поддерживает, т.к это функция. И почему уйма? Сколько передаваемых параметров, столько и POKE. А если поднимается вопрос скорости, то даже упоминать бейсик неуместно. В Паскале, Си и PL/M при вызове внешних процедур/функций параметры передаются в оговоренных для данного компилятора регистрах и стеке.

В бейсике-интерпретаторе другая проблема, - как разместить ассемблерный код в ОЗУ. Это делают с помощью операторов DATA, READ и программной перегрузки кода под вершину ОЗУ или в какую-либо длинную строчную переменную. После чего подпрограмма в маш.кодах вызывается оператором USR. Делая свой бейсик несложно ввести оператор CODE, который похож на DATA, только числа задаются в HEX-виде (отпадает префикс &H) и оператор CODE сам загружает код из бейсиковой строки на текущий адрес размещения, исходно заданный ранее оператором ORG.
После этого команды IN/OUT перестанут попадать в порты. Кстати, ПДП занимает не 4, а 9 адресов. Если открывать ОЗУ в дырках портов, то чтобы не переделывать РК-программы, на порты надо оставлять по целому килобайту. А ОЗУ дырками неудобно. Если надо большой сплошной кусок доп.ОЗУ, то лучше всего выкинуть запасной ППА и отдать под доп.ОЗУ участок 8400...BFFF размером в 15 кб.
Это же аппаратно намного сложнее и неудобнее в использовании, чем просто ввести вторую страницу с ОЗУ в адресах 0...EFFF. Порты остаются в 0-вой странице и не мешают.
Это маниловщина, к тому же ненужное усложнение архитектуры.
А зачем сейчас хоть кому-то из пользователей РК86 нужны 64 кб? Никто из фанатов РК не одобрил идею сделать новодел РК с бОльшим ОЗУ? И Вы не объяснили для каких целей Вам в РК86 необходимо иметь 64 кб.

Разве есть или вскоре ожидается поступление множества программ с объёмом более, чем 29 кб ? Большое сплошное ОЗУ было надо до середины 90-тых годов, когда программы писались на самих 8-ми разрядках. Т.к тогда, чем больше в бездисководной ЭВМ ОЗУ, тем бОльший исходник можно в него загрузить и странслировать (хотя это не закон, а является отражением несовершенства имеющегося тогда инструментария). ОЗУ размером под 60 кб позволяло использовать CP/M, где имелись нужные инструменты для программиста, а также давало DOS в качестве средства хранения файлов.

А сейчас Вам наличие 128 кб ОЗУ что даст? Тем более такой изощрённой архитектурой. Пока даже на неэффективных ЯВУ для РК ещё не странслировали ни одной программы объём кода которой при трансляциии неожиданно превысил бы 29 кб. И совершенно непоследовательно отвергать простейшие и всем доступные доработки и тут же предлагать делать сложные и громоздкие.

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

Например, текстов редактор без блоков написанный на ассемблере с размером в 2 кб (т.е уровня Микрон-1) переписанный на Си или Паскаль занимает уже 8 кб. РК-нортон с минимальными окнами в 8 кб, написанный на ассемблере, переписанный на ЯВУ разбухнет до 29 кб (что вообще не оставляет места ни под буфер копирования, ни под буфер сохранения окон). А например, CP/M нортон MIVFI для ОРИОНА имеет размер в 17 кб. Если его переписать на ЯВУ, то он займёт 64 кб.

Паскаль позволяет грузить оверлеи, как в окно A000...BFFF, так и в основное ОЗУ 0...7FFF с автоматическим переключением банок. Так, что, дополнив РК (в любом виде) дополнительным странично-коммутируемым ОЗУ, полностью снимается ограничение на объём кода. И тогда ничто (кроме отсутствия графики) не помешает написать на ЯВУ (естественно, с фрагментами ассемблера, там где важна скорость) большое количество игр с высоким игровым аспектом.
Застряли Вы потому, что пытаетесь программируя в машинных кодах (что уместно в XIX веке, но явное безумие в XXI веке), уместить что-то в те же 2 кб ПЗУ. Хотя никто не мешает припаяв пару проводков и заменив 24-х ногую панельку на 28-ми ногую (или впаять рядом в имеющиеся отверстия) и установив в неё микросхему 2764, поиметь ПЗУ размером в 8 кб.

Тогда можно запрограммировать драйвер клавиатуры программируя, как теперь принято, в стиле "Quick and Dirty" абсолютно не заморачиваясь экономией байтов (за счёт такого размещения символов в матрице, что укорачивает драйвер). Не имея ограничений на объём кода, таблицу кодов клавиш можно при инициализации копировать из ПЗУ в ОЗУ, что и позволяет программно менять "раскладку клавиш".

А что касается подпрограмм для магнитофона, - зачем их вообще трогать? Они работают нормально (хотя и непонятно зачем перепрограммируют ВГ75 после ввода/вывода каждого байта). Или Вы улучшаете их, чтобы экран не гас при работе с МГ-лентой? Если это так уж надо, то Вам достаточно просто перейти на Специалист, там экран вообще никогда не гаснет.
Отладочные средства в ROM-BIOS означают просто трату впустую ~100 байтов. Приличный отладчик занимает объём ~10 кб. И отладчик д.быть привязан к среде, т.е к DOS. Потому отладчики включают в состав DOS, а не делают частью ROM-BIOS.
Это самая здравая мысль во всей этой теме, во всём разделе этого форума, во всех других разделах этого форума, где речь о программировании 8-ми разрядок и во всех остальных форумах, где речь о том же.
Ну так и забудьте как о кошмарном сне о программировании в машинных кодах КР580 и займитесь Паскалем МТ+. А, если с помощью платки-переходника замените КР580 на Z80, то и Турбо-Паскалем, который хоть и менее серъёзный инструмент, но зато позволяет писать программы быстрее (я в 90-тые годы написал на TP текстов редактор с блоками менее, чем за три дня).

К тому же Паскаль МТ+ (в отличие от Турбо-Паскаля) ничуть не отменяет ассемблер, - он позволяет иметь модули не только на ассемблере, но и на других ЯВУ. А мелкие процедуры на ассемблере удобно встраиваются прямо в код Паскаля используя INLINE вставки (хотя для этого используется менее удобная мнемоника КР580).

На ЯВУ можно делать сложную часть алгоритма, а скоростную часть выполнять на ассемблере. В РК-играх (за небольшим исключением, типа шахмат, что написаны на PL/I) обычно объём собственно кода не превышает 5-6 кб (остальное уровни). Потому большинство РК-игр можно переписать на ЯВУ и они уместятся в имеющиеся 29 кб.
Всем известно, что РК отображает 64*25, 64*30 или 64*51 знакомест. Без аппаратных переделок, формат экрана 78*64 никак не увидеть ни на одном телевизоре или мониторе. И если эмулятор это отображает, то это плохой эмулятор, не соответствующий реалу. Если матрица знакоместа 3х1, то экранный формат в пикселях - 192*25. А если включить режим изобретённый vinxru с 51-й видимой строкой, то будет формат 192*51.

Зачем реализовывать матрицу пикселей, - просто применяйте символы для рамок толщиной в одну точку. И непонятно, чем для псевдографики и рамок лучше матрица знакоместа 3х1? Ведь тогда, хотя вертикальные линии рамок будут толщиной в 2 точки, горизонтальные линии будут толщиной аж в 8 линий, т.е рамки станут ещё более противными.
Получить рамки допрошив второй фонт в имеющееся полупустое ПЗУ, - это реально. Делать апп.доработки, тем более ради того, что достигается без хлопот и корёжения платы РК - никто не будет. Это ни в одном из клонов РК не использовали, т.к тогда курсор должен быть реализован программно, а он уже во всех РК-программах аппаратный.
Зачем нужен код для поддержки окон без решения проблемы нормального дизайна окон? Когда Вы видите красоту, у Вас резко возрастает энтузиазм, а когда Вы видите уродство, то наоборот.
Эта ссылка работает не для всех.
Я сейчас пытаюсь изучить/вспомнить/освоить Паскаль (ассемблер стараюсь забыть) и мне не хочется заниматься ассемблером, хотя изменить ПЗУ под режим 27/28 строк - просто. Кроме смены параметров установки режима, требуется изменение адреса начала экрана при HOME и адресов и размеров экрана в п/п-ме ролика. Было бы полезно, если бы крутые эмуляторы чётко привязанные к реальным времянкам выдавали индикацию какая текущая частота кадров и строк.

Проще всего попробовать режим в 27 строк задав полные 32+1 строки (с частотой кадров ~53 ГЦ) и экраном на 36D0H-78*2, т.к при этом начала строк остаются там же и вывод символов будет корректно работать без изменений кода драйвера вывода символов. Здесь длина КСИ не меняется, а в коде меняется только два параметра в подпрограмме задающей режим ВГ75. Попробуйте сначала с экраном на 36D0H-78*2 (тогда, естественно вывод символов п/п-ми F809, F818 не сработает), а затем попробуйте задать адрес экрана 76D0H-78*2 и сделайте вывод текста на экран обычными подпрограммами ПЗУ.


- - - Добавлено - - -

Вдруг вспомнил... Есть одна программа от Микроши, что использует режим с высотой знакомест в 9 линий. Но она не поможет в данной задаче, т.к хотя там число строк хранимых в ОЗУ 33, но строчный шаг - 78 (а не 76), а как уже сказано выше, 33 строки длиной в 78 байтов не умещаются в стандартной экранной области 7633...7FFF. Для интереса попробуйте такой режим, ниже его процедура инициализации. Обратите внимание, что в ВТ57 тут записываются другие байты (не знаю почему и что это меняет, - в программировании ВТ57 никогда не пытался разбираться, т.к там всё очень сложно).


Да, кстати. У Вас не вышло заставить для РК86 успешно работать конвертор CGA --> VGA потому, что Вы исходили из неверных идей. Число строк (точнее линий) в кадре не играет роли. Тем более, что никогда 312 строк не присутствуют в сигнале. В видео сигнале ОРИОНА, Специалиста и клонов ZX-Spectrum есть в наличии только 192...260 строк снабжённых ССИ. А далее идёт пауза, уровень чёрного, гашение по кадрам, в середине которого выдаётся КСИ. А в сигнале от РК86 строчные синхроимпульсы ССИ идут и во время гашения по кадрам. Возможно это сбивает конвертор. Ещё конвертор возможно сбивает слишком длинный КСИ и он формирует из одного слишком длинного КСИ на выходе несколько стандартных КСИ.

Вообще телевизор и монитор определяя формат сигнала могут опираться только на период следования ССИ и КСИ и их параметры. Колебания периодов следования ССИ и КСИ в диапазоне +/- 10% не играют роли (лишь центровка растра слегка сбивается). Роль играют длительности КСИ и ССИ и их полярности. По ним телевизор и монитор и определяет формат сигнала.

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

инетерстно почему не разместили cp/m в ПЗУ и не сделали эмулятор диска на магнитофоне

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

Этo непонятно не мне, а пользователю Бейсика…
Выше я экспериментировал с Motorola-синтаксисом 6502.
Думаю, чем «POKE X,&46», запись «BM» будет намного прозрачнее.
Можно даже унифицировать саму функцию USR:
Вот потому и концептуально я застрял и ушёл в эмулятор бинарить Монитор!
Если ИД7 подключить не напрямую к шине адреса, а к выходу РТ-ки, прошитой соответствующим образом (как сделано во многих Микро-ЭВМ побольше - Ириша, Поиск и т.д.), то этого будет более, чем достаточно!
Меня изумляет факт, что в МРБ публиковали «Музыкальные Шкатулки» на РЕ3 для сборки и прошивки пионерами, а в Компьютере уж слишком упростили архитектуру, сэкономив на РТ в качестве дешифратора!
(Даже та же 155РЕ3 имеет вход на 5 бит, а это - A15-A11, что уже квантует шаг дешифрации до 2 Кб, вместо 8 Кб!)
Что и искушает меня, практически пустяковыми доработками, добиться большего…
541РТ1 - 256×4. Для входа ИД4 - идеально подходит. И шаг блоков - по 256 байтов…
Вы выше писали про замкнутый круг разработчиков эмуляторов без фишек и отсутствия программ под эти фишки…
Кажется, это - из той же оперы!
Зачем писать драйвер клавиатуры на Си‽
А застрял я из-за расчётов тактов… Да и после опытов с ВГ75/ПДП на zx-pk.ru стал подумывать не гасить экран, а ввести счётчик, так как ПДП-цикл из 32 байтов раз в кадр, думаю, магнитофонная операция переживёт…
И это будет ВТОРОЙ АРГУМЕНТ в рекламацию моего Монитора.
На которой у меня и написан весь мой код!
Как-то пытался писать эмуляцию ВГ75 с плавающими строками, чтобы, как в моём бытовом телевизоре, синхронизация сбивалась и сворачивалась.
Но писал inline MS-VC «asm{…}» и сильно запутался (x86-регистров не хватило), забросил…
На JavaScript в HTML5 попробовать можно, но очень лень…
Теорию телевизионных стандартов знаю плохо с балансом чёрного, белого и т.д…
А так, можно кидать картинку из ВГ75-эмуляции не на экран сразу, а в буфер целых чисел, который затем разбирать как надо…
(Были же т.н. дешёвые софт-модемы, которые программно заменяли реальный модем. Телевизионный сигнал - тоже можно программно разбирать и без карты захвата. А если вместо захвата - тупо буфер ВГ75, то в разы проще! Но… Лень… Данных мало…
Вообще, я любил разъём с RGBV из ZX-Spectrum выдёргивать и втыкать в магнитофон, чтобы на аудио кассету попытаться записать кадры местного канала. Получалось, но только экраны с титрами…
Это хоть кривой и тупой опыт, но - опыт! Я и на Windows через звуковую карту выход телевизора писал и программно пытался превратить хоть в какой-нибудь кадр. Но 15 лет наз памяти мало было и 1 секунда много диска съедала WAV-файлом…)
Пусть хоть 1 кадр в минуту рисовать придётся, но уже будет явно видно, что произошло бы в реале аппаратно!
Я об этом тоже думал: Все атрибуты, включая реверс и подчёркивание, подать на ПЗУ знакогенератора. А прошивку синтезировать как-нибудь так, чтобы всё было.
Да и другой канал ПДП задействовать для подгрузки знакогенератора на КСИ, чтобы программно не париться…
Наверно, как раз из-за отсутствия чувства красоты я и сижу в машинном коду под чудной архитектурой РК!
(Так как архитектура PC вообще скандально кривая! Чего стоит один только код «00» x86 под операцией «ADD»: При сбитом указателе, процессор в пустом нулевом пространстве будет до одури складывать, из-за чего MS ввели в Windows целые мегабайты запрещённой области. Будь «00» = «HLT», исключение случилось бы сразу!
Просто i8080 - менее кривой и в нём меньше ошибок. Свой «x80» я подправил и «00» - это «HLT»…)
Напротив! Если качество принимаемого сигнала низкое и один канал накладывается на другой (в случае с кабельным ТВ 90-х на шесть каналов из 12 у ПТК, где каналы 3-5-9-11 - государственные, а 1-4-6-8-10 - кабельное), то вполне можно было изучить структуру кадра.
И та самая ЛП5 у РК - правильно смешивает сигналы…Нe уж то я так сурово представляюсь‽

Чтобы достичь идеальной синхронизации, следует добиться частоты 15625.
Для этого необходимо в строке обеспечить 512 графических точек.
Так, 78×6=468, остаётся 44. Однако, 44 на 6 не делится, но делится на 2. То есть, «ZZZZ» нужно настроить на 22 символа:
А частоту ВГ75 - утроить (в период HRTC):
(Можно и на период VRTC менять частоту раз в 6, чтобы высоту знакоместа сократить…)

P.S.: Возможно, в схеме неточность: ИЕ4 - мой самый нелюбимый счётчик, так как тяжело с ним разобраться и трёхфазную схему разок лепил на нём…
Но, суть, надеюсь, я донёс…
(Да и максимальную частоту i8275 следует учесть…)