Отдельное спасибо Сергею Киселеву за огромную работу, которую он проделал, чтобы мы все могли найти ответы на свои вопросы про IBM PC/XT и не только.

Дальше будет очень много текста (черновик около 40 страниц). Не столько технического, сколько «научно-популярного».

Итак, IBM-PC (XT), он же IBM 5150/5160. Я здесь пишу так нестандартно через дробь, потому что принципиальной разницы между чистым PC и PC/XT нет. Это был по сути просто рестайлинг, как сказал бы автолюбитель. Добавили оперативки, обновили BIOS и OS, сделали поддержку HDD, убрали поддержку (разъем) магнитофона, заменили блок питания на более мощный. В общем, принципиальная разница только в том, какой BIOS установлен.

Сначала я хотел сделать 5150, который казался мне более простым, но когда погрузился в тему, понял, что если уж делать, то 5160. Дальше я буду для краткости называть его просто ХТ.

Вообще весь текст будет чем-то средним между техническим описанием и литературой. Думаю, что технические подробности уже мало кому интересны. Это скорее развлечение, чем что-то полезное. Но на вопросы, если такие будут, отвечу.

Итак, делаем ХТ. В сети не сложно найти подробное описание ХТ в виде pdf-фалов. Инженеры IBM оставили очень подробное описание, по которому можно просто собрать полностью оригинальную конструкцию. Там есть абсолютно все, включая полный листинг BIOS.

Но повторять ту машину из начала 80-х нет большого смысла, да и не интересно. Интересно сделать свою версию. В этом же и была прелесть PC – свои версии делали все, кто хотел.

Для начала следовало определиться с конфигурацией. Например, мне не нужен LPT-порт. Я просто не смогу к нему ничего подключить.

Таким образом, после некоторых размышлений, получилось следующее описание проекта:

1. CPU NEC V20 (μPD70108) – это улученная версия 8088 от компании NEC. Работает (может работать) на более высокой частоте и имеет некоторую оптимизацию в вычислениях чисел с плавающей точкой и что-то еще по мелочи. Я читал, что в те годы считалось круто заменить в своем РС 8088 на V20. Мой CPU будет работать на частоте 7.16 МГц вместо родных 4.77 МГц в оригинальном ХТ. +33% производительности,  не считая +30% от NEC, обещанных за счет внутренней оптимизации, но тут есть сомнение, что это касается всех команд.

2. Арифметического сопроцессора не будет. Его почти невозможно купить, и он по-настоящему полезен только в очень специфичных программах, и у меня V20 (см п.1).

3. Т.к. сопроцессора нет, то CPU может работать в минимальном (однопроцессорном) режиме похожем на Z80. Из схемы можно исключить все, что нужно для бесшовного переключения между CPU и сопроцессором.

4. Память RAM будет статическая и по объему сразу перекрывать все адресное пространство. Сразу скажу, что я использовал две K6X4008. В сумме 1 МБ. Контроля четности нет и, соответственно, нет всей схемы, с этим связанной. И нет немаскируемых прерываний по ошибке памяти (дедушка синего экрана смерти). Кроме того, отказ от динамической памяти  - это автоматический прирост производительности на 5-7%, т.к. в оригинальной конструкции процессор тормозится циклами DMA на регенерацию памяти каждые 15 мкс (примерно).

5. DMA нет. В ХТ без специальных плат расширения контроллер DMA используется только для регенерации динамической RAM. Мне, получается, он не нужен. Как потом оказалось, все не так просто, но об этом позже.

6. Клавиатура. Отдельная тема. В ХТ используется клавиатура, похожая по протоколу обмена на PS/2, но не совсем она. Без переходника, который будет перекодировать сигналы, подключить PS/2 не получится. Но я решил пойти еще дальше и подключить простую Bluetooth-клавиатуру из "Фикспрайса". Так интереснее и на столе места немного занимает.

7. Разъемов ISA (предшественник PCI, если кто не знает) не будет. Прежде всего, потому что купить сами разъемы по адекватной цене я не смог. С другой стороны, я принципиально не планировал потом покупать какие-то ретро-модули для установки в свой ХТ. Но т.к. какой-то разъем в принципе был нужен, то  остановился на варианте 2х20-пин обычный PLS/PLD коннектор как в Ардуино, например.

8. Видеокарта MDA для запуска и вторым этапом, VGA. Обе карты не 100% стандарт, а минимально чтобы работало в основном режиме.

9. Гибких дисков нет (зачем они сейчас?). HDD есть. Точнее эмулятор на CF card. 32 МБ.

10. Весь монтаж традиционно для меня просто навесными проводами.

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

1.       Видеокарта MDA

Начать решил с видеокарты MDA. Я хотел иметь гарантию, что потом, когда буду делать основной модуль (материнскую плату), я буду точно знать, что картинка должна быть. А если ее не будет, то дело не в видеокарте.

