nedoPC.org

Взялся я восстановить эту схему, благо растактовки команд теперь стали очень близки к оригинальному К580ВМ80А!

И угораздило меня задуматься, а зачем я тогда навертел такой сложный буфер?

Понятно, что мне был нужен аналог К580ВА86, понятно, что в Proteus его нет...

Но ведь есть же весьма близкий аналог 74LS245...

И радостно впиявил я 74LS245 в проект... но забыл старую мудрость:"Если оно работает - не трогай!"

Больше суток угробил, чтобы вспомнить, что 74LS245 на шине глючит так, что спасу нет!
И я не первый раз с ней бодался...

А глюк (или не глюк) у модели ШФ 74LS245 вот какой: если она включена на передачу А-->B,
но со стороны А состояние высокоимпедансное, то на выводы В она передаёт лог."1".
Точно так же если она включена на передачу В-->А...

Если задуматься... то вроде это и не глупо... но по шине такие глюки и конфликты начинаются!

Первоначальный вариант в нулевом приближении заработал!

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

Хотя я схеме не поверил и вновь проверял все узлы заново - но тоже полезно оказалось.
Кое-где подсократил то, что было явно излишеством.
И в этом варианте я сразу учёл, что шина адреса - не чистый счетчик, как предполагал ранее.
Все нужные адреса защелкиваются в регистр по фронту SYNC.

Теперь необходимо точно допилить TV-развёртки, и постараться сделать их схемотехнически компактней...

Лучше выходить из формирования экрана раньше, тогда - да, размер по вертикали будет меньше.
Постом выше я ошибочно вышел из 170-й строки, хотя планировал выйти - из 192-й...
Только необходимо будет гасящим импульсом компенсировать размер по вертикали.

А кадр размером 256х256 выглядит вот так:

Собственно, под такой размер это всё изначально и проектировалось...

В общем затеялся я выполнить этот проект, чтобы убедиться, что в СССР при желании могли сделать что-то типа
zx80 (zx81) но на микропроцессоре К580ВМ80А.
Собственно, этот проект как есть - хороший аналог zx80, но с графическим экраном.
Да, я понимаю, что в то время память была дорогой, поэтому у zx80 экран алфавитно-цифровой.

Если в программную генерацию импульса обратного хода по кадру добавить опрос клавиатуры, то получится полная
аналогия действий zx80: микропроцессор формирует изображение программно-аппаратно, и если его послали что-то
делать - он отображение видео бросает и экран гаснет.
Выйдя из задачи, микропроцессор снова формирует изображение и опрашивает клавиатуру...

В оригинальном проекте у меня было устройство для ввода информации в проект из файла.

В Протеусе такой фичи нет, поэтому вместо видео-ОЗУ подключено ПЗУ, а видео-информация в него заложена
заранее из файла C000RAM.bin.
В этом файле изображение находится по смещению 4000Н, в экране оно - по адресу 0C000H до 0EFFFH.

Структура экрана следующая: каждые 32 байта от начала (два параграфа) - это изображение по строке.
Следующие 16 байт микропроцессор исполняет - это расчитаный по тактам импульс обратного хода по строке.
И так далее: следующие 32 байта - изображение, 16 байт - импульс обратного хода по строке...
Изображение 256х256 точек черно-белое.

Чтобы прекратить генерацию изображения, надо передать управление на адрес за диапазон 0C000H...0EFFFH.
Я передаю на адрес 0BFF0H, поскольку предполагаю, что с адреса 0F000H до 0FFDFH будет системное ПЗУ.
Порты ввода-вывода, как в ПК "Специалист-МХ", расположены по адресам 0FFE0H...0FFFFH .

Хотел я написать утилиту, формирующую из *.bmp файла *.bin-файл структуры экрана, но Венда 7 меня подвела.
А с понедельника мне будет довольно-таки некогда этим всем заниматься...

Поэтому - вот файлы проекта, выполненного под Proteus 6.7 Pro:

При запуске - светодиод внизу моргает синим - отработал обратный ход по кадру, после чего следует уверенно
нажать кнопку INT - начнётся генерация изображения.
Долго лучше не ждать, данная модель дисплея нуждается в кадровом импульсе О.Х. - сбрасывает буфер.
Без кадрового буфер переполняется и проект падает. Модель дисплея я взял как есть из проекта Galaksija здесь
на форуме, там такое предупреждение было, и факт имеет место быть...

А в этом архиве - вся теория с расчетами, разбор узлов схемы и осциллограммы.

Если вдруг я что-либо забуду или потеряю, начнём с этой точки возврата.

Не работает

Так написано же, что ошибка с tvdisplay.dll, тут я ничем помочь не могу.
Я выше предупредил, что она местная и может падать...


P.S. Можно поискать на форуме другую библиотеку, их несколько было.

