Модульный РАДИО-86РК

[Alex_LG]

Сообщение B2M о том, что в одном из клонов РК86 есть целых 8 фонтов, навело меня на мысль, что если число фонтов сделать ещё большим ...
...При использовании ПЗУ 27256 или 62256 с подпаянной батарейкой, т.к каждый фонт занимает 1 кб, получаем 32 фонта...

Нескромно с моей стороны, но пропиарюсь еще раз (уже приводил для Вас данную ссылку), посмотрите http://zx-pk.ru/threads/20714-pomech...l=1#post713206 Там схема загрузки шрифтов в теневую память. Я дал только пару вариантов использования загружаемых шрифтов, но никто не запрещает загружать нужный шрифт/спрайт в процессе выполнения программы! И тогда мы получим не 8-32 шрифта, а столько, сколько нам нужно, хоть на каждый скрин/уровень свою графику! Переключается, кстати, по кадровому импульсу и нет никаких мерцаний. Схема минимальна, доработок практически никаких (кроме стандартных и пару проводков порезать) делать не нужно. Данная схема была поддержана пользователями форума (за что им моё спасибо), так зачем изобретать велосипед!? Схема, конечно не идеальна, но она УЖЕ работает.

[barsik]

Посмотрел схему загрузки фонта. Ничего неожиданного, хотя я бы сделал немного иначе. Но в общем-то примерно так я это и представлял. Вот выдержка из темы "Что можно выжать из ВГ75", где freedy использует конструкцию на ВГ75 с загрузкой фонтов.

... знал одного фаната, который пытался доработать РК, введя загрузку фонта (чтобы игры РК стали красивыми). Фонт для ВГ75 хранится в ОЗУ с раздельными входом и выходом. Входы ОЗУ подключены к ШД. А адреса ОЗУ с помощью трёх КП11 при обращениях КР580 переключаются от ВГ75 на ША. Благодаря чему и происходит загрузка фонта. Думаю конструкция могла бы работать.
. . . .
Не вижу, что в таком варианте помешает загрузить фонт (кроме нагрузочной способности шины РК). ОЗУ 1 кб имеет 10 адресных входов, три КП11 коммутируют 12 цепей. Входы ОЗУ на шине данных. Что ещё надо? Ну, для совершенства можно предусмотреть гашение, чтобы не было блёсток по экрану, в момент загрузки фонта.

Этим хочу сказать, что сама концепция загрузки фонта и её достоинства мне известны с 1988 года. Реализовывать её не стал, не было нужды. Фонт 8*10 использовал (правда не в 80-е, а уже в середине 90-х). Фонт у меня был не обычный, а извращенный (2 последних линии - во 2-м килобайте). Это для того, чтобы можно было использовать и фонт 8*8 и 8*10.

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

Загрузка фонтов, позволяет иметь полноценную графику, если дополнить её другой идеей. позволяющей аппаратно или программно выбирать фонт для каждой строки. Режим полноценной графики интересен, но практически бесполезен, т.к реально может быть использован только для текстообработки, а тут настоящий текстовый режим намного быстрее. Игры в полноценной графике на РК86 будут тормознуты.Такой конструкцией я, возможно, займусь позже. Для начала проще ввести спрайтовую графику для игр на принципе Денди.

Использование спрайтов из ПЗУ, как в Денди, - не тормозит, здесь загрузка фонтов актуальна. А если есть и цвет из фонта, т.е аппаратная раскраска спрайтов, то для создания игр это удобнее, чем писать для цветной графики АПОГЕЯ. А удобство программиста важно.

А по трудозатратам. Что проще, просто перезашить ПЗУ или спаять отдельную платку на 8-ми корпусах, соединяемую ворохом проводов с платой РК?

В предлагаемой конструкции доработки до игр со спрайтами за счёт большого ПЗУ фонта удобно использовать не 27256, а 62256 с батарейкой. Вытащил, вставил в панельку загрузчика, загрузил код и опять воткнул в РК86. При старте игры, загружать фонт не надо и во многих играх можно использовать одни и те же спрайты. Это как альтернатива загружаемому фонту для ленивых. Хотя конечно, при разработке программ Ваша платка была бы полезна программистам игр и рисовальщикам спрайтов.

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

