ПК-01 Львов. Я нечасто покупаю ретро железо - предпочитаю паять новоделы - но тут было, прямо скажем, вкусное предложение, да ещё и в моём городе. Советский компьютер на базе процессора ВМ80 с 64КБ ОЗУ, практически мой ровесник.

Выложил свой вариант прошивки для ZXKit1 - скандаблера, позволяющего подключить Спектрум или подобный компьютер к VGA монитору.

Github: https://github.com/UzixLS/zxkit1-vga-scandoubler-firmware

Обсуждение на форуме zx-pk.ru: https://zx-pk.ru/threads/10548-zxkit1-plata-vga-amp-pal.html?p=1177544&viewfull=1#post1177544

Моя небольшая находка на али - девайс, развязывающий земли соединённых аудиокабелем устройств.

Частая беда при подключении спектрумов или подобных устройств к линейному входу ПК - это фоновый гул, который зависит от выводимого этим устройством на экран изображения, при том при отключении видеовыхода этот гул пропадает. Происходит это из-за относительно больших токов, протекающих в цепях аналогового видеосигнала. А у любого тока есть прямой путь (от устройства к монитору) - это сигналы цветности RGB (или композитное видео, в зависимости от устройства) - и возвратный (от монитора у устройству) - земляной проводник. Т.к. видеокабели не идеальны и сопротивление земляной жилы в них не нулевое, то ток стремится растечься, достичь цели всеми возможными путями (пропорционально сопротивлению/падению напряжения каждого пути). Если земля монитора соединена с землёй ПК, а земля ПК с землёй нашего источника видеосигнала (например, через линейных вход) - то ток потечёт по этому пути, вызывая колебания напряжения на АЦП линейного входа. Называется это явление земляной петлёй.

Этот девайс как раз и делает то, что разрывает этот нежелательный путь. Схема на самом деле элементарная, но китайцы продают уже готовое и упакованное в красивый корпус. Найти его можно по ключевым словам “Ground Loop Noise Isolator”.

Столкнулся с неработоспособностью DOSLFN на Хароне-386: программы с поддержкой длинных имён файлов либо не видели их, либо (если запущен EMM) падали с сообщением об ошибке. Сначала грешил на проблемную CF-карту, на битую память, на ошибку в схеме по части подключения CF, но в итоге стало понятно что проблема, скорее всего, программная. Я долго не хотел лезть в эту проблему т.к. совершенно ничего не знаю ни об отладке в MSDOS, ни даже ассемблера x86 (спойлер: если бы знал, проблема бы решилась спустя 30 минут после прочтения сообщения об ошибке). В общем, пришлось погрузиться в этот мир на пару вечеров. В обнимку с debug.exe (а позднее уже и Turbo Debugger) и документацией по DOS API, скачанной с самых задворков интернета, написал небольшую программку, которая всё что делает - это простое обращение к LFN API для поиска файла по длинному имени. Ожидаемо, на Хароне это обращение проваливалось - с ошибкой “файл не найден”, в то время как на любой другой машине проходило.

Долго ли, коротко ли - трассировка привела к замечательной функции в исходниках DOSLFN:

proc GlobbingEx
 mov di,[CurPathComp]
 xchg si,di
 call Globbing
 xchg si,di
 db 0D6h ;setalc
 or al,al
_glob_ret:
 ret
endp

Эта функция вызывается для каждого файла в каталоге и сопоставляет его длинное имя с искомым. И трассировка показала, что именно в этой функции есть странная инструкция “db 0D6h ;setalc”, которая на Хароне выполняется не так, как на других машинах! Оказалось, это недокументированная инструкция, которая по факту есть во всех процессорах начиная с 8086. Во всех, но, не в M6117D, который используется в Хароне! И который вроде как заявляется как полностью 386SX-совместимый. После замены этой инструкции на стандартную “sbb al,al”, которая делает то же самое, но занимает на 1 байт больше места (вот так “экономия”!), DOSLFN прекрасно заработал. Вот такой мини-детектив. Письмо мейнтейнеру DOSLFN я написал, надеюсь, это исправление войдёт в следующую версию.

Давненько ничего не писал про Харон-386. Ещё в прошлом году столкнулся с проблемой в работе звукового чипа ES1868 - назначался неправильный IRQ при загрузке драйвера. Т.е., например, драйвер назначает карте IRQ 5, а она оказывается на IRQ 7. Искал проблему в схеме, на плате, перебирал драйвера, перечитывал документацию, прозванивал, сравнивал с аналогичными картами - всё без результата. Так и забросил на полку почти на полгода. Сейчас просто решил сдуть чип и запаять другой - и всё завелось как надо… Что это было? Может быть перемаркировка другого чипа, или, может быть на заводе зашили другое содержимое встроенного ПЗУ (в котором и хранятся номера IRQ) - непонятно.

Движемся дальше - нет звуковых эффектов в Tyrian (а MIDI/FM музыка есть). Посмотрим сколько времени займёт эта проблема…

Наброски новой звуковой карты для NemoBus. Предварительно - добавятся бипер, Covox, SID, OPL3, 2мб ОЗУ для GS. Спешить с ней не буду, сначала хочу разобраться насколько реально сделать для спектрума плеер существующих форматов OPL3 и что для этого потребуется от карты. Думаю, готова будет не раньше осени-зимы.

Наладил TCP/IP через WiFi на Хароне, но пока весьма костыльным способом - поднял на Linux-машине SLIP-туннель на виртуальном последовательном порте, расшарил с помощью socat этот порт через TCP, на Хароне в WiFi-модем залил прошивку Zimodem, подключился через неё на этот TCP-порт, и, наконец, подключил к COM-порту wifi-модема пакетный драйвер с поддержкой SLIP - ethersl. В общем, “в зайце утка, в утке яйцо”… Эту цепочку можно сильно сократить если использовать прошивку esp_slip_router, но этим займусь уже потом.

А тем временем верхняя плата Харона-386 запаяна и показывает картинку!

ZX-MultiSound - звуковая карта TSFM+GS+SAA+SD+MIDI для NemoBus.

ТТХ:

• TurboSound FM (2xYM2203)
• General Sound (12МГц, 1024Кб ОЗУ)
• SAA1099
• SounDrive
• MIDI
• Подходит для установки в низкопрофильные корпуса. Размер карты: 170x64мм
• Питание 5 и 12В
• 4x 1-битных цифровых ЦАП для GS и SounDrive

Проект открытый, лицензия MIT.

Ссылка на исходники, схемы, герберы и т.д.: https://github.com/UzixLS/zx-multisound , зеркало: https://git.err200.net/uzix/zx-multisound

Тема на ZX-PK.RU: https://zx-pk.ru/threads/34790-zx-multisound-zvukovaya-karta-dlya-nemobus.html

Нижняя готова. Не без ошибок, но ничего непоправимого.