nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 13 Nov 2019 11:06



Reply to topic  [ 5 posts ] 
Что бы сделать из платы РК86 ? 
Author Message
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 307
Location: С-Петербург
Reply with quote
Тема более широкая (т.к тему "Варианты доработок РК" закрыли), - о всех конструкторских решениях пригодных для платы РК86. Для начала хочу поделиться одной победительной идеей переделки РК в графическую ЭВМ. Сама идея не нова. Но заключительную часть головоломки я придумал лишь недавно и, кстати, уже позавчера начал пытаться её воплотить в реале (начал восстановление базовой платы РК, на КР580).

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

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

Пару месяцев назад у меня образовалась плата журнального РК86 с хорошим качеством печати. И желание как-то эту плату использовать. С тех пор я думал как схему РК наиболее интересно доработать не заморачиваясь ограничениями совместимости. Задача - не сделать апгрейд, т.е улучшить базовый РК, сохранив совместимость, или получить возможность прогонять на нём программы CP/M. Цель - сделать из платы РК другой компьютер. Совместимость не волнует, т.к 99% программ для РК86 я видел, и они меня и тогда не впечатлили (т.к в 1987 году я уже имел самодельный Синклер). При желании насладиться РК-играми можно и в эмуляторе.

Кстати, и в CP/M на РК теперь нет особого смысла, т.к уже незачем компилировать или писать тексты на самой ретро ЭВМ, это теперь удобнее делать на PC или даже на планшете с Андроидом ценой в 3 килорубля. А другие (кроме компиляторов) программы из CP/M (деловые приложения и CP/M-игры) бесполезны.

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

Речь об единственной плате и задача сделать минимальной ценой из платы РК другой вариант компьютера на ВГ75 для которого будет интересно программировать. Для самого РК без введения в него новых видео-режимов программировать неинтересно, т.к без альтернативных фонтов, инверсии и цвета, ничего визуально более качественного, чем имеющееся ПО не написать. Потому с 1991 года практически никто не пишет ПО для РК, а пассионария на внедрение доработок не нашлось (вариант РК-МАКСИ не в счёт, это было изначально обречено, а поставленная задача добиться совместимости с другими клонами невыполнима, т.к кроме адресов портов у клонов много других отличий). Другая возможная цель - это чисто спортивная, реализация аппаратного конструкторского хобби, доказать, что можно было сделать из тех же деталей вариант более подходящий быть любительским компьютером 1986 года.

Если задача не просто показать возможность поиметь лучшее видео, а получить платформу для программирования, то первое, что желательно, это турбирование. Чтобы ПО скомпилированное на ЯВУ не сильно тормозило. Для текстовой машины и программ написаных на ассемблере скоростей РК хватает. Но т.к программы из под Турбо-Паскаля работают тормознее в многие разы, нужно аппаратное ускорение хотя бы до 4 МГЦ реального такта.

Затем нужен процессор Z80. В принципе не хуже MC6809 или 65C816, но для них трудно найти инструментарий, а для Z80 всё есть, как в CP/M, так и в виде кросс-средств. Цепляться за КР580 могут только те, кто собирает ретро компьютеры сдуру, неизвестно зачем. А для использования ретро компа как платформы для любительского программирования лучше иметь более удобный для программиста процессор, дающий к тому же значительно лучший и больший инструментарий.

Исходя из того, что было нужно в 1986 году в качестве бытового компьютера, разумно использовать ВГ75 не для текста, а для имитации графики, т.е синтезирование графики символами за счёт разложения знакоместа на матрицу три на два пикселя. Такой фонт занимает 64 символа.

Многим известно, что в РК альтернативный фонт с 64-мя специальными графическими символами позволяет выводить графику 192*104 (64 символа 6*4 в строке, 52 видимых строки, знакоместо 3*2 пикселя). При некоторых ухищрениях можно выводить и на экран 200*104. В этом режиме частота строк не 50, а 60 Гц, что не было проблемой даже для советских телевизоров 80-тых годов, а для современных всеядных телевизоров это норма (в NTSC 60 Гц).

Режим с 52-мя строками аппаратно присутствует в Апогее, но практически почти не использовался. Лишьvinxru сделал демо.

Image

Не правда-ли, картинку скорее можно принять за скриншот Специалиста, чем РК86?

В этом демоvinxru использовал особый фонт, где не только графические символы с разложением знакоместа на матрицу 3*2, где каждый пиксель состоит из 2*2 физических точек, но и есть символы, где линии имеют толщину в 1 точку. Потому на картинке отдельные элементы соответствуют разрешению 384*208.

Забегая вперёд, укажу, что в предлагаемом режиме такого не будет, т.к используется особый фонт, в котором в каждом байте фонта прошит код символа. Это означает, что фонт вообще не нужен (достаточно код символа напрямую подавать на выходной сдвиговый регистр). В предлагаемом режиме просто физически нельзя вывести одну физическую точку, а только квадратик 2*2.

