Эмуляторы отечественных компьютеров

[Patron]

Скорее доделывай КГД и КЦГД.

Обсуждаемый эмулятор пишется как "наглядная иллюстрация" разрабатываемого мною модульного API эмуляции.

Отсюда следующие проблемы:

1. API "поток видео" - далеко не самая важная часть модульного API.

2. Нет смысла эмулировать источники потока видео ( т.е. видеоконтроллеры ), пока не написан "универсальный монитор видео".

Если в любом конфигурационном файле эмулятора подставить консоль в качестве приёмника байтового потока (вместо универсального терминала), то сразу станет понятно, почему перед написанием эмулятора последовательного порта DL11 - был написан эмулятор универсального терминала :)

Кстати, если при этом не отключать от потока байтов терминал - можно запускать игрушки и наблюдать на консоли "дамп потока байтов".

3. При эмуляции КГД нужно одновременно эмулировать источник "тексто-графического" видеосигнала ( например - КСМ ).

4. Для эмуляции КЦГД нужно эмулировать шину 1801ВМ2 ( т.е.плату МС1201.02 ).

[Advertiser]

[Titus]

3. При эмуляции КГД нужно одновременно эмулировать источник "тексто-графического" видеосигнала ( например - КСМ ).

4. Для эмуляции КЦГД нужно эмулировать шину 1801ВМ2 ( т.е.плату МС1201.02 ).

Я знаю) У меня в эмуляторе-то они есть.
Хотя, в моем эмуле КГД эмулируется, а КСМ нет. И без проблем. Т.е. почти без проблем. Кроме случаев, когда КСМ и КГД используются вместе.

[Patron]

У меня в эмуляторе-то они есть.
Хотя, в моем эмуле КГД эмулируется, а КСМ нет. И без проблем.

При закрытой "монолитной" эмуляции проблем вообще не слишком много.

Но если речь заходит про модульную эмуляцию с обменом потоками данных через открытые интерфейсы, когда модуль эмуляции КГД принимает "поток видео" от другого модуля ( например, от эмулятора КСМ ), добавляет туда свою картинку и передаёт по "потоку видео" на эмулятор устройства отображения - то нужно для начала хотя бы написать API потока видео :)))

[Titus]

когда модуль эмуляции КГД принимает "поток видео" от другого модуля ( например, от эмулятора КСМ ), добавляет туда свою картинку и передаёт по "потоку видео" на эмулятор устройства отображения - то нужно для начала хотя бы написать API потока видео ))

Не тормознуто ли получится?

[Patron]

Не тормознуто ли получится?

Посмотрим.

Локально (если не через интернет) в потоке видео будут передаваться указатели на объект "кадр потока видео". Само-по-себе-изображение будет представлено массивом 8-битных значений RGB (для чёрно-белых кадров все три значения будут одинаковы).

Таким образом, типичный эмулятор "видеоустройства" будет несколько (до 60) раз в секунду получать ссылку на кадр, модифицировать изображение и передавать ссылку дальше в поток.

Сколько сложений матриц RGB в секунду сможет выполнять типичный сегодняшний комп для размерностей порядка 800х400..

Мне кажется, что где-то 1000 в секунду ( или 10'000 ? ).

[Titus]

Сколько умножений на константу (в типичном случае "равновесного" сложения двух кадров - на 0.5) и сложений матриц RGB в секунду сможет выполнять типичный сегодняшний комп для размерностей порядка 800х400..

Мне кажется, что где-то 1000 в секунду ( или 10'000 ? ).

Экран 800x400 - это милион байт примерно. Значит миллион байт КСМ сложить со сдвигом с миллионом байт КГД, 60 раз в секунду. Т.е. не менее 200мипсов одну математику, если влоб, побайтно. Но, учитывая, что написано будет на Си. В общем, на 2ГГц'овом проце больше, чем 250 фпс рассчитывать наверное не стоит. Но это если писать на Си, не на асме.

Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.

[Patron]

Экран 800x400 - это милион байт примерно. Значит миллион байт КСМ сложить со сдвигом с миллионом байт КГД

Хотя у КГД изображение 400x286, а у КСМ - 800х286, но поскольку они используют "общий" видеосигнал, то очевидно, что формат массива изображения у них одинаковый, но КГД "заполняет" только каждую вторую ячейку.

учитывая, что написано будет на Си

Ограничения API распространяются только на интерфейсы. Все интерфейсные объекты должны быть написаны на С++ в Visual Studio. Но к интерфейсному коду на C++ авторы эмуляторов могут линковать в Visual Studio что угодно. Хотя, на мой взгляд - ассемблерные вставки и специализированные библиотеки - самое оно.

Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.

Вообще-то, при сложении двух кадров умножение требуется только для моделирования "притухания" исходного кадра при прохождении через смеситель. Для простого объединения двух изображений (на мой взгляд) достаточно обычного сложения с ограничением максимального значения ( т.е. когда 100% + 100% = 100% ).