Оригинальная MDA карта в стандартном режиме показывает алфавитно-цифровую картинку 25 строк по 80 символов. Частоты синхронизации совершенно телевизионные, поэтому современный ЖК-монитор почти точно откажется показывать такой сигнал. Необходимо рисовать его в более современном формате.

Каждый символ MDA рисуется в матрице 9х14. Нетрудно посчитать, что вся картинка получается 720х350 (привет от NTSC, где разрешение 720 x 480). Ближайший VGA формат, куда это можно хорошо вписать, это 800х600. При этом часть кадра останется неиспользованной. Но тут есть проблема – пиксельная частота получается 36 МГц, что, на мой взгляд, слишком много для реализации на рассыпной логике навесным монтажом. Да и картинка получится некрасивая, сплющенная.

Чтобы решить проблему совместимости, решил изменить размеры знакоместа и поместил каждый символ в матрицу 8х9. Примерно как на ZX-Spectrum, т.е. совершенно нормально читаемые символы, хотя и не такие симпатичные как в настоящем ХТ. Теперь картинка получилась размером 640х225. Прочерчиваем каждую строку два раза и получаем на выходе 640х450.  Почти идеальные 640х480. И пиксельная частота примерно 24 МГц.

ROM знакогенератора пришлось полностью переписать под эти символы. Но это было не сложно. Написал нехитрую программу на C#, которая позволяет редактировать ROM.

В остальном ничего примечательного. Картинка из кода символа и кода атрибутов формируется на дискретной логике и отправляется в монитор.  Почти как в Радио-86РК.

CPU при загрузке компьютера, или потом при необходимости, может отправлять в MDA команды конфигурации и настройки. В моей версии эти команды уходят в космос. Видеоадаптер сразу аппаратно настроен на один стандартный режим и работает только в нем.

В итоге поучилась вот такая конструкция:

Если просто подать питание, то рисует всякий мусор от случайных данных в RAM. Можно разглядеть небольшой переключатель рядом с ROM. Т.к. в наличии была слишком большая микросхема, то сделал возможность выбирать одну из четырех прошивок знакогенератора. Не очень важно для этого проекта, но может быть пригодится.

Схема, если кому-то интересно: MDA

2.     Клавиатура

Как я уже писал, в проекте используется бюджетная клавиатура Bluetooth из "Фикспрайса". Чтобы подключиться к ней, пришлось приобрести ESP-32S. Сначала я испытал парочку модулей попроще, но с клавиатурой они работать не захотели. Там все довольно сложно с протоколами и профилями.

Bluetooth – это целая вселенная, погружаться в которую у меня желания не было. Я взял за основу этот проект (спасибо turgu1 из Канады) и доработал под свою задачу. Коды нажатых и отпущенных клавиш принимаются  ESP-32S, перекодируются в соответствующие коды клавиатуры  IBM PC и через  com-порт выкидываются в другой микроконтроллер, о котором будет написано дальше.

Каких-то проблем тут не возникло. Я дольше разбирался, как заливать прошивку в ESP, чем делал саму прошивку.

3.   Материнская плата

Далее я буду использовать краткие наименования микросхем типа «8088» просто чтобы было меньше букв. Желающие смогут легко найти их описание в сети.

Для материнки заказал большую макетную плату. Размером почти А4.

За основу схемы взял оригинальную конструкцию. Но почти все немного или сильно изменил. Прежде всего, добавил микроконтроллер STC8H8K64U (далее просто STC), который заменил собой тактовый генератор, т.е. сам тактируется тем же кварцем, что и оригинальный 8284, и формирует своими таймерами  частоты для CPU и для системного таймера 8253. Но это не все. Еще STC выполняет функцию буфера клавиатуры, сообщая CPU коды нажатых и отпущенных клавиш, которые принимает через com-порт от ESP-32S. При этом он еще занимается автоповтором нажатых клавиш, который в XT реализован аппаратно внутри клавиатуры.

ROM (BIOS). Сначала я хотел весь код BIOS хранить в STC  просто как статический массив байтов и загружать его в RAM при старте. Это позволяло хорошо сэкономить на количестве микросхем. Но когда решил делать полноценную модель 5160, пришлось пойти по классике и вынести BIOS в отдельную ROM. Слишком большой объем 64 кБ – это вообще вся память STC. Для собственного кода места не остается.

Системный таймер, контроллер прерываний и параллельный порт для внутренних устройств почти без изменений повторяют оригинальную конструкцию.

CPU, в отличии от оригинала, включен в минимальном режиме, как я уже писал выше, поэтому в схеме нет 8288, процессор по сути сам рулит всеми устройствами.

При старте компьютера STC включает режим DMA, забирая управление на себя. Очищает экран, пишет свое приветствие и производит легкий тест RAM. Просто пишет и читает несколько байт в каждую микросхему. Этот тест появился не сразу, а в процессе отладки, но так и остался.

Чтобы было понятно, это выглядит примерно так:

Ушло примерно полтора месяца на это увлекательное занятие. Конечно не с утра до вечера каждый день, но все равно это было долго. Вообще, это скорее муторно, чем сложно.