Несколько слов по поводу этой динамической библиотеки, основной вариант которой, как считается,
находится здесь: http://www.nedopc.org/forum/viewtopic.php?p=152820#p152820
Но в разных ветках форума можно найти разные версии этой библиотеки.

Разнообразие вызвано тем, что по непонятным обстоятельствам она у кого-то работает, а у кого-то
не работает от слова совсем.

Первое и очень важное обстоятельство заключается в том, что у оригинала display.dll не очень
удачное название было выбрано, и она может вступать в конфликт с одноименной системной dll.

У меня на предыдущих ноутбуках всё работало хорошо и конфликта не было.
На текущем ноутбуке выяснилось, что есть системная библиотека display.dll и конфликт с ней:

В этом случае библиотеку надо переименовать, я переименовал в tvdisplay.dll, после чего в проекте
ткнуть мышью по этому значку:

Вывести свойства элемента как текст и display.dll заменить на tvdisplay.dll.

Также, поскольку я знал, что с display.dll бывают проблемы на разных компьютерах под разными
версиями Proteus, то я скачал с форума несколько заведомо рабочих проектов, где используется display.dll,
попробовал их на своём новом ноутбуке, и для этого своего проекта выбрал вариант, который, на мой взгляд,
работал наиболее корректно.

Представленный здесь проект я разрабатывал под Proteus 6.7 Pro и ОС Windows 7 Thin PC - предустановлена
она такая на моём ноутбуке...

Поскольку дальше в проекте предполагается таймер i8253, а под Proteus 6.7 Pro его модель не работает,
я этот проект проверил и под Proteus 7.7 Pro и той же ОС Windows 7 Thin PC - он полностью работоспособен.


P.S. Да, вот ещё... если используете элемент display в своём проекте, учитывайте, что названия
строчной и кадровой синхронизаций перепутаны: SYNC_H - это кадровая, хотя Horizontal -
это по строке, а SYNC_V - это строчная, хотя Vertical - это по кадру.
Я не знаю, исправлено ли это в итоговом варианте, но здесь в проекте это так... Сорри, фишка не моя...

Чего-то больше ни один проект не работает с этой dll. Скачал её исходник, скомпилировал, вроде заработало, но иногда всё равно падает. Стал её мучить под отладчиком, выяснилось:
Память для палитры не выделяется, при записи цветов в палитру происходит запись в не выделенный участок памяти и что-то там затирает.
При записи в буфер пикселов иногда пишет мимо буфера и происходит exception, хотя памяти для буфера выделяется в 10 раз больше чем реально необходимо.

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

Это очень полезное дело будет, если Вы этот вопрос одолеете!
Исходник не раз правили и переписывали, но всё равно она у кого-то да падает, а у кого-то и совсем не запускается...

Я решил не тратить время на борьбу с причудами Windows, поскольку
для утилиты, всего-то перекодирующей файл одного формата в файл
другого формата, это совершенно непринципиальный момент, так как
утилита такого типа вполне может быть консольной и не иметь никакого
интерфейса от слова совсем.

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

И как апологет использования Quick Basic в качестве первого учебного языка,
я решил использовать свой старый шаблон для утилит такого типа, где априори
есть некоторый интерфейс, процедуры поиска и открытия файла, ну и завершение
программы с выходом в систему.
В середине этого действа можно добавлять любой код, производящий действия
над входными данными из открытого файла.

Ну и мне было интересно, заработает ли всё это в итоге под Windows 7, поскольку
этот наш Интернет просто полон заявлений, что начиная с Венды Виста, Windows XX
больше не поддерживают приложений DOS.

То, что графику не поддерживают, это я знал, и проблема тут не в Windows,
а в видео-драйверах, их попросту поленились написать...

Но для консольного приложения графика не нужна, поэтому из моего старого
шаблона у меня получилось вот что, оно работает у меня под Windows 7, и
не требует никаких DOS-боксов...

Ниже - архив с файлами:

BMP2BIN.EXE - утилита, конвертирующая рисунок формата *.BMP,
черно-белый (два цвета) в файл формата *.BIN - образ ПЗУ для
проекта Proteus "Программно-аппаратное формирование видеосигнала".

Размер рисунка формата *.BMP строго 265Х256 точек.
Файл формата *.BIN создаётся с тем же именем, что и у файла *.BMP.
После конвертации следует не забыть изменить имя файла *.BIN в ПЗУ.
В качестве теста я свою здешнюю аватарку сконвертировал:

Тестовый рисунок формата *.BMP B/W 265Х256 в архиве также есть.

Технология Drag & Drop поддерживается: файл формата *.BMP можно
"перетянуть" с помощь мыши на пиктограмму файла BMP2BIN.EXE в
меню файлового менеджера.

Программа тестировалась только под Windows 7 и является консольным
приложением.
Даже интересно, заработает ли утилита на более старших Виндах ?