«Специалист» в 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» можно было поддержать и размер поддерживаемого ОЗУ изменять в
настройках оперативно.