Как оказалось, CPU не находил контроллера DMA, который я исключил из схемы, и выполнял команду HLT, т.е. просто останавливался. Я заменил HLT на NOP и теперь POST  стал падать на проверке контрольной суммы ROM (логично). Пришлось обойти и эту проверку.

Всего в код BIOS я внес изменения в шести местах. И это не всегда была простая замена одного байта. Местами более обширные, но не особо сложные изменения. По мере адаптации кода к конструкции компьютер начал проявлять признаки жизни. Прежде всего писать коды ошибок на экране. Например так:

Т.к. в системе нет никаких дисков для загрузки, то управление передается встроенному Basic от Билла Гейтса. Получился такой чёрно-белый вариант Spectrum или Радио-86РК на максималках. Можно было что-то кодить. А если добавить проводков, то и сохранять программы на магнитофоне.

Микросхемы с радиаторами – это КР580ИР82 / ВА86. Я их выбрал потому что они продаются за копейки и имеют удобное расположение выводов. Но, как оказалось, очень сильно греются при работе. Если бы я знал, что это нормально для них, я бы взял другие аналогичные, но менять после монтажа уже не хотелось. Работают то они хорошо. На MDA-карте тоже стоят 4 штуки и без радиаторов. Никаких проблем при этом нет. Только горячие очень.

Небольшой переключатель – единственное, что осталось от оригинального конфигуратора. Здесь он указывает, какая видеокарта будет использоваться. Сейчас в положении «MDA».

Есть второй разъем «почти ISA», который появился в процессе отладки. Видеокарта на нем тоже работает, но вообще он для логического анализатора.

4.      Жесткий диск

Оригинальный PC XT комплектовался жестким диском размером 10 или 20 МБ. В те годы это был вполне приличный размер. Когда я учился в институте, у нас на кафедре были 286-е машины с диском 20 МБ и этого было более чем достаточно. XT  должен уметь загружаться с этого диска. По настоящему контроллер HDD вставляется в один из слотов на материнской плате. ROM на его борту автоматически попадает в общее адресное пространство, и XT  по ходу загрузки находит его и далее работает с ним.

В наше время уже нет смысла прикручивать настоящий ЖМД. Среди любителей ретрожелеза давно известен проект Сергея Киселева. Можно подключить CF-карту к XT в качестве ЖМД.

От этого проекта я взял только код ROM и общую идею. Сергей предлагает свой контроллер как универсальный модуль для установки в любой PC. Поэтому там есть переключатели для настройки конфигурации под конкретную машину. Мне это не было нужно, потому что я делал этот модуль встроенным в материнку. Так же я совсем отказался от ROM и весь его код положил в прошивку STC. Теперь при включении STC не только делает то, что уже описано выше, но и загружает XTIDE Universal BIOS в нужное место RAM. Таким образом, и без того простая схема контроллера стала совсем уж примитивной. Она вся на этой картинке:

Проблема была ожидаемая и заключалась просто в том, что карта была отформатирована на современном ПК непонятным для XT образом. Нулевой сектор всегда нулевой, поэтому  MBR читается без проблем, а дальше XT просто не может найти на диске нужный сектор. Я потратил немало времени, пытаясь хоть как-то установить MS-DOS на карту так, чтобы XT смог ее увидеть, но все оказалось бесполезно.

Все инструкции, какие я смог найти, сводились к тому, что надо сначала загрузиться с гибкого диска, которого у меня не было, чтобы отформатировать HDD. В конце концов на «главном» сайте для ретро-PC в разделе про проблемы при установке CF-карт в качестве ЖМД я прочитал вариант проблемы:  “User attempted to create a bootable CF using virtualisation software on a modern computer.  This is problematic.  Do the partitioning and formatting when the CF is in the XT-IDE card.” Сделать это можно было только имея в системе FDD.

Пришлось пересмотреть начальный план и сделать FDD. Может и к лучшему.

5.    FDD

Уже давно прошли те времена, когда FDD был нормой для конфигурации ПК. Сейчас даже просто пойти и купить сам привод с разъемом под шлейф скорее всего не получится. Да и за дисками придется побегать. Не говоря уже об их качестве. Когда я последний раз имел с ними дело, приходилось делать несколько копий документов, на разных дисках, чтобы гарантированно донести файлы до другой машины. Но к счастью наши друзья из Китая придумали замечательную штуку, которая позволяет эмулировать это все на обычной флешке:

Сам контроллер тоже «эволюционировал» с тех времен, когда это был отдельный большой модуль, и сейчас практически целиком помещает в одной микросхеме M82077 или PC8477B. Нужен только дешифратор портов для того, чтобы CPU мог обратиться к FDD. Это одна дополнительная небольшая микросхема. Поддержка FDD уже встроена в BIOS и не должна вызывать проблем.

И вот тут меня ожидал сюрприз. FDD не работает без DMA. Такая реализация в PC. А DMA я старательно выпилил из конструкции. Надо было что-то придумать. Самое простое – это вернуть DMA. Припаять 8237 и сделать все «по Фен-Шую». Но это потребовало бы отдельного буфера для подключения контроллера DMA к системной шине и еще кое-чего по мелочи. Конструкция грозила стать монструозной.

Тут я вспомнил, что сам режим DMA у меня уже в общем-то есть. STC использует его при загрузке. Почему бы в таком случае не дать ему дополнительных задач? Была только одна проблема. Я использовал STC8H8K64U в ретро-корпусе на 40 ног, которые уже даже не выпускают, но еще продают. И почти все эти 40 ног уже были задействованы. Подключать FDD было просто некуда.

Самым простым решением было заменить STC. Я взял точно такой-же, но уже в корпусе TQFP-64. Это абсолютно тот же самый чип, но у него выведено  дополнительно 2 полных 8-битных порта и еще несколько пинов. Даже прошивку менять не пришлось. Только припаял на это же место другую микросхему. Все-таки макетная плата – это удобно.

Было – стало:

Как видно, тут добавился куллер. Я их заказал, когда понял, с кем имею дело, и потом прикрутил, но и без них нормально. Поставил просто потому что уже купил. В таком варианте температура микросхем держится около 35 градусов, а без радиаторов микросхемы нагреваются до 50, но работают нормально.

Новая STC запустилась без проблем. К тому времени подъехали другие детали, и на материнке появился контроллер FDD:

Сама микросхема контроллера не новая, но их уже наверно не производят. Микросхема с номером 23 на фотографии – это дешифратор портов. Таким образом, все детали контроллера FDD поместились на этой картинке. За основу взял проект все того же Сергея Киселева только без com-порта, но, справедливости ради, подключение контроллера совершенно типовое как по даташиту. Проект Сергея помог мне просто понять, как это устроено.

В STC программно реализован функционал DMA по мотивам i82C37A. Реализация не полная в том смысле, что есть только один канал DMA, а не все 4. Канал DMA2, который нужен для FDD. Все остальное не нужно, поэтому не запрограммировано в STC. Точнее, STC принимает все команды управления и правильно отвечает на запросы CPU, но режим DMA реализует только для одного канала из четырех.

Здесь пришлось столкнуться с разницей в производительности аппаратных и программных реализаций. Настоящий 8237 работает почти мгновенно, отвечая CPU за один такт (ну почти).  Программно же чтобы уложиться в один такт процессора STC должен работать на частоте больше 100 МГц, что почти в три раза больше предельно возможной его частоты. На 14 МГц ну ни как нельзя успеть за CPU.  Замена на какой-нибудь STM даже не рассматривалась по целому ряду причин. Прежде всего потому, что все современные MCU плохо интегрируются напрямую с восьмибитными системами. «Плохо» - это значит  «не так же запросто». Все это решаемо, но в итоге все равно не дает такой скорости, чтобы уложиться в один такт CPU. На бюджетных MCU, разумеется.

Чтобы решить все это, пришлось добавить схему задержки, которая автоматически включает режим ожидания CPU (снимает сигнал READY) как только он обращается к контроллеру DMA. Это полностью снимает вопрос скорости и позволяет в перспективе поднять частоту CPU. Незначительная пауза в работе совершенно пустяковая на фоне времени чтения или записи сектора данных на диске. Логическим анализатором видно, что CPU тормозится примерно на 5 команд по времени. Да и вообще, в силу неисправимой однопоточности, CPU в это время просто ждет в цикле когда очередной байт будет передан через DMA, никакие параллельные задачи тут не подтормаживаются.

Вот так это выглядит на диаграммах:

Короткие нолики – это нормальные сигналы чтения или записи, а длинные – это растянутые пока STC  прикидывается контроллером DMA.

Приятным бонусом от эмуляции 8237 стала совместимость с оригинальным BIOSом. Теперь мой XT  стал загружаться без корректировки BIOS. В теории это позволяет попробовать альтернативные прошивки. Не знаю зачем, просто так. В свое время они появились больше для обхода авторских прав.  Для пользователя разница не заметна.

Хотя родной BIOS поддерживает FDD, для "современного" микроконтроллера FDD все же лучше использовать специальную версию все того же Сергея. Это расширение стандартного BIOS позволяет работать с дисками любого формата. Там еще можно подключить до четырех накопителей, но в моем случае это не актуально. Код этого расширения я разместил в коде загрузки STC как статический массив байтов. Он аналогично BIOS HDD заливается в RAM при старте.

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

Дальше ничего не было.

Пришлось снова подключать логический анализатор, все перепроверять. Вердикт – дохлый контроллер FDD. Было обидно, но он честно продавался бу-шный без гарантии.

Покупать там же еще один контроллер я не решился. Заказал на Озоне с доставкой из Китая. Сразу пять штук по цене одного здесь. Еще почти месяц ожидания. Приехали совершенно новые чипы в заводской упаковке.