Собираюсь спаять Вашу (или чуть изменённую) схему загрузки фонта, но позже. Пока надо сделать более актуальные доаботки.

Теперь, что касается оцвечивания не игр, а текстовых программ, где не требуется, чтобы каждая буква была своим цветом. Истратив всего 8 фонтов по 1 кб, в варианте с двойным ПЗУ (фонт + цвет) и три атрибутных сигнала для их выбора, можно иметь 8 сочетаний цветов, что гораздо лучше, чем просто 8 цветов. Хотя, как и в АПОГЕЕ, при работе с текстом в пределах полной строки возможны лишь 3 смены цвета, и т.к в каждом из этих 8-ми фонтов все символы одного цвета, то смена цветов происходит не кодом символов, а только атрибутами ВГ75 переключающими фонт.

Если соответственно выбрать атрибуты и коды цветов, то схема будет совместимой с АПОГЕЕМ, одновременно давая быстрые цветные спрайты. Но не вижу смысла стремиться к совместимости по цвету с АПОГЕЕМ, т.к во-первых он несовместим с РК86, а во-вторых оцвеченные для АПОГЕЯ игры не нужны - с такой доработкой можно использовать монохромные игры РК в цвете, имея соответствующий цветной фонт.

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

PS: Чтобы было ясно насколько неудобен для программиста цвет АПОГЕЯ вспомните, что каждая атрибутная команда управляет только одним битом из R.G.B. Это же не байт записываемый в ОЗУ цвета, как в ОРИОНЕ. Поэтому чтобы установить неосновной цвет надо записать в строку подряд несколько атрибутов, а в строке Вы можете записать их всего 3. Т.е число цветов в строке ограничено. Ничего такого нет при цвете встроенном в фонт.

; ----------------------

Используя раскраску в варианте с одним ПЗУ фонта, но когда чётные биты в фонте несут информацию о графике, а нечётные - о цвете, из РК86 при минимальной пайке и расходе деталей (только формирователь R.G.B. и замена ПЗУ фонта на 27256) получается совершенно новый цветной текстовый режим с текстовым экраном 32*24, как в ZX80, только с цветом и быстрыми цветными спрайтами для игр. Причем разрешение цвета лучше, чем в ZX-Spectrum и в ОРИОНЕ - два цвета в пределах 4 пикселей и числе цветов 8. Тогда каждый "символ" в ПЗУ фонта имеет ширину 4 пикселя и для формирования символа на экране надо вывести рядом два знакоместа.

Это ограничивает общее число экранных символов до 64 (число символов в одном фонте 128). Но это не фатально, т.к переключая фонты 4-мя атрибутами ВГ75, мы можем иметь даже 256 КОИ-8 символов. Хотя трудно сочетать символы из разных фонтов в одной строке, т.к число атрибутов в строке ограничено.

Если изменить схему видеовыхода, то цвет можно сделать по принципу CGA, когда два соседних бита в фонте задают цвет пикселя (один из 4-х цветов). Это на пару корпусов больше, но зато можно использовать спрайты от PC XT и Amstrad CPC и каждая точка в спрайте может быть своего цвета. Тогда в качестве редактора спрайтов можно использовать графический редактор от PC XT для CGA.

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

[Error404]

На порядок обозначает разницу в 10 раз, т.е. 3.2кб вместо 20кб.

