«Специалист» в Proteus

[Lavr]

Я давно хотел сделать наш любимый «Специалист» в среде Proteus...
Но раньше модели процессора не было, а сейчас эта модель у нас есть!
Оставался непонятный момент - как быть с графическим экраном «Специалиста»?

Ну и в этой связи я давно присматривался к самой крупной модели LCD Proteus-a:
256x256 точек... На нём обычно шахматы демонстрируют в Proteus-е...



Ну и я сегодня даже в шахматы чутка поиграл, чтобы созреть...

В общем решил я сделать такую же модель LCD для «Специалиста», но заложить в неё
несколько иную идеологию: это должно быть статическое ОЗУ размером в 16384 Байта,
верхние 12 кБайт которого отображаются на экране LCD размером в 384х256 точек.
В этом случае весь хлам со счетчиками регенерации ОЗУ и формирователями растра из
схемы «Специалиста» удаляем нафиг, и получается весьма компактная схема.

В общем, рабочую модель этого SRAM/LCD для «Специалиста» я таки сделал...

LCDSP580.gif

И тут выяснились два неприятных 'НО'!...

Дисплей в 384х256 точек получается довольно большой, и при наличии процессора, ПЗУ
и селектора - он зело вылезает за край стандартного проекта.

LCDSP580b.gif

Так что «Специалист» придется умещать на двух стандартных листах - но не это самое
неприятное.

Самое неприятное, что у экрана проекта Proteus-а своя собственная метрика, измеряемая
в его собственных экранных единицах.
Окно графики модели LCD размером в 384х256 точек в метрике Proteus-а составляет 5010 на
3310 экранных единиц. Причем, надо укладывать прямоугольник в шаги сетки 10...50...100 ед.

Получается, что наши 384х256 точек, ну хоть застрелись, не уложить кратно в его 5010х3310 ед.,
как их не подбирай. Следствие этого - на изображении LCD "проглатываются" линии в 1 пиксель
и могут появляться ненужные светлые линии, на скриншотах это видно.

Кардинально решить это можно, увеличив размеры LCD вдвое, но тогда он просто выглядит очень
огромным, и один будет занимать лист проекта. А я еще хотел для "кошерности" и модель
оригинальной клавиатуры «Специалиста» на первый лист проекта разместить...

В общем, модель SRAM/LCD в 384х256 точек работает весьма шустро, благодаря очень продуманной
организации графики экрана «Специалиста» ... но некоторые проблемки имеются.

Что ж... "будем посмотреть"...

[Lavr]

Самое неприятное, что у экрана проекта Proteus-а своя собственная метрика, измеряемая
в его собственных экранных единицах.

По HELP-у они называют эти единицы "юниты"...

P_units.gif

Чем-то они мне напоминают "твипы" от M$... В "твипах" по умолчанию работает большинство
графических функций в Visual Basic, если не изменит настройки...

[Lavr]

Так что «Специалист» придется умещать на двух стандартных листах

Хотя, пожалуй, стандартный «Специалист» можно и на одном листе уместить, если постараться...

LCDSP580L.gif

Порт 580ВВ55А положить на бок на месте временного регистра ввода, и модель клавиатуры
сделать не шибко большую...

Пока пытаюсь довести до ума отображение графики на модели LCD.
Здесь вариант, когда весь экран «Специалиста» 384х256 уложен по центру LCD
в юнитах - 3840х2560. Но идеальной четкости тоже это не дало...


P.S. В увеличенном масштабе видно, что графика-то отрисовывается верно, а все нечеткости возникают,
когда она "упихивается" Протезусом в экранные размеры LCD по точкам.

LCDSP580Y.gif

[Lavr]

...графика-то отрисовывается верно, а все нечеткости возникают,
когда она "упихивается" Протезусом в экранные размеры LCD по точкам

Да и у самого фирменного дисплея от Labcenter Electronics - те же самые проблемы...

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

LcdCHESS.gif

