Компьютер "Xi Aleste"
Введение
Несмотря на то что до окончания проекта ещё предстоит много сделать, для того чтобы не смешивать темы, было принято решение создать эту отдельную ветку — она будет посвящена исключительно новой платформе, отдельно от обсуждения оригинальной Aleste 520EX.
Краткое введение в историю проекта
Несколько лет назад была разработана Xi Aleste — точнее, лишь печатная плата, которая так и не была собрана и протестирована. Не было завершено проектирование ПЛИС (FPGA), не говоря уже о программном обеспечении. После разводки платы начались всем известные печальные события, которые сильно усложнили и удорожили процесс производства. Поэтому проект был заморожен.
Не так давно было принято решение продолжить разработку, но с упором на минимизацию себестоимости одного изделия. Решено было начать именно с FPGA, потому что без этого дальнейшие шаги были невозможны. Проект получил название Aleste LX — как напоминание о необходимости сдерживать «хотелки» и стараться минимизировать все накладные расходы.
Напомню также, что весь проект, включая исходный код, открыт. Любой желающий может скачать материалы и внести изменения при необходимости.
Краеугольный камень
В основе проекта лежит идея сделать оригинальную платформу Amstrad CPC более тесно связанной с расширениями Aleste. Чтобы программное обеспечение Amstrad могло пользоваться всеми расширениями, включая звуковыми, графическими и прочими. Эта задача сама по себе весьма нетривиальна.
Оригинальная платформа Amstrad CPC называется legacy-платформой и является «заповедником»: она не подлежит фундаментальным изменениям и должна сохранять полную совместимость и работоспособность. Это очень усложняет проект, так как требуется обеспечить совместимость не только на уровне регистров и бит, но и на уровне тактов и временны́х параметров.
Платформа Aleste 520EX в данном случае даёт лишь дух, идею и развитие концепции. То есть новая платформа не обязана повторять с точностью до бита или компонента оригинальную 520EX. Она должна заимствовать основные принципы, заложенные в той платформе, и при этом — исправить «родовые травмы», вызванные не только ошибками разработчиков, но и ограниченностью компонентной базы и технологий своего времени.
Примеры заимствований и улучшений:
• Качество цвета: Одной из ключевых концепций в Aleste 520EX было то, что точность передачи цвета порой важнее его количества. Палитра была расширена до 64 цветов в формате RGB. В Aleste LX этот принцип сохранён и улучшен — используется 12-битная палитра (4096 цветов), поддерживающая как оригинальные режимы CPC, так и палитру MSX+ (RGB+YJK).
• Управление памятью: Заимствована концепция использования маппера от MSX, что сделало систему управления памятью более прозрачной и простой. В LX она расширена: нативный менеджер памяти позволяет управлять памятью как четырьмя независимыми слотами по 4 МБ каждый.
• Файловая система: Исходная файловая система CP/M на CPC была рассчитана на односторонние 2.5" диски, что являлось большим недостатком. Aleste использовала MSX DOS и FAT16. В новом проекте этот принцип взят за основу для совместимости и удобства.
Все эти и многие другие принципы должны быть улучшены и применены в более совершенном виде.
*(Картинка ниже показывает амстродовский 16-цветный режим, но с более качественной палитрой Aleste LX. Как говорится, комментарии излишни.)*
https://raw.githubusercontent.com/hw...ns/cpc16b4.png
Ключевая идея, подсказанная Aleste: эффективность через прямые манипуляции
Ещё одна важная концепция, которая стала очевидна в процессе разработки и анализа архитектуры Aleste, заключается в следующем:
Главное преимущество даёт не выделенный видеопроцессор, подключённый через узкую 8-битную шину периферии, а центральный процессор с прямым доступом к видеопамяти.
Когда CPU может напрямую и быстро оперировать данными в графическом буфере, это снимает множество проблем с пропускной способностью и задержками. Следовательно, основная задача разработчика платформы сводится не к созданию сложного автономного графического ядра, а к тому, чтобы максимально устранить любые помехи на этом пути.
Приоритетами должны стать:
• Увеличение эффективной тактовой частоты доступа CPU к видеопамяти.
• Полное исключение тактов ожидания (wait states) при операциях с видеобуфером.
• Минимизация затрат процессора на рутинные графические операции:
• Смешивание пикселей (alpha-blending, наложение).
• Преобразование битовых карт в поток пикселей для вывода.
• Вычисления адресов в видеопамяти (например, для режимов с нелинейной организацией).
Именно эти «узкие места» — те операции, где процессор традиционно тратит львиную долю времени, — должны быть вынесены в аппаратуру или максимально оптимизированы. Цель — позволить CPU заниматься логикой приложения, а не преодолением искусственных ограничений доступа к собственной памяти.
Этот принцип, наблюдавшийся в практике работы с Aleste, стал одним из руководящих при проектировании подсистемы памяти и видеоконтроллера Aleste LX.
Напомню, что после окончания разработки на FPGA, печатная плата будет полностью переработана в сторону уменьшения размеров и себестоимости.
Текущий статус разработки (что готово и работает):
• SDRAM-контроллер на 16 МБ, работающий на частоте 108 МГц (шина Wishbone платформы будет работать на 54 МГц).
• Модифицированный видеоконтроллер 6845, позволяющий воспроизводить изображение из буфера до 64 КБ с линейной адресацией.
• Генератор пикселей, поддерживающий как оригинальный формат Amstrad, так и линейный формат с упрощённой кодировкой цвета.
• 12-битная палитра, обеспечивающая оригинальные режимы CPC, а также палитру MSX+ (RGB, YJK).
• Скалер и вывод HDMI.
• Арбитр системной шины, на которой находится микропроцессор и специальное отладочное устройство. Оно позволяет удалённо исполнять программы с режимом отладки: точки останова, пошаговое выполнение, инспекция выводов процессора.
• Нативный менеджер памяти, позволяющий управлять памятью как четырьмя слотами по 4 МБ, управляемыми отдельным маппером.
• Устройство UART Bridge, предназначенное для связи с будущим PMI-контроллером, но на этапе разработки используется для связи с хост-платформой для удалённой разработки.
Инструментарий и софт:
• Написано много ПО на Python для удалённой загрузки файлов в память платформы, инспекции памяти, управления регистрами внутри FPGA и т.д. (В конце проекта UART, скорее всего, будет заменён на SPI для скорости).
• Разработан собственный графический формат PIX для платформы и конвертер PNG-файлов в него.
Архитектура платформы схематично изображена на рисунке ниже.
https://raw.githubusercontent.com/hw..._xl.drawio.png
Пояснение к схеме: Устройства типа PIC, IPC, NMI — это простейшие механизмы на основе регистров и триггеров, предназначенные для быстрого детектирования источника прерываний или сообщений. Фактически, это механизм ускорения работы процессора не за счёт повышения тактовой частоты, а за счёт минимизации расходов на опрос периферии, проверку флагов и активное ожидание. Это, кстати, результат наблюдений за работой Aleste 520EX — анализ её «узких мест» показал, где процессор тратит много ресурсов на рутину, которую можно упростить добавлением одного считываемого регистра.
Ну, это примерное описание проекта. Я планирую добавлять комментарии и новости по ходу разработки прямо в эту ветку.
- - - Добавлено - - -
От тестов к системе: рождение BIOS для Aleste LX
Разработка железа — это всегда диалог с «железом» через код. В процессе тестирования различных подсистем на FPGA для Aleste LX было написано множество ассемблерных тестов. Их становилось всё больше, код в них дублировался, а логика работы различалась. Встал вопрос: как организовать этот хаос?
Так родилась идея, казавшаяся тогда почти абсурдной — написать BIOS для машины, которая еще даже не работала. Создать единый хаб для всех низкоуровневых операций.
Философский выбор: революция или прагматизм?
На старте было много идей, в том числе — заимствовать элегантные принципы из ОС Plan 9. Однако нехватка времени и желание сохранить простоту привели к парадоксальному решению.
Пришлось обратиться к истокам. Оригинальная Aleste 520EX имела на первый взгляд сырой, но гениально простой принцип: в ПЗУ жил софт от CPC и небольшой загрузчик — тот самый BIOS. Этот загрузчик умел с диска подгружать всё остальное: BDOS, COMMAND.COM, драйверы. То есть, стабильным и неизменным был лишь крошечный код в ПЗУ, а вся система — динамической, живущей на диске.
Именно этот подход показался идеальным для условий, где силы и время в дефиците. Это был прагматичный фундамент, который можно развивать.
Среда разработки как система
Диск разработчика Aleste содержал компилятор и все исходники системы. Если требовалось добавить функцию в графический драйвер или BDOS, изменения вносились прямо в исходники и пересобирались зависимости. Такой подход идеально ложится на начальный этап, да и, возможно, останется основным. План всегда можно «кристаллизовать» в более законченную пользовательскую платформу. Это программное окружение получило название Aleste LX.
Основной инструмент — z88dk, который работает со слоем драйверов и компилирует код, начиная с адреса C000h.
Архитектурные возможности: 4 МБ на слот — это пространство для манёвра
Теперь — самое интересное. Предстоит решить, как правильно организовать структуру памяти BIOS. Дело в том, что в третьем слоте, где он находится, доступно 4 МБ памяти. Это очень много, и о тотальной экономии можно не думать.
Это открывает любопытные возможности. Теоретически, каждый драйвер мог бы иметь свою собственную страницу или даже несколько. Например, драйвер графического вывода для каждого видеорежима мог бы разместить свои данные и код в отдельной 16-КБ странице, сохраняя при этом общую таблицу переходов (jumptable) для единообразного вызова. Драйвера могли бы не пересекаться, живя в изолированных пространствах.
Главный вопрос сейчас — не «как втиснуться», а как обеспечить простоту и элегантность архитектуры на таком пространстве.
Видно два основных пути для старта:
• Страница 3 (C000h и выше) — константная. Там живут jumptable и весь код для вызова функций драйверов. Страница 0 — переключаемая, содержит векторы прерываний и код активного драйвера.
• Наоборот: Страница 0 — перманентное ядро с векторами. Страница 3 — мутирующая, подгружаемая по требованию.
Окончательное решение, как наиболее эффективно использовать это богатство, предстоит найти в процессе.
Каркас системы: что уже есть
На этой неделе был собран каркас — ядро системы. Небольшой main-файл на C и набор драйверов, который включает:
• Графический (видео) драйвер
• Звуковой драйвер
• Драйвер NVS (non-volatile storage)
• Сетевой драйвер
• Драйвер клавиатуры
• Драйвер системной информации
• Менеджер памяти
• Драйвер прерываний и таймеров
• Драйвер файловой системы
Это сырой скелет, который предстоит тестировать и отлаживать. Но ключевое — его можно будет легко менять и пересобирать в духе Aleste.
Новый порядок загрузки
Изначально в Aleste ПО CPC при старте искало свой ROM и запускало его. Теперь подход иной: первым всегда запускается BIOS Aleste LX. Он проводит необходимые настройки и уже при необходимости загружает ПЗУ Amstrad CPC и передаёт ему управление.
Что важно: слоты 0 и 1 зарезервированы для Amstrad лишь «по договорённости». В нативном режиме все слоты (0,1,2) идентичны. В них можно запускать разные программные окружения. Например, в одном — MSX DOS для инструментов разработки, в другом — тоже MSX, но для запуска целевых приложений.
Заключение: инструмент, который сделал это возможным
Стоит признать, что вряд ли кто-то взялся бы за такую задачу в одиночку, если бы не существование современных ИИ-инструментов. Они стали незаменимыми ассистентами, позволяя быстро «склеивать» из разнородных библиотек целостные куски кода. Этот BIOS — во многом результат симбиоза классических знаний и новых технологий.
Работа только начинается. Впереди — отладка, оптимизация и поиск той самой идеальной архитектуры. Следите за обновлениями!