Спасибо, Кэп.
Предвидя именно такие реплики из серии "я не читатель, я писатель" я и указывал постом выше, что в левой части неравенства у нас утилита для FAT12 (просто копирование с/на дискеток), а в правой - полный функционал файловых систем FAT12/FAT16/FAT32 одновременно (с датами и атрибутами файлов, каталогами, длинными именами {и UTF, но я его отключал}, произвольным позиционированием, поддержкой партиций жесткого диска), причем требующая 32-битной арифметики, которая в отличие от 12-битной не может быть реализована на единичных регистровых операциях процессора z80/8080 (соответственно int16 умеет любой компилятор для 8080/z80), а требует подпрограмм. При этом HitechC не только это нативно поддерживает (что уже космос для 8-биток на 8080/Z80), но и код генеририрует более компактный при гораздо большей функциональности. И таки да, на нормальных процессорах где нет такой разницы между 32 и 16 бит (на странице Elm Chan-a есть статистика по разноплатформенным компиляциям FatFS) оно компилируется в ~3..5кб.

Но что интересно и тот и другой пример как бы намекает: нужны способы (оверлеи) поднять общий обьем кода\данных программы с обычных 50...60кБ до 128...4Мб для более-менее серьезных программ. А иначе писать все прийдется на ассемблере (который дает выиграш в 3...5 раз по обьему).

Тоже это уже обсуждали и пришли к мнению, что овчинка реализуема, но выделки не стоит, т.к. при сложности сравнимой с борьбой за компактность кода, лишает удобств и добавляет кучу регулярно вызываемого обслуживающего кода (т.е. и +размер и +тормоза). Если код (что характерно, заведомо известный понятный код, который пишешь ты сам, а не портируемый "на конвейерной основе - фигак_фигак_впродакшн" где ХЗ какие взаимосвязи) еще как-то можно распланировать и разнести по сегментам оверлеев, то все равно это не дает приемлимой гибкости программирования, т.к.:
- все равно в сегменте нельзя сделать malloc куска большего, чем сегмент оверлея (а большой сегмент делать неэффективно)
- нельзя заехать кучей (а это заранее не прогнозируемо) на сегмент оверлея (он же в общем адресном пространстве), т.е. требуются проверки в коде при выполнении каждой операции а не на этапе компиляции
- нельзя заехать стеком (это тоже заранее не прогнозируемо) на сегмент оверлея, т.е. аналогично - требуются проверки при каждой операции

Впрочем, один вариант применения оверлея есть, и мы его обсуждали в теме Uzix - вынесения в оверлей libc (в случае Uzix и libc от HitechC это в максимуме экономии даст 20-30кб). libc часть константная, переписать надо единожды, и можно попробовать этот способ для случая "оверлея только для кода" если сделать оверлей в начале адресного пространства (заведомо ниже кучи и стека). НО я уверен, подводные камни все равно полезут, и кроме того: ну вынесли мы libc, а дальше то - все равно начинается борьба за компактность.

Ну и продолжая мысль с libc: можно и прочий библиотечный по логике использования фукционал (ту же поддержку FAT, IP) выносить в ядро (сиречь в другие страницы ОЗУ), но для произвольного приложения все равно вводные не меняются.

[b2m]

Потому есть просьба к авторам эмуляторов EMU80 и B2M сделать там поддержку атрибута RVV в качестве коммутатора фонта.

RVV у меня жёстко зашит в коде для инверсии, а вот HLGT можно хоть сейчас использовать для коммутации фонтов. Собственно, он и используется в комбинации с GPA1,GPA2 для выбора одного из восьми фонтов при эмуляции Партнёра.

[barsik]

Для РК86 компиляторы ЯВУ с поддержкой много-банковости, т.е когда код программы раскидывается по всем банкам - пока не особо нужны. Здесь ещё даже не придумали, как ввести эти самые банки. И максимум ОЗУ, что у кого-то есть - это 64 кб. И только в эмуляторе B2M мы имеем до 4 мб. Ограничение потому, что 256 (номер сегмента однобитовый) умножить на размер окна в 16К даёт 4 мб.