Ну и у меня точно такой же эффект имеет место быть...
Видимо лучше, чем сам Labcenter Electronics, сделать графику их моделей LCD трудно...

Но еще поразмышляю чутка, неприятный в общем-то эффект...

[Lavr]

Ну и при глубоком размышлении с цифрами проблема тут вырисовывается очень неприятная...

Получается, что Proteus пытается "упихать неупихуемое", от чего и происходит несуразица с графикой:

LcdDOTS.gif

Понятно, что желаемые 256 точек модели LCD не упихать без искажений в 265 реальных пикселей экрана.
Поэтому и была у меня мысль попадать графикой в реальные пиксели экрана, если их заведомо хватает,
и располагать это изображение посредине прямоугольника модели LCD.

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

У меня разрешение монитора - 120 dpi, то есть, 120 пикселей дисплея на "мировой дюйм".
Графические функции Proteus работают с условными единицами "units", и в "мировом дюйме" их 1000.

By default, the units are defined in terms of 1000 pixels per world inch.

Значит, соотношение следующее:
1000 "units" = 120 пикселей дисплея, и на 1 единицу приходится 120/1000=0,12 пикселея дисплея,
или на 10 единиц, соответственно, приходится 1,2 пикселя дисплея.

Получается, что работая с графическими функциями Proteus, я принципиально не могу точно попасть в реальные пиксели дисплея, даже если мне их хватает заведомо.

В VSM API есть функция VOID ICOMPONENT::setdrawscale (INT ppi)

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

Но я подозреваю, что существующего соотношения и ей не преодолеть:
на 10 единиц приходится 1,2 пикселя дисплея.
поскольку такие функции работают обычно с целыми числами.

Остается еще одна тема для размышления: графические функции Proteus, видимо, на всякий случай, дают
возможность узнать Windows DC (device context) своего графического объекта.
И VSM API позволяет использовать функции Windows GDI, не поддерживаемые в самом VSM API.
Ну а функции Windows GDI работают с реальными точками экрана, если я ничего не забыл...

[Lavr]

Остается еще одна тема для размышления: графические функции Proteus, видимо, на всякий случай, дают
возможность узнать Windows DC (device context) своего графического объекта.
И VSM API позволяет использовать функции Windows GDI, не поддерживаемые в самом VSM API.
Ну а функции Windows GDI работают с реальными точками экрана, если я ничего не забыл...

А вот этот трюк с функциями Windows GDI мне помог!!!

Lcd_GDI.gif

Это Rectangle(ghdc,10,10,100,100); - и прямоугольник со сторонами 90х90 в пикселях экрана - "с точностью до миллиметра"!

Жалко только, что столько времени зря потерял...

Если кто-либо захочет использовать функции Windows GDI в графике Proteus, там может случиться небольшой конфликт между windows.h и vsm.hpp, почему я несколько и задержался...

vsm.hpp определяет

Code: Select all

struct BOX  { LONG x1, y1, x2, y2; };

А это уже определено в windows.h:

Code: Select all

typedef struct tagRECT
{
    LONG    left;
    LONG    top;
    LONG    right;
    LONG    bottom;
} RECT, *PRECT, NEAR *NPRECT, FAR *LPRECT;

Поэтому компилятор С++ ругается на:

Code: Select all

   lcd_width  = lcdarea.x2-lcdarea.x1;
   lcd_height  = lcdarea.y2-lcdarea.y1;

и необходимо внести правку:

Code: Select all

   lcd_width = lcdarea.left-lcdarea.right;
   lcd_height = lcdarea.top-lcdarea.bottom;

[Lavr]

Ну а функции Windows GDI работают с реальными точками экрана, если я ничего не забыл...

А они ещё и работают ЗАМЕТНО БЫСТРЕЕ функций VSM API, потому как нет масштабирования !!!
Но главное - на изображении всё четко, как в приличном эмуляторе ПК «Специалист»!!!

LCD580GDI.gif

Самое главное - заработало!!!

