Скомпилировал gcc под Windows 64 bit, попробуйте:
Вложение 82059
Вид для печати
Скомпилировал gcc под Windows 64 bit, попробуйте:
Вложение 82059
Работает! Спасибо, теперь можно поиграться со шрифтами
Вложение 82060
Кстати - левая половина логотипа
Продолжаю разбираться с коллизиями.
ivang78 указал на слипшиеся пиксели на логотипе
Вложение 82086
Аналогичную картину видел на фото, которые выкладывал AlexBel
Параллельно замечено при распечатке таблицы шрифтов неправильное отображение символов псевдографики
Вложение 82087
Идет расползание левого столбца знакоместа, точнее задвоение пикселей символов по левому столбцу знакоместа.
Анализ осциллограмм показал:
Вложение 82088
Длительность сигнала Shift/-Load (15 нога U5 74HCT166) составляет 240 нс, при этом захватывается 2 такта Dot Clock.
Т.е. происходит загрузка строки из знакогенератора - сдвиг на один пиксель - и снова загрузка той же строки. Отсюда задвоение левого столбца.
На символах, которые не прилегают к левой стороне знакоместа это не заметно, все выглядит хорошо. А символы псевдографики практически все задваиваются слева.
Вложение 82089
Спасибо ivang78 за утилиту))
Shift/-Load, формируемый U18b 74HCT74 слишком длинный, в блоге Tomaž Šolc’s в описании его CMOS Galaksija указана длительность этого порядка 60-100нс (по памяти, возможно не точно), но смысл понятен - длительность должна укладываться в один такт Dot Clock.
В моем случае решение простое - заменил Z80 на CMOS версию (до этого стоял обычный). Осциллограмма стала выглядеть так:
Вложение 82090
Длительность уменьшилась примерно до 200нс, многовато, но хватило для попадания в такт Dot Clock.
Картинка на мониторе стала нормальной, слипание точек ушло:
Вложение 82091
Если не помогает, то нужно рассматривать более кардинальные меры, например внедрение одновибратора с фиксированной длительностью по типу реализованного на U13 генератора КСИ или ССИ
Надеюсь кому нибудь будет полезно.
Сейчас включил "Галаксию-2024" и посмотрел. Вот так выглядит после включения:
https://i.ibb.co/21zrM36F/Galaksija-chars.jpg
Длительность импульса на U5.15 - 280нс.
Процессор Zilog Z84C006PEC.
В общем, слипается. Возможно, это связано с тем, что U5 у меня установлена К555ИР10 вместо 74HCT166.
Интересно! С процессором Zilog Z84C006PEC компьютер потребляет порядка 280мА. С процессором Zilog Z84C0020PEC не запустился вообще (все строчки забиты частью логотипа, только последняя колонка - буквами "P"). С процессором ST Z80BCPU потребляет 250мА и символы слипаются, как с Zilog Z84C006PEC. При этом оба процессора слегка тёплые, хотя, КМОПовский должен быть холодным, насколько я помню. То ли он подгорелый, то ли перемаркированный (хотя, я его вытащил из "Спектрума", собранного в 199х-2000 годах, когда вряд-ли перемаркировывали Z80). С8 на RFSH, кажется, 1нФ (уже точно не помню) - подбирал по удалению мельтешения пикселей в символах. В общем, пока что - загадки, надо заниматься.
Простейший вариант
10 for i=1 to 255
20 print chr$(i);
30 next i
- - - Добавлено - - -
Как я выяснил - 280 нс это много. В идеале должно быть меньше 160нс (Период DotClock - 166 мс). И U5 вообще не причем. Сигнал Shift/Load формируется U18b в совокупности с процессором.
U18 у меня стоит 74HC74 и С8 на RFRH как на схеме 100пФ. Процессор сейчас Zilog Z84C0006PEC.
Кстати потребление тоже порядка 280 мА.
Когда я ставил 100пФ, то на символах было мельтешение пикселей. Буду ещё играться, надо же выяснить причину. Насчёт U5 - сам не верю, но, она, всё же, TTL, мало ли, может, чего не знаю, может, чего и забыл. Но с процессором как-то странно - с КМОП потребление выше, чем у обычной ТТЛ. Может, завтра ещё поковыряюсь...
Получил заказанные 74HCT74, поставил вместо 74HC74. С 38 ноги процессора конденсаторы убрал совсем, включил - мельтешение некоторых покселей в символах есть, но, через, примерно, 30 секунд, пропадает - скорее всего, с прогревом процессора. Процессор Zilog Z84C0006PEC. Слепленные пиксели как были, так и остались, длительность сигналов сдвигового регистра видеовывода ещё не проверял. Если уж без конденсатора C8 пиксели слипаются, то с конденсатором, думаю, точно лучше не станет. Потом буду разбираться...
Вот статья, которая описывает обнаруженную доработку в старой версии Galaksija
https://web.archive.org/web/20231115...nerator_patch/
Судя по всему, проблема давняя. Где-то еще читал, что процедура видеовывода очень чувствительна к таймингам микросхем и процессора в частности, ну и доработки это решение проблемы.
Кстати, в своей версии CMOS Galaksija узел на U18b Tomaž реализовал по другому:
Вложение 82164
Тут с описанием:
https://web.archive.org/web/20230610...ter_generator/