nedoPC.org

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

ОЗУ экрана лучше частью общего озу сделать - причём и знакогенератор (на 2048 букв) и собственно видеопамять с кодами букв (как я уже говорил - 2-байтовыми) - можно в разные страницы запихнуть (половинки кода буквы кстати тоже можно разбить по страницам - код символа в одну, его атрибут - а это цвет и номер фонта - в другую) и кстати установку атрибутов можно сделать по специалистовски - автоматикой

P.S. видео вообще отдельно - программное заполнение экрана медленное будет

Как оно может быть медленным, если им будет заниматься отдельный проц?
- этот вариант я имел в виду.

медленным будет ПРОГРАММНОЕ ЗАПОЛНЕНИЕ ЭКРАНА - например когда тебе надо нарисовать на экране какую-то картинку, заполняющую 100% порщади кадра - если её в какой-то порт сувать, то это будет медленнее чем проц просто будет в свою непосредственно доступную память лить

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

и как же ты на графическом языке скомандуешь ему - а ну ка возьми с хард-драйва вот этот JPEG и изобрази его на полный экран?

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

Видеопроц ненужен - вот если бы у нас был FPGA, то можно было бы помудрить, а тут - ненужен

Ещё одна хотелка - страницы видеопамяти (2 либо 4), где храняться коды букв, должны располагаться друг над другом с возможностью плавного скроллинга сквозь них - типа для генерации титров для видео

Наверное чего-то сложновато получилось - вобщем ещё раз:
имеем 80x30 знакомест для символов 8x16
имеем 8 фонтов по 256 символов в каждом (т.е. всего 2048 символов)
для хранения битмапов этих фонтов нужно 32K памяти (можно подключать в общую память процессора половинками по 16К)
далее имеем две области по 16К - в одной из них у нас будет место для 204 текстовых строк (по 80 символов в строке), а в другой - место для их атрибутов (цвет фона - 2 бита, цвет буквы - 3 бита, номер фонта - 3 бита)
желательно иметь возможность скролировать, т.е. указатель на первую строку, видимую на экране может указывать на любую из 204-80=124 строк (идеальным наверное было бы иметь воможность попиксельного скроллирования, но тогда это будет слишком сложно)
в общую память процессора(ов) можно подключить любую из этих 16К областей для непосредственного доступа, однако кроме того предлагается сделать вариант указания атрибутов аля спец - сохраняем в некоем порту байт и далее ставим только буквы, а железо само размножает атрибуты
по видимому надо предусмотреть отключение этой фичи - можно скажем договориться, что 0, записанный в этот порт, отключает автоматическое размножение атрибутов
теперь о цветах - 3 бита цвет текста это 8 цветов, причём писишный RGB (0 - чёрный, 1 - синий, 2 - зелёный, 3 - бирюзовый, 4 - красный, 5 - фиолетовый, 6 - коричневый, 7 - белый)
и 2 бита на фон - вроде как только 4 - можно выбрать цвета, которые обычно используются для задника (ну скажем чёрный, тёмно-синий, серый, ярко-белый), а можно иметь палитру на 4 цвета - либо 3 битную либо 4 битную (с яркостью)

P.S. 8 цветов пожалуй мало - надо бы 16 (полная стандартная EGA/VGA-палитра), но тогда на фон останется только 1 бит - чёрный (#000000) и ярко-белый (#FFFFFF)? Либо сделать этот бит битом инверсии и второй цвет всегда будет чёрным? Либо задавать цвет задника через порт и он будет одинаковым для всех букв в пределах экрана...

Что-то мне это напоминает...
А, компьютер Арго!
Но там для этих целей ВГ75 стояла. А знакогенератор вывернут по Спектрумовски (и проц был Z80), поэтому там был несложный эмулятор Спектрума.

Вот такой концепт видится мне.

1. Конструкция "слотовая". Каждый процессор и ресурс - на своей платке в полной требуемой обвязке.

2. Арбитр на кросс-плате со слотами. Адреса и данные на слотах - параллельны. Управляющие сигналы, вроде тактов F1, F2, EN, RD, WR, RDY и IRQ (и т.д.) - у каждого слота индивидуальные. На F1 и F2 каждого гнезда заводится своя фаза тактовой последовательности, RD и WR пропускаем через мультиплексор, который будет выбирать сигнал нужного процессора, сигнал EN будет подключать модуль к шине в свой временной слот простым включением Z буферов. Получается, что каждый процессорный модуль будет буферизирован. Это касаемо процессорных слотов.

3. Остальные слоты ресурсов имеют полностью параллельные сигналы, в том числе сигналы RD/WR после мультиплексирования. Таким образом, каждый процессор имеет полный доступ ко всем ресурсам.

4. Так же, предлагаю "фильтровать" память/порты, при этом просто поставить регистр а не использовать ВК28/ВК38. И в портах выделить один порт с физическим номером процессора. Это позволит тусовать платки процессоров между собой, запускать их одновременно и независимо, потому как при применении супервизора он автоматом становится слабым звеном.

Ну вот как-то так.

Угу, а что по поводу видео думаешь?

Если хочется хорошее видео, то надо увеличить адресное пространство. Предлагаю сделать как было сказано на дружественном ресурсе. Вводится еще одни регистр номера банка, который указывает с каким банком сейчас работает процессор. Технику сделать как уже пролетала: A15 и A14 проца пропускаем через регистр номера банка, сами регистры обнуляемы по сбросу принадлежащего процессора (устанавливая 0 банк во всем пространстве его адресов). Таким образом, адресное пространство общих ресурсов возрастает и туда можно поставить ОЗУ больших размеров и соответственно можно замапить хороший графический адаптер.
Адаптер предлагаю гибридный: фон графический с наложенным текстовым экраном. Один из атрибутов символьного экрана становится цветом "прозрачности", позволяя во первых быстро оперировать с текстом, причем с обратной связью, а во вторый "врезать" графику в быстрый текст, просто вырезав окно, как оверлей.
Конкретики пока не вижу, но нужно просто выставить требования к узлам, и начинать надо с ядра: модули процессоров и кросс.

Без отдельного "управляющего" мне в будущем видится проблема сложности программного обеспечения. Одно дело, когда один сказал, а все делают, другое - когда начинается демократия. Жизнь показывает, что при дефиците ресурсов сатрапское управление заметно эффективнее коллегиального .