Просмотр полной версии : Идея по введению лучшей графики в РК86
Наиболее востребованый режим псевдографики РК86 это 128*60. При этом за счёт сокращения высоты знакоместа с 10 до 8 линий растра в экран умещается 30 строк. Базовый фонт псевдографики разбивает знакоместо на 2*2 пикселя, т.е на 4 пикселя затрачивая 16 символов в фонте. Размер элементарного пикселя 3*4 точки. Так и получается 64*2=128 по горизонтали и 30*2=60 по вертикали.
Однако ВГ75 позволяет большее. Допустимо иметь до 64 строк. Сократив высоту знакоместа ещё более, - с 8 до 6 линий растра и применяя альтернативный, специально для графики предназначенный фонт, можно увеличить разрешение по вертикали. При этом общее число рядов знакомест 52, что даёт в кадре 6*52=312 требуемых линий растра. Видимыми будут только 43 знакоряда. Разделив знакоместо на 2*3 пикселя с размерами каждого пикселя в 3*2 точки, при 43 строках знакомест высотой в 6 линий, получается графика 128*129. Естественно, в знакогенераторе 64 псевдографических символа.
Но и это оказывается не предел для РК86. За счёт использования interlaced режима с частотой полукадров в 25 Герц можно иметь картинку с разрешением 256*129.
Для пояснения идеи расскажу о одном эксперименте с ОРИОНОМ, что я делал в 1993 году. Итак в ОРИОН добавляется триггер ТМ2 по схеме D-триггера, т.е по каждому заднему фронту на C-входе его выход изменяется. На C-вход триггера заводим КСИ, а выход триггера подаем в схему ОРИОНА так, чтобы переключать экран с C000 на 4000. Тогда один период частоты 50 ГЦ отображается один экран, а в следующий период - другой. Идея обычной черестрочной развёртки телевидения. В ходе эксперимента я загружал в экран 4000 одну картинку, а в экран C000 другую картинку. И убрав сброс с входа RESET ТМ2, я видел на экране объединённые 2 картинки. Но яркость изображения заметно падала.
На РК86 сигнал с выхода триггера с помощью ЛП5 будет инвертировать адрес А12, причём только когда идёт HLDA, т.е только пока экран читает ПДП. Это приведёт к тому, что чётные кадры будут читаться с обычных адресов экрана 76D0...7FFF, а вот нечётные будут читаться с адресов 66D0...6FFF. Причём сигнал триггера будет переключать фонт. В каждом знакогенераторе обоих фонтов псевдографика занимает только только половину знакоместа (или левую половину или правую).
Лучше использовать фонт шириной не 6, а 8 точек (чтобы делилось на 4). Высота знакомеcт 6 линий (чтобы делилось на 3). Фонт 8*6 разбивается на матрицу 4*3 с размером пикселя в 2*2, но фонт для каждого полукадра занимает лишь половину знакоместа по горизонтали, т.е в матрице 2*3, отчего число символов те же 64.
В чётных полукадрах отображются левые половины знакомест, а в нечётных кадрах правые половины знакомест. Но общее разрешение по горизонтали увеличивается вдвое до 256. При высоте знакоместа в 6 линий по вертикали умещается 43 строки. Так получается разрешение 256*129. Это вполне нормальное разрешение для игровых автоматов вплоть до середины 80-тых.
Если же не менять ИЕ4 на ИЕ5, т.е сохранив убогий фонт 6*8, то тоже получается графика 256*129, но пиксели по ширине не одинаковые - чётные шириной в 2 точки нечётные шириной в 1 точку.
Итого, расход деталей - один дешёвый триггер и затраты труда на перепрошивку фонта превращают РК86 в приличный (для своего времени) графический компьютер.
Интересно, многие ли читатели поймут эту идею. Если не поняли, - спрашивайте, уточню что не ясно.
Kakos_nonos
31.12.2017, 20:59
Круто! Но тут встает вопрос необходимости. РК и так тормозной, а пдп его еще сильнее тормозит, и чем больше строк тем больше тормоза.
У рк частота 1,77 мгц, но эффективная частота - 1,3 мгц. В режиме 50 строк апогея тормоза еще сильнее, мало остается тактов на прерывание, а если добавить что экран большой, надо перерисовывать его дольше, то есть фпс еще сильней упадет.
Может, есть какая-то деталь, которую я не понял, но во время создания уточек демо я столкнулся с этим.
У партнера отличные режим, у МЦПГ. И почти не освоен еще, столько крутого можно понаписать.
В режиме 50 строк апогея тормоза еще сильнее, мало остается тактов на прерывание, а если добавить что экран большой, надо перерисовывать его дольше, то есть FPS ещё сильней упадет.
Чем больше строк, тем больше торможение. О каких 50-ти строках речь? Это 50 строк видимых или 50 строк это их общее число с учетом верхнего и нижнего бордюров?
Если 50 строк видимых, то разве есть у Апогея фонт высотой в 5 линий ? 50 строк иметь не проблема. Выбираем фонт высотой в 5 линий, с общим число знакорядов в 62. Получаются те же 62*5=310 линий растра в кадре. Из них 50 видимых рядов знакомест высотой в 5 точек. Но псевдографика при высоте не кратной 2 - некрасива. Верхние пиксели высотой в 2 точки, нижние высотой в 3 точки.
В текстовом режиме по сбросу общее число строк 31, видимых 25. В традиционном графическом режиме общее число строк 36, из них 30 видимы. А в предлагаемом режиме с высотой знакомест в 6 линий общее число строк 52, из них 42 или 43 видимых.
Невидимые строки тоже жрут быстродействие. Потеря скорости на смене режима, думаю, процентов 15-20, и это легко компенсируется перекидыванием проводника в схеме РК86, чтобы поднять такт ВТ57.
В РК есть 2 метода ускорения - это поднять такт ВТ57 (короче будут циклы ПДП) и второе, - это поднять такт КР580 (по журналу РАДИО, кажется 01.1991). В РК86 видео и CPU могут быть асинхронны, т.к никак не связаны. Я ставил кварц 27 МГЦ (такт 3 МГЦ), устойчиво работало. Но при подключении РК-КНГМД пришлось понижать кварц до 20 МГЦ, т.к нет запаса по нагрузочной способности, ОЗУ просто не тянут нагрузку. А вот если ОЗУ на статике, то 3 МГЦ не предел даже при нагруженной шине. При большой нужде в турбировании можно поставить буфера на ОЗУ и разогнать КР580 выше 3 МГЦ.
РК86 тем и приятен, что в нём очень простые доработки дают выдающийся результат. Например, простейшая допрошивка в РФ2 альтернативного фонта резко улучшает качество вводя инверсию знакомест, рамки и высокую графику, тупая замена кварца повышает быстродействие, а замена ИЕ4 на ИЕ5 делает красивый фонт.
Ну а если скорости не хватает, можно использовать два экрана. Это снимает необходимость в прерываниях для синхронизации с видео. На прерываниях остаётся только функция счёта времени. А вообще-то в РК86 нет прерываний. Зато есть возможность считать КСИ из регистров ВГ75. Но вряд-ли кто -то это делал или будет делать.
Хочу попробовать такую простую доработку РК86 до графики. Это делает симпатичный компьютер из уродливого.
не вижу смысла. в Апогее графика делается знакогенератором и получается вполне прилично для такого компьютера и никакого аппаратного изменения.
NEO SPECTRUMAN
01.01.2018, 04:50
Это приведёт к тому, что чётные кадры будут читаться с обычных адресов экрана 76D0...7FFF, а вот нечётные будут читаться с адресов 66D0...6FFF.
зачем это?
в РК уже все это изначально есть
нужно всего лишь запрограммировать ПДП на перекидывание в два раза большего количества данных
а вг75 уже будет каждый раз получать данные из разных полукадров
не подумал что нужно каждый фрейм менять шрифт
а у рк нет прерываний
Итого, расход деталей в дешёвый триггер и затраты труда на перепрошивку фонта превращают РК86 в приличный (для своего времени) графический компьютер.
спектрумисты мигали мигали экраном
даже пытались получить этим цвет на точку
но в конечном итоге пришли к выводу что все это вырвиглазно
от этого устают глаза, это нормально не эмулируется
нельзя просто так взять и мигать в таком диапазоне яркостей с такой низкой частотой
была бы развертка герц 75-80 а не 50 Гц
это б уже прокатило (но при поворотах головы сразу же видно что нам подсунули что то не то)
я достаточно наэксперементировал с этим
и думаю что ты даже не представляешь как оно будет выглять на самом деле
нет если подобрать телек с большим послесвечением
выкрутить яркость в минимум
и сидеть смотреть на это безобразие в темноте
то да
картинка будет относительно стабильной
почитал внимательней и увидел что ты знаешь как оно мерцает
но если это мерцание терпимо для тебя
то оно не терпимо для других (например меня неимоверно бесило мерцание менюшки двдшника с его непрогресивной разверткой(хотя там диапазон мерцания был явно меньшим и еще ж было само смещение строк))
и это при том что я достаточно хорошо отношусь к этому эффекту
он отлично годится для демосцены
когда нужно несколько секунд показать какой то крутой эффект
но когда нужно пялится в экран
это мерцание быстро надоест
хотя само по себе мерцание с черезстрочником в 4 пикселя уже достаточно сильно ослабляет мерцание
но все равно
с черезстрочниками в 2 и 1 пиксель оно не сравнится
в принципе можно проверить идею на состоятельность
найти любой рк подобный с доработкой со сменным шрифтом
или зашить в пзу-шку кому не трудно
для теста сгодится и традиционный рк с 6х8 шрифтом
можно взять так удвоить разрешение по вертикали например
- - - Добавлено - - -
barsik, более рациональным будет применение такой матрицы
122000
112000
344000
334000
566000
556000
000122
000112
000344
000334
000566
000556
1. не нужно никаких модификаций рк только перепрошивка ПЗУ
2. мерцание с шагом в 3 пикселя менее заметно
(хотя если в доработаном до 8х8 рк пиксель клок больше(пиксели уже) то разницы как таковой не будет)
ну пиксели не совсем квадратные
ну и что?
на фоне мерцания это не такая проблема
а может все таки лучше удвоить разрешение по вертикали
112233
112233
445566
445566
000000
000000
000000
000000
000000
000000
000000
000000
112233
112233
445566
445566
в итоге у нас красивые ~квадратные пиксели
+кажется мне что мигающие горизонтальные полосы это лучше чем мигающие вертикальные
самый оптимальный вариант
110022
110022
003300
003300
440055
440055
006600
006600
001100
001100
220033
220033
004400
004400
550055
550055
но он из разряда смерть кодеру
пушо работать с ним будет трудновато
но картинка будет довольно стабильная
- - - Добавлено - - -
Это приведёт к тому, что чётные кадры будут читаться с обычных адресов экрана 76D0...7FFF, а вот нечётные будут читаться с адресов 66D0...6FFF.
не забывай что рк нет понятие экрана с такого то адреса !!!!!
у него экран может быть с произвольного места
и произвольных размеров
тут нужно ксоренье какого нибудь старшего бита
еще напомню что мы не знаем в какой момент времени какой из экранов у нас сейчас рисуется
и просто так нельзя привязать смену шрифтов к частоте фреймов
иначе полу кадры просто поменяются местами (тк програмирование вг75 и пдп может произойти как на четном полукадре так и не на четном)
или лучше смену экранов оставить обязаностью ПДП
а переключение шрифтов чтоб зависило от сигнала с ноги какого нибудь старшего адреса
тогда можно будет тулить экрана произвольных размеров так чтоб посредине была смена шрифтов
а лучше попытаться менять шрифт каким то другим образом
порасматривать внимательно вг75
и подумать как
- - - Добавлено - - -
короче что предлагаю я
впилить в рк прерывания от КСИ
впилить перепрограмируемый шрифт (несколько сменных переключаемых наборов)
всё
все проблемы решены
у програмиста развязаны руки
он может получить 64 "спрайта" в нативном разрешении 5**х3**
а может и запилить любой видео режим который он захочет с любым строением байта
и без проблем запилить все то что описано выше (каждый фрейм щелкать набором шрифтов)
3ы
кстате я предлагаю не жлобиться
а отдать под сменные шрифты столько памяти
сколько максимум может съесть вг75 за 2-3 кадра (лучше конечно 3)
это ну очень сильно расширит возможности
начиная от сильного упрощения всей анимации (просто в начале кадра меняем набор шрифтов и всё (все что на экране даже не трогаем)
заканчивая тем что можно будет иметь 3 экранных буфера с разрешением 5**х3** (нужно будет щелкать наборы шрифтов каждое определенное время с начала фрейма (для синхронизации с которым как раз будет инт от КСИ) и будет софтварный режим высокого разрешения (который я пока еще не выжал из обычного недоработанного рк))
3ы3ы меня если понесет я могу строчить посты и побольше чем ты:v2_tong2:
Раз речь шла о графике, я не упомянул ещё об одном шикарном режиме для РК86. Речь о великолепном текстовом режиме 64*21 с фонтом корветовского качества 8*12. Режим программирования тот же, - мой любимый режим с высотой знакомест в 6 линий в 42-х отображаемых линиях, при полном числе линий в 52. Этот режим полностью соответствует стандарту. Считайте сами 52*6=312 линий в кадре, что и требуется. Базовый режим РК86 чуть-чуть не дотягивает до стандарта, он даёт всего 31*10=310 линий в кадре.
В этом режиме используя специальный фонт для 64 символов, в котором символ на экране составляется из двух знакомест одно над другим, получается очень красивый фонт 8*12 в 21-ной строке по 64 символа в каждой. Но общее число доступных символов падает с 128 до 64. Это не так страшно, т.к большинство первых компьютеров в 70-тые (в т.числе и Apple-II) тоже имело всего 64 символа и никто не переживал из-за этого. Гораздо хуже, что для инверсии придётся использовать атрибут Reverse Video. Что резко сокращает цветовые возможности. Я предпочитаю иметь красивый шрифт вместо русских букв.
Дико удивлён, что нашлись таки люди до которых дошла сама идея чересстрочной развертки с имитацией двух экранов фонтами "вползнакоместа".
В раннем кинематографе использовали частоту кадров в 12, потом в 16 ГЦ и только в середине 20-тых годов стали использовать 24 Герца. Если людям хватало 16-ти Герц, и в телевидении до сих пор хватает 25 Гц частоты полукадров, почему тут должны возникнуть проблемы? Когда я коммутировал кадры с частотой 25 ГЦ, не помню, чтобы было заметно мерцание. Хотя это был профессиональный видео монитор, возможно с бОльшим послесвечением. Вот яркость заметно упала, это да. Но для этого есть ручки яркость и контрастность на видео мониторе.
Где-то читал, что современные телевизоры захватывают сигнал с частотой кадров в 60 ГЦ. При частоте полукадров в 30 Герц экран явно не будет мерцать даже для аборигенов Австралии. Просто тупо повышаем кварц с 16 МГЦ до 19.2 МГЦ (а если основной кварц был 20 МГЦ из-за применения красивого фонта 8*8, то для частоты кадров в 60 Гц понадобится кварц 24 МГЦ). Проблему мерцаний, если они и будут, можно таким образом решить.
Но вот с программированием поточечной графики сложнее. Псевдографика она и есть псевдографика. Тут сложнее программировать. А вот выводить текстовые символы это совсем не проблема.
Текстовый драйвер пишется один раз и он не сложен (помнится я написал драйверы 192*100 и 128*120 всего за полчаса каждый, сложнее было написать программку конверсии обычного фонта в фонт нужный для такой графики). Скорость работы драйвера вывода текстов примерно в 4-5 раз выше, чем у драйвера ОРИОНА с шириной фонта в 6 точек (там тормозит небайтовость шрифта, требуются маскирования).
По поводу быстродействия. У ИРИШИ в режиме "320 точек моно" эффективный такт ~1.5 МГЦ, а в режиме цвета или "моно 640 точек" эффективный такт ~1 МГЦ. И даже такой скорости хватает. Там ролик экрана делается стеком и при выключенном изображении, отчего эффективный такт временно поднимается до 1.77 МГЦ, что позволяет сдвинуть экран в 16 кб всего за 0.25 секунды.
Считаем размер экрана для режима 256*129. 43 строки по 64 символа в каждой, два экрана. Итого 43*64*2=5504 байта. Такой экран сдвинется быстрее, чем на ИРИШЕ. Причём, т.к при копировании массива регенерация ОЗУ получается программной, то ПДП на время ролика можно просто отключать и двигать экран на максимальной скорости CPU в 2.22 МГЦ (это при фонте 8*8 и кварце 20 МГЦ). Это будет почти мгновенный ролик. Ну а для вывода символов достаточно скорости и в 1 МГЦ, а при кварце 20 МГЦ эффективная скорость равна ~1.8 МГЦ (выигрыш не кратен соотношению кварцев, а намного выше, т.к цикл ПДП сокращается из-за повышения такта ВТ57).
Также как и с выводом символов, нет особых проблем с выводом заранее заготовленных спрайтов в играх. Есть готовый спрайт, есть подпрограмма его вывода. Задаём позицию в экране с шагом в 4 пикселя по горизонтали и 3 пикселя по вертикали и вызываем подпрограмму. Хлопот у прикладного программиста никаких.
А вот вывод реальной графики, т.е подпрограмм рисования точки, линии, окружности, прямоугольника - намного сложнее. Не то, чтобы это было невозможно, но сложно написать поддержку полноценной графики псевдографикой.
На таком РК удобно иметь 2 графических режима 256*129 чересстрочный для текстов и более простой режим 128*129 без чересстрочной развёртки для более простой псевдографики, полезный в основном для игр. Это оптимально, т.к в фонте как раз занимается 64 символа на чересстрочный фонт и 64 символа остаются на обычный псевдографический фонт знакоместа 8*6 с графической матрицей 2*3 (размер пикселя 4*2).
Как указано в начале поста, используя ещё один фонт для 64 символов, в котором символ на экране составляется из двух знакомест одно над другим, получается очень красивый фонт 8*12 в 21-ной строке по 64 символа в каждой.
Получается великолепный скоростной компьютер с текстовым экраном 64*21, красивым шрифтом и цветом. Плюс к тому же такой компьютер, простейшим переключением фонта получает вышеописанную графику 256*129 со шрифтом КОИ-8 и инверсией знакомест.
Теоретически при графике 256*129 можно иметь 42 символа в строке в 14-ти строках c фонтом для символа в 6*9. Однако 42 символа в строке запрограммировать сложно (я за это не берусь), а вот драйвер на 32 символа в строке простой. Причём драйвер даёт и инверсию знакомест, т.к вывод графический. Яркость на экране во всех режимах (interlaced - non interlaced) легко уравнивается путём доп.расхода одного транзистора.
Итого считаем, что надо для того, чтобы из РК86 сделать такой шикарный текстово графический компьютер.
Сделать фонт 8*8. Поставить 155 ТМ2 заведя ему на C-вход сигнал КСИ. Прошить дополнительный фонт в ПЗУ фонта. Для нового текстового режима фонт чисто текстовой машины с высотой знакоместа в 6 линий и фонтом из двух знакомест. И дополнительно фонты для двух графических графических режимов 128*129 и 256*129. Для режима 256*129 в первый килобайт шьётся фонт для чётного кадра, во второй килобайт фонт для нечётного кадра. Ещё придётся поставить 155 ЛП5. Итого надо всего три доп.микросхемы ТМ2, ЛП5 и 27256.
Старый базовый фонт тоже надо оставить, чтобы использовать старые программы РК86. Удобно использовать для фонта ПЗУ 27128 и управлять переключением фонтов разрядами запасного ППА D14. Тогда по сбросу, когда управляющие биты на адресах A11, A12, A13 ПЗУ фонта = 0,0,0 устанавливается базовый фонт РК86.
В это ПЗУ фонта умещается 2 фонта для текстового режима с красивым фонтом от Корвета 8*12, (в одном фонте латинские заглавные буквы, в другом русские заглавные буквы). Графический фонт для графического режима 128*129, предназначенный в основном для игр и два фонта для чересстрочного режима 256*129.
Если не делать замену ИЕ4 на ИЕ5, т.е оставить убогий фонт 6*8, то получается графика 128*129 и 192*129, а текстовый режим с двухблочными символами становится бессмысленным. Тогда лучше в 'interlaced' режиме увеличивать разрешение по вертикали (192*200) используя знакоместа высотой в 5 линий в 50-ти строках
Это, помимо базового режима РК86 с 25-ю строками, даёт три дополнительных режима (в которых 42 или 43 ряда знакомест с высотой знакоместа в 6 линий):
1. Text 64*21 mono с качественным фонтом для текстообработки (для программистов)
2. Graf Low Resolution Color 128*129, режим для псевдографических цветных игр (16 цветов)
3. Graf High Resolution Mono 256*129, чересстрочный режим графики высокого разрешения.
Чересстрочный режим пока не проверял на практике, но (как говорил пан начальник тюрьмы из "Ва-банк-2") не вижу проблем.
Для драйверов удобнее всего расширить ПЗУ РК86 до 15 кб в адресах C400...FFFF. Это можно сделать позднее, отлаживать ПО проще в ОЗУ.
Для начала достаточно слегка модифицировать базовое ПЗУ F800. Я уже давно освободил в ПЗУ РК86 100 байт. Потому не проблема перетранслировать это ПЗУ введя флаг драйвера. Тогда по сбросу флаг устанавливается в 0, отчего п/п-ммы F803, F809 и F812 работают как в оригинале. Но если этот флаг поставить в не_0, то по входу в эти подпрограммы будет делаться JMP в фиксированные адреса в ОЗУ (разумно в ОЗУ выше 8400) или (если есть) в ПЗУ C400.
Нужны текстовые драйвера двух режимов: Text mono 64*21 и High Resolution. Чисто графический режим для игр не нуждается в текстовом драйвере (хотя он у меня есть). Эти два текстовые драйвера могут грузиться в ОЗУ с ленты, но удобнее грузить их из ROM-диска от ОРИОНА. Драйвер в ОЗУ предпочтительнее на этапе отладки драйверов.
Драйвер режима Text 64*21 совсем простой, размером менее 200 байт. Экран в этом режиме занимает 52*78= 4056 байт, потому его удобно делать в верхнем ОЗУ (выше 8400). В обоих драйверах курсор выводится программно, аппаратный курсор ВГ75 не виден.
Текстовый драйвер шрифта 8*9 для графического режима 256*129, дающий текст 32*14 также очень прост, но имеет размер в 3 кб из-за необходимости иметь в нём фонт. На каждый символ тратится 6 байтов, потому размер фонта КОИ-8 составляет 256*6= 1.5 кб.
Если кого интересует, давайте "забацаем" такой компьютер. Выпуск плат не особо нужен. Жаль, что в платах новоделов РК86 сразу не предусмотрели большого ПЗУ для фонта и большого ПЗУ F800 (с страничной коммутацией в окне размером в 2 кб). Тогда бы все доработки ограничились бы монтажом ТМ2 и ЛП5 (да и они нужны только для чересстрочного режима, остальные режимы достигаются тривиальной сменой фонта и применением другого режима ВГ75).
Я лично для начала хочу сделать его эмулятор для ОРИОНА, чтобы отладить текстовые драйверы или даже целый ROM-BIOS, т.к меня не особо волнует совместимость с базовым РК86 (если надо посмотреть ПО РК86, то нет проблем поставить эр-кашные ПЗУ F800 и ПЗУ фонта назад).
HardWareMan
01.01.2018, 12:36
Для пояснения идеи расскажу о одном эксперименте с ОРИОНОМ, что я делал в 1993 году. Итак в ОРИОН добавляется триггер ТМ2 по схеме D-триггера, т.е по каждому заднему фронту на C-входе его выход изменяется. На C-вход триггера заводим КСИ, а выход триггера подаем в схему ОРИОНА так, чтобы переключать экран с C000 на 4000. Тогда один период частоты 50 ГЦ отображается один экран, а в следующий период - другой. Идея обычной черестрочной развёртки телевидения. В ходе эксперимента я загружал в экран 4000 одну картинку, а в экран C000 другую картинку. И убрав сброс с входа RESET ТМ2, я видел на экране объединённые 2 картинки. Но яркость изображения заметно падала.
И... Это не интерлейсед режим а два чередующиеся с частотой полуполей кадра в режиме 288р (привет Спецтрумский мультигигаколор!). Чтобы получить настоящий интерлейсед, надо менять количество строк в поле: четное 312, нечетное 313. Это вызовет смещение растра на полстроки у обычного ЭЛТ телевизора (и соответствующую коррекцию у цифровых телевизоров или плат захвата, либо ЭЛТ телевизоров с цифровой обработкой изображения) и падение яркости будет уже не таким сильным (не в 2 раза а примерно в 0.7 раз) + точки двух полей не будут слипаться. Пытайся еще.
PS Это справедливо и для РКшки.
И... Это не интерлейсед режим а два чередующиеся с частотой полуполей кадра в режиме 288р (привет Спецтрумский мультигигаколор!).
Для ЭЛТ мониторов это не чересстрочная, а, например, тюнер AVER воспринимал 2 соседних прогрессивных кадра вектора (312 строк, 50 Гц) как полукадры одного чересстрочного кадра. Это было четко видно про скроллу вбок - если каждые 20 мс сдвиг влево на 8 точек, то при захвате (с горизонтальным разрешением 576 и частотой кадров 25 Гц) была гребенка - в нечетных строках было сдвинутое на 8 точек изображение, в следующем кадре уже на 16 и т.д. В virtualdube есть фильтры для разбора таких кадров в два полукадра с удвоением частоты, чем и пользовался при захвате. Но это касается именно тюнера, на ЭЛТ такого, конечно, не было.
NEO SPECTRUMAN
01.01.2018, 17:15
25 ГЦ
но никаой тебе телевизор не покажет меньше чем 50
и если в телеке мигание будет в небольшом диапазоне яркостей
и будет еле заметным
то тут магиние в диапазоне от 0 до максимума
что очень заметно
- - - Добавлено - - -
Сделать фонт 8*8. Поставить 155 ТМ2 заведя ему на C-вход сигнал КСИ. Прошить дополнительный фонт в ПЗУ фонта.
еще раз
перепрограмирование вг75 может произойти как в четном полукадре
так и не в четном
твоей поделки на это фиолетово
и после сброса(или вообще после старта машины) вполне возможно этот недовидеорежим уже работать не будет
нужно будет ручная синхронизация
по принципу видите фигзнаетчто
нажмите кнопку
Если кого интересует, давайте "забацаем" такой компьютер.
я за инт от кси
и сменный фонт
и ненадо никакого колхоза
дошла сама идея чересстрочной развертки с имитацией двух экранов фонтами "вползнакоместа".
дык спектрумисты это уже все давно прошли
вот те пара примеров
http://vtrd.in/full_ver/OPENS.ZIP
http://vtrd.in/demo_ver/WORMSWV2.zip
с таким же успехом ты сейчас изобретешь цвет на псевдо точку
(потом запилю пример для апогея как это может выглядеть)
на комоде эту гадость применить намного проще
там много не сильно отличающихся цветов
и мигать ими намного безопасней
цвет на псевдо точку
(потом запилю пример для апогея как это может выглядеть)
типа такого (http://zx-pk.ru/threads/19920-gigaskrin-na-apogee.html?p=535202&viewfull=1#post535202)?
NEO SPECTRUMAN
01.01.2018, 18:18
barsik, вот те пример как оно будет выглядеть
63603
можно запустить на реальном рк и апогее
и посмотреть как сильно оно мерцает
никакой разницы между этим и железной реализацией не будет
еще подскажу если не догадываешься
может возникнуть такая ситуация
что некий движущийся объект
будет оказываться все время в не отображаемой части знакоместа
тоесть он будет тупо исчезать вообще
или даже не появляться на экране
а в железной реализации это даже нельзя будет отследить и что либо с этим сделать
то есть чисто в железном виде это, учитывая количество недостатков, бессмысленная мертворожденная поделка
инт и изменяемый на ходу шрифт(несколько наборов) будет намного эффективней
и при желании можно будет спокойно повторить данный эффект
- - - Добавлено - - -
типа такого?
это простой гигаскрин
а я про триколор (еще более жуткая вещь(хотя правильные черезтрочники очень сильно давят мерцание))
- - - Добавлено - - -
типа такого?
типа такого
http://vtrd.in/demo_ver/WORMSWV2.zip
триколор
понятно, делал такое (http://zx-pk.ru/threads/8378-pk8000-soft-staryj-i-novyj.html?p=183301&viewfull=1#post183301) для ПК8000
Вы обсуждаете абсолютно не то. Вне темы. Чётко указано, что для игр режим 128*129 с 16-тью цветами по схеме Апогея. Доработка, в случае, если цвет от "Апогея" уже есть, требующая только допрошивки фонта. Работа прошивателя УФ-ПЗУ на 1 минуту. Остальное делается программно.
А режим с чередованием кадров это для текста КОИ-8 и статичной графики. Качество шрифта как в ZX-Spectrum, но только лучше, т.к символы не приплюснуты как в ZX, а вытянуты по вертикали. Думаю, что можно чуть подняв частоту кварца на 5% увеличить общее число знакорядов до 56, а число видимых знакорядов до 45. Что даст 135 пикселей по вертикали, т.е ровно 15 строк высотой в 18 линий растра или 9 пикселей и визуально уменьшит экранчик, чтобы как раз влезало в телевизор.
Могу поспорить, что всё будет работать в пригодном для использования виде. Я делал в СПЕЦИАЛИСТЕ и в ОРИОНЕ кучу видео режимов и всё всегда работало без проблем. Я использую фирменный моно дисплей, он не только синхронизируется на любых частотах, но более того, - растягивает растр на весь экран при любом сигнале. У меня есть советские мониторы ВК-8071 от Корвета и 6105, так вот они так не делают.
А для игр скорее всего скорости текстового режима хватит, чтобы не мерцали динамические игры без всяких привязок к гашению кадров. В ОРИОНЕ и на СПЕЦИАЛИСТЕ не мерцало, с чего вдруг будет мерцать на РК, где текстовый режим и вывод спрайтов намного быстрее.
Прерываний в РК86 нет и насколько мне известно, никто их вводить в РК не планирует. Вот если бы кто-то взял обязательства сделать игры использующие прерывания, то да, это имело бы хоть какой-то смысл. Потому обсуждать демки и их FPS, мерцание и немерцание в играх, которых никогда не будет, - не имеет смысла.
перепрограмирование ВГ75 может произойти как в четном полукадре так и не в четном
Какое это имеет отношение к предложенным режимам? Ни в одном из этих режимов ВГ75 динамически не перепрограммируется. Как задали при инициализации режим в 52 строки с высотой знакоряда в 6 линий, так и остаётся, пока не понадобится перейти в другой режим ВГ75.
после сброса (или вообще после старта машины) вполне возможно этот недовидеорежим уже работать не будет
Если в ROM-BIOS для экрана в 256*135 режим ВГ75 устанавливается по сбросу, то хоть сколько раз жми на сброс режим всегда установится. Я вообще не понимаю о чём Вы пишете. Вы обсуждаете что-то непонятное, никак не связанное с темой.
А режим 128*129 давно надо было сделать вместо основного графического режима 128*60. Просто все почему-то считают, что как сделано 37 лет назад, так всё и должно оставаться. Даже перепрошить фонт это считается преступлением.
Лучше осваивайте PL/M и начинайте штамповать в огромном количестве цветные графические игры для РК86. Графики 128*129 (с обычной частотой кадров в 50 Герц) вполне достаточно, чтобы игры получились приличные. Как я уже неоднократно писал, РК86 приятен тем, что если его скорости не хватает, то нет проблем эту скорость увеличить почти вдвое, до ~2.5 МГЦ эффективного такта.
в железном виде это, учитывая количество недостатков, бессмысленная мертворожденная поделка
Очень простая доработка и очень простое программирование. Откуда возьмутся проблемы?
Какие недостатки? Мне нужен хороший шрифт на РК86 и почему бы мне его не поиметь?
Не сомневаюсь, что ещё до конца праздников сделаю скрин-шот с реала текста 64*21 со шрифтом от Корвета и текста выведенного шрифтом 8*9 на экран 256*135. Копии экрана я делаю с реала через TV-карту. Это даёт копии экрана только в монохроме, но цвета у меня на РК86 всё-равно нет.
тут мигание в диапазоне от 0 до максимума, что очень заметно
Яркость упадёт, но на профессиональном мониторе, где послесвечение бОльшее, чем в телевизоре ничего такого не будет. Видели когда-нибудь так называемый запоминающий советский осцилограф? Применялся для наблюдения непериодических процессов. Послесвечение люминофора 5-10 секунд.
NEO SPECTRUMAN
01.01.2018, 18:58
Какое это имеет отношение к предложенным режимам? Ни в одном из этих режимов ВГ75 динамически не перепрограммируется. Как задали при инициализации режим в 52 строки с высотой знакоряда в 6 линий, так и остаётся, пока не понадобится перейти в другой режим ВГ75.
да в твоей реализации этого нет
но у нас разве есть какойто стандарт на режим в 52 строки?
или на расположение экрана в памяти?
а у твоей поделки
эти параметры зачем то прибиты гвоздями...
- - - Добавлено - - -
Могу поспорить, что всё будет работать в пригодном для использования виде
посмотрел пример что выше?
поспорь с кем угодно что он не мерцает (хотя что выдадут современные лсдшные телеки хз(дето упоминалось что они вообще смешивают полукадры при гигаскрине))
жаль нет риндекса
поспорил бы ты с ним на счет что гигаскрин хоть как то пригоден к использованию
3ы
вот если задрать частоту до 60гц
это уже будет по лучше (хотя мерцание все еще будет сильным)
...но 60гц это не совсем труЪ
вот если задрать частоту до 60 ГЦ, это уже будет получше
Если понадобится могу повысить частоту кадров до 80 Герц, и соответственно частоту полукадров до 40 Герц. Это без проблем в РК, т.к меняется только такт подаваемый на ВГ75, а известно, что ВГ75 без проблем тянет двойное повышение частоты смены знакомест.
На обычном ОРИОНЕ на Z80, я просто заменял кварц 10 МГЦ на 16 МГЦ (ничего более не меняя), синхронно перекручивая частоты строк и кадров в видео мониторе. При этом частота кадров составляла ровно 80 Герц и всё работало как часы. Только отображаемый экранчик почему-то сокращался в размере. Это не значит, что любой ОРИОН на это способен, - только грамотно настроенный. Обычные ОРИОНЫ на Z80 едва тянут замену кварца до 12 МГЦ.
На видео мониторе это не понадобится. А для телевизора, если вдруг будет мерцать, не составит труда поднять частоту кадров до 30 Герц (как раз есть кварц 24 МГЦ).
NEO SPECTRUMAN
01.01.2018, 19:38
повысить частоту кадров до 80 Герц
вот это уже возможно прокатит
я достаточно плохо различал мерцание на такой частоте
оно очень хорошо сливалось в один цвет
а 60 гц это еще мало
3ы:
остается только ~2-х кратная потеря яркости
и то что у рк видео память может быть где угодно и произвольных размеров
3ы3ы
не помню
а ктонить расширял память в ркшках еще
чтоб несколько щелкаемых страниц было?
3ы3ы3ы
как по мне чем изобретать велосипед
лучше сделать програмируемый знакогенератор и впилить инт (хотя для совместимости нужна будет его аппаратная блокировка(тк di\ei используются не по назначению))
Kakos_nonos
01.01.2018, 20:00
У меня жк телек объединяет два быстрочередующихся кадра в один, так что гигаскрин показывается без мерцания вообще.
Партнер с мцпг хорошая штука, вот такое можно делать:
https://www.youtube.com/watch?v=v3h3a-ZA_FI
Там программируемый знакогенератор, точно не помню разрешение, но блок символ - 4*8 8-мицветных пикселей, и, наверное стандартные 64*30, то есть 256*240 или типа того. Это очень круто.
NEO SPECTRUMAN
01.01.2018, 20:09
жк телек объединяет
тк жк телек это не труЪ
он не теплый и не ламповый
а вот на теплом и ламповом...
- - - Добавлено - - -
такое можно делать
жесть конечно...
...даааа
а мне казалось что я видел эту демку о_О
Kakos_nonos
01.01.2018, 20:21
а мне казалось что я видел эту демку о_О
Может быть, ей уже года два или три.
- - - Добавлено - - -
а мне казалось что я видел эту демку о_О
Может быть, ей уже года два или три.
NEO SPECTRUMAN
01.01.2018, 20:46
в смысле я знал что она есть
но забыл ее посмотреть...
Разделив знакоместо на 2*3 пикселя с размерами каждого пикселя в 3*2 точки, при 43 строках знакомест высотой в 6 линий, получается графика 128*129.
... и получается псевдографический режим "Партнера" (см. например, мою lifepro.rkp, других программ, использующих этот режим, не знаю).
barsik, кстати, в этой программе еще и опрос клавиатуры сделан через прерывания.
Ещё интересный режим получается при задании высоты знакоместа в 9 линий. Тогда задаём общее число знакорядов в 35 (что даёт 35*9=315 линий растра в кадре, что вполне в полосе захвата) при числе видимых знакорядов в 28.
Преимущество при этом в том, что сохраняется обычный текстовый режим для вывода текста, но одновременно высота знакоместа кратна 3-м. Потому знакоместо для целей псевдографики можно разбить на 2*3 пикселя с размером пикселя ровно в 3*3 экранные точки.
Тогда в псевдографике получается экран 64*2=128 по горизонтали и 28*3=84 по вертикали. Фонт для 6-ти пиксельного занкоместа занимает 2 в 6-той степени символов, т.е тратится 64 символа из имеющихся 128-ми. Это значит, что на одном экране, причём без оперативной коммутации фонта с помощью атрибутов (все 4 атрибута остаются для 8-ми цветов для PINK и PAPER) можно выводить и псевдографику и надписи обычным шрифтом.
Причём легко получить отсутствие междустрочной линии, что получается из-за того, что фонт имеет высоту 8 линий, а не 9. Идея, как в текстовом режиме VGA и адаптере Hercules, где матрица знакоместа 9*14, но последняя 9-тая вертикальная колонка повторяет 8-ю колонку, что и обеспечивает сплошную по горизонтали псевдографику, хотя ПЗУ фонта лишь 8-ми битовое.
Ставится КП11, на её вход SEL заводится LC3 (старший адрес для адресации фонта из ВГ75). Тогда пока идут линии знакоместа 0...7 на адреса ПЗУ фонта проходят адреса LC0,LC1 и LC2, а когда пошла 9-тая линия при LC3=1, то КП11 выдаёт на адреса ПЗУ фонта 3 единицы, и из ПЗУ снова читается содержимое 8-мой нижней линии фонта. Т.е 8-я и 9-тая линии знакоместа одинаковы. Если бы авторы РК86 додумались до этого, то можно было бы рисовать сплошные вертикальные рамки и в режиме по сбросу.
вот пример как оно будет выглядеть: barsik-gigascreen.zip
Посмотрел это демо на EMU80 от Pyk. На файле .RK в эмуляторе РК86 просто сорвалась синхронизация по кадрам (вообще-то файлы для РК86 должны иметь расширение RKR, расширение RK не существует). Что-то Вы перепутали в варианте для РК86. Файл .rka на эмуляторе АПОГЕЯ не мерцал, но рывком сдвигался раз в несколько секунд.
А вот в EMU от b2m действительно на экране какая-то ерунда. Причём в обоих вариантах и RK для РК86 и RKA для АПОГЕЯ. Расскажите, что делает это демо. Посмотрел коды, но ничего не понял. Там просто задаётся режим в 38 строк с высотой знакомест в 8 линий и далее программа зацикливается.
Вообще-то режим в 38+1 строк (1 строка это КСИ) должен синхронизироваться, т.к это широко применяемый псевдо графический режим РК, чётко соответствующий стандарту (39*8=312 линий). Возможно, Вы что-то нахимичили с ПДП.
Какая-то химия демонстрируемая на эмуляторе это вообще не показатель. Вот если бы эмуляторы эмулировали кадро-коммутируемый режим 256*135, вот тогда можно было бы о чём-то судить. Кстати, действительно было бы неплохо поиметь такой режим в эмуляторе.
получается псевдографический режим "Партнера"
Принялся искать информацию о мощном графическом режиме Партнёра. Не смог найти даже картинки с его псевдографическим фонтом. Вы не путаете режим 128*60 с 30-ю строками и разделением знакоместа на 2 пикселя по вертикали, с режимом 128*135 с 45-ю строками и разделением знакоместа на 3 пикселя по вертикали?
Тогда стал искать информацию про МЦПГ, вдруг о нём речь. Тоже не нашёл в описании какую графику он реализует. Единственная фраза, что нашёл на тему графики: "Цветной псевдографический символ содержит 4х8 точек." Ну и как его делят на пиксели?
см. например, мою lifepro.rkp
Посмотрел, но вообще не увидел никакой псевдографики, даже обычной 128*60. И вообще не понял как играть. Никто не бегает, никто не стреляет, вообще никакого движения. Зачем здесь прерывания? Похоже на крестики-нолики или Отелло, но компьютер на мои ходы почему-то не отвечает. Предпочитаю стрелялки или бродилки, а не скучные логические игры.
NEO SPECTRUMAN
02.01.2018, 06:37
опять забыл проверить на 2-х эмуляторах...
и старых исходников мод рукой нет...
оно должно мигать
типо заполненными полузнакоместами
каждый кадр меняя видео буферы
- - - Добавлено - - -
Вы что-то нахимичили с ПДП.
да ПДП со мной не особо дружит (жаль нет железного рк)
но я набрал все по примеру с emuverse
- - - Добавлено - - -
Файл .rka на эмуляторе АПОГЕЯ не мерцал, но рывком сдвигался раз в несколько секунд.
проверил на
Emu80_40277
рк действительно не завелся ...может не те порты прописал
рка показывает при этом то что нужно
у меня это явно не стабильная картинка...
и вообще смотреть на эмуляторе это бесполезно
этот эффект не эмулируется
нужно смотреть на реале
на теплом и ламповом телевизоре (не на лсдшнике)
- - - Добавлено - - -
Какая-то химия демонстрируемая на эмуляторе это вообще не показатель. Вот если бы эмуляторы эмулировали режим 256*135, вот тогда можно было бы о чём-то судить. Кстати, действительно было бы неплохо поиметь такой режим в эмуляторе.
рукалицо...
эта химия показывает как мигают твои "не мигающие" 25 гц
и на эмуляторе оно и не нужно смотреть (пушо там мигает намного сильней чем на самом деле изза разсинхронизации частоты кадров эмуля и частоты кадров монитора)
а эмулировать "это"
можно только при наличие монитора
который держит или 50 или 100 гц
- - - Добавлено - - -
И вообще не понял как играть
помоимо опять рука лицо
судя по названию это
https://ru.wikipedia.org/wiki/%D0%98%D0%B3%D1%80%D0%B0_%C2%AB%D0%96%D0%B8%D0%B7% D0%BD%D1%8C%C2%BB
- - - Добавлено - - -
да это действительно оно
...божы еле вспомнил как нарисовать планер...
а играть в это можно...
...в принципе можно
- - - Добавлено - - -
можно доиграться до такого
https://upload.wikimedia.org/wikipedia/commons/e/e5/Gospers_glider_gun.gif
или такого
https://upload.wikimedia.org/wikipedia/commons/e/e6/Conways_game_of_life_breeder_animation.gif
- - - Добавлено - - -
никто не стреляет
как это никто не стреляет?
https://ru.wikipedia.org/wiki/%D0%A0%D1%83%D0%B6%D1%8C%D1%91_%28%D0%BA%D0%BE%D0% BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8 %D1%8F_%D0%BA%D0%BB%D0%B5%D1%82%D0%BE%D1%87%D0%BD% D0%BE%D0%B3%D0%BE_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D 0%B0%D1%82%D0%B0%29
и вообще смотреть на эмуляторе это бесполезно
этот эффект не эмулируется
Если на ПК монитор работает в режиме 60 Гц (что чаще всего и бывает), то эффект еще более-менее похожий: в этой демке экран ВГ75 программируется на частоту кадров, близкую к 60 Гц - получается мерцание через кадр (хотя и нестабильное, так как частота полностью не совпадает). Если посмотрите более новые версии Emu80, то там я сделал еще 2 режима отображения этого эффекта: смешивание полукадров и чересстрочное отображение (начиная с версии 4.0.256). Кроме gigascreen demo этот же эффект можно посмотреть на заставке игры lines от vinxru.
Кстати, если будете смотреть в Emu80 alien demo от Kakos_nonos, видео которого привел он выше, возьмите версию из вложения: в оригинальной не полностью инициализируется цветной режим, но это игнорируется в эмуляторе от b2m.
Принялся искать информацию о мощном графическом режиме Партнёра.
Не пояснил сразу: этот черно-белый псевдографический режим 128*128 можно запрограммированить в родном знакогенераторе "Партнера", к МЦПГ он не имеет никакого отношения. Но он почему-то практически никем не использовался.
http://emu80.org/temp/lifepro.png
http://emu80.org/temp/lines1.png
http://emu80.org/temp/lines2.png
...честно говоря, не пойму, зачем использовать режимы, которые не поддерживает ни одна известная программа... Для демок и только? Только ради ковыряния в железе? Уважаемый Alex_LG (http://zx-pk.ru/members/7683-alex_lg.html) уже сделал более полезную доработку РКшки с загружаемым знакогенератором, почти как в Денди, http://zx-pk.ru/threads/20714-pomechtaem-ili-vopros-o-videovykhode.html?p=713206&viewfull=1#post713206 И совместимость на высоте, и возможностей больше.
Ну это так, новогоднее брюзжание, можете не обращать внимания...
этот черно-белый псевдографический режим 128*128 можно запрограммированить в родном знакогенераторе "Партнера"
Впервые узнаю о графическом режиме 128*128 для РК-клонов. Читал где-то, что vinxru удалось получить режим в 192*100, но он хреново синхронизируется на телевизоре, а динамическое ОЗУ хреново регенерируется.
Что за режим ВГ75 позволяет это? На какое число знакорядов программируется ВГ75, сколько из них видимых? Какова высота знакоряда в линиях растра? Думаю, что такой режим возможен только в ПАРТНЁРЕ благодаря тому, что у него повышенный пиксель клок: 9 МГЦ вместо 8-ми МГЦ.
А для РК86 это не годится. Я когда пытался улучшить графические возможности РК86 рассматривал разные варианты высоты знакомест. Вариант с высотой знакомест в 3 линии отпадает из-за ограничения ВГ75 всего в 64 знакоряда, т.к 64*3=192 линии в кадре, а надо 312.
Режим с высотой знакомест в 4 линии для советских телевизоров не годится, т.к они не мультисинк и всегда работают с частотой кадров 50 Гц. А какая частота кадров получается? Считаем: 64*4=256 линий в кадре, а надо 312. Из-за этого частота кадров возрастёт до (312:256)*50= 61 Герц.
Потому в те времена, когда в эксплуатации находилось 200 тысяч РК86 и его клонов, никто до такого режима не мог даже додуматься, т.к все знали, что в телевидении частота кадров 50 Гц. И только тот из пользователей, кто решил бы поставить в видео монитор 6105 тумблер для переключения частоты кадров 50-60 Герц, смог бы поиметь такой режим. Но зачем нужен видео режим, если он только для одного человека.
И только в 21-вом веке нашлись люди, которые изобрели этот режим с частотой 61 Герц и высотой строк в 4 линии растра. Они использовали свойство уже современных импортных телевизоров работать с видеосигналом в каком-то американском стандарте с частотой 60 Герц. При этом из общего числа в 64 знакоряда видимы будут 50-51 знакоряд. Что при 2-х пикселях в знакоместе по вертикали даёт режим 128*100, но никак не режим 128*128.
Потому режим с знакоместами высотой в 6 линий и 43-мя линиями растра, дающий режим 128*135 точек, является не только более качественным, но и соответствующим стандарту телевидения, а режим с частотой кадров 61 Герц это извращение. И совершенно нелампово, т.к в 1987 году любой владелец РК86 мог допрошить второй фонт в РФ2, но никто не имел телевизора с американским стандартом частоты кадров.
Если наплевать на стандарты телевидения, то можно изобрести ещё более крутой режим с высотой знакоместа в 3 линии и соответственно частотой кадров в (312:192)*50= 81 Герц, дающий 3*52= 156 точек по вертикали. Но кому нужен такой режим 128*156, если видео монитор надо перекручивать, и не на всех мониторах это получится без замены ёмкости в генераторе кадров.
А режим 128*128, что есть только у ПАРТНЁРА потому и не поддержан программами, что поддерживаются только такие режимы, что есть у РК86 и его клонов с тем же пиксель клоком.
не пойму, зачем использовать режимы, которые не поддерживает ни одна известная программа
Новое вводят не потому, что его поддерживают старые программы, а для того чтобы делать новые программы, использующие лучшие возможности и потому более качественные, чем старые программы. Тем более когда новые возможности достаются так просто, лишь за счёт перепрошивки ПЗУ с фонтом.
Ну а кадро-коммутируемый режим 256*135 с пониженной частотой кадров нужен не для игр, а для удобства текстообработки при написании программ, чтобы не портить зрение с убогим некачественным фонтом, к тому же только 7-ми битовым в КОИ-7. Гораздо приятнее читать тексты в КОИ-8 с большими и маленькими русскими буквами и красивым шрифтом. Для текстообработки другие программы не нужны, достаточно изменить пару байтов в моём текстовом редакторе для РК86. Также можно доработать и другие текстовые редакторы.
В ленинградский монитор СПЕЦИАЛИСТА для того, чтобы текстовые редакторы не зависели от использованного фонта, т.е режима дисплея, введена ячейка 8FD0, в которой хранится число символов в строке. Потому программы читая эту ячейку не выводят символы за пределы экрана, всегда подстраиваясь под драйвер.
Alex_LG уже сделал более полезную доработку РК-шки для загрузки знакогенератора
Но эту доработку нельзя сделать за минуту, что занимает перепрошивка ПЗУ или за полчаса, что знимает монтаж ТМ2 и ЛП5 (для режима 256*135). И разрешение экрана это нисколько не повышает, и даже шрифт как был так и остаётся мелким и некрасивым.
И чем же эта доработка полезнее, чем допрошивка ПЗУ фонта? Т.к игр с использованием загружаемый тайлов для вывода спрайтов нет, то всё, что такая плата даёт, это то же самое, что даёт допрошивка ПЗУ фонта - только альтернативный фонт. Но фонт ещё надо загружать в плату от Alex_LG, а когда он в ПЗУ достаточно выдать байт в ППА D14 для смены фонта. Я не против доработок железа, но хотелось бы чтобы они были простыми и поддержанными программами.
это так, новогоднее брюзжание, можете не обращать внимание...
Ладно, не будем.
А вот в EMU от b2m действительно на экране какая-то ерунда.
Если это версия 7-летней давности, то не мудрено.
NEO SPECTRUMAN
02.01.2018, 19:20
Если это версия 7-летней давности, то не мудрено.
b2m а можно подписывать emu.rar
номером версии или датой сборки?
чтоб проще было ориентироваться
можно дать нормальное название эмулятору? (если его еще нет)
нагуглить emu по одному названию никто не сможет
и обозвать им же архив
допиши b2m справа или слева чтоли
Что за режим ВГ75 позволяет это? На какое число знакорядов программируется ВГ75, сколько из них видимых? Какова высота знакоряда в линиях растра? Думаю, что такой режим возможен только в ПАРТНЁРЕ благодаря тому, что у него повышенный пиксель клок: 9 МГЦ вместо 8-ми МГЦ.
Все очень просто: 50 строк по 6 линий растра, из них 43 видимых. Пиксель клок тут абсолютно ни при чем, просто на Партнере есть нужный набор знакогенератора с матрицей 2x3 в знакоместе 6x6 (на самом деле там матрица 2x4 в пределах 6x8, но ей практически невозможно пользоваться из-за того, что она разбита на 2 набора по 128 символов)
...Читал где-то, что vinxru удалось получить режим в 128*100, но он хреново синхронизируется на телевизоре, а динамическое ОЗУ хреново регенерируется...
Пожалуй стоит пояснить. Vinxru разрабатывал свои игровые программы (Линии, Кособан и тд) для Апогея и его режима 192х108. Он не сам его выдумал - это Апогей умеет от своего рождения. Графические программы, например Гонки, Бэйсик Графический, что с ним в комплекте идут, как раз используют этот режим. Режим этот работает в 60Гц и нормально отображался на советских телевизорах, и цветных, и чб (сам наблюдал, у меня был Апогей в 90-м году).
У Апогея есть второй набор знакогенератора (переключаемый по ei/di). Высота символов в нём 4 линии. Основной набор (64 символа) это все варианты матрицы 3х2 (размер пикселя 2х2). Таким образов в строке можно отобразить 192 "пикселя" (вместо 128 при основном знакогенераторе). Остальные 64 символа - разнообразные узоры. Для нормальной работы с этим режимом надо настроить ВГ75 на 64 отображаемых строки высотой по 4 линии (из них примерно 6 сверху и 4 снизу оставить пустыми). VRTC установить 1-2 строки - получится 260-264 линии в кадре (58.7-59.6 Гц). Советских телевизоров у меня давно нет, но все современные тв эти режимы держат без срывов. Можно сократить общую длину строки на один символ (85) - получится 63,75мкс (вместо 64,5мкс изначальных) что более соответствует стандарту NTSC.
Так же этот режим стабильно отображается на РК, Микроше и подобных компьютерах на основе ВГ75. Только из-за отсутствия знакогенератора под этот режим, он на РК бесполезен (кроме Партнёра конечно).
На регенерацию он никак не влияет - то были попытки сэкономить экранные байты и заменить неотображаемые строки спецсимволами (конец строки, стоп пдп). Вот если таких строк напихать без меры в экран, то при любом режиме остановленный надолго пдп не будет ничего регенерировать.
50 строк по 6 линий растра, из них 43 видимых
Значит Вы ввели нас в заблуждение. Там используется именно тот режим, что я и предлагаю в этой теме. Если бы Вы сразу режим ПАРТНЁРА назвали правильно 128*129, а не 128*128, то и вопроса бы не возникло.
А почему 50 строк? Для точного соблюдения стандарта надо 52 строки высотой в 6 линий. При 50-ти строках будет на 4% повышенная частота кадров и 52 строки лучше, т.к тогда видимыми будут не 43, а 45 знакорядов и значит вертикальное разрешение чуть выше.
Если это версия 7-летней давности, то не мудрено
У всех пользователей эмулятора EMU одна и та же версия 1.01 семилетней давности. Так написано в окне "About". Принято писать полный номер версии и дату ставить текущую. Видимо это окно Вы перестали изменять 7 лет назад, как и текстовый файл 'history.txt' перестали сопровождать много лет назад.
На регенерацию он никак не влияет - то были попытки сэкономить экранные байты
Как же не влияет? Если кодом F1 прекращать работу ПДП после 71-й позиции, отчего не все адреса ОЗУ пробегаются.
И нельзя делать обратный ход по кадрам более одной строки, т.к это сразу увеличивает перерыв в регенерации свыше 2 МСЕК, что требует РТМ на 565РУ3/6,5. Авторы РК86 не были идиотами и именно поэтому вынуждены были "городить огород" с программным формирование бордюров по строкам и кадрам (что вызывает смещение экр.позиций на 3, 8) и задавать только одну строку на обратный ход луча по кадрам.
Это "химия", но она работает просто потому, что в реальности ОЗУ дают максимальный период регенерации без сбоев бОльший, чем это указано в РТМ. Но попадутся образцы РК86, где ОЗУ старые с накопительными ёмкостями с большой утечкой и оттого с малым периодом регенерации.
режим 192х108... vinxru не сам выдумал, - это Апогей умеет от своего рождения
Обидно. А я думал, что это только я такой сообразительный, что догадался об этом. Оказывается советские инженеры догадались как увеличить разрешение псевдографики задолго до того.
Получается, что как минимум два клона РК86 имели свою расширенную псевдографику. ПАРТНЁР с увеличением разрешения по вертикали, а АПОГЕЙ с увеличением разрешения по горизонтали. Может и другие клоны РК имели лучшую графику ?
Я использовал режим 192 на 100, т.к использовал монитор, в котором удобно подстраиваются частоты строк и кадров (про существование АПОГЕЯ даже не знал). И даже текстовый драйвер 192*100 имею. Но для фонта 8*8 такой режим не годится, т.к 8 точек по горизонтали не разделить на 3 пикселя равномерно, отчего один пиксель из 3-х получается ущербным.
И если уж оба варианта улучшения разрешения графики более грамотным фонтом (по горизонтали или вертикали) при введении в РК86 требуют допрошивки фонта, то для игр графика 128*135 всё равно лучше, а для текста лучше кадро-коммутируемая графика 256*135.
barsik, я пытался никого вводить в заблуждение, я лишь подтвердил в 21 сообщении, что в Партнере используется предлагаемый вами режим.
Как же не влияет? Если кодом F1 прекращать работу ПДП после 71-й позиции, отчего не все адреса ОЗУ пробегаются.
Так я и написал - если не использовать (без меры) спецсимволы, то всё нормально с регенерацией. Откуда там F1 взяться то?
- - - Добавлено - - -
...
И нельзя делать обратный ход по кадрам более одной строки, т.к это сразу увеличивает перерыв в регенерации свыше 2 МСЕК, что требует РТМ на 565РУ3/6,5...
По умолчанию у нас VRTC равно одной строке высотой из 10-ти линий. Если высота строки будет 4 линии, то почему нельзя выставить VRTC равное двум строкам? Итого 8, что даже меньше чем было.
Если у нас на отображение экранной строки уходит 64,5мкс, то чтобы уложиться в лимит 2МСЕК можно для VRTC безболезненно для регенерации использовать до 31 линии.
Если кодом F1 прекращать работу ПДП после 71-й позиции, отчего не все адреса ОЗУ пробегаются.
Даже если F1 и есть, то ничего страшного - в начале следующей строки пробегутся дальше... Много раз уже эти коды использовали - проблем с регенерацией не было...
- - - Добавлено - - -
чтобы уложиться в лимит 2МСЕК можно для VRTC безболезненно для регенерации использовать до 31 линии
А реально обычно и еще реже можно безболезненно регенерировать...
чтобы уложиться в лимит 2 МСЕК можно для VRTC безболезненно для регенерации использовать до 31 линии
На самом деле 29 линий, т.к 2 линии уходят на саму регенерацию. Но это здорово удлинит КСИ, не уверен, что это полезно для синхронизации.
Если высота строки будет 4 линии, то почему нельзя выставить VRTC равное двум строкам?
Теоретически можно, но совсем не нужно, т.к желательно наоборот укорачивать КСИ. Советский ГОСТ на ТВ-сигнал требует:
4.7 МКСЕК - длительность ССИ
27.3 МКСЕК - длительность КСИ
ССИ в базовом режиме РК86 длится 6 периодов частоты смены знакомест. Т.е 6 * 1/1.333= 4.5 МКСЕК. Это норма. А вот КСИ длится слишком долго - 645 МКСЕК, что намного больше, чем требуемые 27 МКСЕК.
А весь период кадрового гашения в РК86 длится время вывода 6-ти строк (3 + 2 это бордюры сверху и снизу и 1 строка это КСИ), т.е: 6 * 64.5 МКС * 10= 3.87 МСЕК (в ОРИОНЕ и СПЕЦИАЛИСТЕ это 3.6 МСЕК).
Откуда там F1 взяться то?
Речь шла о режиме vinxru в котором для сохранения размера экранного буфера активно ставятся F1.
Способ экономии размера экранного буфера при высоте знакоместа в 8 линий, изобретённый vinxru в основном основан на том, что в невидимых строках не выполняется видеовывод и соответственно, регенерация ОЗУ. Перерыв в регенерации при не-выводе 5-ти строк составляет 5*64.5*10 + 2 * 64.5 = 3.354 МСЕК .
DonkeyHot
19.02.2018, 20:53
всё не читал, но что мешает ввести вместо ROM ЗГ SRAM, подключить его через порт и программно грузить любой набор символов?
Error404
19.02.2018, 21:40
предположу "это будет уже не РК". :)
DonkeyHot
20.02.2018, 01:14
кстати, раз уж заговорили об этом - даже в "топовой" версии задействовано 32 озу, так что вообще можно выделить 2кб из адресного поля для прямого доступа к памяти знакогенератора и кастомной загрузки спрайтов. Это будет уже например Радио-2018РК :)
ЗЫ я помню что первую самоделку, которую увидел - это был 86РК у соседа. Именно поэтому первый у меня был Специалист. Будь тогда решена проблема графики в игрушках, возможно всё было бы иначе...
всё не читал, но что мешает ввести вместо ROM ЗГ SRAM, подключить его через порт и программно грузить любой набор символов?
этой идее в обед 100 лет
можно выделить 2 кб в неиспользуемых участках памяти выше 8000 для прямого доступа к памяти знакогенератора и кастомной загрузки спрайтов
Идея хорошая, и я слышу о ней с 1988 года. К сожалению, Вас опередили. Но Вы в верном направлении думаете. В оригинале у РК много недостатков, но многое при желании легко исправить.
С реализацией этой идеи нас опередил Alex_LG, сделавший загрузку фонта в РК86 ещё лет 10 назад. http://zx-pk.ru/threads/27125-modulnyj-radio-86rk.html?p=893104&viewfull=1#post893104
Это полезная для игр идея. Она позволяет строить игровые фигурки (спрайты) из загруженных графических символов (назовём их тайлами, хотя это и не совсем точно). Это даёт возможность вывести 6-10 фаз каждой фигурки, и за счёт этого имитировать движение и сделать более зрелищным игровой процесс. Качество графики таких игр может теоретически не уступать графическим машинам. К тому же скорость спрайтов выше, никаких проблем с миганием, а программировать квази-графические игры легче, чем для полноценно графических машин. Для такой машины можно написать даже совсем примитивный GUI, графика это позволит.
Увы, производство плат этого изделия наладить (т.е набрать заказов столько, чтобы цена платки упала до разумного) не удалось. Т.к здесь большинство пользователей РК не программируют сами и потому не понимают, что такая платка даёт. Ну и конечно не верят, что откуда-то возьмутся программы использующие эту плату. Так что гораздо более реально уговорить какого-нибудь изготовителя новоделов добавить большое число фонтов, коммутируемых атрибутами ВГ75, что также позволит делать игры с лучшей графикой.
Но если имеете энтузиазм и умения, Вы можете наладить производство таких плат загружаемого фонта для РК86 и клонов, по своей схеме или воспользоваться наработками от Alex_LG.
Лучше не использовать англиканизмы типа кастомный (от англ. custom). Если губить русский язык англиканизмами, то ваши внуки будут разговаривать на убогом англо-русском суржике. Пропаганда англиканизмов это новый способ предательства Родины.
Недавно соорудил нечто подобное на макете для Апогея.
https://youtu.be/SNgWk6kL3mQ
DonkeyHot
20.02.2018, 10:45
схема-то будет?
схема-то будет?
Я в схемных редакторах опыта ещё не имею, только учусь. Как освою хоть что-нибудь, так сразу и выложу (может к вечеру).
В принципе, моя схема на 90% похожа на упоминаемую ранее в теме схему от Alex_LG. Только мультиплексор у меня построен на 74хх244 (за неимением 74хх157 или 74хх257), а в качестве буфера данных озу наоборот 74хх245. Ну и вместо тумблера программно переключаю знакогенератор незадействованным сигналом C1 контроллера клавиатуры.
DonkeyHot
20.02.2018, 12:02
SegaBoy, качай халявую версию diptrace, удобно и достаточно
схема-то будет?
Так пойдёт?
П.С. Все необходимые для работы сигналы берутся с платы Апогея. На самой плате требуется удалить перемычку 78-79, соединяющую сигналы CRT VSP и ROM3 /CS.
Версия не окончательная, так как планирую задействовать всю память (8КБ) для четырёх наборов по 128 символов.
Все необходимые для работы сигналы берутся с платы Апогея.
Желательно добавить переключение по кадровому импульсу. У меня без него было то зависание, то картинка портилась.
DonkeyHot
24.02.2018, 19:35
Так пойдёт?
П.С. Все необходимые для работы сигналы берутся с платы Апогея. На самой плате требуется удалить перемычку 78-79, соединяющую сигналы CRT /VSP и ROM3 /CS.
Версия не окончательная, так как планирую задействовать всю память (8КБ) для четырёх наборов по 128 символов.
для 128 вроде необходим 1кб, так что 8 комплектов спрайтов можно держать. Я примерно к похожей схеме пришел, заказал десяток 6264 для экспериментов. Но я думаю полную дешифрацию адреса делать на одной pal16 или ртшке. Кроме того I/O 6264 цепляется к двум однонаправленным буферам, переключающим выход на общую ШД (для записи в память) или на шину данных вг75 (на чтение) при наличии дешифрованного адреса и сигнала WE
Желательно добавить переключение по кадровому импульсу. У меня без него было то зависание, то картинка портилась.
Пока за два месяца не наблюдалось ни одного зависания.
для 128 вроде необходим 1кб, так что 8 комплектов спрайтов можно держать...
У меня 2КБ на один набор - до 16 линий на знакоместо.
DonkeyHot
26.02.2018, 16:53
у меня уже (пока еще) 3 версии плат - есть на чем экспериментировать. Скоро будут и оригинальные на ру3 и на ру5.
Версия не окончательная, так как планирую задействовать всю память (8КБ) для четырёх наборов по 128 символов.
Программируемый знакогенератор для Апогея с четырьмя одновременно отображаемыми наборами по 128 символов.
При записи в память знакогенератора старшие линии адреса (А11 и А12) выбираются сигналами С1 и С2 контроллера клавиатуры. При чтении - линии адреса выбираются через неиспользуемые для отображения биты 7 и 8 шины данных знакогенератора.
На скриншоте приведён пример, когда одновременно видны четыре набора символов - два набора алфавитов с псевдографикой и два набора составленных из спрайтов по мотивам Диззи.
Shumadan
02.04.2018, 23:24
О, хосподи! Когда уж вернёмся к ГОСТовскому начертанию схем?
О, хосподи! Когда уж вернёмся к ГОСТовскому начертанию схем?
Зачем? Им так удобно - никаких заморочек - использовать готовые буржуйские элементы - головой думать не надо.
Попытался перерисовать схему. Не знаю получилось "в стиле ГОСТ" или нет, смотрите сами.
Проект отлажен на макете и работает стабильно больше месяца. Дальше попробую портировать пару игрушек под "новые" возможности Апогея = ))
При чтении - линии адреса выбираются через неиспользуемые для отображения биты 7 и 8 шины данных знакогенератора
Извиняюсь, но я не сумел понять о чём здесь речь. Не поясните понятнее?
Непонятно как в этой схеме получается более 128-ми символов? Как на представленной картинке оказался и полный текстовый фонт (128 симв) и графические фигурки DIZZY? Ведь это возможно только при использовании атрибутов ВГ75, а на схеме этого не нашёл.
Графика от ZX на экране РК86 это круто. Побольше бы таких картинок, тогда может изготовители новоделов РК наконец поймут, что простейшее расширение ПЗУ фонта с РФ1 до 27256 (или загрузка фонтов) резко улучшают качество РК86. Если бы ещё и авторы эмуляторов РК86 добавили в свои эмуляторы коммутацию фонтов, то программирование для РК86 игр с графикой от ZX стало бы всем доступным.
И для графики сразу становится гораздо более желательной переделка РК86 на нормальный фонт шириной в 8 точек, тогда графику использовать проще. Не знал, что в Апогее применён фонт шириной в 8 точек.
Кстати, чтобы четыре атрибута ВГ75 остались для цвета, для оперативного переключения фонта разумно ввести пятый атрибут формируемый из LA0, LA1.
Попытался перерисовать схему
Схема не очень сложная. Тем не менее нужны и словесные пояснения по схеме и алгоритму.
Кто помнит логику работы JK-триггера, разве необходимо было ставить именно КМОП JK-триггер? Что за странная логика использования выхода INTE? Непонятно как запись в триггеры 74LS74, задающие номер фонта, производится сигналом VSP из ВГ75? Ведь этот сигнал от ВГ75 программно недоступен, это же просто сигнал гашения луча.
Зачем в качестве мультиплексора адресов 6264 применять буфер, а тем более АП5, у которого цоколёвка расчитана на двунаправленность (тогда соединяются соседние ноги)? Кстати, во всех имеющихся справочниках для LS244 нумерация входов-выходов второго буфера (B) зеркальная, относительно, изображённой у Вас. Вместо двунаправленных АП6 достаточно однонаправленных буферов или регистров с Z-выходом.
Потому удобнее и дешевле вместо четырёх АП5, применить четыре КП11, а вместо двунаправленных АП6 применить однонаправленный АП4 или регистр ИР22.
В любительской практике неразумно называть цепи в шинах цифрами, как сдуру требовал советский ГОСТ 70-тых годов. На порядок проще разбираться в схеме, если цепи обозначены осмысленными буквенно-цифровыми символами. На некоторых советских предприятиях вводились внутриотраслевые правила, допускающие буквенно-цифровые названия цепей, чтобы нормоконтроль, вынужденный руководствоваться ГОСТ-ом, не мог придраться.
Попробую ответить по порядку.
Извиняюсь, но я не сумел понять о чём здесь речь. Не поясните понятнее?
Непонятно как в этой схеме получается более 128-ми символов? Как на представленной картинке оказался и полный текстовый фонт (128 симв) и графические фигурки DIZZY? Ведь это возможно только при использовании атрибутов ВГ75, а на схеме этого не нашёл.
В Апогее, как и в других клонах Радио, ширина знакоместа 6 точек и старшие биты (7 и 8) в ПЗУ знакогенератора не используются (не выводятся на экран). При использовании в качестве знакогенератора микросхемы ОЗУ эти биты так же не будут задействованы при формировании изображения. Но физически они доступны и в них можно записать нули или единицы. Эту информацию можно использовать как раз для переключения старших адресов (А11 и А12) микросхемы ОЗУ.
Один из вариантов такой. В первой таблице у меня четыре пробела (коды $00, $10, $20 и $7F), но старшие биты во всех рядах этих пробелов равны 00b, 01b, 10b и 11b соответственно. При отображении такого пробела происходит "переключение" на другой набор символов путём изменения старших адресов знакогенератора. Так же все остальные символы в первой таблице и в трёх дополнительных содержат эти же значения (00b, 01b, 10b и 11b соответственно) для предотвращения отключения отображаемого набора раньше времени. В приведённом примере сначала отображается половина строки из первого набора, затем в середине строки стоит "пробел" с кодом $10 и поэтому дальше отображается вторая половина строки из второго. С картинками из Диззи тоже самое - в начале первых 4-х строк стоит пробел с кодом $30, а в начале последних - с кодом $7F. Эти картинки и есть содержимое третьего и четвертого наборов.
Кто помнит логику работы JK-триггера, разве необходимо было ставить именно КМОП JK-триггер? Что за странная логика использования выхода INTE?
Логика работы JK-триггера следующая. По положительному фронту С(Clock) если (JK==00) то состояние Q не меняется, (JK==10) Q = 1, (JK==01) Q = 0, (JK==11) Q = !Q.
В данном случае сигналы С1 и С2 контроллера клавиатуры подключены к J и K триггера, а сигнал INTE работает в качестве Clock. При этом сами сигналы С1 и С2 в оригинальной схеме никак не задействованы и если их не трогать, то по INTE мы включим/выключим альтернативный набор "родного" знакогенератора (на Апогее) - то есть никак не повредим программам использующим его. Программы которые будут работать с новым знакогенератором могут самостоятельно выставлять значения для С1 и С2 и выполнять серию команд EI DI.
Сигнал R(Reset) JK-триггера подключён к RES процессора, что обеспечивает его начальную установку при включении или по сбросу. При Q=0 на мультиплексоре адреса активны адресные линии процессора. При попытке записать что-нибудь в область ПЗУ1 ($F800-$FFFF) будет происходить запись в знакогенератор. В режиме записи старшие биты адреса (А11 и А12) выставляются сигналами С1 и С2 контроллера клавиатуры (таким образом у них здесь двойная функция).
Почему запись в триггеры 74LS74, задающие номер фонта, производится сигналом CRT VSP? Этот сигнал ВГ75 программно недоступен, это просто сигнал гашения луча.
Запись в D-триггер (74HCT74 в моём случае) происходит по инвертированному сигналу CRT CLK (а не CRT VSP). Таким образом в триггер попадают значения уже для следующего символа.
CRT VSP (который надо не забыть отрезать от ROM3 /CS) выполняет тут свою изначальную функцию - отключает знакогенератор во время гашения изображения.
Зачем в качестве мультиплексора адресов 6264 применять буфер, а тем более АП5, у которого цоколёвка расчитана на двунаправленность (тогда соединяются соседние ноги)? Кстати, во всех имеющихся справочниках для LS244 нумерация входов-вывходов второго буфера (B) зеркальная, относительно, изображённой у Вас. Вместо двунаправленных АП6 достаточно однонаправленных буферов или регистров с Z-выходом.
Потому удобнее и дешевле вместо четырёх АП5, применить четыре КП11, а вместо двунаправленных АП6 применить однонаправленный АП4 или регистр ИР22.
Все микросхемы я применял только из имеющихся в наличие дома. Именно поэтому JK-триггер отвечает за переключение мультиплексора. В свою очередь мультиплексор "собран" на микросхемах буфера из-за полного отсутствия у меня мультиплексоров. И с двунаправленными та же история. Аналогичную по функционалу схему можно собрать и на других элементах.
244-й элемент я отобразил так из-за удобства - так как он выполняет здесь функцию мультиплексора и так нагляднее видно что на входах и выходах.
В любительской практике неразумно называть цепи в шинах цифрами, как сдуру требовал советский ГОСТ 70-тых годов. На порядок проще разбираться в схеме, если цепи обозначены осмысленными буквенно-цифровыми символами. На некоторых советских предприятиях вводились внутриотраслевые правила, допускающие буквенно-цифровые названия цепей, чтобы нормоконтроль, вынужденный руководствоваться ГОСТ-ом, не мог придраться.
Честно говоря, рисую схему третий раз в жизни и с ГОСТами не знаком. Делал по подобию схемы Апогея что идёт в комплекте с компьютером. Тоже подумал что с названиями было бы намного легче "ползать глазами" по схеме (и в оригинальной уж точно). Для меня главное было проверить на практике работоспособность "теории". Попробую исправить и выложу ещё раз.
Чуть не по ГОСТу нарисовано. Позиционное положение микросхем внутри прямоугольника не пишется.
В любительской практике неразумно называть цепи в шинах цифрами, как сдуру требовал советский ГОСТ 70-тых годов. На порядок проще разбираться в схеме, если цепи обозначены осмысленными буквенно-цифровыми символами. На некоторых советских предприятиях вводились внутриотраслевые правила, допускающие буквенно-цифровые названия цепей, чтобы нормоконтроль, вынужденный руководствоваться ГОСТ-ом, не мог придраться.
Переделал. Так лучше?
HardWareMan
04.04.2018, 07:52
Переделал. Так лучше?
Но что изменилось? Ведь:
Чуть не по ГОСТу нарисовано. Позиционное положение микросхем внутри прямоугольника не пишется.
Оно пишется снаружи, рядом с номиналом. А еще управляющие входы обычно снизу (как у памяти), я про регистры и буферы.
Но что изменилось? Ведь:
Оно пишется снаружи, рядом с номиналом. А еще управляющие входы обычно снизу (как у памяти), я про регистры и буферы.
В предыдущей версии схемы, цепи в шинах были обозначены цифрами. Теперь буквами = ))
Позиционное положение это что?
За образец брал схему от Апогея - думал она то уж точно по ГОСТУ должна быть = ))
TomaTLAB
04.04.2018, 08:14
Дались вам эти ГОСТы. Никогда этот идиотизм не соблюдался, если нормоконтроль не злобствовал.
ГОСТа придерживались в той мере в которой он работать не мешал.
Еще вспомните, что и номиналы ни на принципиалку, ни на монтажку не проставлялись, только позиционные обозначения. А за номиналами - в специю лезь.
Мы смотрели схемы в журнале Радио и делали похоже. Я рисую в Altiume Designer'е и там библиотек по ГОСТу почти нет - рисую свои. А так если схема нарисована по буржуйски, я не злорадствую, принимаю как есть.
Попробую ответить по порядку...
Кое что прояснилось, но вопросы остались.
у меня четыре пробела (коды $00, $10, $20 и $7F), но старшие биты во всех рядах этих пробелов равны 00B, 01B, 10B и 11B соответственно. При отображении такого пробела происходит "переключение" на другой набор символов путём изменения старших адресов знакогенератора
Эти коды, отображаемые на РК86 пустотой, используются в некоторых играх РК86, например, в одном из XONIX, чтобы маркировать экранную позицию (при подсчёте площади).
Из этого понял, что вывод символа с таким кодом, приводит к тому, что по концу вывода такого пробела в триггеры LS74 защелкиваются два бита (которые подаются на A11, A12 псевдо-ПЗУ фонта), что приводит к тому, что следующий символ берётся из фонта, чей номер защелкнулся в этих триггерах.
Также понятно, что раз все биты D6, D7 во всех символах каждого из 4-х фонтов выставлены в соответствие с номером фонта, то до очередного "управляющего" пробела или конца строки, последующие символы будут браться из того же фонта, т.к каждый символ задавая битами D6,D7 фонт следующего символа, сохраняет текущий фонт.
Это идея как бы самоподдерживаемости включённого фонта, освобождающая атрибуты от задачи коммутации фонта. Из-за этого в начале каждой строки (в области бордюра) надо вставлять соответствующий "управляющий" пробел или вообще весь бордюр слева составлять из таких "управляющих" пробелов.
Но не понял зачем понадобилась сама идея самоподдержки текущего фонта, т.е зачем графикой каждого выводимого символа с помощью битов D6, D7 задавать номер фонта следующего по горизонтали символа. После включения соответствующим пробелом триггеров выбора нужного фонта, их состояние не меняется, а гашение экрана удобно делать запретом /CS "ПЗУ" фонта и привязкой его выходов на +5В (т.к фонт инверсный).
Зачем нужен буфер D6 на выходе ОЗУ фонта ?
Для коммутации фонта кодом самого символа я предлагал стандартные для этого коды 0E и 0F. Как это и делается в фирменных терминалах. А вообще на идее коммутации фонта кодом самого символа можно поиметь 32 фонта, переключаемых кодами 00...1F. Недостаток - для переключения фонта выводится пустое знакоместо, что для работы с текстом не особо вредит, а вот для графики фатально.
http://ipic.su/img/img7/fs/GrafikanaRK86.1522841282.jpg
По принципу, как Вы вывели спрайты, freddy реализовал полноценную графику на базе ВГ75. Там для вывода поля в 2 знакоряда, т.е символьного куска экрана 64*2, со знакоместами 8*8, что из двух знакорядов даёт графическое поле (64*8)x(2*8)= 512x16, в соответствующие экранные позиции заносятся числа 0, 1, 2, 3... 127. Благодаря чему графика каждого из 128-ми символов фонта становится графикой одного экранного квадратика 8*8. ОЗУ фонта становится ОЗУ экрана, а старое текстовое ОЗУ экрана при этом играет роль счётчиков видеогенератора.
Четыре атрибута позволяют последовательно включать по экрану 16 таких полей 512*16 следующих один под другим, что и даёт полноценный графический экран 512*256 с удобным экраном в виде последовательно лежащих в "экранном ОЗУ" квадратиков 8*8. Но выгоднее с'экономить атрибуты для цвета, а для адресации по рядам использовать счётчик 561 ИЕ10 инкрементируемый по ССИ.
Кто-нибудь знает передаётся ли код (точнее его 7 битов) аппаратного графического символа (для рисования рамок) на выходы CC0...CC6 ВГ75 ?
Кое что прояснилось, но вопросы остались.
Эти коды, отображаемые на РК86 пустотой, используются в некоторых играх РК86, например, в одном из XONIX, чтобы маркировать экранную позицию (при подсчёте площади).
В данном случае у нас программируемый знакогенератор и эти коды "заняты" не навсегда, а только для одной конкретной программы. В другой программе автор может выбрать свои собственные коды. Например если мы запускаем старую игру/программу ничего не знающую про новые возможности знакогенератора, то эта программа никак и не сможет его (знакогенератор) включить. А в новой программе можно использовать свой собственный набор отображаемых символов и условных кодов для переключения, даже совпадающих со служебными или вообще какими-угодно. По завершении работы такой программы (или по ресету) всё равно включится системный знакогенератор и при запуске того же Зоникса мы увидим старую добрую символьную картинку.
- - - Добавлено - - -
Зачем нужен буфер D6 на выходе ОЗУ фонта ?
Буфер D6 разделяет шины данных статического ОЗУ и системного знакогенератора. По умолчанию у нас подключён системный знакогенератор и с его выходов мы получаем байт для следующего отображаемого символа. Во время записи в программируемый знакогенератор откроется буфер D5 и на шину данных статического ОЗУ поступит новый байт. Если не будет буфера D6, то возможен конфликт на шине.
Возможно я где-то и ошибаюсь, поправьте если не так.
- - - Добавлено - - -
Попробую прояснить некоторые моменты. Изначально данное изделие планировалось использовать именно с Апогеем. Одно из (главных для меня) условий - минимум изменений на печатной плате компьютера. В этом варианте единственная обязательная доработка это удаление перемычки 78-79, заботливо предусмотренной разработчиками. Остальное это подключение проводами платы устройства к обозначенным на схеме выводам.
Применение символа шириной 8 точек потребовало бы переделку (или установку нового) счётчика. Биты 7 и 8 у регистра сдвига намертво посажены на +5 вольт и даже перерезать дорожку там невозможно (только откусывать и отгибать ножки микросхемы). Вывод по умолчанию осуществляется через шестой бит, а не восьмой - тоже потребовались бы переделки на печатной плате.
Так что в данном случае это самое простое (и я надеюсь что элегантное) решение, продиктованное имеющимися ограничениями = ))
- - - Добавлено - - -
Кто-нибудь знает передаётся ли код (точнее его 7 битов) аппаратного графического символа (для рисования рамок) на выходы CC0...CC6 ВГ75 ?
Да, передаётся. Это легко проверить на реальном РК или клоне. Если занести такой символ в экранную память, то отобразится символ соответствующий младшим семи битам.
Попробую сделать скриншот...
В самой верхней строке 12 спецсимволов с кодами от 0000 до 1011
Использование битов D6, D7 в самой графике фонтов для формирования номера фонта хуже, чем любое другое решение, т.к для удобного использования ZX-графики лучше иметь переделку на полноценный фонт шириной в 8 точек.
Вам пришлось конвертировать байтовую графику от ZX в графику по 6 битов на экранный байт ? И даже при 6-ти битовом фонте лучше эти два бита D6, D7 истратить под что-то полезное, например, цвет с бОльшим разрешением (свой цвет на каждую линию знакоместа, вместо общего цвета на все 8 линий знакоместа).
Не лучше ли перенести область загрузки фонта в область 8400...BFFF ? Это позволит постепенные дальнейшие доработки, в частности позволит провести макетирование полноценной графики.
Тогда, истратив всего несколько проводков, чтобы ввести коммутацию ОЗУ-шных знакогенераторов атрибутами ВГ75, получится полноценная графика. Отмакетировав с атрибутами, далее можно освободить атрибуты для цвета и добавив счётчик 561 ИЕ10, инкрементируемый по ССИ, получить уже цветную графику с объёмом экранного ОЗУ в 8...12 кб.
В данном случае у нас программируемый знакогенератор и эти коды "заняты" не навсегда, а только для одной конкретной программы.
Да, использование в играх пробела 7F не повредит, если по сбросу грузить фонт, в котором все биты D6, D7 =1.
Не понял почему "родной" фонт прошитый в ПЗУ РФ2 остался и для борьбы с ним пришлось вводить буфер D6. Для макетирования достаточно его деактивировать подачей "1" на его /CS. А в окончательной конструкции этого ПЗУ вообще не должно быть, - по сбросу из ПЗУ (или ROM-диска) в ОЗУ фонта грузится базовый фонт РК86.
Если занести такой символ в экранную память, то отобразится символ соответствующий младшим семи битам.
Я так и думал, т.к это упрощает микросхему. Это можно использовать, чтобы из выходов LA0, LA1 управляемых графическими символами получить больше, чем один атрибут.
Но отобразится не любой символ и некоторые символы не целиком, т.к во время вывода символа графики в некоторых символах до, а в некоторых после линии заданной, как линия подчёркивания, формируется активный VSP, гасящий луч.
Использование битов D6, D7 в самой графике фонтов для формирования номера фонта хуже, чем любое другое решение, т.к для удобного использования ZX-графики лучше иметь переделку на полноценный фонт шириной в 8 точек.
Не лучше ли перенести область загрузки фонта в область 8400...BFFF ? Это позволит постепенные дальнейшие доработки, в частности позволит провести макетирование полноценной графики.
Не понял почему "родной" фонт прошитый в ПЗУ РФ2 остался и для борьбы с ним пришлось вводить буфер D6. Для макетирования достаточно его деактивировать подачей "1" на его /CS. А в окончательной конструкции этого ПЗУ вообще не должно быть, - по сбросу из ПЗУ (или ROM-диска) в ОЗУ фонта грузится базовый фонт РК86.
Основная цель была разработать программируемый знакогенератор для Апогея, а не переделать Апогей.
У Апогея жёстко прибито знакоместо на 6 точек - ничего с этим уже не поделать (не кромсая компьютер). Единственная доступная область памяти куда можно "безболезненно" подсунуть знакогенератор это $F800-$FFFF - все необходимые сигналы генерируются на плате, а ПДП не мешает, так как "висит" по адресам $F000-F7FF. Родной фонт не планировалось удалять или изымать - он неотъемлемая часть компьютера, а плата знакогенератора всего-лишь довесок. По (моей) логике работы родной фонт постоянно включён, когда выключен "новый" знакогенератор.
Повторю - основная идея была сделать плату, которую можно поставить в любой Апогей при этом ничего не изменяя и не переделывая в самом Апогее (кроме удаления перемычки и соединения проводами платы знакогенератора с платой Апогея). То есть любой владелец Апогея может это повторить (при желании), а владелец клона может адаптировать некоторые идеи под свой клон (опять же при наличие желания).
Наверное в каком-то другом решении использовать биты D6 и D7 это неправильно. Но насколько я могу видеть - в "классических" решениях они вообще никак не используются. И в первой версии знакогенератора я их тоже не использовал. Из доступных 8 килобайт в микросхеме ОЗУ бесполезно пропадали 6 килобайт. Поэтому были попытки найти решение для использования этой памяти под дополнительные наборы символов, а так же найти решение для переключения этих наборов. Использовать LA0 и LA1 для переключения я не стал, так как не совсем разобрался как они работают и не был уверен в конечном результате. Использовать "ранее никому не нужные биты" показалось самым оптимальным решением. Они и так никому не нужны - пусть послужат делу.
П.С. Возможно мне стоило изначально создать тему "Программируемый знакогенератор для Апогея", чтобы не вводить в заблуждение владельцев и пользователей классического РК или других клонов.
Раз уж тут собрались знатоки ВГ75, то может быть кто знает, отличается ли она от i8275 или же является ее полным клоном? Равно как и ВТ57 против i8257.
- - - Добавлено - - -
Заодно, может быть кто знает что-то о следующих вещах (в инструкции к 8275 описаны, но не поняты):
1. Что такое 'Spaced Rows'? Этот флаг может быть установлен в команде Reset.
2. Что означает вот эта сноска:
http://d.radikal.ru/d19/1804/71/f180759d472d.png
3. Что делает Preset Counter Command?
4. Как в режиме Character Attribute Codes контроллер вычисляет, где находится середина знакоместа? (позиция Underline). Просто делит параметр 'число линий на строку' пополам?
П 2. Всё просто. uuuu - номер строки подчёркивания. Если больше 7 - то верхняя и нижняя строки растра в символах бланкируются, если меньше- то нет. Этот номер строки и определяет п4.
1. Что такое 'Spaced Rows'? Этот флаг может быть установлен в команде Reset.
На первой картинке экран "здорового человека" - стандартный экран РК86 - три пустые строки сверху, 25 видимых строк и две пустые снизу, ну и плюс одна строка на кадровый синхроимпульс (30+1). Занимает в памяти 78*30=2340 байт.
На второй - экран "курильщика" - режим с включённым атрибутом Spaced Row - две пустые строки, 12 отображаемых и одна снизу пустая, так же плюс одна строка на кадровый импульс (15+1). Занимает в памяти ровно в два раза меньше 78*15=1170 байт. В этом режиме после каждой строки символов ВГ75 генерирует ещё одну, но полностью пустую строку - получается такой "через-строчный" режим.
freddy реализовал полноценную графику на базе ВГ75.
что и даёт полноценный графический экран 512*256 с удобным экраном в виде последовательно лежащих в "экранном ОЗУ" квадратиков 8*8. Но выгоднее с'экономить атрибуты для цвета, а для адресации по рядам использовать счётчик 561 ИЕ10 инкрементируемый по ССИ.
Немного уточню. У меня разрешение 640x400@70Гц, самый, что ни есть, VGA-шный VGA. Pixelclock стандартный 25Мгц. Видеопамять 32к с одновременным доступом процессора и видеоконтроллера. Они даже не знают о существовании друг друга :) При этом подразумевается, что процессор и видеоконтроллер работают асинхронно, доступ к видеопамяти осуществляется с помощью специального сиквенсора, переключающего шины управления, адреса и данных видеопамяти в определенной последовательности. Fillrate получается 1,6Мб/c, что дает возможность прокачать 50 раз в секунду 32-х Кб экран. В случае с 8080 50FPS- запредельный праметр с большим запасом на разгон/апгрейд процессора.
На настоящий момент - эта технология признана бесперспективной, мой компьютер с 80-м процессором на 3,6Мгц ворочал такой графикой со скрипом. Если двигать фигурки персонажей 128х32 пикселя то нормуль, а если перерисовывать экран, то начинается драма. Видно как прорисовывается. Был сделан вывод, что видеокарта не для этой машины, а также нужен другой подход.
Вот теперь пора и по РК-шке вставить свои 5 копеек. Постараюсь высказаться кратко и сильно не тролить кривость авторов РК-шки.
В общем то, если говорить о классике, на оригинальной печатной плате с 32к на борту, то графика ей и не нужна. Она сильно тормознее 3,6Мгц, поэтому там совсем будет слайд шоу, даже в телевизионном разрешении. Она то и текст скролит с тормозами. Поэтому ее нужно в первую очередь хоть как то ускорить, а графику ей лепить уже потом. Как разогнать процессор, можно посмотреть у меня. Избавиться от тормозов на время DMA циклов, можно многочисленными способами. Мой способ - изолированная шина видеокарты, на которой лабает DMA, с доступом со стороны процессора через спец буфер, используя механизм приостановки DMA с захватом у нее захваченной шины :)))) На стандартной плате это делать бесполезно, уйдут километры МГТФа. Проще слепить новодельную РК, ну тогда уже с исправлением остальных косяков. Будет ли такая РК-шка той РК-шкой, что раньше? Вот в чем вопрос!
Наверное не будет... Нужна ли она в таком виде кому то?
Эх.. ну и немного технического троля на счет вышеупомянутого "другого подхода". Спасти РК-шку сможет только чудо в виде 2D-акселя. Для этого нужно даблбуферинг. С одного буфера ВГ-шка будет разворачивать кадр, прикидываясь счетчиком адресов и генератором синхросигналов. А в другом видеобуфере будет рендериться картинка с помощью самодельного GPU. Его задача сканировать координаты спрайтов, сравнивая с текущими координатами в видеобуфере и, при совпадении, из спрайтовой памяти быстро перелить данные в видеобуфер. Потом по сигналу VRTC буферы меняются местами. Хватит 2-3 плоскости спрайтов. Тайлы можно делать спрайтами :) Все это можно осилить 3-мя способами: на логике, на FPGA, на STM32 :)
сорри за офтоп, просто увидел тему, решил заглянуть :)
что дает возможность прокачать 50 раз в секунду экран в 32 кб...
Не существует 8-ми разрядки способной обновить экран в 32 кб за 1/50 секунды. РК за 1/50 секунды не может обновить даже чисто текстовый экран, хотя он имеет размер в 20 раз меньший.
Если двигать фигурки персонажей... то нормально, а если перерисовывать экран, то начинается драмаДелать игры в полной графике задача не стоИт.
Даже если сделать в РК полноценную графику, то нет смысла для игр использовать такой режим. Для упрощения и ускорения игр выгоднее красивые спрайты выводить тайлами в текстовом режиме (здесь тайл это графический квадратик 8*8 с произвольной графикой). Вроде бы быстродействия хватит даже для написания красивых игр на ЯВУ.
О полной графике речь зашла потому, что сделав загрузку фонта и поставив достаточный размер памяти, остаётся припаять 4 проводка, чтобы получить полностью графический режим.
При наличии загрузки фонтов полная графика для игр не особо нужна. И для текстообработки это тоже не надо. Это интересно лишь мне, чтобы сделать для РК86 GUI. Так при фонте 8*8 (что даёт экран 512*256) и турбировании до 2.5 МГЦ реального такта, получается ЭВМ более удобная для GUI, чем Специалист, где и скорость ниже и экранчик маленький.
оригинальной печатной плате с 32К на борту графика не нужна. РК сильно тормознее 3,6 Мгц, поэтому [в режиме полной графики] там будет слайд-шоу. Потому РК нужно в первую очередь хоть как то ускорить, а графику лепить уже потомРК уже турбировали простой заменой кварца в ж.РАДИО 01.1991. При кварце 27 МГЦ, такт КР580 составляет 3 МГЦ (а эффективный такт ~2.5 МГЦ), хотя на практике из-за слабости шины используют кварц 22.5 МГЦ, что даёт реальный такт ~2 МГЦ.
Спасти РК-шку сможет только чудо в виде 2D-акселяВы ведёте речь о ужасно сложной и громоздкой конструкции. Я сторонник только простых доработок. Платка для загрузки фонтов - это уже и-так сложнее, чем хотелось бы.
Акселератор действительно нужен, но только не акселератор видео, а акселератор шины (http://zx-pk.ru/threads/27125-modulnyj-radio-86rk.html?p=902702&viewfull=1#post902702). Это делается путем подключения через розетку CPU внешней платки с Z80B на такте 10 МГЦ со своим скоростным ОЗУ. При этом экранный буфер 7700...7FFF остаётся в РУ5-тых, для доступа к экрану и В/У вводятся такты WAIT. Попутно такая плата будет улучшать архитектуру, давая сплошные 48К ОЗУ плюс 15К ПЗУ. Реальное быстродействие такого РК будет ~8.5 МГЦ.
3. Что делает Preset Counter Command?
Эта команда выключает отображение (если оно включено) и сбрасывает горизонтальный и вертикальный счётчики (что соответствует началу экрана). В этом положении счётчики остаются до получения контроллером любой другой команды.
Зачем это нужно или как это можно использовать не очень понятно.
Ниже привожу тест (для Апогея), по первому нажатию вызывающий команду Preset Counter, а по второму Разрешение Прерываний и так по кругу. По первому нажатию изображение пропадает, по второму появляется, но со смещённым экраном по вертикали. Это происходит потому что неизвестно в какой момент пришла команда Preset Counter и соответственно следующая строка отображается уже первой при повторном запуске изображения.
program_begin:
call $f803
mvi a, $e0
sta $ef01
call $f803
mvi a, $a0
sta $ef01
jmp program_begin
Не существует 8-ми разрядки способной обновить экран в 32 кб за 1/50 секунды.
А при чем здесь существование 8-ми разрядки к характеристикам шины видеокарты??? Делалось оно не только под унылые 8-ми разрядки. И вобще существует - Z80@20Мгц. Еще есть всякие PC, там у них 386, 486 они могут и быстрее. Я ее как раз и делал по самодельный PC. Потом забил, из-за не желания получить частично совместимое УГ, да еще потратив на это не малые усилия.
Я сторонник только простых доработок.
Ну... "трактор знает куда едет" (с)
под категорию "простое" моя конструкция не попадает :(
П 2. Всё просто. uuuu - номер строки подчёркивания. Если больше 7 - то верхняя и нижняя строки растра в символах бланкируются, если меньше- то нет. Этот номер строки и определяет п4.
Не совсем понятно, как это выглядит и зачем.
И, самое главное, как это связано с пунктом 4, так как предполагается, что курсор - это самая нижняя линия знакоместа, тогда как в режим псевдографики underline - это средняя линия знакоместа.
Не совсем понятно, как это выглядит и зачем.
И, самое главное, как это связано с пунктом 4, так как предполагается, что курсор - это самая нижняя линия знакоместа, тогда как в режим псевдографики underline - это средняя линия знакоместа.
По идее, не следует использовать одновременно подчёркивание обычных символов и псевдографические (аппаратные) символы.
Например при отображении только текста имеет смысл ставить номер линии подчёркивания в самый низ (если нужно что-либо подчеркнуть). Если же мы используем псевдографику (а это обычно какие-то углы и другие элементы рамок), то номер линии подчёркивания ставим где-то посередине. Контроллер не вычисляет середину символа, он её берёт из заранее заданной в параметре uuuu.
Если линия подчёркивания установлена посередине, то для обычного текста она уже выглядит как перечёркивание. В тоже время и аппаратный курсор в виде подчёркивания будет посередине символа, поэтому (если в данном случае очень необходим курсор) следует использовать курсор в виде инверсного знакоместа - обычного или мигающего.
Надо бы это все проверить на реале)
Не совсем понятно, как это выглядит и зачем.
И, самое главное, как это связано с пунктом 4, так как предполагается, что курсор - это самая нижняя линия знакоместа, тогда как в режим псевдографики underline - это средняя линия знакоместа.
Ну,вот так устроено. Я в 1988г проводил эксперименты на ВГ75. Вы правильно понимаете. Хотите хардвар графику-двигаете подчеркивание на середину. Нужен курсор (подчеркивание)-вниз.
Ну,вот так устроено
Но это даже не обьяснить логически)
Зачем если у нас, например, высота знакоместа более 8, и мы хотим иметь курсор, то у нас обязательно будет бланкироваться верхняя и нижняя линяя знакоместа. Зачем? Кому это надо? )
Не, курсор может быть и на 10й строке, он отобразится. Между символами из знакогенератора вставляются 2 пустые линии растра, чтоб не тратить емкость пзу знакогенератора на промежутки.
Зачем если у нас, например, высота знакоместа более 8, и мы хотим иметь курсор, то у нас обязательно будет бланкироваться верхняя и нижняя линяя знакоместа. Зачем? Кому это надо? )
Это если только мы хотим иметь курсор в виде подчёркивания. Если мы будем использовать курсор в виде инверсного знакоместа, можно отменить бланкирование верхней и нижней линии.
Но никто не ответил, зачем это бланкирование)
Экономии ПЗУ на промежутки это не дает, т.к. бланкирование только в знакоместе с курсором.
А если это распространяется на весь экран, то все равно ПЗУ не экономится, т.к. адресация забланкированных адресов в ПЗУ все равно производится. Если только не делать дополнительную схему, исключающую это.
Бланкирование строк на всем экране, естественно. В РК, например, в пзу зашито 8 строк каждого символа, а на экране - 10. (В 10й - курсор). Экономия пзу.
А зачем - чтоб строки символов не слипались. Красиво.
Бланкирование строк на всем экране, естественно. В РК, например, в пзу зашито 8 строк каждого символа, а на экране - 10. (В 10й - курсор). Экономия пзу.
А зачем - чтоб строки символов не слипались. Красиво.
ага а потом выясняется что псевдографикой рисовать нельзя
картинки полосатые
Бланкирование строк на всем экране, естественно. В РК, например, в пзу зашито 8 строк каждого символа, а на экране - 10. (В 10й - курсор). Экономия пзу.
А зачем - чтоб строки символов не слипались. Красиво.
Т.е. ВГ75 не ведет счет на LC0..LC3 для строк, бланкированных таким образом?
- - - Добавлено - - -
ага а потом выясняется что псевдографикой рисовать нельзя
картинки полосатые
При этой 'экономии' половина РФ2 в РК86 не используется! Т.е. только 1кб от 2кб ПЗУ.
Хотя могли бы при той же комплектухе напихать символы высотой в 10 пикселей (актуально для неразрывной псевдографики).
Т.е. ВГ75 не ведет счет на LC0..LC3 для строк, бланкированных таким образом?
Во время бланкированных строк там может быть любая информация, но выход видео заблокирован сигналом "Гашение". Первая отображаемая строка символа считается от 0.
При этой 'экономии' половина РФ2 в РК86 не используется! Т.е. только 1кб от 2кб ПЗУ.
Хотя могли бы при той же комплектухе напихать символы высотой в 10 пикселей (актуально для неразрывной псевдографики).
В РК для знакогенератора использовалась РФ1 - 1кб. Посмотрите схему.
В РК для знакогенератора использовалась РФ1 - 1кб. Посмотрите схему.
Значит у меня схема какого-то более нового РК, т.к. там РФ2.
Тады ой.
- - - Добавлено - - -
Во время бланкированных строк там может быть любая информация, но выход видео заблокирован сигналом "Гашение". Первая отображаемая строка символа считается от 0.
Я имею в виду, что счет линий при таком бланкировании идет примерно так: 0 (?), 0, 1, 2, 3, 4, 5, 6, 7, 8 (?).
... счет линий при таком бланкировании идет примерно так: 0 (?), 0, 1, 2, 3, 4, 5, 6, 7, 8 (?).
Именно так.
Значит у меня схема какого-то более нового РК, т.к. там РФ2.
А на моей схеме написано, что она перерисована с журнала Радио, автор prusak.
При этом РФ1 почему-то преобразовалась в РФ2.
Поэтому всегда надо смотреть только в оригинал. В перепечатках/копиях бывают свои неточности/ошибки.
Shumadan
07.04.2018, 20:59
В журнальный версии знакогенератор на РФ1. В Микроше уже стоял РФ2. Там дополнительно зашит строчный шрифт. Непонятно какой экономией руководствовались авторы. РФ2 и тогда была более распространенной и доставаемой)
Я имею в виду, что счет линий при таком бланкировании идет примерно так: 0 (?), 0, 1, 2, 3, 4, 5, 6, 7, 8 (?).
Именно так.
За порядок счёта отвечает параметр М.
Если он равен 0, то счёт идёт так - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 и затем опять 0, 1 и тд. Во время отображения линий 0 и 9 активируется сигнал VSP (гашение видео), который отключает знакогенератор, а на подтянутой к питанию шине данных знакогенератора будет единица (что равнозначно чёрной линии точек).
Если параметр М равен 1 (как в РК86), то счёт идёт так - 9, 0, 1, 2, 3, 4, 5, 6, 7, 8 и затем снова 9, 0 и тд. VSP будет активен во время отображения линий 9 (верхней) и 8 (нижней). Если отключить бланкирование линий (uuuu меньше 8), то можно увидеть что над символом отображается линия 1 (она же 9), а под символом линия 8 (она же 0).
Если параметр М равен 1 (как в РК86), то счёт идёт так - 9, 0, 1, 2, 3, 4, 5, 6, 7, 8 и затем снова 9, 0 и тд. VSP будет активен во время отображения линий 9 (верхней) и 8 (нижней). Если отключить бланкирование линий (uuuu меньше 8), то можно увидеть что над символом отображается линия 1 (она же 9), а под символом линия 8 (она же 0).
Четко) Все сходится)
Документация очень скудная, и фраза 'смещение счета на 1' - может быть понята очень по разному. Куда смещен? В плюс или в минус? С чего начинается счет? И т.д. А из этого теста все сразу понятно.
- - - Добавлено - - -
Еще вопрос по ВГ75 в РК86 - обязательно ли неотображаемые поля экранной области должны быть заполнены пробелами? В какой-то статье авторв РК86 говорилось, что нужно заполнять пробелами из-за упрощенного формирования смеси кадровых и строчных импульсов.
Titus, ВГ75 хорошо документирована. Шахнов, "Микропроцессоры и микропроцессорные комплекты", том 1. Я по этой книге в 1988г программировал ВГшку. Вот, например, стр.125. Всё вроде понятно.
64941
Еще вопрос по ВГ75 в РК86 - обязательно ли неотображаемые поля экранной области должны быть заполнены пробелами? В какой-то статье авторв РК86 говорилось, что нужно заполнять пробелами из-за упрощенного формирования смеси кадровых и строчных импульсов.
Нет, не обязательно. Можно "схитрить" и использовать специальные символы F1 (Конец строки - Стоп ПДП) и F3 (Конец кадра - Стоп ПДП). Три верхние пустые строки можно заменить на шесть байт F1,00,F1,00,F1,00. Шесть пустых символов в конце каждой строки можно заменить на два байта F1,00 и в последней строке на F3,00 (это позволит избавиться от двух нижних пустых строк). Так же в параметрах инициализации контроллера ПДП надо указать другой размер пересылаемых данных (меньше на сэкономленное количество байт).
А вот восемь пробелов слева убирать никак нельзя.
... обязательно ли неотображаемые поля экранной области должны быть заполнены пробелами?
Обязательно, просто необходимо. Каждый "не пробел" - и вся строка тёмная. Или вообще срывается синхронизация.
Titus, ВГ75 хорошо документирована. Шахнов, "Микропроцессоры и микропроцессорные комплекты"
Наврал я. Нашел и в буржуйской документации все тоже самое.
SegaBoy, :) "Ты и я - мы оба правы!" (c) Пугачева
А вот восемь пробелов слева убирать никак нельзя.
Иначе?
Можно скриншот, как срывается синхронизация из-за непробелов в конце какой-то строки?
- - - Добавлено - - -
Да, и самое главное, за счет чего срывается синхронизация? Ведь все равно во время HRTC активен сигнал VSP.
Titus, тут не скриншот, тут настоящий комп рк86 нужен, чтобы это увидеть и покрутить. От используемого телевизора очень зависит, как он отобразит испорченный видеосигнал.
А вот восемь пробелов слева убирать никак нельзя.
Иначе?
Иначе изображение будет сдвинуто влево и первые восемь символов не влезут в экран.
Да, и самое главное, за счет чего срывается синхронизация? Ведь все равно во время HRTC активен сигнал VSP.
скриншот, тут настоящий комп рк86 нужен
Скриншот с настоящего РК, разумеется.
Помнится, когда я на настоящем РК писал в экранную область какой-то атрибут, из-за чего весь экран начинал плавно циклически ехать вбок (из-за того, что размер экранной области увеличился на 1, а ПДП не был перепрограммирован под новый размер). При этом, боковые пробелы, соответственно, уезжали со своего места, а на их место приезжала другая информация, но не помню, чтобы синхра срывалась. Все плавненько циклично ехало.
ВГ75 в рк86 включена не по даташиту. HRTC и VRTC задействованы как синхроимпульсы, а гашение обратного хода реализовано записью пробелов в начало строки/кадра.
Иначе изображение будет сдвинуто влево и первые восемь символов не влезут в экран.
Почему?
Почему?
Потому что в телевизионной сигнале должны следовать синхроимпульс, затем front porch (извиняюсь, не помню как это на русском называется), затем что-то вменяемое/отображаемое и затем back porch. На всё это дело есть тайминги. И вот первые восемь пробелов в строке как раз выполняют роль front porch. И если мы там что-то разместим или сдвинем наш экран влево, то это изображение как раз и не будет видно.
Манипуляциями с командами Стоп ПДП мы можем убрать из экрана вертикальный front и back porch, а так же горизонтальный back porch, но они по прежнему будут присутствовать в видеосигнале. Потому что вместо пробелов в экранной памяти ВГ75 будет сама "генерить" пробелы.
Потому что вместо пробелов в экранной памяти ВГ75 будет сама "генерить" пробелы.
Каким образом?
Каким образом?
В параметрах инициализации ВГ75 мы оставим 78 символов в строке и синхроимпульс 8 символов. А так же 30 строк в кадре и синхроимпульс 1 строка. То есть сохраним пропорции для нормального отображения телевизионного кадра (310 строк по 516 точек). Получив спецсимвол с командой Стоп ПДП, ВГ75 прекращает запрашивать символы у контроллера ПДП, но продолжает формирование заданных нами 78 символов в строке. Что там при этом на выходах СС6..СС0 я не проверял, изображение погашено сигналом VSP.
- - - Добавлено - - -
Можно скриншот, как срывается синхронизация из-за непробелов в конце какой-то строки?
Заполнил всю экранную область символами, даже ту которая изначально заполняется пробелами. На моём телевизоре синхронизация не срывается, просто часть изображения не влазит в экран.
Заполнил всю экранную область символами, даже ту которая изначально заполняется пробелами. На моём телевизоре синхронизация не срывается, просто часть изображения не влазит в экран.
Скриншот в студию.
Еще вопрос по ВГ75 в РК86 - обязательно ли неотображаемые поля экранной области должны быть заполнены пробелами? В какой-то статье авторв РК86 говорилось, что нужно заполнять пробелами из-за упрощенного формирования смеси кадровых и строчных импульсов.
Скриншот в студию.
http://zx-pk.ru/threads/27478-sekrety-i-tryuki-programmirovaniya-(v-tom-chisle-i-igr)-dlya-rk-86.html?p=905294&viewfull=1#post905294
http://zx-pk.ru/threads/27478-sekrety-i-tryuki-programmirovaniya-(v-tom-chisle-i-igr)-dlya-rk-86.html?p=906498&viewfull=1#post906498
http://zx-pk.ru/threads/27478-sekrety-i-tryuki-programmirovaniya-(v-tom-chisle-i-igr)-dlya-rk-86.html?p=908067&viewfull=1#post908067 (ссылка в сообщении)
Ссылка на некоторые результаты (не вечная).
Вот это показалось интересным, только не совсем понятно, к какому тесту данные видеозаписи относятся.
А, понял, к какому.
Заполнил всю экранную область символами, даже ту которая изначально заполняется пробелами. На моём телевизоре синхронизация не срывается, просто часть изображения не влазит в экран.
Хотя вру, срывается. Опытным путём выяснил что это зависит от того, каким символом заполнить экран.
DonkeyHot
20.05.2018, 20:40
Вопрос, какую глубину цвета способен переварить 580 проц без тормозов скроллинга?
Вопрос, какую глубину цвета способен переварить 580 проц без тормозов скроллинга?
Вопрос слишком абстрактен. В таком виде на него нет четкого ответа.
Все равно, что спросить - сколько человек может перевезти жигули, чтобы бензин тратился не сильно.
Один из ответов:
Если скроллинг аппаратный - то любую глубину цвета)
DonkeyHot
23.05.2018, 05:41
Аппаратный есть ли смысл городить. Я вообще склоняюсь к идее даже цвет не делать. Помню на специалисте скроллинга всего экрана волнами был.
Идея под РК проста и позаимствована с двк - второй контроллер с отдельным полем графики наложен на текст. Это обеспечит совместимость и графику. Страничная адресация в окне 2к на поле ПЗУ монитора, как я ранее писал, ну и ПЗУ зг переключается на ру10 с загружаемыми спрайтами которая доступна через вв55
Единственное что хотелось бы сделать по уму это сигнал hsync vsync, размер 8х8 символа на экране
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot