Игровая консоль радиолюбителя по схеме РК86

Не ошибаюсь. Сам пользуюсь этим способом и он тоже. И у нас точно ВТ57. Как работает описал выше для ведущего специалиста. Не написал только что метод работает сразу для всего экрана. Окно так не покрутишь. Даже для Виктора демку выкладывал, там кнопочками можно было скролить экран туда сюда, писать при этом как в не видимую так и видимую область.

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

А ещё когда то давным давно был риск процессор на борту, вот ним я все рутинные операции и ускорял, у него даже был отдельный командный интерфейс. А помните как из-за него меня обвинили в не спортивном поведении? Во смеху то было!

freddy пишет:Ириша? У неё хоть нормальный графон по меркам 8080 возможен.

Да, экран 320*200 на примере IBM PC XT показал, что такой размер экрана даже при всего 4-х цветах (при цвете на каждый пиксель) это идельно для игр.

Но даже с идеальным для игр экраном 320*200 с родной иришиной скоростью (при включённом цвете) в ~1 МГЦ "Принц Персии" выйдет доволько тормозным. Чтобы сровняться с Apple-IIe применённым в оригинальной платформе "Принца Персии" нужен эффективный такт КР580 в 2.75 МГЦ (при Z80 м.быть чуть менее) и это ещё не считая торможение при доступе процессором в экран ИРИШИ (что временами стопорит процессор аж на 40 мкс, что больше, чем в РК86).

Вот, если сделать ИРИШЕ альтернативную плату ЦП на Z80 с клоком в 8...9 МГЦ и своим ОЗУ в 48 Кб на бестормозной статике, то прогон программ будет происходить быстрее, чем на IBM PC XT (там клок 4.77, но регенерация ОЗУ с помощью ПДП тормозит, да ещё и в CGA экран ради борьбы с блёстками приходится лазить только во время бордюра).

А ещё, если поставить в ИРИШУ процессор Z80 не простой, а укрутнённый, в виде японского процессора HD64180ZP8, в котором внутрь встроен контроллер DMA качающий память-память (не знаю сколько тактов он тратит на байт, но явно меньше, чем 21 такт, что у LDIR), то ИРИША по аппаратным возможностям для игр сравняется с XT-Турбо с клоком 8088 аж в 10 МГЦ. Я, кстати, купил матку XT-Турбо в конце 1993 всего за 14 у.е, после того, как долго тщетно пытался настроить самодельную матку "Правец-16", изведя только на детали в 5 раз больше денег (жаль, что я распилил плату "Правец-16", хотя возможно сейчас купить целую PC XT ещё не запредельно дорого).

А если добавить на плату граф.адаптера ИРИШИ один корпус ОЗУ 565РУ5, заставив её оперативно коммутировать свои палитры, то будет и 8 цветов (хотя всего 4 цвета в пределах 4 пикселей). Программ это не прибавит, но может привлечёт пользователей и программистов. Хотя для ненапряжного программирования РК-игр достаточно обычного РК86 с ПЗУ 27256 для знакогенератора (что сделать не особо трудно даже криворучкам).

Кстати, забыл упомянуть, что в РК86 делать бордюр аппаратно (т.е возможностями самого ВГ75) можно только при статике, т.к если длительность VRTC более длительности одного знакоряда, то период регенерации динамического ОЗУ превысит допустимые 2 мс (это из-за того, что в РК86 БИС видеоконтроллера ВГ75 попутно с видео выводом регенерит динамическое ОЗУ).

freddy пишет:в соседней ветке Виктор вовсю озадачился довести её [ИРИШУ] до ума.

Из того, что он пишет, следует, что он озадачился лишь изменить конструктив плат ИРИШИ с идеального на очень неудачный.

Да и скорее всего, это у него ненадолго. Т.к у Виктора совсем иные приоритеты (чем удобство программирования и скорость процессора). ИРИША отвращает Виктора своей чрезмерной простотой (т.е в ней слишком мало микросхем), - его больше привлекают аппараты содержащие не менее, чем 2000 TTL-корпусов, с десятками красивых плат (в которых все резисторы лежат, а не стоят) размещённых в красивых шкафах покрашенных светло-серой краской и лучше в нескольких комнатах снабжённых мощными сильно гудящими кондиционерами.

320х200 даже монохромное уже вполне играбельно. Проверено долгими зимними вечерами в молодые годы. И для ретро процессоров это разрешение вполне по силам. Я вот тут подумал, а зачем z80 или 8080 ставить на новодельную плату. Может  стоит присмотреться к 8088 на 10МГц? Можно выполнять код 8080 и 8086. Я где то видел конвертер программ 8080->8086, но не помню у кого. А дополнительные возможности адресации аж целого мегабайта позволят не только сохранить совместимость с Иришей, но и добавить больше памяти, сделать плату переходник с системной шины Ириши в isa-8 и пользоваться различными контроллерами от IBM PC. Сейчас их есть много и стоят они дешевле деталей, из которых сделаны. Я что то такое видел в компьютерах с шиной s100. Там можно устанавливать несколько процессорных модулей и пользоваться нужным. И переходники в isa-8 они тоже во всю использовали.
Насчёт торможения видеоконтроллером процессора. Нужно перейти на статическое ОЗУ, отказавшись от регенерации видеоконтроллером. И перевести память на работу с удвоенной частотой работы видеоконтроллера. Четные такты для тактирование процессора, не четные для видео. Ну метод как на спекки. Только в Ирише.
Есть и сложный путь. Изолировать шину видеоконтроллера. Дать ему собственную видеопамять. На плате Ириши при этом по аресам окна видеоконтроллера тоже будет ОЗУ. Запись будет производиться одновременно и в озу видеоконтроллера и в озу процессором платы. А чтение только из озу процессорной платы. Такой метод упрощает логику видеошины, меньше паять. Нужно чтоб видеошина только писать могла и это проще. Это я описал частный случай одного из режимов взаимодействия лично моей видеошины с материнской платой при наложении адресного пространства.
Этот способ хоть и сложнее, но универсальнее. Он позволяет в адресное окно, отведённое под видеобуфер подсовывать любое железо. Т.е. если вдруг что то в видеоконтроллере надоест, можно впихнуть другой.
Но наверное и это не привлечёт взор Виктора. Даже при самой криворукой и прямоизвилинной реализации этот способ никак не дотягивает даже до 100 ttl корпусов и поэтому наверно кажется сильно простым, примитивизмом веющим. У меня все обошлось в примерно 50 корпусов, из них 10-15 это и есть видеошины. Куда там до 2000 корпусов... я даже боюсь представить сколько оно потребляет энергии. А кулерами то компьютерными тут уже не обойтись. Нужно из каждого зеленого шкафа выводить воздуховоды, объединять  их в общий и выводить на крышу дома. А там будет стоять улитка на пару киловатт и откачивать горячий воздух из этих шкафов и квартиры.

ведущий_специалист пишет:От Вас, Барсик, я готов получить помощь в схемотехнике графической части на ВГ75

Опять-таки не очень понял о чём речь. Концепция, что я изложил в начале этой темы, была рассчитана именно на игровую консоль, а не на совместимую доработку РК86. Т.е забываем о сотне текстовых игр РК86 из сезона 1986...1992 года и новодельных РК-играх написанных в XXI-веке (кажется их было всего порядка десятка игр).

О том, как совместить обычные текстовые режимы использующие фонт и прямо адресуемую графику, я даже не думал, - год назад, т.е исходно, я думал лишь о компьютере работающем в режиме с 80-ю знакоместами в строке, что давало формат экрана 240*128 (что, кстати, всё равно маловато для приличного компьютера). А в таком варианте совмещение с базовым РК не сделать или это получится настолько громоздко, что не стоит и заморачиваться, да и плюсы от сплошного ОЗУ в 63 Кб сыграли роль.

Т.о при реализации концепции графического ВГ75 планировалось удалить ПЗУ фонта как класс и заменить на 555 КП11. Для игровой консоли работающей с картриджами достаточно всего несколько килобайт ОЗУ (лишь для экрана и стека), но нам картриджи не нужны, потому при при изготовлении игровой консоли из готовой платы РК86 на 565 РУ5 ничто не мешает сделать сплошное ОЗУ в 63 Кб (оставив 1 кб под порты) и отключаемое теневое ПЗУ в окне 0...7FFF, включаемое по сбросу. Потому и о совместимости с ретро РК-программами не было и мыслей.

Смотрите всего лишь во что выливается на готовой плате РК86 переделка в графический компьютер (пусть и с очень мелким экраном). Если не менять архитектуру, то изменения схемы для получения полноценного граф.экрана на РК86 с экраном шириной в 72 знакоместа сводятся лишь к установке альтернативного формирователя ССИ на 555 АГ3 и 555 КП11 для загрузки выходного видео регистра 589 ИР13 (или 555 ИР10) то одной тройкой битов, то другой.

Если же 216...240 пикселей по горизонтали слишком много, то при ширине экрана всего в 192 пикселя (192= 64*3) даже 555 АГ3 не требуется ставить, достаточно лишь одной КП11 (а по деньгам это даже экономия, т.к ПЗУ 573 РФ2 стоили в 1987 году в 6 раз дороже, чем 555 КП11, которую можно заменить на две ЛП8, ЛП10 или ЛН6).

А если ОЗУ на статике, то можно ещё расширить экран по вертикали до 128 пикселей ценой затрат в ещё одну 555 АГ3. Ещё упомяну, если кто не догадался, то введение аппаратного бордюра по кадрам ускорит КР580, т.к целых 14 знакорядов из 78 (78= 64+14) он будет скворчать совсем без тормозов (т.е без остановов на захват шины).

А теперь подумав о совмещении режимов текстового и полноценно графического, получается, что... При условии, что не меняем архитектуру РК86, для совмещения двух вариантов видеовыхода потребуется лишь при включении граф.режима деактивировать ПЗУ с фонтом и разрешать работу 555 КП11 вместо него. Т.о получается, что возможно графический режим в РК86 можно поиметь ценой в один инвертор и 555 КП11.

Вот ведь, блин. Надо думать в чём подвох, иначе получится, что я молодец (что придумал столь просто), а все остальные 100 тысяч владельцев РК86 за 35 лет додуматься до этого не смогли.

freddy пишет:зачем Z80 или 8080 ставить на новодельную плату?

Т.к у ИРИШИ всего три игры, то ничто не мешает ставить в неё альтернативную плату ЦП на любом процессоре (и желательно на интересном экзотическом процессоре), а наличие слотов-разъёмов это упрощает.

Благодаря разъёмам ГРПМ-61 на кросс-плате ИРИША расширяемая. Можно добавить в неё кучу альтернативных процессоров, плату силовых реле на тиристорах для управления "умным домом" или свинофермой, добавить плату осцилографа-анализатора цифр.сигналов и др. Если бы редакция ж.Радио не влезла со своим дурным РК86, а отрекламировала бы ИРИШУ, то она бы прижилась и сейчас ИРИША имела бы кучу перериферийных плат разработанных радиолюбителями и три килограмма игр уровня ZX-Spectrum.

В 1977 году появились TRS-80 и Apple-II. TRS-80 за первые годы продавалось в 5 раз больше, чем Apple-II, а затем TRS-80 скис и быстро исчез. Потому-что был одним нерасширяемым моноблоком с клавиатурой. А Apple-II имел 8 слотов для расширений и потому успешно прожил ещё 12 лет, поставив рекорд долголетия 8-ми разрядок. А всё потому, что для Apple-II сделали более 400 периферийных плат. Даже была плата с 8088 дающая совместимость с PC XT (хотя с ценой в пол цены XT, это в основном из-за несовместимости дисководов).

freddy пишет:Может стоит присмотреться к 8088 на 10МГц? ... Я где то видел конвертер программ 8080->8086

Может быть здесь.

Конечно программирование для 8088 очень приятное. Если отвык от мнемоники 8086, то при желании с ним можно программировать и в мнемониках Z80, - достаточно написать макрокоманды. Исходники программ КР580, если они без извратов, легко конвертируются (а вот, если они с извратами, то нужна переделка). Если речь о программировании только на ассемблере, то 8088 лучший (и как код и для программиста). Хотя код 8088 немного менее плотный, но отсутствие необходимости для операций пересылать операнды всегда в аккумулятор, это с лихвой компенсирует.

Однако для КР580/Z80 есть куча эффективных компиляторов ЯВУ. А вот для 8088 кросс-компилятор классического ЯВУ ещё надо найти, их будет немного, код из под них будет иметь бОльший объём и будет более тормозным. Затем, для Z80 есть без-DOS-овые отладчики, есть также DOS (CP/M и другие), а для 8088 это проблема. MSDOS и CP/M-86, даже если возможно найти их исходники, не подойдут (мы же не захотим внедрять в ИРИШУ ROM-BIOS совместимый с IBM PC).

Я не могу заняться установкой 8088, хотя его имею (он даже работал на 10 МГЦ). В 8088 для меня нет особой привлекательности, т.к нет ничего интересного или незнакомого. Так что для меня объём электротраха ради немного более удобного ассемблера не стоит того. А главный минус, что нет у меня для 8088 ни компилятора бейсика, ни Си, ни Паскаля.

freddy пишет:Насчёт торможения видеоконтроллером процессора. Нужно перейти на статическое ОЗУ, отказавшись от регенерации видеоконтроллером. И перевести память на работу с удвоенной частотой работы видеоконтроллера. Четные такты для тактирование процессора, не четные для видео. Ну метод как на спекки.

Видеоадаптер ИРИШИ слишком сложный. Сейчас уже не осталось в живых людей, кто бы сумел спроектировать подобную плату. Даже понять как работает граф.адаптер ИРИШИ уже почти никто не может.

А главное, зачем столько трахаться делая новый граф.адаптер? Тогда зачем его делать совместимым с ИРИШЕЙ. Тогда и сама ИРИША ни к чему. Граф.адаптер и карты памяти - это всё, что по сути образует ИРИШУ. Т.к программ нет, диспетчер памяти не особо удачный, то граф.адаптер это единственное, что цепляет нас к ИРИШЕ. Плата граф.адаптера уже есть и её достаточно (для всех четырёх пользователей ИРИШИ). Плата граф.адаптера слишком сложная для оставшихся владельцев ИРИШИ, а специалисты, кто мог разработать хоть что-то подобное на TTL уже умерли (конечно на ARM и т.п современные инженеры сделают всё, что можно сделать на TTL-корпусах).

Насчёт торможения. Асинхронный граф.адаптер тормозит только когда в него идёт обращение, а обращений в экран даже в самой динамичной игре не более 5-10 %. Так, что если всё остальное ОЗУ без тормозов, то общее торможение игры вызванное медленным граф.адаптером не станет фатальным. Тормознёт вероятно всего на несколько процентов. Это вполне терпимо и ради устранения этой потери нет смысла трахаться переделывая плату граф.адаптера.

Я пока ещё способен. И чисто на логике. И куда более сложнее,чем у бытовых ретро компов. Кто отгадает, что изображено на этом фото? Я такие сохраняю для истории


Я согласен, что если у Ириши забрать ее видеоадаптер, то она перестанет быть Иришей. Тем более что всех владельцев устраивает. Пусть остаётся как есть.
Остаётся тогда переделка РК. Но у меня нет больше ее. Продал давно. И помочь здесь я не смогу. Если ведущий специалист разработает плату игровой консоли по мотивам РК, то я куплю одну.

Я так дам

Сообразил, что если фонт остаётся, то можно обойтись и без монтажа 555 КП11, а то же самое получить просто применив соответствующий фонт. Таким образом, всё что требуется, чтобы получить удобный для программиста графический режим в РК86 - это лишь прошить в ПЗУ фонта другое содержимое.

Обидно, что я не догадался до этого в своё время, когда писал драйвер текста для режима фонтовой псевдографики 192*86. Сбивающим с панталыка стало то, как авторы разбили 16 символов псевдографики по кодам. Так с графикой работать сложно.

Если бы разработчики РК86 в 1986 году сообразили, как с помощью фонта напрямую зажигать пиксели и в качестве ПЗУ фонта применили бы РФ2 вместо РФ1, чтобы во второй его половине был альтернативный фонт, то большинство игр РК были бы написаны для графики 192*86 (а м.быть даже кто-то додумался до 60-ти герцового режима 192*104 задолго до XXI-века).

Моно режим 160*129 (или 128*129) получается с программным формированием бордюра и частоте 50 ГЦ за счёт 43 видимых строк и не требует статики. Моно режим 192*128 с аппаратно-программным бордюром даёт большее разрешение, но требует ОЗУ на статике.

Для нас ценно, что это соображение позволяет проверять монохромные программы для такого (по железу того же самого) РК86, на имеющихся эмуляторах оригинального РК86. Достаточно в них только заменить фонт. Жаль только, что в эмуляторах РК цвет (см.ниже) не проверить, - из-за этого возможно захочу написать свой эмулятор. Кстати, очень интересно, что будет на экране эмуляторов, если в режиме ВГ75 задать не один знакоряд на обр.ход луча, а 14. Завтра об этом сообщу.

А чтобы в эмуляторах было удобно грузить файлы с эмулируемого магнитофона (по директиве I) достаточно написать новый ROM-BIOS для РК86/M который не поддерживает текст из фонта вообще, но выводит текст графикой 192*104 (192*128) - это, кстати, тот же директивный RAM-монитор, но драйвер экранного вывода в нём иной. Хочу написать такой ROM-BIOS для полностью графического РК86. Если кого интересует, - обращайтесь, завтра постараюсь нацарапать (кстати, драйвер выводящий текст в графике у меня уже есть).

Любопытно, что в реальном железном РК86 щелчком тумблера можно вернуть назад базовый РК86 (при этом фонт переключается на базовый эр-кашный КОИ-7 и ПЗУ F800 включается родное) - получается два компьютера в одном железе.

---

В вышепредложенной концепции вывода графики, бит D6 с выхода ВГ75 не нужен для графики. Этот лишний бит семибитового кода можно задействовать для управления миганием знакоместного прямоугольника (3 на 2 пикселя) или для цвета. Но всего два цвета для зажжённых пикселей это не особо много (тогда всего в экране всё-же 3 цвета, т.к нулевые биты из в экр.байты выводятся чёрным).

Однако, по-видимому, самый удачный для построения игровой консоли вариант использования битов получается, если истратить на графику только 4 бита из 7. Тогда экранный 7-ми битовый код из экранного ОЗУ будет задавать графику не прямоугольника 3*2, а квадратика 2*2. Что при стандартных для базового РК 64-х знакоместах в строке даст графику лишь в формате 128*104 (а при ОЗУ на статике 128*128).

Но зато при 80-ти символьном знакоряде (это уже при кварце у ГФ24 в 20 МГЦ) получится разрешение 160*104  (что даже чуть лучше, чем разрешения аркадного автомата). Кстати, у Commodore-64 много игр работает именно в видео режиме 160*100 и играющие в эти игры дети были довольны (никто не жаловался).

Но главное, что при этом, используя оставшиеся 3 бита, можно задавать 8 цветов на этот квадратик 2*2, причём без всяких атрибутов. Для программирования цветной игры это на порядок удобнее, чем задание цвета атрибутами ВГ75 (что вообще противно и для игр этого стоит избегать любой ценой). Можно 3 бита интерпретировать как RGB (тогда всего 8 цветов) или с перекодированием (тогда на экране возможно 9 цветов).

И снова не забывайте, что речь не о неудобной псевдографике 128*104, что даёт базовый РК86 (при особом фонте из 16-ти символов для высоты знакомест в 4 линии растра), а здесь каждым пикселем управляет один бит экранного байта. Т.е получаем то же разрешение, что достижимо и в РК86 за счёт фонта, но это программируется удобно и при этом ещё получаем 8 удобно программируемых цветов. Графика 160*104 (или 160*128) при 8-ми цветах это как раз то, что требуется игровой консоли. Такая графика превосходит возможности видео Atari 2600 из 1977 года. Т.к я узнал, что видео возможности Atari 2600 были ещё хуже, чем я ранее описал.

Оказывается разрешение 160*192 в Atari 2600 - только для аппаратных спрайтов, а пейзаж в игре должен рисоваться в грубом разрешении всего 40*192. Зато число цветов не 4. А лишь 4 цвета задаются на экранную линию и выбор для этого произвольный (в смысле не палитрами) из 128-ми цветов. Возможно, что-то типа того, как в цветном РК86 цвет знакоряда можно задать атрибутным байтом отображаемым пробелом и размещённым в бордюре. БОльшее разрешение по вертикали в Atari 2600 малополезно (т.к экран телевизора вытянут по горизонтали), хотя возможно позволяет более плавные движения спрайтов вверх-вниз. При историю Atari можно почитать здесь.

Разве вот такую (и даже лучшую) графику мы не сможем реализовать в полноценном графическом экране 192*128*монохром или 160*128*8_цветов :




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

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

Честно отвечу на ваш интерес, не хватает, читаю по диагонали, на предмет, чтобы никто не ругался и не матерился, а остальное..., не хватает ума, так как вся память занята под другую программу, поинтереснее для меня на данный момент. А то долго, несколько лет не мог понять, как бы мне сделать одну весчъ, и тут как не осенило, "не так страшен чёрт как его малюют" хотя тонкостей полно, и вот сижу обдумываю то, чем меня осенило, как это в "железе" сделать, да да да всё о том же о нескольких CPU в системе, раньше кроме обмена через порт, на большее не хватало... А тут прорастают зародыши идеи, как прямо через внутренние шины взаимодействовать, понятно, что велосипед, и скорее всего это называется арбитр шин или ещё как-то, ну уж очень мне хочется поиметь на одной плате 2 или 4 микропроцессора и чтобы это всё работало, в два раза быстрее, чем один...
А все эти рюшечьки, игрулечки, ну вот как-то не очень интересно, поэтому, не хочу выделять ни кусочка ума, чтобы понять, по крайней мере сейчас, вот дойдёт дело до графики, хотя думаю МКГД от Ириши, меня вполне устроит...

Viktor2312 пишет:думаю МКГД от Ириши, меня вполне устроит...

Так кончайте прокрастинацию, не тяните кота за хвост, не занимайтесь никому ненужным выпуском ИРИШИ в левом конструктиве, а заканчивайте, запускайте стандартную нормальную ИРИШУ. Может тогда и блажь выпускать ИРИШУ в левом конструктиве (лишь ради того, чтобы стоящие вертикально резисторы положить горизонтально) сама собой постепенно пройдёт.

Посмотрел на графику игр Atari 2600 с горизонтальным разрешением в 160 пикселей и что-то не особо это меня впечатлило красотой. Осталась робкая надежда, что графика 192*128 будет смотреться получше. Или придётся использовать графику 240*128. Ранее я применял неудачный графический фонт (без соответствия битов пикселям), отчего работа с графикой была сложной. А с более грамотным фонтом алгоритм вывода графики быстрый и простой.

Если честно, с аппаратной части абсолютно не понятно. Вы пишете, выпаиваем ПЗУ с фонтом и ставим кп11 и доп инвертор. В голове не увязывается совсем как такое возможно. Схему бы глянуть, тогда бы осенило.
По поводу разрешения атари, конечно же это очень мало. Я играл в эту консоль, вызывало только смех, сравнивая имеющиеся нес и спектрум. Поэтому если уж и выдумывать, то разрешение минимум 192,а лучше 240 точек. Что то вчера весь вечер убил, перестраивая программно вт57 чтобы сделать скроллинг экрана. Либо лыжи не едут либо что то там хитро. Есть ли у кого наработки где можно подсмотреть?

Так кончайте прокрастинацию, не тяните кота за хвост, не занимайтесь никому ненужным выпуском ИРИШИ в левом конструктиве, а заканчивайте, запускайте стандартную нормальную ИРИШУ. Может тогда и блажь выпускать ИРИШУ в левом конструктиве (лишь ради того, чтобы стоящие вертикально резисторы положить горизонтально) сама собой постепенно пройдёт.

Категорически с вами не согласен. Понимаете, во-первых, мне абсолютно всё равно, нужно это кому-то или нет, главное, что это нужно мне. Во-вторых, это разумный конструктив, практика показала, насколько вертикальное расположение убогое и трудоёмкое в запайке, пока запаяешь одну уродливую микросборку, можно пол сотни запаять красивых резисторов, удобно расположенных и ещё и получить от этого огромное удовольствие. А про электротрах - могут говорить только люди не паявшие заводские платы, когда пайка доставляет не кучу гемора, с обжиганием пальцев и другими проблемами, а огромное удовольствие, и экономит огромное количество времени ещё при этом. Ну а про разъёмы я и говорить не хочу, пока настраивал МП мне пришлось раз пять втыкать и изымать, да то тут говорить, правильнее сказать впихивать разъём один в другой и с трудом выдирать при разъёдинении, не тут практика чётко показала непригодность этих разъёмов ГРПМ (ГРПМШ) они просто проигрывают IDC по всем параметрам удобства, по надёжности одинаковые, то есть если брать и сравнивать ГРПМШ то они такие же по надёжности как и катайский ширпотреб, хотя китайские понадёжнее будут, но это на мой взгляд, так как есть у меня дисководы, которым по 25...27 лет, и разъёмы там в отличном состоянии и работают нормально, а вот ГРПМШ, тоже есть, честно говоря я их запаивать не стал пока, не нравятся мне их контакты, их сохранность за 15 прошедших лет. Ну и так же и ГРПМ и IDC с позолоченными контактами, с зажимами и доп. зажимом кабеля на шлейфе, так эти просто превосходят ГРПМ, серебро всё же окисляется, техническое золото нет, так что по разъёмам однозначно IDC, практика и опыт эксплуатации ещё в 2017 году, требовали от меня этим заняться, но я тогда не решился, так как знал, что это всерьёз и надолго и я тогда к этому был не готов, сейчас я готов, потихоньку, вычертить модифицированную схему, и развести не спеша все платы, с заказом будет сложнее, с 2016 года просто жесть и крах всей фин. системы, ну как нибудь накоплю.
Так что, ничего не пройдёт, к тому же не забывайте, это не просто ПЭВМ на пару плат, а МВК, и там длина шлейфа позволяет и 20 плат, а если посудить то минимум выходит запросто в 5 плат, это если только основные и + 1 плата ПЭ, хотя бы с вторым, но скорее всего с двумя ведомыми микропроцессорами....

ведущий_специалист пишет:Если честно, с аппаратной части абсолютно не понятно. Вы пишете, выпаиваем ПЗУ с фонтом и ставим кп11 и доп инвертор. В голове не увязывается совсем как такое возможно. Схему бы глянуть, тогда бы осенило.

А у меня в голове не укладывается, как человек знающий как работает видеоконтроллер 580 ВГ75 и обычный советский ЭЛТ-телевизор может не понять с полуслова о чём речь. Думаю, что Вы преувеличили степень непонимания.

КП11 подаёт на загрузку выходного сдвигового регистра то одни три бита из "кода символа", то другие три бита (это возможно потому, что всего на выходах ВГ75 этих битов - семь). Т.к переключает КП11 сигнал LC1, то в верхние две линии растра в знакоместе отображаются в виде пикселей первые три бита (младшие), а в нижние две линии растра отображаются в виде пикселей - другие три бита из "кода символа", что из экр.ОЗУ периодически считывает и выдаёт на свои выходы CC0...CC6 CRT-контролер ВГ75 в моменты прохождения луча по данному знакоместу.

К концу дня, я надеюсь, странслирую ROM-BIOS РК с граф.видеорежимом 192*128 (это если эмулятор правильно с'эмулирует вывод 64 знакорядов, что максимум для ВГ75) или 192*104 в противном случае. Можно будет директивой монитора M пописать в экранное ОЗУ и посмотреть как интерпретируются биты экранного байта на экране.

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

Всякий раз когда отображается конкретное знакоместо, CRT-контроллер 580ВГ75 выдаёт на выходы CC0...CC6 семибитовый код расположенный в экранном ОЗУ по адресу рассчитываемому по формуле (с раннего детства хорошо знакомой всем любителям РК программирующим на ассемблере) :

Экранный адрес знакоместа = $76D0 + (Y+3)*78 + 8 + X

Тремя битами D2, D1 и D0 в зависимости от того, равны они 0 или 1, гасим или зажигаем пиксель в верхнем ряду пикселей. А битами D5, D4, D3 управляем нижним рядом из трёх пикселей в знакоместе имеющем в таком раскладе пиксельное разрешение 3 на 2, т.е два горизонтальных ряда (стоящие один над другим) по 3 пикселя располагающихся рядом. Таким образом, если нам надо зажечь три нижних пикселя знакоместа, мы записываем в рассчётную ячейку двоичное число 0011.1000. Программировать вполне удобно, как графику так и текстовый вывод.

И Вы не обратили внимание, что в предыдущем посте я упомянул, что КП11 ставить совсем не обязательно. Точнее это имеет смысл лишь, если РК переделывается под 80 символов в строке (как в Роботроне-1715, там тоже стоит ВГ75). Тогда естественно, старые РК-программы уже не подойдут и значит родной текстовый режим не нужен (отчего и ПЗУ знакогенератора 573 РФ2 из жадности можно снять и потратить на что-то иное). Хотя если сделать строчный шаг не 80, а лишь 78, высоту символов 10 линий и задать нач.адрес экрана 76D0, то при наличии фонта РК-шные программы работающие в сбросовом видео-режиме 64*25 будут отображаться (на чуть сплющенном с боков экране). А при 80-ти символьном размере знакоряда, раз все РК-шные программы не годятся, то и дорогостоящее ПЗУ знакогенератора не нужно.

Вот схема, хотя она и словами исчерпывающе описана, схема тут вряд-ли добавит понимания. Кстати на этой схеме я попутно изобразил, как использовать лишний седьмой бит кода под мигание прямоугольника 3*2 пикселя. Хотя какая польза от мигания? -- Никогда не понимал зачем вместо бОльшего числа цветов Ричард Альтвассер ввёл в ZX-Spectrum мигание знакомест.

Удалось ли продвинуть теорию в практике? Вы вроде хотели программно какие то моменты отработать?
Сижу вот пол вечера уже думаю. Стоит ли овчинка выделки. Посмотрел возможности апогея, по сути там 192х128 при 8 цветах. Правда вся графика вышла из доп фонта пзу. Но!! Не быстрее ли получится выводить графику спрайтами из пзу нежели таить в 1 байте 2 точки? Спрайт 3х2 точки по моему удобнее(быстрее).
По мне, так все таки лучше - это перегружаемый знакогенератор налету. То есть, вывел символами например 2х2 символа стандартного знакогенератора рк что позволит нарисовать персонажа 12х16 точек или в современных реинкарнациях рк86 со знакогенератором 8х12 точек 16х24. Получается и быстродействие - двигай 4 символа, и расход меньше памяти, и неплохая графика. Ну что я пишу, все это думано передумано по сто раз, а я всего лишь тут капитан очевидность.
Вобщем пока не сделаю и не проверю, буду на своей волне.

ведущий_специалист пишет:Удалось ли продвинуть теорию в практике? Вы вроде хотели программно какие то моменты отработать?

Не, не отработать, вывод текста такой графикой уже попробован ещё в 90-тые годы (но тогда ума на кое-что не хватило). Я собирался лишь сделать монитор РК86, чтобы получилось ДЕМО для поднятия энтузиазма на тему такой графики. А так-то сам драйвер вывода текста в режиме (и даже не только 192*104, но и) 192*128 у меня есть и он очень прост (т.к без обслуги упр.кодов VT52, что, кстати, и не особо надо, да и добавить эти коды не проблема). И есть конвертор нормального фонта в знакоместный фонт из прямоугольников 3*2.

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

Спойлер:

Исходники РК-шного ROM-BIOS тоже есть. Достаточно из него выкинуть родной драйвер вывода текста и вставить драйвер вывода в графике.

Кстати, для текстообработки можно, во-первых, сделать драйвер со шрифтом 5*8 это даст 192:5= 38 символов в строке (хотя некоторые широкие буквы тогда слегка уродливые, хотя и различимые), а во-вторых можно написать драйвер пропорционального шрифта. Уже лет 20 собираюсь написать драйвер пропорционального шрифта. Он увеличивает число символов в строке. Вероятно в 192 точки влезет в среднем 42 символа в строке (а в 240 вообще немеряно). Так что и минимальная текстообработка в графич.режиме будет возможна.

ведущий_специалист пишет:Не быстрее ли получится выводить графику спрайтами... Получается и быстродействие - двигай 4 символа, и расход меньше памяти, и неплохая графика.

Т.е Вы против полноценной, но низкоразрешающей графики, за чистую текстовость с большим числом фонтов и написание РК-игр на базе тайловой графики. Тайловая графика конечно намного качественнее, т.к при ширине фонта в 8 точек полный формат экрана 64*8=512 или даже 80*8=640 точек. Никакой Синклер с таким разрешением спрайтов не сравнится. Кстати в Atari 2600 как раз только спрайты имели более менее графику, а пейзаж - очень низкое разрешение (так они экономили ОЗУ, что стоило в 1976 $50 за 1 кибибайт).

А расширять режим развёртки с 64 до 80 знакомест в строке собираетесь? Граф.режим 192*128 (192*104) или в случае 8-ми точечного знакоместа 160*129 (128*129) - ничего не стоят по деталям. Они получаются лишь за счёт более разумного фонта занимающего 64 кода. Оставшиеся 64 кода можно занять мелко-спрайтами и тайлами (типа пули, взрыва и т.п), тогда в одном экране и грубая пиксельная графика и мелкоточечные спрайты. Можно переключать фонт половинкой, т.е 64 символа для графики не меняются, а 64 символа для тайлов оперативно преключаются атрибутами.

80 знакомест в строке уничтожают совместимость с ретро-ПО РК86, но зато получается полноценная графика 240*104, (а это уже будет намного красивее) и с фонтом 6*8 будет 40 символов в строке. И всё это делается лишь альтернативным фонтом и формирователем ССИ на АГ3.

Как выглядит такая графика на РК, - вот как раз Демо работы текстового драйвера в графике 192*128. А графика в 240*128 - д.быть ещё лучше.



Из-за нежелания связываться с неудобным атрибутным цветом, мне больше по душе вариант более убогого разрешения в 160 горизонтальных пикселей. Это когда режим развёртки 80 символов в строке (т.е с аппаратным формированием ССИ) и получается графика 160*128. Когда из 7-ми битов кода экранного байта 4 бита - на графику, а 3 оставляем на цвет. Тогда знакоместо 6*4 или 8*4 попиксельно делится на матрицу всего на 2*2 пикселя.

Режим в два горизонтальных пикселя на знакоместо выгоден не только из-за цвета. А также из-за того, что на моей РК-плате фонт уже 8*8, а 8 плохо делится на 3. Что кстати будет и у Вас, если вывод будет на VGA, т.к там тоже фонт шириной в 8 точек. Это можно исправить увеличив пиксель клок на 1/8 и расширив сдвиговый регистр до 9-ти битов. Тогда в 9-й бит выходного сдвигового регистра пишем то же самое, что в 8-й, и получаем три равноразмерных пикселя из 8-ми битового ПЗУ. И тексту это, кстати, только на пользу (можно сделать шрифт красивее, а иметь сплошные линии по горизонтали не мешает).

При нежелании тратить биты кода на цвет и фонте шириной в 8 точек возможно деление знакоместа лишь на пиксельную матрицу 2*3, что при 43 строках высотой в 6 линий даёт экранное разрешение 128*129 или 160*129.

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

А 8 или 9 цветов на знакоместо 2*2 с цветовым разрешением 80*43 это не так уж плохо, т.к графическое разрешение остаётся 160*129. А главную роль в восприятии играет как раз графическое разрешение. В "Принце Персии" на Apple-IIe графическое разрешение в цвете было всего лишь 140*192. Т.к цвет в Apple-II вдвое понижает графическое разрешение (в моно там 280*192). Цвет там задаётся позицией бита - чётные биты байта дают одни цвета, нечётные - другие. Итого эта идея вместе с незанятым графикой битом D7 даёт нам два бита на цвет чётных точек и 2 бита - на цвет нечётных точек. Всего 6 цветов. И этого цвета всем игрокам в "Принца Персии" хватило.

Обидно, что знакоместо в 8 пикселов и VGA теряет совместимость с ранним рк86. Теперь буду усиленно думать, как обеспечив совместимость с остальным ПО, сделать принципиально новое разрешение в новоделе. Да, возможно многие сейчас скажут толку с этого новодела, но.... такого еще никто не делал, да и желающих купить рк86 на барахолке zxpk немало. Почему бы не приподнести что то желаемое давно.
Ведь согласитесь, 3 корпусами простой логики удалось добиться переключения адресации убогой старой конфигурации к принципиально новой, освобождающей место с доп ОЗУ. Почему бы той же тм9 на свободных ногах не организовать переключение видеорежимов. Повторюсь, при включении это будет тот же самый рк86, но при запуске соответствующего по пользователь начнет "немного" не понимать, что же происходит, и почему псевдографика у него на глазах переходит в графику, да с цветом, да начинает пиликать музыка, да потом появляются видеоролики )))), которые формируются путем быстрой смены видеообласти в доп озу и считываются последовательно из гигабайтной SD карточки при помощи дос Седова )))....
вот это и хочется приподнести пользователям рк. И это возможно...

ведущий_специалист пишет:Обидно, что знакоместо в 8 пикселов и VGA теряет совместимость с ранним РК86.

Да ничего не теряет. У базового РК86 нет граф.фонта в котором бы знакоместо по горизонтали делилось на 3 пикселя и соответственно программ таких нет как класса !!! Что, кстати, очень глупо, т.к это в 1.5 раза увеличило бы качество псевдографики и ничего бы не стоило по деталям. А то каким образом нарисован символ в фонте на работу игры не влияет, при фонте 8*8 лишь буквы выглядят посимпатичнее.

Базовый псевдографичкский фонт - всего 16 символов (причём распределённые в коды идиотским образом, что исключает логическое управление пикселями, когда бит в коде соответствует пикселю) и матрица его разложения там всего 2*2. И даже моих скромных умений пользоваться арифметическим калькулятором встроенным в Windows XP хватило, чтобы успешно выяснить, что 8 делится на 2 нацело (как и 6).

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

Первое надо, когда число знакомест в строке увеличиваем с 64 до, например, 72. Тогда надо поднять частоту клока ВГ75, пиксель клока и, соответственно, кварца с 16, например, до 18 МГЦ. И соответственно полное число знакомест в ряду увеличить с 86 до 96 (чтобы частота строк осталась в норме), что при оставлении строчного шага в 78 символов потребует длины периода строчного гашения в 96-78= 18 (вместо 8 в оригинале). В базовом РК полное число знакомест в строке (т.е отображаемые 78 + длина HRTC) равны 78+8= 86 (правильнее бы 85, но это программно не сделать, потому 50 ГЦ чуть не точны).