Пока ждал, чтобы не скучать, решил убрать ROM и сделать всю загрузку  BIOS’ов в оперативную память. Для этого использовал флеш W25Q32Q32VB. Емкость 1 МБ, подключается по SPI к STC. Бонусом к этому решению идет упрощенный дешифратор адресов – нет необходимости выделять диапазон, когда нужно работать с ROM, процессор всегда работает только с RAM.

Немного технических деталей об устройстве PC. Можно пропустить.

В адресном пространстве PC CPU выделен большой диапазон адресов для ROM. Начиная с F0000H и до конца памяти идет основной системный BIOS, а диапазон D4000H — EFFFFH выделен для дополнительных ROM, в которых находятся, как сейчас бы сказали, драйвера подключаемых устройств. Если в слот ISA вставляется любой модуль расширения, например, аудио‑карта, то в нем почти обязательно имеется микросхема ROM, в которой записана программа общения CPU с этим модулем. Иначе процессор просто не узнает, что в составе компьютера есть такое устройство.

Это ROM автоматически попадает в адресное пространство по одному из допустимых адресов. На модуле, как правило, имелись перемычки или переключатели, чтобы выбрать адрес и избежать конфликтов с другими модулями.

При старте CPU проверяет область адресов, где могут появиться дополнительные ROM и, если находит их, запускает записанные в них программы инициализации устройств.

Таким образом, если я при старте загружаю все коды ROM в нужные места одного большого RAM, то мне не нужно переживать о всяких перемычках, дешифраторах и самих микросхемах ROM. Очень удобно. Но невозможно воткнуть в систему стандартный модуль. А мне и не нужно.

Вот так получилось:

Теперь есть возможность легко ставить любые эксперименты с разными BIOS’ами.

Приехали новые микросхемы контроллеров FDD и загрузка стала выглядеть так:

Интересно, что если вставить теперь CF-карту, которая отформатирована в XT, в USB-адаптер, то современный ПК ее вообще не видит.  Первоначальный план использовать ее как флешку для переноса файлов не сработал. Теперь стало понятно, почему в Интерне нет образов жестких дисков XT. Без каких-то хитрых приемов их просто не получится развернуть на CF-карту. И видимо прочитать тоже не получится, чтобы сделать образ. Все дело в нестандартной геометрии разметки «поверхности» диска.

Для переноса файлов оказалось проще использовать запись в образ гибкого диска любой доступной программой, которая понимает образы .imo или .img .

Еще картинка, чтобы показать результат этого этапа.

Ну и конечно теперь можно было попробовать поиграть во что-нибудь. Для чего еще нужны компьютеры? А если серьезно, то игры – это отличный тест системы. С MDA картой сильно не разгонишься, но кое-что можно попробовать. Вот, например, Тетрис, даже кажется оригинальный:

Под конец этого этапа чувство прекрасного достало меня окончательно, и я перепаял буфер CPU на нормальные микросхемы вместо КР580 (микросхемы 1...4). Радиаторы покинули конструкцию.

6.     VGA

Пришло время делать полноценную видеокарту. Как я уже писал выше, в начальном плане было сделать минимальную конфигурацию 640х480 с какой-то одной глубиной цвета. Однако, погружение в эту тему привело к понимаю того, что делать минимальную карту не очень логично. Дело в том, что настоящая VGA карта поддерживала целый пакет различных видеорежимов и могла налету переключаться между ними. На практике отсутствие такой возможности привело бы к тому, что очень много программ не смогли бы нормально работать.

Пришлось изучить конструкцию оригинальной карты. Эта схема тоже легко находится в Интернете в виде подробного pdf-файла. Там все довольно сложно. По сути, второй компьютер. Было бы странно надеяться, что я смогу как-то оптимизировать и упростить  схему после десятилетий работы над ней множества инженеров.

Оставалось два варианта: использовать какую-то ПЛИС, чтобы синтезировать все в ней, или применить один из видеоконтроллеров, на которых строились видеокарты где-то в 90-х годах. Я выбрал второй вариант.