Увеличить разрешение по горизонтали можно увеличив число символов в строке. Базовая схема РК не позволяет изменить число символов в строке, т.к бордюр по горизонтали сделан программно. На это не было необходимости (кроме желания с'экономить 1 корпус), т.к длительность гашения по строкам регулируется программно. Лишь на программный бордюр по вертикали необходимость была (иначе перерыв в регенерации РУ3 превысил бы 2 МСЕК и некоторые микросхемы ОЗУ могли сбоить).

Если же формировать горизонтальный бордюр не программно, а аппаратно, средствами ВГ75, задав при задании режима соотвествующее число знакомест на обратный ход луча по строкам, то можно выводить 80 символов в строке, как сделано в Роботроне-1715. 80 символов в строке при разложение знакоместа на матрицу 3*2 позволяет получить псевдографический экран 240*104 с частотой кадров в 60 Гц.

240*104 это вполне приемлемый графический режим. Для сравнения, некоторые бытовые ЭВМ и игровые консоли из 70-тых имели типовое разрешение 160*100, этого для игр хватало. Текст на 40 символов в строке на 13-ти строках (знакоместо 6*8) это даже оптимально для компьютера с выводом на телевизор. При желании можно иметь 48 символов в строке с худшим фонтом 5*8.

Когда я делал эксперименты с подобным режимом в 90-тые годы, то делая вывод (на 42 строки, о возможности иметь 52 видимых строки просто не знал), вынужденно, т.к это задано железом, использовал неоптимальный графический фонт. Для текста это неважно, а вот при выводе графики это сильно усложняет. Для вывода точки приходилось специальной довольно сложной процедурой высчитывать код символа.

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

Я додумался, как работу с графикой сделать традиционной, т.е когда каждый бит экранного байта управляет одним пикселем, а не влияет на их целую группу. Для этого достаточно сделать весьма простую аппаратную коррекцию в видеовыходе и применить особый фонт. В таком фонте 6 битов кода символа кодируют две тройки пикселей стоящих одна над другой, причём так, что биты D2,D1,D0 управляют зажиганием точек верхней триады, а биты D5,D4,D3 - нижней. Тогда не требуется сложных расчётов, всегда известно какой бит какой точкой управляет.

Фонт высотой в 4 линии, отчего используются лишь выходы LC0 и LC1 из ВГ75. В схему добавляется мультиплексор, переключаемый сигналом LC1 из ВГ75. Тогда на адреса ПЗУ фонта в линиях 0 и 1 знакоместа подаются биты D2,D1,D0 кода символа, а в линиях 2 и 3 на ПЗУ подаются биты D5,D4,D3 (номера линий соответствуют весам LC1,LC0). Тогда верхним рядом пикселей управляют одни биты, а нижним - другие. Что и обеспечивает такое простое кодирование графики.

Отличие от традиционной графики в том, что тут в одном байте задаются два ряда пикселей, а не один ряд, как например в ИРИШЕ или ОРИОНЕ. ПЗУ фонта для графики может быть 3-х битовым, а если не нужен обычный текстовый режим, то ПЗУ с фонтом вообще можно снять, подав выходы КП11 прямо на ИР13.

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

Теоретически, если обеспечить коммутацию (т.е отключение КП11), то и обычный текст обычными РК-шными символами 6*8 можно выводить, т.к режим с фонтом высотой в 4 линии устанавливается программно, а в ПЗУ РФ2 как раз и влезают два фонта - фонт для графического режима и обычный текстовый фонт 6*8. Но коммутация усложнит схему, потому вряд-ли я так сделаю.

Т.к совместимость с РК недостижима и не волнует, разумно исправить и адресацию портов. После доработки получится обычный компьютер, например, с ОЗУ 59 кб (4 кб ПЗУ и 1 кб - под В/У), шириной экрана в 80 символов и имеющий дополнительный графический режим с разрешением 240*104 (при желании с цветом). Графический экран занимает 4000 байтов. 59-4= 55 кб остаются для программ в граф.режиме. Но это лишь прикидка, может быть лучше поиметь ОЗУ в 48 кб, а 16 кб отдать ПЗУ (оставив 256 адресов с $FF00 под В/У)

Возможно, что идея такой организации псевдографики применена и в каких-нибудь иностранных текстовых ЭВМ с псевдографикой из 70-тых годов (идея-то очень полезная и обходится всего в один дешёвый TTL-корпус). Но для отечественных ЭВМ это однозначно оригинальная идея. Никто из отечественных разработчиков и любителей РК86 о этой идее не знал, в т.числе и разработчики РК86 и Микро-80. С ними, кстати, в Москве 31 октября состоится встреча (надеюсь видео снимут).

Вот такой графический РК с экраном 240*104 или 192*104, аппаратно отличающийся от оригинала лишь формирователем ССИ (это один корпус сдвоенного одновибратора типа 155АГ3) и напайкой 555КП11 на выходы данных ВГ75. И естественно, для цвета остаётся ещё 5 битов на знакоместо 3*2 пикселя (это бит D6 в коде символа плюс ещё 4 атрибутных выхода ВГ75). А если удовлетвориться экраном в 192*104, то весь расход деталей составляет лишь одна 555КП11.

Собираюсь сделать такую переделку на плате РК. Но сначала хочу заменить в РК процессор и хотя бы тупо (т.е заменой кварца) турбировать его до 2.3...2.5 МГЦ. Чтобы поиметь бОльший такт (например, желательные 4 МГЦ) нужны буфера на ОЗУ или придётся менять РУ5 на статику. Чтобы сохранить эстетичный вид платы, собираюсь впаять Z80 в посадочное место КР580. Я уже так делал в Специалисте: Z80 впаивается и держится на 4-х (удлинённых) ножках, остальное МГТФ-ом под процессором (это одновременно самый простой способ и эстетичный, т.к нет нависающих доп.плат).

Для программирования придётся изменить свой эмулятор РК86 работающий на ОРИОНЕ для поддержки такой схемы - в нём отлажу соответствующий ROM-BIOS, а затем уже сделаю железо и буду отлаживать ROM-BIOS в реале. Без эмулятора писать программы 8-ми разрядки сейчас не принято, т.к на самой 8-ми разрядке это намного дольше, да и не всегда там есть DOS и инструментарий.

Кстати, безотносительно к теме, - схему РК86 на РУ5 можно удешевить, если воспользоваться идеей применённой в Acorn Electron. Там ОЗУ тоже всего 32К и главная задача была именно удешевление. 565РУ5 (4164) дают 64 кб, а требовалось всего 32. Потому там поставили всего 4 штуки 4164 вместо 8-ми и применили временнОе мультиплексирование. Т.е за один цикл доступа в память процессора, к реальному ОЗУ делается два доступа, при чтении сначала в защёлку читается одна тетрада, затем вторая и обе поступают на шину процессора. При записи аналогично. В 1982 году банка 4164 стоила треть цены компьютера, потому замена 4-х дорогих ИМС 4164 на несколько дешёвых TTL-корпусов позволила создать дешёвый клон BBC Micro доступный для малообеспеченных слоёв населения.

https://ru.qwertyu.wiki/wiki/Acorn_Electron (это кое-какой перевод английской вики)
https://www.theregister.co.uk/2013/08/2 ... ory_at_30/

Для Acorn Electron эта идея тормознула процессор и стала фатальной (т.к ОЗУ уже до того работало на пределе из-за общего доступа с видеоадаптером). В РК можно этого избежать сократив вдвое время доступа к ОЗУ, т.к 565РУ5 легко тянут удвоенный такт 1.77 МГЦ, т.е 3.5 МГЦ (на такой частоте работают РУ5-тые в клонах Синклера и не дохнут). Но можно оставить время доступа к ОЗУ тем же, что тормознёт прогон.


Last edited by barsik on 26 Oct 2019 13:04, edited 4 times in total.



23 Oct 2019 14:15
Profile
Novelist

Joined: 10 Mar 2018 13:50
Posts: 36
Reply with quote
Валяется старая собранная плата Р86рк с 32 кб. Даже не знаю рабочая или нет. Восстанавливать желания нет, но можно использовать как донора. Только кроме доработок придётся и монитор переписывать и знакогенератор и о программной совместимости можно забыть.
А насчёт полного использования 4 шт Ру5 на 32кб интересно. Как это будет выглядеть для Р86?


23 Oct 2019 15:13
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 307
Location: С-Петербург
Reply with quote
Post .
Shumadan wrote:
А насчёт полного использования 4 шт. РУ5 на 32 кб интересно. Как это будет выглядеть для Р86 ?
Это будет выглядеть печально, как пять TTL-корпусов напаянные на плате РК вторым этажом. Экономически сейчас это уже и ещё не имеет смысла. Уже потому что РУ5 (4164) с начала 80-тых годов здорово подешевели, а ещё - потому, что они ещё не стали такой дорогой археологической редкостью, что окупается электротрах по замене четырёх штук РУ5 на пять TTL-корпусов.

Само мультиплексирование делается несложно, на это в основном расходуется 555КП11 (коммутация двух тетрад с ШД на входы ОЗУ) и 555ИР23 (в качестве четырёхразрядной защёлки с Z-состоянием). С входами всё просто - у всех четырёх РУ5-тых отрежем входы от выходов и отрежем входы от печати, т.е от шины данных (но выходы ОЗУ должны по-прежнему соединяться с ШД). Четыре входа ОЗУ подключим к четырём выходам 555КП11. На две группы счетверённых входов КП11 подадим цепи D3...D0 и D7...D4 шины данных процессора.

С защёлкой с Z-состоянием тоже нет проблем. На входы ИР23 поступают сигналы с выходов ОЗУ, а выходы ИР23 - на D4...D7 шины данных процессора. Кстати, если ИР23 или другого регистра с Z-выходом нет, пойдёт 155ТМ8 с подключенным к его выходам 4-х разрядным буфером типа 589АП16 или 155ЛП11 (выходы буфера, как и выходы ИР23 подключаем на D4...D7 шины данных). Во время второго /CAS разряды D4...D7, как и ранее поступают в шину прямо из выходов ОЗУ, а разряды D0...D3 поступают в шину данных из регистра-защёлки, в котором выходы разрешены (выведены сигналом /OE из Z-состояния) на время пока второй /CAS=0.

Сложнее сообразить, как сформировать два /RAS-/CAS из одного /MREQ, изменяя при втором /CAS один из адресов на адресном мультиплексоре D18,D19. /MREQ (от Memory Request) это сигнал о доступе в память, при КР580 формируется на D4.4/11 получаемый как /WR и NOT DBIN объединённые на ЛИ1 (а у Z80 это уже готовый сигнал).

Можно сделать новый формирователь дающий два импульса /CAS при неизменном активном /RAS, а можно использовать тот же формирователь /RAS-/CAS запуская его дважды, удлинив цикл доступа к памяти на один маш.такт сигналом READY=0 (это тормознёт, но скорость можно выровнять заменой кварца).

По числу доп.деталей чуть проще, но тормознее, получится, если запускать ту же схему формирователя /RAS-/CAS дважды. Более грамотно (т.к без тормозов) сделать свой формирователь /RAS-/CAS, например применив вместо 4-х разрядного более длинный 8-ми разрядный регистр со всеми выходами, например, сделанный на двух ИР16 (можно ТМ9+ТМ2, две ТМ8 или 155ИР13).

Кстати, если бы во времена разработки Acorn Electron уже производилась динамическая память 41464 имеющая организацию 64К*4 (т.е 4 штуки 4164 в одном флаконе), то вся память была бы в одном корпусе.

В общем, по этим прикидкам получается, что экономия 4-х штук 565РУ5 обойдётся в установку на плату примерно 5-ти дополнительных корпусов (возможно и всего 4) с расходом примерно 2-х метров дефицитного провода МГТФ-0.03. Кстати, судя по фото на тематических форумах сейчас никто вообще не имеет такого провода, на всех фото виден монтаж толстым проводом МГТФ-0.5, а вовсе не МГТФ-0.03.

 кстати
.
Кстати, идею временнОго мультиплексирования ОЗУ я использовал ещё в середине 80-тых. Тогда я осваивал цифровую технику на 155-й серии, и среди многих других устройств сделал несколько музыкальных автоматов. Первые автоматы имели ОЗУ в 512 бит из 8 шт. 155РУ2 (16*4). А в последнем автомате ОЗУ было сделано всего на одной 537РУ3, которая имеет однобитовую организацию 4К*1. Для кодирования одной ноты надо было 8 байтов. Записывались коды музыкальных мелодий в ОЗУ с помощью 8-ми тумблеров. При записи набранный тумблерами байт по одному биту пересылался в ОЗУ. А при воспроизведении по одному биту данные считывались в 8-ми разрядный регистр. 4 килобита позволяло иметь мелодию длиной в 512 нот. Кстати, была возможность записи (и чтения) муз.программ из ОЗУ на МГ-ленту. Понятно, что при однобитовом ОЗУ скорость байтового обмена падает минимум в 8 раз, но бывают конструкции, где это не фатально.

Кстати, и в промышленных изделиях используются одноразрядные ОЗУ для хранения байтов, например в 80-тые так было сделано в цифровом ревербераторе и цифровом магнитофоне на микросхеме YC8256M в однобитовое ОЗУ записывался оцифрованный звук (такие устройства применялись для записи и выдачи коротких ~15 сек голосовых объявлений и в детских игрушках).
.


Когда сейчас смотрел на схему РК86, на узел формирователя /RAS-/CAS на 155ИР1, задумался почему он сбоит. Там схема работает так. На входе V2 ИР1 без наличия /MREQ всегда сидит уровень 1, что вызывает постоянную запись в регистр всех единиц и, соответственно, /RAS, SEL и /CAS равны 1. Когда приходит /MREQ, то V2 становится равным 0 и 155ИР1 переходит в режим счёта, сдвигая по заднему фронту импульсов частоты 16 МГЦ. После первого импульса - /RAS становится равным 0, после второго - SEL=0, а после третьего - /CAS=0. А возвращаются в единицу они одновременно по исчезновению сигнала /MREQ. Из-за ГФ24 период машинного такта равен 9-ти периодам такта 16 МГЦ. Вроде бы всё сделано грамотно, точно по РТМ для ОЗУ.

Но надо проверить какой минимальный интервал допустИм между фронтами /RAS, SEL и /CAS. Тут это выходит равным одному периоду частоты 16 МГЦ, т.е 62.5 МКСЕК. Не мало ли это?

Ещё можно подумать о том, хорошо ли для РУ5-тых, что /RAS исчезает одновременно с /CAS, в РТМ нарисовано, что /RAS исчезает раньше, чем /CAS.

А ещё можно попробовать сдвинуть и укоротить /RAS-/CAS подав на счётный вход вместо 16 МГЦ - 8 МГЦ.

Можно увеличить время активности /CAS, формируя его из SEL, просто задержкой на ~10 НС (например на RC-цепочке или 1533-вентилем). Это удлинит /CAS на ~50 НСЕК.

Ещё можно все 3 сигнала с выходов ИР1 сдвинуть на разряд (тогда /RAS будет браться не с первого выхода ИР1, а со второго, SEL с третьего, а /CAS - с четвёртого). Это приведёт к тому, что /RAS не будет формироваться почти одновременно с /MREQ, а сдвинется на 62 НСЕК. Сейчас получается, что адреса в РУ5 защёлкиваются в ОЗУ по /RAS сразу по фронту /MREQ - слишком рано, когда адреса ещё не до конца выставились.

Ещё есть идея попробовать вообще отказаться от эркашного узла формирователя /RAS-/CAS на регистре 155ИР1, а использовать в качестве /RAS сигнал получаемый объединением на вентиле ИЛИ (555 ЛЛ1) такта Ф2TTL и /MREQ. А /CAS получать простой временнОй задержкой /RAS, например стробированием на ТМ2 тактом 16 МГЦ полученного так сигнала /RAS, или просто используя RC-цепочку (видел много немецких компьютеров, в которых /CAS получают из /RAS именно так, на простейшей RC-цепочке).

А вообще, как способ борьбы со сбоями, для повышения надёжности при турбировании, или эксперимента-ради (чтобы понять причину проблемы) можно попробовать ввести один такт WAIT. Вот проект схемки для этого.


Image


По заднему фронту /MREQ первый триггер взводится выдавая на вход READY сигнал 0. Выход первого триггера подан на D-вход второго триггера, на C-вход которого заведён такт Ф1. Второй триггер взведётся в маш.такте T2 и своим инверсным выходом сбросит оба триггера в 0. Это более, чем вдвое удлинит длительность /RAS-/CAS (кстати, от удлинения /CAS должно потеплеть ОЗУ, а то оно в РК слишком холодное).

Эту идею добавки одного такта WAIT в такте Т2 собираюсь попробовать использовать для турбирования РК без потери надёжности. РК с небуферизованным ОЗУ при турбировании (по варианту из ж.Радио 01.1991) и доп.нагрузке шины подключением РК-КНГМД начинает сбоить, так что реально поднять частоту кварца удаётся лишь до 20...22 МГЦ (хотя при разгрузке шины и со снятым запасным ППА D14, РК абсолютно без сбоев работает с кварцем 28 МГЦ, т.е при сумасшедшем клоке 3.1 МГЦ). Возможно, что за увеличенное время хилые выходы РУ5-тых сумеют лучше вытягивать шину данных (т.е перезагружать паразитные ёмкости шины и входных цепей) и поднять частоту кварца удастся на большее значение.

Добавка одного такта WAIT тормозит процессор, потому при КР580 это скорее всего мало поможет в деле турбирования, т.к выигрыш от повышения частоты кварца сожрёт проигрыш из-за введения WAIT-а, а задрать клок КР580 выше 3 МГЦ нельзя (если не применять вместо него винтажный 8080D, допускающий клок в 4 МГЦ). А вот при Z80 польза может быть, т.к у него клок Z80 можно поднять намного выше, например, до 6 МГЦ.


Last edited by barsik on 26 Oct 2019 05:22, edited 7 times in total.



24 Oct 2019 17:41
Profile
Novelist

Joined: 10 Mar 2018 13:50
Posts: 36
Reply with quote
barsik wrote:
Shumadan wrote:
А насчёт полного использования 4 шт. РУ5 на 32 кб интересно. Как это будет выглядеть для Р86 ?
Это будет выглядеть печально, как пять TTL-корпусов напаянные на плате РК вторым этажом. Экономически сейчас это уже и ещё не имеет смысла.

Если с обычными Ру5 то конечно не имеет смысла. Но вот у меня сейчас лежат РУ5 в золоте и как раз 4 шт. Докупать до 8 шт. пока желания нет и поставить некуда. Вот с ними и можно было нагородить.


25 Oct 2019 11:42
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 307
Location: С-Петербург
Reply with quote
Post .
По поводу графического режима РК. Если разрешение 240 или 192 по горизонтали - более-менее приемлемо, то 104 по вертикали маловато. Ещё чуть поднять разрешение по вертикали можно, сделав видимыми ещё часть линий за счёт формирования КСИ аппаратно и удлинения вертикального бордюра заданием режима с большей длительностью VRTC.

При общем числе линий развёртки в 64 строки по 4 линии в каждой (что 256) соотношение общего числа линий к видимым равно (256+4)/208= 1.25 (4 добавляет заданная в режиме ВГ75 одна строка высотой в 4 линии на обратный ход луча по вертикали, используемый в РК в качестве КСИ). Пропорция 1.25 для телевизора нормально.

Для профессиональных CGA видеомониторов и современных TFT/LCD телевизоров это соотношение допустимо меньше. В плоских телевизорах в режиме 50 ГЦ с общим числом линий в 312 видны обычно не менее 280 линий, т.е пропорция 312/280= 1.11. Если исходить из такой пропорции, то в данном режиме будут вИдимы аж 234 строки, что даст разрешение 117 пикселей по вертикали. Хотя это требует точной центровки по вертикали и картинка может быть полностью видна не на всех аппаратах. К тому же спортивнее исходить из наличия кинескопного телевизора.

ВГ75 позволяет на обратный ход кадровой развёртки выделять от 1 до 4 строк (в РК выделяется 1 строка, она там задаёт длительность КСИ). Задав 4 строки вместо одной, при высоте знакоместа в 4 линии общее число линий развертки составит 256+4*4=272 . Используя пропорцию 1.25 расчитаем сколько будет видимых линий, если формировать кадровый бордюр частично аппаратно (КСИ при этом, естественно, также придётся формировать аппаратно). 272/1.25= 217. Это позволит иметь графику 240*109 или 192*109.

Кстати, проверим, сохранится ли регенерация при добавке ещё 3-х строк на VRTC. 16 линий на обр.ход луча будут длиться 16*64= 1024 МКСЕК. Так как для регенерации надо перебрать 128 адресов, а в каждой строке перебирается 80 (или 64) адресов, то на регенерацию ОЗУ выводом строк уходит две строки. Что в данном случае (т.е в случае знакомест высотой в 4 линии) составляет 2*4= 8 линий. 8 линий выводятся за 8*64 МКСЕК= 512 МКСЕК.

Итого: максимальный перерыв в регенерации из-за её отсутствия во время обратного хода луча при знакоместе в 4 линии составит 1024+512= 1536 МКСЕК, т.е всего ~1.5 МСЕК, что приемлемо, т.к меньше 2 МСЕК, что допускают динамические ОЗУ. А вот при обычных знакоместах в 10 линий перерыв в регенерации составит: (2*10 + 4*10)*64= 3.84 МСЕК. И регенерация нарушится. По этой причине авторы РК использовали полностью программный бордюр. Это значит, что если в такой граф.машине с динамическим ОЗУ требуется иметь и обычный текстовый режим, то надо переключать метод формирования КСИ. Это лишние сложности. По счастью мне текстовый режим на 80 символов совсем не нужен, и усложнять схему ради этого нет смысла. Потому в моём РК будет только графический режим.

Т.о при высоте строк и знакомест в 4 линии нет препятствий для удлинения кадрового бланка за счёт удлинения VRTC. Бордюр будет аппаратно-программным, т.к для кадрового бланка надо гасить 280-218= 62 линии. 16 линий гасятся аппаратно сигналом VRTC, но оставшиеся линии надо по-прежнему гасить программно, т.е выводить пустотой.

Конечно и разрешение в 109 линий по вертикали мало, да и пиксель неквадратный. Вообще желательно иметь соотношение разрешения по вертикали и горизонтали 2 к 3. Тогда пиксель квадратный, а круги круглые. Т.е при 240-ка точках по горизонтали желательно иметь разрешение по вертикали в 240*2/3= 160 точек. Но увы, ВГ75 программируется максимум на 64 строки и часть из них надо тратить на бордюр.

Еще немного улучшить разрешение можно используя ещё одну мою "плодотворную дебютную идею", как говорил великий комбинатор. Которую я придумал в 90-тые, но до реализации не доводил, т.к выигрыш от неё не велик. Она позволяет ещё немного улучшить разрешение по вертикали добавив в растр 16 линий. Суть этой идеи в том, чтобы искусственно удлинить длительность VRTC, вертикального бланка задающего время обратного хода луча.

Такую "химию" можно реализовать несколькими способами. Во-первых, тупо выключая клок ВГ75 в момент начала VRTC, например, на длительность вывода 16-ти линий растра, т.е на 16 строчных периодов по 64 МКСЕК. Тогда VRTC будет длиться 16 добавленных строчных периодов (это 16*64 МКСЕК = 1 МСЕК) плюс ещё 16, которые заданы режимом ВГ75. Это можно сделать взведя триггер по фронту VRTC и сигналом триггера запретить прохождение такта 8 МГЦ на вход CLK ВГ75, а затем начать отсчет 106*16*4=6784 входных импульсов 1.333 МГЦ (106 здесь длина строки в символах 80 плюс длина строчного бордюра в символах 26). А после их получения, сбросить триггер, вернув тем самым подачу такта на вход CLK ВГ75. Считать импульсы можно на 580ВИ53 или счётчиками, но гораздо проще отмерять время не счётом, а использовать стабильный аналоговый одновибратор на 1 МСЕК.

Вряд-ли ВГ75 сбойнёт при перерыве в подаче CLK на 1 МСЕК, но всё-равно есть более простой вариант. Можно не отключать такт CLK, а понизить его вдвое на время VRTC. Для этого самИм сигналом VRTC переключаем входной клок узла видео (т.е вход 155ИЕ4) с 16 МГЦ на вдвое меньшие 8 МГЦ. Это приведёт к тому, что VRTC будет длиться вдвое дольше, т.е не 16 строчных периодов, а 32 строчных периода (хотя сам ВГ75 будет думать, что он выставлял HRTC=1 лишь 16 строчных периодов).

Искусственное удлинение кадрового бланка до времени вывода 32-х линий растра увеличивает общее число линий до 256+32= 288. И с учётом той же пропорции 1.25 это позволит сделать видимыми уже 232 линии. Что поднимает разрешение экранной графики до 240*116 (кстати, если пересчитать на TFT-телевизор с большей пропорцией числа видимых строк, то на нём можно отобразить 240*128).

Выигрыш невелик, хотя и расход деталей на "химию" (половинка триггера и 2 вентиля из 155ЛИ1) небольшой. Но максимальный период регенерации ОЗУ составит уже 2.5 МСЕК, что больше, чем допустимо для РУ5. Если РУ5 будут сбоить, то придётся сократить интервал VRTC или заменить их на РУ7, у которых допустИм период регенерации в 4 МСЕК.

Если же ОЗУ заменить на статику, то не боясь сбоев регенерации, VRTC можно удлинить аж до длительности 64-х строчных периодов, что при общем числе линий в 312 (256+64) позволит выводить на кинескоп 260 видимых линий и иметь графический режим 240*130 (а на TFT-экране 240*140).

Если текст не волнует, а для игр важно, чтобы пиксель был квадратным, то не стОит переделывать схему на 80 символов, оставив 64 (с строчным шагом 78 и программным формирование бордюра по горизонтали). Тогда выводя лишь 64 символа в строке получится граф.экран с разрешением 192*128, соотношение точно 2 к 3, что и требуется. Кстати, при этом появляется возможность ещё чуть увеличить разрешение по горизонтали.

Современный телевизор и по горизонтали умещает бОльшее число знакомест, даже некоторые советские телевизоры показывали больше 64 знакомест и 25 строк. Именно потому некоторые РК-игры в строках выводят 68 знакомест и используют 27 строк. Можно не делая переделку на формирование ССИ аппаратно, лишь поднять на ~1% частоту кварца, запрограммировать ВГ75 на полное число знакомест в строке не 82 (78+4), а 86 (80+6), что немного уплющит экран и сделает видимыми вместо 64 знакомест в строке 66...69 знакомест. На вывод больше 80 отображаемых знаков в строке ВГ75 не расчитан.

67-68 видимых символов в строке позволят без апп.доработок сделать горизонтальное разрешение в графическом режиме 67*3= 201 или 68*3=204. Для игр экран 200*116 возможно удобнее (при статическом ОЗУ можно и 200*128). Графика 204*112 позволяет текстовый экран 34*14, что не хуже, чем текстовый режим у ZX-Spectrum.

Вначале, т.к при этом меньше всего изменений в ПО и минимальны доработки железа, разумно попробовать именно режим шириной в ~200 точек. Вот как выглядит графический текст в режиме 192*100. Из чего становится ясно, что символы при экране шириной в 240 точек будут выглядеть слегка уплющенно. Вскоре я перепишу драйвер под экран шириной в 240 точек и выложу скриншот, чтобы показать, как это выглядит.

Image


 частоты строк и кадров в РК86
Когда я считал частоту кадров для предложенного режима, то случайно обнаружил, что базовый режим в РК запрограммирован с отклонением от стандарта ТВ. Может я как-то не так считаю, хотя до сих пор все мои понятия о развёртках в разных компьютерах были верны. Может я что-то всё-же упускаю ? Получается, что для 67 символов в строке даже не требуется увеличивать пиксель клок на 1%, достаточно изменить один байт в ПЗУ РК.

Если я правильно считаю, то получается, что базовый режим ВГ75 в РК настроен не вполне по стандарту телевидения. Стандарт предусматривает частоту строк 15.625 КГЦ (что соответствуе строчному периоду в 64 МКСЕК), частоту кадров 50 ГЦ и дительности ССИ и КСИ 4.7 МКСЕК и 160 МКСЕК соответственно.

А что мы имеем в РК86? Строчный период длится 78+4= 82 периода знакомест-клока (это 1.333 МГЦ) и получается равным 82*(1/1.333)= 61.5 МКСЕК (а надо 64 МКСЕК) и соответственно завышенную частоту строк в 16.26 КГЦ вместо 15.625. Чтобы получить требуемый стандартом период 64 МКСЕК надо задать общий размер строки в знакоместах не 82, а 85 или 86. Длительность HRTC=ССИ - это в РК 4 периода частоты 1.3333 МГЦ, т.е 3 МКСЕК, вместо требуемых стандартом 4.7 МКСЕК. Его длительность в РК правильнее было бы задать не в 4, а в 6 периодов входного клока.

Число линий растра в РК - 310, т.к режимом задано 30 строк и еще одна строка отведена на обратный ход луча. Т.о при высоте знакоместа в 10 линий, получаем 31*10= 310 линий (в стандарте 312.5). Из-за неверной частоты строк и кадровый период получается не тем, равным 310*61.5= 19.07 МСЕК (вместо требуемых 20 МСЕК), что даёт частоту кадров 52.5 ГЦ вместо требуемых 50 ГЦ.

Если же задать в строчном режиме коэффициент 85 вместо 82 (изменив число периодов HRTC с 4 до 6 и строчный шаг с 78 на 79), то исправляется и частота строк и частота кадров и длительность ССИ становится соответствующей стандарту. И попутно большее число символов влезает в строку.

КСИ в РК длится, вместо требуемых стандартом 160 МКСЕК, целых 64*10= 640 МКСЕК. Это кстати, нисколько не вредит синхронизации.

Если в моих расчётах ошибок нет, то могут быть несколько объяснений. Возможно это сделано сознательно, т.к при завышенной частоте строк растр немного плющится по горизонтали и больше знакомест влезает в экран. Но это неграмотно, т.к экран проще и больше плющится заданием большей длины HRTC. Возможно, что в прототипе из которого заимствовали схему, использовался кварц не 8 МГЦ, а меньшей частоты, или использовался свой дисплей не связанный с ТВ-стандартом. Или может конкретный экземпляр телевизора на котором авторы настраивали РК имел сдвинутую частоту строк в генераторе строчной развёртки, отчего центровка растра получалась лучшей при таких параметрах развёртки. Естественно, телевизоры имеют значительную полосу захвата по синхронизации и без проблем переваривают кадровую частоту в 52 ГЦ и завышенную строчную (эта ошибка с частотой строк, кстати, была исправлена в некоторых клонах РК). Ещё одно объяснение в том, что в оригинальном ПЗУ исказился один бит (97H на 93H).

Если кто-то найдёт ошибку в этих моих рассуждениях о базовых частотах РК, жду доброжелательных поправок.


Вообще в ВГ75 диапазон задания VRTC не позволяет использовать его в качестве бордюра при числе строк более 25. Если диапазона программной регулировки HRTC вполне достаточно для максимального числа строк в 80 (отчего программно формировать строчный сигнал гашения излишне), то при числе строк >25 VRTC можно использовать лишь для гашения, требуемого по стандарту на момент выдачи КСИ, а не в качестве бордюра по вертикали. Хотя для режима 25 строк VRTC вполне годится для формирования бордюра (тогда соотношение общего числа строк к видимым равно 1.16, что для монитора нормально). А для числа строк более 25 бордюр приходится делать или чисто программным или аппаратно-программным.

Недавно кто-то открыл способ как включать две ВГ75 в параллель (что даёт для одного знакоместа 7+7= 14 битов для кода символа). Использование этого в граф.режиме позволяет даже без растягивания VRTC получить видеорежим 240*208, или при желании более оптимальный режим 240*160. Я это не буду делать, т.к мне под силу только простейшие доработки платы РК, ограниченные простыми коррекциями с напайкой всего нескольких TTL-корпусов вторым этажом, а для такой доработки общее число добавленных корпусов будет ~15 или более.

Пока у меня в планах лишь попробовать удобное программирование графики, для чего достаточно лишь добавить всего одну КП11 на коммутацию выходов ВГ75 (что нужно, чтобы управление пикселями в граф.режиме было простым). Это даёт граф.режим 204*104. Такой доработки достаточно для отладки графического ROM-BIOS и уже можно будет сделать выводы о плюсах и минусах.

Далее, чтобы получить экран 204*116 (или чуть больше, если будет влезать в экран моего кинескопного CGA-монитора) достаточно добавить формирователь КСИ на АГ3 и искусственно удлинить VRTC, чтобы растянуть экран. Не меняя архитектуру и адресацию портов РК, всё вышеперечисленное требует напайки вторым этажом четырёх дешёвых микросхем 555-той серии.

Отладив ROM-BIOS с текстовым драйвером на граф.режим, уже позже заменю кварц на 20 МГЦ и сделаю аппаратное формирование ССИ (обе эти коррекции нужны для 80-ти символов в строке). Аппаратное формированиее ССИ это лишь 555АГ3. Но это даёт граф.режим 240*116. А в заключение добавлю простейшую доработку по изменению адресов портов и расширению ОЗУ до 60 кб (это делается заменой адресов на входе 555ИД7, D11).

Сегодня я уже настроил РК в базовом виде. Далее начну ставить Z80. Но для начала мне надо решить проблему с РК-клавиатурой, старая герконовая разбилась (отломались штоки, клавиши утерялись, провода отвалились). Подключаю ретро аппаратную клавиатуру (называемую иногда ASCII). Также мне пришлось сделать и для ОРИОНА (драйвер намного короче, чем обслуга матричной, т.к на выходе сразу ASCII-код). Но для игр такая клавиатура неудобна, нужен джойстик.

После установки КП11 РК уже не сможет выводить текст базовым ROM-BIOS, тем более, что и ПЗУ с фонтом не будет (панелька знакогенератора пойдёт впоследствии под ПЗУ F000, чтобы ROM-BIOS был 4 кб). Неотлаженную систему можно будет тестировать только программами переносимыми в ПЗУ РФ2. Т.е или в виде самого ПЗУ F800, или считываемых из РФ2 стоящей в прошивателе УФ-ПЗУ для РФ2 (подключаемом через запасное ППА D14). Но 100 раз перешивать ПЗУ РФ2 слишком утомительно. Намного удобнее, отлаживать программами загружаемыми по проводной линии из PC. Тем более, что загрузка из линии всё-равно нужна и в окончательном изделии.

Потому для отладки в качестве ПЗУ F800 собираюсь прошить код, который при старте программирует ПДП и ВГ75 (чтобы началась регенерация ОЗУ, в экранном ОЗУ мусор и синхронизация не важна), а затем запускает процедуру ввода блока из проводной линии. Отлаживаемый ROM-BIOS работающий в граф.режиме загружается в ОЗУ и стартует.

Цвет атрибутами делать не хочу, его программировать в режиме с неотображаемыми атрибутами слишком сложно, а при отображении их пробелом ограничения в раскраске. А вот неиспользуемый бит D6 можно (с расходом в 2 TTL-корпуса) использовать для маркировки, т.е когда бит D6=1, то фон знакоместа (т.е PAPER) из чёрного становится серым. Ещё этот бит можно использовать для включения мерцания знакоместа 3*2, как это в Синклере, хотя польза от этого нулевая.

Но я подумываю о том, чтобы используя незадействованные биты D6, ввести 4 цвета на два соседних знакоместа, т.е на прямоугольник 6*2 пикселя. Тогда бит D6 от знакоместа в чётной позиции экрана одновременно с записью 6-ти бит в ИР13 защёлкивается в отдельном триггере. А когда, через 750 НСЕК выводится соседнее вправо знакоместо, то его бит D6 совместно с запомненным в триггере битом D6 предыдущего знакоместа, защёлкиваются в двухбитовом регистре цвета. Сихронизирует запись в триггер и регистр цвета отдельный D-триггер, переключаемый сигналом записи в ИР13. Когда на выходе триггера 0, идет нечетный байт, а при 1 чётный. Начальная установка достигается тем, что по HRTC этот управляющий триггер сбрасывается.

Таким образом получаем 2 цветовых бита длящихся время вывода двух соседних знакомест. Добавив ПЗУ перекодирования 4-х логических цветов в физические (вот так), получаем 4 цвета из 16 палитр, задействовав для переключения палитр безхозные атрибутные выходы ВГ75. Т.о в режиме с неотображаемыми атрибутами можно одновременно отобразить на экране 64 разных цвета с вдвое пониженным цветовым разрешением по горизонтали.

Использовать атрибуты даже для управления палитрами заметно усложняет программирование, да и для многоцветия схема для меня слишком сложна, чтобы её паять проводками, а вот получение 4-х цветов потребует добавки всего нескольких TTL-корпусов, что не предельно утомит меня при ручном монтаже. Но даже с всего 4-мя полноценными цветами и графикой 240*116 такой графический компьютер для игр намного лучше, чем оригинальный РК86.


26 Oct 2019 05:54
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 3 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.