И даже, если число знакомест в строке изменено, но при этом строчный шаг оставлен 78 (изменена только длительность HRTC, чтобы довести частоту строк к стандарту при уплющивании растра с боков, чтобы до 78 знакомест стали видимыми), то всё что надо изменить в РК-игре с псевдографикой это изменить в игре один байт (там где задаётся режим ВГ75, а найти это в коде занимает примерно 7 секунд, т.к в игре только тут идёт запись на C001), который задаёт длину HRTC в команде задающей режим ВГ75.

После этого частота строк вернётся, а т.к строчный шаг тот, адрес начала экрана тот, то и экранные позиции символов в тех же адресах, отчего игра будет точно так же видна, как и на оригинальном РК. Только растр визуально будет выглядеть немного уплющенным с боков (т.к это и была задача достигаемая аппаратно-программным формированием ССИ на АГ3, и отдачей HRTC её стандартной задачи - гашения на обратный ход луча по строкам, с целью поднять число видимых знакомест до более, чем 64, например до 72 или даже до 78).

Если же не только ССИ, но КСИ формируется на АГ3 из переднего фронта VRTC (что надо чтобы в растр умещалось не лишь 52 знакоряда, а все 64), то для возврата частоты кадров в игре из 57 ГЦ до стандартных 50 ГЦ надо менять аж два байта в процедуре установки видеорежима ВГ75 в псевдографической игре (задающих как HRTC для строк, так и VRTC для кадров).

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

ведущий_специалист пишет:согласитесь, 3-мя корпусами простой логики удалось добиться переключения адресации убогой старой конфигурации к принципиально новой

Три корпуса это не шедевр аппаратного творчества, т.к разработчики РК86 планировали улучшение архитектуры сделать совсем без роста числа корпусов, простой заменой 555 ИД7 на 556 РТ4 и кусочек проволоки (соединяющий старший адрес РТ4 и выход одного из ППА).

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

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

А имея аж 32 фонта в ПЗУ 27256 можно атрибутами переключать в нужных знакорядах фонт, что позволит на одном и том же экране иметь все возможности базового РК86 (т.е все его базовые 96 символов, - символы с кодами ниже $20 не нужны, т.к там поганая якобы псевдографика) и одновременно графику с разрешением 192*128 (или аж 240*128, если совместимость с древними РК-играми не волнует). Тогда атрибут отображаемый пробелом ставится в поле левого бордюра и никак не мешает (т.е не сдвигает адреса экранных позиций, что является проклятием атрибутного цвета).

Это самое разумное и очень полезное использование атрибутов. Получается машина и с графикой и с цветом и всё это на одном экране. А самое поразительное, что при этом в принципе ничего даже паять не надо, - просто перезашей ПЗУ фонта РФ2 и тащись от крутизны аппаратных возможностей.

А вот такой вопрос, честно не знаю, сколько в специалисте занимает экранная область.?

ведущий_специалист пишет:А вот такой вопрос, честно не знаю, сколько в Специалисте занимает экранная область?

384*256:8= 12 Кб. Но несложно (и это делалось в ОРИОНЕ) расширить экран до 512*256 (16 Кб). Я расширял экран в своём Специалиста в 1990 году до 640*256.

Для игр 512 точек это не лучше (т.к для игр на небыстрой 8-ми разрядке достаточно экрана 256*192), а вот для текста - значительно лучше, т.к тогда при байтовом шрифте получается 64 символа в строке, а байтовый шрифт 8*10 в 2.5 раза быстрее, чем фонт 6*10 или 7*10 (т.к отпадает маскирование с старым содержимым экрана).