Лучшим кандидатом для применения показался TVGA9000i. У Сергея Киселева имеется уже проверенная очень популярная реализация под этот видеоконтроллер (https://github.com/skiselev/isa-super-vga/tree/main). Поэтому если бы у меня что-то и не получилось, то только из-за кривизны рук.

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

Вариантов покупки видеокарты есть масса, я в итоге купил за примерно 600 рублей + пересылка, что мне кажется довольно удачно. Приехал вот такая карта:

Видны следы активной эксплуатации и немного ржавчины.

Был конечно соблазн просто припаять ее как есть, но получилось бы очень некрасиво без разъема. Да и план был другой. В общем, взял фен и паяльник и разобрал почти полностью.

Вот так получилось. Что касается самой схемы, то тут тоже есть немного адаптации. Прежде всего, традиционно для всей конструкции удален ROM.  Код будет загружаться как все предыдущие в оперативную память.

Тут не обошлось без особенностей. Дело в том, что этот видеоконтроллер универсальный. Поддерживает 8- и 16-битные системы. Поэтому у него очень экзотическое подключение ROM. Микросхема ROM находится как бы за видеочипом, который выполняет для нее роль буфера и перекоммутирует выводы на 8- и 16-битный вариант разъема. А сам код размещен в микросхеме ROM так, чтобы оптимизировать этот процесс. Если кратко, то все четные и нечетные байты кода размещены не по порядку, а в разных страницах памяти. Соответственно, чтобы переселить этот код в RAM, пришлось пересобрать его, т.е. расположить байты по порядку. Я использовал код ROM от Сергея Киселева, чтобы быть уверенным, что он запустится на  XT. Хотя на многих форумах написано, что у него используется обычное ROM как от заводской карты. Сама схема к Сергею имеет достаточно косвенное отношение. Подключение скорее стандартное по даташиту как и у него. Но пришлось добавить кварцевый генератор на 14.31818 МГц. Это стандартный сигнал OSC разъема ISA – основной тактовый сигнал всей системы, от которого я отказался, чтобы ускорить процессор. Но здесь он используется для синтезирования различных частот.

При первой попытке карта вообще не завелась. Через пару дней я догадался прогреть феном все контакты и картинка появилась. Но очень печальная. Вот такая:

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

 Изображение пошло, но символы были очень сильно искажены. Можно даже сказать разрушены, хотя атрибуты (цвет и т.п.) шли нормально. После некоторых экспериментов я понял, что нормально работают простые видеорежимы типа MDA или CGA, а VGA рассыпается. Все дело в интенсивной работе с памятью. Фактически я уперся в предел для навесного монтажа. Сигналы RAS/CAS не могли нормально дойти до памяти. Я переложил прочие жгуты подальше от памяти, а RAS/CAS протянул максимально короткими проводами. Стало значительно лучше, но не совсем.

Окончательное решение – сделал две коротких витых пары и пропустил сигналы по ним. Стало отлично. Вот так получилось:

Что особенно радует – это удивительно чистая картинка. Словно это настоящий ПК с настоящей видеокартой. Никогда еще мои самоделки не давали такой результат.

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

Из плохих новостей – компьютер перестал быть стабильным. Загружался даже не через раз, один раз из десяти наверно. И глючил при запуске программ. Но достаточно было вынуть CF-карту и все начинало работать. Другими словами, шина данных была перегружена потребителями.

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

Я добавил второй буфер на шину данных (74HC245N) стало прямо очень на много лучше, но все еще не достаточно хорошо. Логичным следующим шагом было сделать аналогичный второй буфер на шину адреса. Буфер я сделал из трех 74HC245N, работающих в прозрачном режиме. Как итог – все перестало работать. Точнее POST BIOS проходил нормально, а вот дальше ни FDD, ни ЖМД не грузились. Иногда что-то загружалось, но в целом не работало. На экране постоянно появлялись артефакты в виде символа с ASCII кодом «FF» или атрибута с тем же кодом.

Долгих две недели ушло у меня на изучение неожиданной проблемы. Наконец оказалось, что я с самого начала допустил фундаментальную ошибку в конструкции. Каким-то образом я проглядел, что что в XT нет подтяжки разрядов шин данных и адреса к питанию или земле. Буферы данных и адреса просто никогда не закрываются. Они всегда открыты для CPU кроме моментов DMA или чтения вектора прерывания.

У меня же из-за слишком глубокого изучения даташита на CPU, буферы открывались по соответствующему сигналу процессора.  А когда они закрывались, подтяжка к питанию через 10 кОм начинала поднимать уровень к единице, но из-за большого сопротивления это были не единицы, а эдакие зубья пилы высотой около одного вольта – на сколько успевало подняться напряжение. Пока буфер был единственный, эти зубы обычно принимались потребителями как 0, но второй буфер работая в режиме усилителя превращал их в полноценные единицы и создавал хаос.

Пришлось переосмысливать все и переделывать. Резисторы я убирать уже не стал – они слишком хорошо были припаяны и для открытых буферов проблемы не представляли.

После того, как все было сделано как задумано в IBM, видеокарта совсем плохо стала работать. Теперь это был один сплошной артефакт “FF” на весь экран. Снова изучение осциллограмм и вывод: Неправильные буферы каким-то чудом компенсировали другую проблему. Оказалось, что разгон CPU до 7.5 МГц привел к тому, что он просто проскакивал мимо сигнала готовности видеокарты. Когда Trident при чтении видеопамяти  снимал сигнал готовности, чтобы CPU подождал данные, CPU уже пролетал ту фазу, на которой он проверяет этот сигнал. В результате задержка игнорировалась, видеокарта еще не отдавала байт на шину данных, и CPU читал резисторы подтяжки – те самые FF.

Изучение вопроса показало, что оригинальный XT работает достаточно медленно, чтобы поймать торможение, а  у быстрых CPU типа 386 есть контроллер шины ISA, который всегда тормозит процессор сам, если это требуется.

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

Загрузил его первым сложным тестом – знаменитый Принц Персии. На максималках.

7.       USB

Пока я поисках ответов на разные вопросы изучал Интернет, наткнулся на интересный модуль для XT.

 

Это самый настоящий адаптер для USB-флешек. Но они продаются по какой-то безумной цене в районе 2,5 тыс, что совершенно отбивает желание покупать. Сердцем модуля является CH375, который можно купить на макетной плате всего за 150 рублей с доставкой:

Однако, житель Интернета по имени @kingcrimson234 поправил исходный код игры так, чтобы она не требовала 286-й процессор. По его словам изменения были крайне незначительными. С его правками  Wolfenstein запустился полноценно в VGA.

Играть с FPS в районе 1 – 2 все равно почти невозможно. Но забавно это видеть.

Ну и мой любимый Retal. Когда-то эта игра была у меня на дискетке всегда с собой. Я играл в нее в институте в свободное время в компьютерном классе кафедры на 286-х ПК. В прошлый раз это было в 1994 году. И вот теперь опять. Работает, кстати отлично, без тормозов. В самом начале, когда я только все планировал, я именно эту игру хотел увидеть как конечную цель. Получилось.

8. COM-порт

COM-порта в начальном плане не было. Я не смог придумать, что в него подключать, поэтому и не стал конструировать. Однако, когда проект зашел достаточно далеко, мне захотелось иметь мышку. Стандартный аксессуар для любого нормального компьютера. А в годы зарождения ПК мышки подключались обычно через COM-порт.

Первая проблема тут – это сама мышка. Конечно, есть варианты всяких конверторов, превращающих современную USB-мышь в старинную, а еще можно было заморочиться и сделать эмуляцию через тот же контроллер клавиатуры (ESP32) и использовать bluetooth’ную мышку. Но решил пойти по классике.

Прежде всего, удалось купить новенькую настоящую COM-мышку с шариком. Нашел в одном единственном магазине на Яндексе. Видимо товар совершенно не ходовой. Когда достал ее из упаковки – чуть не прослезился. Ровно такие же мышки я гонял по коврикам 30 лет назад.

Так получается конечно не полноценный RS-232, а урезанная версия. Какой-нибудь модем из 70-х точно не будет работать на таком интерфейсе.

При проверке оказалось, что мышка тоже не работает. Пришлось погружаться в теорию устройства мышек наших предков. Как оказалось, питание для мозгов мышки берется из сигнальных линий. Точнее с линии TXD, которая должна быть в логической единице RS-232, а это -12 Вольт. (Хотя если будете гуглить, то информация будет не совсем такая, но я разбирал и прозванивал реальную мышь, мне можно верить.) Этот сигнал подключен к земле мышки, а ее плюс – это земля компьютера. Вот такая загогулина. MAX3232 умеет делать минус, но только для сигналов. Что-то запитать с этого минуса не получится – слишком слабый ток.

Пришлось все переделывать, но вышло даже лучше. Т.к. для питания мышки по даташиту от ее чипа нужны  просто 5 Вольт, то я их подал прямо на разъем в нужной полярности. Осталось два сигнала RTS и RXD. Первый делает сброс мышки, а по второму она асинхронно выкидывает байты о своем перемещении. Их только нужно инвертировать оба и можно подключать к контроллеру COM-порта. Никакие буферы в таком варианте не нужны. На плате как раз были два свободных инвертора.

Так и сделал, все сразу заработало. С драйвером проблем не возникло. Получился конечно не совсем COM-порт, а скорее разъем для комовской мышки, но это в общем-то и было целью.

Вот так, если кто-то не знал, выглядит курсор мышки в DOSе, точнее в файл-мененджере. Полупрозрачный оранжевый прямоугольник.

9. UMB

UMB - Upper Memory Block. Любой, кто погружался в изучение конструкции PC, мог заметить, что в адресном пространстве после основных 640 кБ остаются пустые окна (или промежутки), которые не заняты каким-то ROM или видео. Их не очень много и они могут быть изрядно фрагментированы, но они есть. Возникает соблазн использовать их для дополнительного RAM, что и было в свое время реализовано и названо UMB. В эту память переносились код DOS и драйвера, освобождая место для пользовательского кода в основной памяти. Были такие специальные модули с памятью, которые вставлялись в слот ISA.

В моем случае оставалось 143 кБ бесполезной памяти (СС000 - EFFFF). Плюс, они уже «покрыты» физической RAM и могли бы быть очень просто переданы DOS как верхняя память.

Единственная проблема, я изначально физически заблокировал для CPU запись в RAM в верхнюю четверть адресов (A18, A19 = 1, 1). Сделано это было, чтобы никакой код не мог изменить код BIOS или драйвера. Как оказалось, такое иногда случается и вызывает сбои. После блокировки проблема ушла, но теперь вернулась с другой стороны.

Чтобы вернуть в область доступного RAM эти 143 кБ, пришлось переделать схему блокиратора. Паять дополнительные микросхемы места уже не было, поэтому новый блокиратор синтезирован в GAL16V8B. Так что в итоге микросхем получилось даже меньше – туда переехал еще дешифратор обращения к видеопамяти VGA. К тому же, эти GAL – это очень атмосферно. Настоящий артефакт из той эпохи.

Раньше я никогда не использовал GAL. Это в общем-то уже забытые технологии. Но для самоделок очень  интересная микросхема.

Для ее прошивки требуется специальный программатор, не похожий ни на что. Такие программаторы не сложно купить, но цена там не очень дружелюбная. Поэтому я ненадолго отложил XT и сделал свой программатор для  GAL. Вот он на этой картинке:

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

 Программатор собран из того, что нашлось в моих закромах,  из двух готовых модулей STC8G1K01 и MT3608. Первый – это мозги, куда загружается файл прошивки и потом эта прошивка переносится в GAL. Второй модуль повышает напряжение питания 5 вольт до 12-16 вольт, необходимых для прошивки GAL (или ATF). Рядом еще видно модуль USB-UART и индикатор, показывающий сколько там «прошивочных» вольт сейчас на выходе.

Все это подключается к компьютеру через com-порт. Наконец, для управления написана небольшая программа, которая загружает прошивку в программатор. Сама прошивка – это просто текстовый файл, который готовится в специальном редакторе WinCapl или другом аналогичном. Вот в общем-то и все.

В строке Upper драйвер UMB нашел всего 144 кБ верхней памяти (147472 / 1024), 13 кБ сразу заняты драйверами и самой ОС – это значит, что в основной памяти эти килобайты освободились для пользовательских программ. Еще 130 кБ доступно для использования. Очень не дурно, надо сказать. Дополнительные килобайты в основной памяти позволили запустить Wolfenstein с мышкой. Раньше приходилось загружаться без драйвера мышки, иначе не хватало RAM.

10.  Улучшения

В этой части я опишу мелочи, которые шли как бы параллельно проекту.

Когда все уже работало «как у взрослых», я обратил внимание, что DOS изредка полностью крашится, а при выходе из программ в DOS вместо Volkov Commander обычно получаю сообщение  «Bad or missing C:\VC\VC.com Press Enter to try again or ESC to abort ». Тут же после ESC и команды “VC” всегда нормально открывался Volkov Commander.

Наконец, при попытке копировать на диск большие файлы я понял, что есть проблемы с чтением CF-карты. Если без подробностей, то иногда, очень редко, вместо нужного байта с карты читался 00h. Для мелких файлов это было почти не критично просто по теории вероятности, но для больших создавало проблемы. Для тестового файла 650 кБ получалось примерно около 10 - 20 ошибок чтения. Всегда в разных байтах.

Более глубокий анализ показал, что из двух купленных мною CF-карт одна работает без проблем, а вторая не умеет ждать. Если в процессе чтения данных происходит стандартное прерывание по системному таймеру, который считает время, то после выхода из прерывания следующий байт может быть прочитан с карты как 00h, смотря по тому, как фаза чтения пересечется с прерыванием.

Эту проблему решил так, что если происходит обращение к порту карты, то сигнал PCLK, который тактирует счетчик, вызывающий прерывания, замирает примерно на пять тактов CPU, чтобы гарантированно завершить чтение. Звучит сложно, но в EPM это довольно простая процедурка.

В погоне за скоростью, я разогнал CPU до 8.6 МГц. Быстрее почему-то не работает. Наверно кто-то не успевает за ним. При этом частота системного таймера при включении выставляется как 1/8 от частоты CPU, чтобы пройти POST, а потом переключается на стандартные 1.19318 МГц.

В итоге остановился на такой конфигурации:

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

Тем не менее, системный переключатель видеорежима (простой тумблер), который указывает CPU с какой картой он работает, я завел также и в STC. Теперь, если STC видит, что будет работать MDA карта, она снижает частоту CPU в два раза.

В этом месте я решил остановиться, хотя хотелось добавить еще RTC (часы на батарейке) и звуковую карту. Но подумал, что лучше не загромождать конструкцию. Места уже не было, требовался второй этаж. А мне хотелось получить ноутбучный плоский формат.

В итоге получилось так:

И самое интересное:

Схема, если кому-то интересно, вот здесь: Схема

К сериям микросхем типа HC / ALS прошу не придираться. На схеме показана только логика. Паял то, что было проще купить. Главное, что оно работает.

Корпус.

Оставить такой компьютер без корпуса было бы неправильно. Поэтому корпус был в плане с самого начала. Пришло время его делать. 

Сам корпус я сделал из отдельных стенок, вырезанных из листового пластика, соединенных винтами через уголки, напечатанные на 3-D принтере. На том же принтере напечатаны элементы для установки эмулятора гибкого диска, элементов управления и индикации и разъемов. Сейчас я думаю, что проще было напечатать весь корпус целиком – вышло бы аккуратнее и не сильно дороже, но уже как сделал, так и будет.

Светофорный индикатор: зеленый - питание, желтый - клавиатура подключена, красный - активность HDD. Левее кнопка "Reset" (нет в оригинальной конструкции!) и выключатель питания.

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

Спасибо тем, кто прочитал столько текста.