Осталось причесать кучу мелочевочки, чтобы придать модели некоторую универсальность
через опции настройки...
Чтобы и «Орион-128» можно было поддержать и размер поддерживаемого ОЗУ изменять в
настройках оперативно.

[Lavr]

.
Понадобилась мне в связи с одной затеей компактная и желательно шустрая модель ПК "Специалист" под Proteus.

Вспомнил я, что уже начинал делать тут нечто похожее, и увидел я, что ещё в 2016 году...

я еще хотел для "кошерности" и модель оригинальной клавиатуры «Специалиста» на первый лист проекта разместить...

В общем 10 лет спустя звёзды сошлись правильно и я это, наконец, сделал!

Sp580KBD1.png

Модель экрана, изображающая LCD, работает весьма шустро!
А вот алгоритм, сканирования клавиатуры в ПК "Специалист" очень и очень медленный...

Но вспомнил я, что у меня есть любимая игрушка и она весьма шустрая!

К580GAME-1.png

Тем более, что цветными клавишами можно играть, нажимая их на клавиатуре, если выставить мышью фокус на панель клавиатуры!
Собственно, потому и кнопки круглые - они дают связь с реальными клавишами...

Ну что сказать про игровой процесс? Напоминает анекдот про трёх наркоманов:

- Кошка...
(прошел час)
- Пробежала...
(прошло 2 часа)
- Задолбали вы своими разговорами...

Но если серьёзно, работает быстрее, нежели модели с эмуляцией видеоконтроллера и TV-дисплея.
Хотя и всё равно слишком медленно.

Короче, все "медленные плюшки" ниже в архиве.

SP580_LCD.zip

Даже интересно, вдруг у кого шустрее заработает!
Я тестировал всё на ноутбуке с Intel Atom 1.8 ГГц, встроенное видео.

[Lavr]

В общем 10 лет спустя звёзды сошлись правильно и я это, наконец, сделал!

И сразу вдруг ЭТО мне что-то очень знакомое напомнило!

teletype-asr35-keys.png

алгоритм, сканирования клавиатуры в ПК "Специалист" очень и очень медленный...

Я, честно говоря, на большую скорость и не рассчитывал, потому как ещё коллега PVV здесь писал:

Для этого эмулируемого ПК быстродействие таково, что можно с клавиатуры набирать команды и смотреть их выполнение(~2c нужно удерживать кнопку для ее детектирования на один символ).

Я сегодня попробовал понажимать, ну не 2 секунды, меньше, но нажимать приходится довольно странно: нажать-подержать-отпустить и так раза 3...4.
Видимо алгоритм опроса клавиатуры в ПК "Специалист" зело отличается от оного в ПК "Радио-86 РК", что реально так и есть.

Тем более, что цветными клавишами можно играть, нажимая их на клавиатуре, если выставить мышью фокус на панель клавиатуры! Собственно, потому и кнопки круглые - они дают связь с реальными клавишами...

А вот нажимая клавиши на клавиатуре, реакции модели можно добиться почему-то быстрее!

Я проделал эксперимент - назначил [D] клавишу "1", [,] клавишу "2", [F] клавишу "3", а [Enter] оставил для нажатия курсором мыши.
Результата добился весьма быстро!

SpKey_2.png

Если кто хочет поэкспериментировать, можно вывести свойства клавиатуры как текст, там множество строк типа:

{A1=ROUND,300,-300,300,1}
{A2=ROUND,700,-300,300,2}
{A3=ROUND,1100,-300,300,3}

A (и другие буквы) 1 (и другие цифры) - это координаты кнопки в прямоугольной матрице, а 1} - назначенная кнопке клавиша.
Можно подставить и буквы клавиш, но в Хелпах предупреждают, что многие буквы работать не будут, так как являются "горячими кнопками" самой среды Proteus.

Кто делает проекты Proteus с кнопками типа BUTTON, в Proteus, начиная с версии 7.xx можно сопоставить им клавиши клавиатуры от 0 до 9 в свойствах кнопки посредством записи KEY=n.

SpKey_1.png

В Proteus версий 6.xx это не работает...