Но пока я даже не имею схемы, т.е не проверил на практике, что РУ7-мые, а тем более SIMM 1 мб регенерируются в схеме РК86. При погашенном экране, т.е при выводе на МГ, регенерации РУ7-мых точно не будет, а будет сбой. Т.к при вводе/выводе байта, п/п-мма в ПЗУ сама делает перебор 128-ми адресов, обеспечивая регенерацию РУ3-их. А на перебор 512-ти адресов, что надо для регенерации РУ7-мых, п/п-мма не рассчитана. Так что всякий, кто ставит в РК РУ7-мые или SIMM должен одновременно демонтировать за ненадобностью адаптер магнитофона.

Но с непогашенным экраном при видео-выводе перебираются 2048 ячеек, что делает прозрачную регенерацию РУ7-мых. Естественно, придётся перенести адреса на мультиплексоре адресов так, чтобы по /RAS на ОЗУ выдавались адреса А0...А8, т.е самые высокочастотные при видео выводе. Т.к в строке 78 байт, то 512 адресов перебираются за время вывода 512 : 78= 7-ми строк. Т.к в строке 10 линий растра период регенерации составит 7*10*64 МКС = 4.48 МСЕК, что, увы, больше, чем 4 МСЕК, максимальный период регенерации РУ7-мых.

Таким образом, при установке РУ7 возможны проблемы. Лишь при использовании РУ7-мых наполовину, т.е на 128К регенерация будет с периодом 2.25 МСЕК, т.е в норме. Потому с старыми РУ7-ми связываться рисковано. Хотя это наименее трудоёмкий вариант.

А вот с SIMM 1 мб, боюсь, без труда ничего не выйдет. У них 11-ти битовый вектор регенерации. Хотя при видео-выводе перебирается как-раз 11 адресов (т.к экран более 2 кб), но увы, в слишком долгом периоде. Период перебора 11-ти адресов равен времени вывода 2048:78= 26-ти строк, т.е 26*10*64= 16.6 МСЕК.

Кто-нибудь знает максимальный период регенерации SIMM 1 мб?

В голову сразу приходит мысль регенерировать SIMM 1 мб программно, на прерываниях, как это делается в PC XT. Но тут РК86 не повезло. Прерывания истрачены на звук, а программы РК нагло занимают область Zero Page, где вектора RST, позволяющие иметь прерывания без ВН59. Но даже ВН59 не поможет. Для регенерации надо перебрать 11 адресов, т.е считать 2 кб. При максимально скоростном цикле с линейным участком из 128 команд LD A,(HL) и скорости в 1.3 МГЦ, это занимает (128*7+16)*16/1.3, т.е ~11 МСЕК. Т.о, имея SIMM с периодом регенерации 11 МСЕК, программа может лишь непрерывно регенерировать ОЗУ, на прогон программы времени не остаётся. А ОЗУ с периодом регенерации в 8 МСЕК вообще не удастся программно регенерировать.

Выходом может быть применение узла скоростной прозрачной регенерации. Идея такая. После каждого обращения к ОЗУ процессора КР580 (не ПДП), адреса A0...A10 на входах мультиплексоров переключаются на счётчик регенерации, и выдаётся импульс /RAS на ОЗУ. Т.к КР580 после обращения к памяти, как минимум 4 следующие маш.такта к ОЗУ "не лезет", то это нисколько не мешает. Расход деталей три КП11, две 561ИЕ10 и пара корпусов 1533 логики. Конечно ради 1 мб паять такую схему лень, а вот ради SIMM 64 мб, труд окупается.

Сначала попробую поставить SIMM 1 мб, используя наполовину. Тогда период регенерации будет 8.3 МСЕК. Надеюсь заработает. 512 кб всё-же прятнее, чем только 256 кб.

Для псевдографических игр и системных утилит, где графики мало, требования по скорости ниже, а математики будь здоров сколько, ЯВУ вполне себе инструмент

Думаю, что при реальном такте КР580 в 1.3 МГЦ серьёзный претендент на инструмент программиста это PL/M, дающий такой же эффективный код, как ассемблер. Кстати, Гарри Килдел, автор PL/M, утверждал, что для больших программ он даёт более эффективный код, чем программа написанная человеком на ассемблере. Но и СИ, думаю тоже для игр подойдёт. Лучше, конечно, иметь эффективный по объёму кода СИ и критичные СИ-процедуры переписывать на ассемблере.

