nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 20 Jun 2018 22:37



Reply to topic  [ 7 posts ] 
«Специалист» в Proteus 
Author Message
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Я давно хотел сделать наш любимый «Специалист» в среде Proteus...
Но раньше модели процессора не было, а сейчас эта модель у нас есть! :kruto:
Оставался непонятный момент - как быть с графическим экраном «Специалиста»?

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

Image

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

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

В общем, рабочую модель этого SRAM/LCD для «Специалиста» я таки сделал...
Attachment:
LCDSP580.gif
LCDSP580.gif [ 20.94 KiB | Viewed 1638 times ]

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

Дисплей в 384х256 точек получается довольно большой, и при наличии процессора, ПЗУ
и селектора - он зело вылезает за край стандартного проекта. :lol:
Attachment:
LCDSP580b.gif
LCDSP580b.gif [ 18.18 KiB | Viewed 1638 times ]

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

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

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

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

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

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

_________________
iLavr


29 Jan 2016 02:19
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Самое неприятное, что у экрана проекта Proteus-а своя собственная метрика, измеряемая
в его собственных экранных единицах.

По HELP-у они называют эти единицы "юниты"...
Attachment:
P_units.gif
P_units.gif [ 3.78 KiB | Viewed 1624 times ]

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

_________________
iLavr


29 Jan 2016 09:26
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Так что «Специалист» придется умещать на двух стандартных листах

Хотя, пожалуй, стандартный «Специалист» можно и на одном листе уместить, если постараться...
Attachment:
LCDSP580L.gif
LCDSP580L.gif [ 19.62 KiB | Viewed 1616 times ]

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

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


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

Attachment:
LCDSP580Y.gif
LCDSP580Y.gif [ 13.7 KiB | Viewed 1615 times ]

_________________
iLavr


29 Jan 2016 13:01
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
...графика-то отрисовывается верно, а все нечеткости возникают,
когда она "упихивается" Протезусом в экранные размеры LCD по точкам

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

Вот я для проверки заполнил весь экран сигнатурой 55H, должны быть линии светлые,
шириной в точку, чередующиеся с тёмными - тоже шириной в точку.
Но наблюдается вот что:
Attachment:
LcdCHESS.gif
LcdCHESS.gif [ 10.47 KiB | Viewed 1607 times ]

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

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

_________________
iLavr


29 Jan 2016 16:26
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Ну и при глубоком размышлении с цифрами проблема тут вырисовывается очень неприятная... :osad:

Получается, что Proteus пытается "упихать неупихуемое", от чего и происходит несуразица с графикой:
Attachment:
LcdDOTS.gif
LcdDOTS.gif [ 16.65 KiB | Viewed 1594 times ]

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

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

У меня разрешение монитора - 120 dpi, то есть, 120 пикселей дисплея на "мировой дюйм".
Графические функции Proteus работают с условными единицами "units", и в "мировом дюйме" их 1000.
VSM HELP wrote:
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)
VSM HELP wrote:
Определяет коэффициент масштабирования, используемый для всех функций векторной графики. Коэффициент масштабирования по умолчанию составляет 1000 единиц на мировой дюйм.

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

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

_________________
iLavr


30 Jan 2016 12:12
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Остается еще одна тема для размышления: графические функции Proteus, видимо, на всякий случай, дают
возможность узнать Windows DC (device context) своего графического объекта.
И VSM API позволяет использовать функции Windows GDI, не поддерживаемые в самом VSM API.
Ну а функции Windows GDI работают с реальными точками экрана, если я ничего не забыл...
А вот этот трюк с функциями Windows GDI мне помог!!! :kruto:
Attachment:
Lcd_GDI.gif
Lcd_GDI.gif [ 4.02 KiB | Viewed 1578 times ]

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

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

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

vsm.hpp определяет
Code:
struct BOX  { LONG x1, y1, x2, y2; };


А это уже определено в windows.h:
Code:
typedef struct tagRECT
{
    LONG    left;
    LONG    top;
    LONG    right;
    LONG    bottom;
} RECT, *PRECT, NEAR *NPRECT, FAR *LPRECT;


Поэтому компилятор С++ ругается на:
Code:
   lcd_width  = lcdarea.x2-lcdarea.x1;
   lcd_height  = lcdarea.y2-lcdarea.y1;

и необходимо внести правку:
Code:
   lcd_width = lcdarea.left-lcdarea.right;
   lcd_height = lcdarea.top-lcdarea.bottom;

_________________
iLavr


31 Jan 2016 16:22
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Ну а функции Windows GDI работают с реальными точками экрана, если я ничего не забыл...

А они ещё и работают ЗАМЕТНО БЫСТРЕЕ функций VSM API, потому как нет масштабирования !!! :kruto:
Но главное - на изображении всё четко, как в приличном эмуляторе ПК «Специалист»!!! :esurprised:
Attachment:
LCD580GDI.gif
LCD580GDI.gif [ 11.03 KiB | Viewed 1571 times ]

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

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

_________________
iLavr


31 Jan 2016 20:56
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.