Если бы был эффективный СИ-компилятор, позволяющий сделать игру в кодах КР580 с объёмом до 28 кб, т.е размером с ОЗУ пользователя, я был бы рад. Где взять хороший компилятор? Хотя я намного больше программировал на СИ, Паскаль мне нравится больше. Возможно можно часть кода писать на СИ или Паскале, а критичные функции на PL/M?

Для игр для РК86 имеющего ДОС можно использовать СИ. Средствами ДОС при старте игра может загрузить файл-оверлей в расширенное ОЗУ (любой конструкции). Тогда в основном ОЗУ размещаем программный код, а, например, в другой банке - графику уровней. Кстати, если спрайты берутся из ПЗУ фонта, то игра фактически состоит только из кода и графики для рисования пейзажей. Тогда в 28 кб даже BDS-C вполне сможет уместить код почти любой игры. Так что для текстовых машин СИ можно применить, если критичные С-процедуры переписать на ассемблере. И фактически никто ещё не писал программ для РК86 на ЯВУ, т.к в 80-е они были недоступны.

RVV у меня жёстко зашит в коде для инверсии, а вот HLGT можно хоть сейчас использовать для коммутации фонтов. Собственно, он и используется в комбинации с GPA1,GPA2 для выбора одного из восьми фонтов при эмуляции Партнёра

Спасибо за информацию. Значит в эмуляторе ПАРТНЁРА можно написать программу с спрайтами в ПЗУ фонта. Ещё бы знать, чем этот ПАРТНЁР отличается от нормального РК86. Не буду в ПАРТНЁРЕ разбираться, а думаю, что изменив в конфиг-файле ПАРТНЁРА адреса портов и имя файла ROM-BIOS, получу желаемый конфиг для РК86. А атрибут RVV, значит, жёстко зашит в код самого эмулятора и конфигом его для иных целей не задействовать.

[tnt23]

Кто-нибудь знает максимальный период регенерации SIMM 1 мб?

Определяется типом использованных микросхем DRAM на модуле.

Вообще же можно не изобретать велосипед, а почитать про технологию регенерации CAS-before-RAS (CBR), например, тут: https://www.pjrc.com/mp3/simm/simm.html

[Vladimir_S]

А в чем кайф ставить динамическую память в РАДИО-86РК? Это ведь супер хреново.

[Vital72]

А в чем кайф ставить динамическую память в РАДИО-86РК? Это ведь супер хреново.

А в чем кайф собирать и даже что-то делать на РАДИО-86РК? Это ведь супер хреново.

[barsik]

А в чем кайф ставить динамическую память в РК86? Это ведь супер хреново.

В чём же здесь "супер хреновость"? Наоборот, хреновость когда их нет. Тогда и возникают компьютеры типа ZX80 c ОЗУ в 1 кб (хотя тогда были доступны РУ5, они стояли в Apple уже в 1976). Как иначе получить мегабайты, что же мне ставить килограмм 62256-тых? Но более важный довод в том, что у меня есть куча SIMM от 386,486 и ПЕНТИУМ, которые лежат мёртвым грузом. У меня наберётся из 62256 и w24257 объём в 512 кб, но я замучаюсь их монтировать в таком количестве и просто жалко тратить 10-ти мегагерцовые ОЗУ на такт 1.77 МГЦ. К тому же 512 кб слишком мало. Однажды в начале 90-х я уже пытался поставить в РК 62256 вместо РУ5-тых. И ничего не получилось (не хватило ума). Поэтому у меня возникло предубеждение против статических ОЗУ на РК86.

В компьютерах с интегрированным видео-генератором, к которым относятся все самоделки, регенерация динамических ОЗУ происходит сама по себе, в ходе видео-вывода. Разве, если бы авторы РК применили вместо 2-х банок РУ3-их 64 штуки 541РУ2 было бы лучше? Сам я конечно намного больше люблю антикварные ОЗУ 2114 и 2102 ( (541РУ2 и 565РУ2) и даже сделал на них комп с текстовым адаптером, но все приличные компьютеры 80-х использовали именно динамические ОЗУ. Потому что соотношение ёмкость/цена у них на порядок лучше.

Кто-нибудь знает максимальный период регенерации SIMM 1 мб?

Определяется типом использованных микросхем DRAM на модуле.

Это ясно любому. Но я вообще-то просил дать число в миллисекундах.

Вообще же можно не изобретать велосипед, а почитать про технологию регенерации CAS-before-RAS

Спасибо за подсказку про CAS-before-RAS. Это конечно, существенно упрощает узел регенерации. Эта идея мне пригодится для изготовления периферийной платы памяти для ИРИШИ, а для РК86, обойдусь без специального узла регенерации, т.к сам РК86 это сделает.

Наконец, сам нашёл информацию о временах регенерации SIMM.

refresh times for DRAM have been improving: from 8 MS for 1M chips, 32 MS for 16M chips, to 64 MS for 256M chips. This improvement is achieved by developing transistors that leak significantly less.

Т.е память мне не изменила и у них действительно время регенерации 8 МСЕК. Кроме того, я обнаружил в своих рассуждениях в предыдущем посте ошибку. В РУ7-х вектор регенерации равен 9, а в ОЗУ 1 мб вектор регенерации равен не 11, а 10, т.к каждый лишний вывод даёт 2 адреса. Тогда 1024 ячейки перебираются при выводе 1024:78= 13 строк, что происходит за 13*10*64 МКС = 8.3 МСЕК. Так, что РК86 регенерирует целый мегабайт, причём всего за 8.3 МСЕК. Хотя 8.3 МСЕК больше, чем 8 МСЕК, но думаю запас есть и сработает на крайнем пределе. Если возникнут проблемы, то, или изменю ПЗУ F800, чтобы ВГ75 программировалась не на 10 линий растра в строке, а на 9, что даст период регенерации в 13*9*64 = 7.4 МСЕК, что намного меньше требуемых 8 МСЕК. Или заменю кварц на повышенный соответственно перекрутив частоту строк в видео мониторе.

Сейчас решаю, что применить: 16 мб SIMM от 486-той, 1 мб (или 256 кб) SIMM от 386-той или 256 мб SIMM от ПЕНТИУМ. Про SIMM от ПЕНТИУМ и думать не стоит, т.к там три сотни выводов. В одно-мегабайтовых удобно, что всего 30 контактов и к одной SIMM подпаяться можно, но для 4-х лучше ставить родной разъём.

В SIMM от 486-той 72 вывода, так что придётся распиливать одну из моих 486-тых плат, чтобы выпилить кусок из 4-х (или 2-х) разъёмов для втыкания туда SIMM на 72 вывода. Если поставлю два разъёма, то смогу поставить 2 штуки SIMM 16 мб и использовать их как 2 мб каждая. Т.к в РК86 при видеовыводе перебираются только 11 адресов, то (без схемы регенерации на принципе CAS-before-RAS) больше, чем 2 мб в каждом SIMM не получить. А 4 мегабайта полученные из двух SIMM на 72 вывода - это как раз то, что надо.

30-ти выводных SIMM по 1 мб у меня 4 штуки. Так что получаются те же 4 мб, но уже на 4-х SIMM. А для 4-х штук уже придётся ставить разъёмы, для чего придётся распилить мою любимую 386-тую. Скорее всего и буду применять 30-ти контактные SIMM от 386-той, т.к они почти то же самое, что и РУ7. А 72-х контактные SIMM слишком подозрительны (зачем столько контактов, если адресов лишь ненамного больше, чем у 30-ти контактной SIMM).

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

А в чем кайф собирать и даже что-то делать на РАДИО-86РК? Это ведь супер хреново.

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

[Vital72]

сарказм уже не понимаем?