ну так-то можно и к ТВ с RGB подключить, или переходник от АлексЕКБ.
просто есть готовая монтажка и лепить туда еще одну малину - ну такое
https://sun9-14.userapi.com/s/v1/if2...m=bu&cs=1280x0
Вид для печати
ну так-то можно и к ТВ с RGB подключить, или переходник от АлексЕКБ.
просто есть готовая монтажка и лепить туда еще одну малину - ну такое
https://sun9-14.userapi.com/s/v1/if2...m=bu&cs=1280x0
Разве он принимает аналоговый сигнал?Цитата:
Сообщение от RW9UAO
Конвертер АлексаЕкб не подходит для компов типа Aleste, Союз-Неон или Вектор по двум причинам 1) всего 4 цифровых входных видеосигнала RGBI (не считаю синхру); 2) ограничение по пиксельклоку.
Так и я про то же, он для цифровых сигналов...
и совсем-совсем нельзя добавить еще два провода?
если брать сразу с регистра цвета. и фиг с ним с BLANK.
Даже если представить ещё два провода, они не спасут. Я могу попробовать включить "Алесту" через такой конвертер, но не раньше выходных
Ну а с ограничением по пиксельклоку что делать? Полностью переделать прошивку (кто этим займется)?Цитата:
Сообщение от RW9UAO
Эволюция архитектуры проекта Aleste 520EX HDMI
За 3 недели интенсивной разработки мы прошли через несколько архитектурных итераций, пытаясь совместить оригинальную 16 МГц систему с современным HDMI:
Проблемы двухдоменного подхода (16 MHz CPU + 27 MHz HDMI):
❌ Несоответствие временных параметров (31.8 µs vs 32 µs строки)
❌ Необходимость буферизации из-за расхождения частот кадров
❌ Усложнение скандаблера и рост латентности
❌ Невозможность идеально согласовать все графические режимы (512x212, 640x200, etc.)
❌ Сложности timing closure между clock domains
Принципиально новое решение:
Переход к единому 27 MHz clock домену с контролируемой приостановкой процессора.
Ключевые преимущества:
✅ Идеальная временная точность эмуляции оригинальной платформы
✅ Гарантированное соответствие циклов процессора на строку/кадр
✅ Простота реализации и надежность timing closure
✅ Возможность "турборежима" при отключении приостановки
✅ Единая архитектура для всех графических режимов
Суть: Вместо борьбы с расхождением частот - контролируемое замедление процессора до оригинального темпа работы, сохраняя при этом современный HDMI output.
Это архитектурно чистое решение, отделяющее "время симуляции" от "реального времени отображения".
P.S. Я рекомендую этот подход для любых проектов на ретро-платформах, сталкивающихся с аналогичными проблемами синхронизации между устаревшими системами и современными видеоинтерфейсами.
от вас реализация будет? в этом году?
Обновление проекта: HDMI Скандаблер и CRTC модуль готовы
Базовые видео-компоненты для проекта Aleste теперь работают:
✅ HDMI скандаублер - конвертация 15кГц в 31кГц с центрированием
✅ CRTC совместимый с MC6845 - генерация видео-таймингов и адресов памяти
Дальше: Графика Aleste 520EX
Перехожу к:
• Пиксельному процессору
• Цветовой палитре (16/256 of 4096 цветов)
• Генератору адресов видеопамяти
Основа для вывода изображения готова, теперь строим графическую систему.
https://cdn.hackaday.io/images/56238...0862-100773458
- - - Добавлено - - -
Да, мне хотелось бы его закончить до конца года.Цитата:
Сообщение от RW9UAO
Файлы полезные вам могу отдать сейчас. Но не думаю что они оттестированы. Если хотите дам в личку ссылку.
Также вам необходимо учитывать, что моя реализация своеобразная, и возможно противоречит вашему замыслу.
Но если у вас нет спешки советую подождать, до момента когда я протестирую весь видео контроллер.
График работ
Его у меня нет, и предсказывать не могу тем более что проект слишком амбициозный при этом находится на более ранней версии чем ваш.
Current Implementation Status
Module --- Status, Test Coverage, Notes
✅ Z80 Core -- Works, ZEXALL
✅ PPI (i8255) --- Works, Loopback
✅ CRTC (6845) --- Works, Read/Write & Sync
✅ AY-3-8910 --- Works, Read/Write & Synthesizer
✅ FDC (u765) --- Works, Read/Write Sector
✅ Simple UART --- Works, Loopback data transfer, Not CPC standard
✅ MMU Legacy --- Works, Advanced test
✅ MMU Native --- Works, Advanced test
✅ SDRAM Controller --- Works, Read/Write
✅ PIC --- Works, Read/Write/Interrupt
✅ NMI Logic --- Works, Read/Write/Interrupt
✅ System DMA --- Works, Read/Write
✅ Magic Sound 2 --- Works, In Progress
✅ Scan Doubler --- Works, Image on TV
✅ HDMI Controller --- Works, Image on TV
❓ Video Core --- In Progress
❓ Video GPU --- Implemented, In Progress
❓ MCU SPI Slave --- In Progress
Где статус означает:
• Works -- означает работу синтетических тестов. Без реального тестирования в железе.
• Advanced test -- означает работу синтетических тестов с использованием ПО на Z80
• Implemented -- означает наличие спецификации и кода
• In Progress -- означает наличие лишь замысла
Думаю, стоит пояснить, почему моя разработка может быть безусловно полезна для RW9UAO, но не является конкурирующей или эквивалентной. Более того, для многих моя версия может показаться не интересной.
Ниже — краткое описание сути моего проекта, который настолько отличается по своим целям и принципам, что в каком-то смысле является офтопиком для этой ветки. Поэтому предлагаю не обсуждать его детально здесь, а отнестись как к альтернативному взгляду на развитие идей, связанных с Aleste.
Две ипостаси одной идеи: Чистота Наследия и Свобода Творчества
Наша разработка основана на двух четко разделенных, но философски связанных принципах:
1. Amstrad CPC: Платформа-Канон
Цель: Абсолютная, музейная точность. Это эталон, где реализуется максимально возможная аутентичность и 100% функционирование в «легаси»-режиме.
Философия: CPC — это законченное произведение. Наша задача — сохранить его в идеальной чистоте, без компромиссов. Это высшая ценность и наш главный приоритет.
2. Aleste 520 EX: Платформа-Интерпретация
Исходная точка: Мы берем не конкретную реализацию старой «Алесты», а её изначальные идеи — мечты о расширенной памяти, графике и звуке, которые тогда не могли быть реализованы элегантно из-за ограничений компонентной базы.
Философия развития: Мы исправляем «родовые травмы» оригинальной аппаратуры (как странная организация видеопамяти), которые были продиктованы технологической необходимостью, а не здравым смыслом. Мы строим идеализированную, чистую архитектуру, о которой могли бы мечтать создатели «Алесты», имея на руках современные FPGA.
Обратная совместимость: Это не цель, а побочный эффект. Мы реализуем ключевые фичи оригинальной «Алесты» (например, палитру), но интегрируем их в новую, логичную архитектуру. Старое ПО может быть адаптировано патчами, но система не будет скована его ограничениями.
Революционные изменения: Это сознательный уход от наследия ради элегантности и мощи. Линейная видеопамять, слотовая память с защитой, супервизор — это не просто улучшения, это шаг в сторону чистой, современной 8-битной архитектуры, вдохновленной, но не ограниченной прошлым.
Ключевой принцип: CPC — это догма, которую мы блюдём. Aleste — это ересь, которую мы творим. Мы не улучшаем CPC, мы используем его ДНК для создания нового, самостоятельного организма, который должен удивлять, вдохновлять и показывать альтернативный путь, который мог бы быть.
P.S. Проект в разработке и многое может поменяться поэтому некоторые перечисленные черты могут измениться или даже удалиться из конечной версии;
Если речь о немаскируемом прерывании при обращении к (настраиваемым) диапазонам портов и памяти то неистово плюсую.Цитата:
Сообщение от Sherlock
«Да, архитектура с использованием немаскируемых прерываний (NMI) для доступа к портам и памяти действительно рассматривалась на ранних этапах. Более того она тестировалась в 1992 году. Однако после нескольких итераций проектирования мы отказались от этой идеи в пользу механизма маскируемых прерываний через syscall. Основная причина этого решения — строгое разделение типов прерываний: немаскируемые прерывания (NMI) будут жёстко зарезервированы для критических аппаратных исключительных ситуаций (например, сбоев по питанию или ошибок памяти). Использовать такой мощный и приоритетный механизм для рядовых системных вызовов было бы архитектурной ошибкой.Цитата:
Сообщение от ivagor
Таким образом, мы пришли к более сбалансированному и целостному решению, выдержанному в ретро-духе.
Ключевой принцип прост: всё, что работает с железом, лучше использовать через syscall, а не прямым доступом. Это не только безопаснее, но и архитектурно чище.
Третий слот адресного пространства жёстко зарезервирован для супервизора. В нём расположено MMIO-пространство, через которое отображены все аппаратные устройства. Прямой доступ к большинству функций возможен только в режиме супервизора.
Попасть в этот слот можно исключительно через вызов syscall. Клиентское ПО загружает данные в регистры и выполняет команду out в порт syscall, что вызывает маскируемое прерывание. Это переключение не оптимизировано и работает как классическое прерывание, что соответствует ретро-стилистике системы. Как только процессор переходит по вектору этого прерывания, происходит аппаратное переключение в режим супервизора с одновременным подключением третьего слота.
Возврат управления осуществляется записью в специальный регистр режима менеджера с установкой бита "отключение супервизора". При этом следующая за этой записью команда выполняется ещё в режиме супервизора, и только последующая — уже в пользовательском режиме, что обеспечивает корректный переход.
Таким образом, вместо прямого управления десятками аппаратных портов существует единственный, хорошо определённый портал — порт syscall. Делая такой вызов, клиентское ПО может запросить супервизор выполнить привилегированную операцию.
Одна из таких операций — включение "доверенного режима". По сути, это запуск кода в режиме супервизора без ограничений: можно исполнять код из любого слота (0, 1 или 2), а после возврата в пользовательский режим — сохранять полный доступ к третьему слоту и его аппаратным регистрам. Это мощный, но опасный инструмент, который предоставляется на страх и риск пользователя.»
Спасибо за информацию, такой вариант меня не интересует, но желаю удачи в реализации проекта.
оверкилл какой-то.
окай. железная алеста не была 100% совместима с амстрадом. это стоит поправить. в проекте ФПГА амстрада есть контроллер прерываний, но в оригинальной машине его тоже не было.
Разумеется, вы правы в том, что наш механизм syscall — это не совсем то, что вы ищете.Цитата:
Сообщение от ivagor
Он изначально не предназначен для низкоуровневой эмуляции аппаратных устройств через NMI. Его основная задача иная — это организация надежного и эффективного обмена данными между пользовательской программой, ядром и драйверами.
Главная ценность такого подхода в работе с драйверами устройств, которые требуют неопределённого времени на выполнение операции. Вместо того, чтобы висеть в циклах ожидания, пока устройство выставит некий "бит готовности", ПО может просто запросить выполнение операции через syscall и немедленно продолжить работу (асинхронный режим) или быть заблокированным до её завершения (синхронный режим). Это позволяет централизованно обслуживать все устройства в обработчиках прерываний (ISR), полностью избегая активного ожидания.
Таким образом, наш syscall решает задачи более высокого уровня — не имитация "железа", а создание отказоустойчивой и эффективной системы управления всеми устройствами в целом. Это иная, но не менее мощная архитектурная концепция.
- - - Добавлено - - -
Вы абсолютно правы, и это следствие работы без полной документации в свое время. В итоге получились следующие расхождения с оригинальной платформой:Цитата:
Сообщение от RW9UAO
• Система прерываний: Не была реализована поддержка Interrupt generation control.
• Расширение памяти: Его пришлось проектировать практически с нуля. По счастливой случайности результат оказался схож с расширением от Dk'tronics, которое, если быть точным, и само не является на 100% каноническим. Насколько я помню, в одной из версий РЕ³ даже была выпущена корректировка на этот счёт.
• Цвет: Компоненты цвета у CPC имеют яркость 0, 50 и 100% (но не у Алесты). Впрочем, ретро-компьютеры вообще не проектировались с оглядкой на точную цветопередачу (color rendition).
• Порты: Принтерный порт был реализован иным способом.
• Клавиатура: Перекодировка клавиатуры действительно теряет смысл, когда в распоряжении есть качественные механические кнопки, позволяющие реализовать более простую и эффективную схему.
• Периферия: Такие вещи, как часы (ВИ53, ВВ51), HIGHZ, FUTURE — да, их тоже лучше не реализовывать или переосмыслить.
И, как вы верно заметили, все эти моменты действительно стоит исправить для достижения большей аутентичности. Я это только приветствую.
ладно ВИ53 и УАРТ, но в часах вы храните настройки. БИОС алесты при этом будет дурковать. проверено.
Вы правы, это действительно так. Однако загрузчик, который единственный использует часы, — невероятно простой, и его легко пропатчить.Цитата:
Сообщение от RW9UAO
Это открывает два пути:
• Установка часов: Можно использовать компактный чип на I2C, если возникнет необходимость в реальных часах.
• Полный отказ от часов: Вместо этого в FPGA можно будет просто загружать крошечный файл с готовыми настройками, которые нужны загрузчику.
• Полный отказ от часов и настроек: Вместо этого всегда использовать константные параметры которые нужны загрузчику.
Все варианты решают проблему без необходимости сохранять сложную и избыточную для вашей задачи систему оригинальных часов.
Еще неполное совпадение скорости процессора (предположительно торможение не на 100% совпадает), какой-то амстрадовский тест и демки на реале запускал Дмитрий2012.Цитата:
Сообщение от Sherlock
Я помню провал этого теста. С большой долей вероятности, корень проблемы лежит не в несоответствии тактовой частоты, а в тонкостях работы системы прерываний.Цитата:
Сообщение от ivagor
На оригинальном железе демки и тесты часто полагаются на прерывания для точного замера времени и синхронизации процессов (например, отрисовки кадров или работы со звуком). Если временны́е характеристики прерываний в эмуляции/реализации хотя бы немного отличаются от оригинальных — это мгновенно приводит к рассинхронизации и сбоям. Таким образом, ключ к решению, вероятно, лежит в тонкой настройке механизма прерываний. Не смотря на то, что Interrupt generation control не поддержан, вряд ли его отсутствие приводит к провалу теста -- но не исключено.
Работаю над арбитром памяти. Мной обнаружены следующие моменты, которые могут помочь другим разработчикам в понимании проблемы совместимости по скорости процессора между Алестой и Amstrad CPC.
Арбитраж памяти в Алесте:
• Память работает на частоте 4 МГц.
• Так как шина памяти 16-битная, видеоконтроллеру для чтения двух байтов за раз достаточно одного доступа.
• Арбитр чередует доступы: каждый второй такт (частотой 4 МГц) жестко отдается видеоконтроллеру.
• Теоретически процессор может получить доступ к памяти в оставшемся такте. Фактически, процессор может работать с памятью с эффективной частотой до 2 МГц, используя одно окно доступа за каждый полный цикл.
Арбитраж памяти в Amstrad CPC:
• Основной цикл длится 16 тактов частоты 16 МГц (что эквивалентно 4 тактам частоты 4 МГц).
• Первые 8 тактов (16 МГц) жестко отданы под доступ видеоконтроллера. Для чтения двух байт используется режим страничного доступа (Burst Mode) DRAM: один раз выставляется сигнал /RAS и два раза сигнал /CAS.
• Вторые 8 тактов (16 МГц) отданы под возможный доступ процессора.
• В результате процессор также имеет эффективную частоту доступа к памяти 2 МГц, но это выглядит как одно окно размером в четыре такта (4 МГц), а не два отдельных окна, как в Алесте.
Вывод для совместимости:
Различие в структуре арбитражных окон (одно большое окно в CPC против чередования тактов в Алесте) делает Алесту в среднем несколько быстрее. Это неизбежно приводит к расхождению в производительности в строго зависящем от таймингов коде.
Для достижения полной совместимости с оригинальным CPC арбитр памяти должен быть скорректирован и эмулировать не только частоту, но и структуру доступа оригинала — то есть, использовать одно процессорное окно за цикл, а не чередование на каждом такте.
Видеоконтроллер полностью закончен и отлажен
Изображение ниже в формате 320x200-8bpp-4096c (64КБ)
https://raw.githubusercontent.com/hw..._64k8b_800.jpg
SDRAM Controller
Работает на частоте 108МГц использует burst режим читает по два слова 16 бит за один доступ
Memory Arbiter
Работает на частоте 108МГц и обрабатывает 16 битные данные. Коммутирует шину между системной шиной, видео-контроллером и графическим сопроцессором. Как и в оригинальной Aleste EX эта подсистема полностью 16 битная.
System Arbiter
Работает на частоте 54МГц и обрабатывает 8 битные данные. То есть вся остальная часть всей системы полностью 8-битная.
Video Buffer
Двойной 32 битный буфер видеоданных. Превращает 32 слова в поток байтов для генератора пикселов.
Pixel Pipeline Unit
Генерирует 8-битные пиксели и потока байтов. Поддерживает оригинальные CPC кодировки и линейные, которые планировались на Alexte EX, но так и небыли реализованы. Это режимы более простой упаковки. Например для 16 цветного режима первые два пикселя [7:4][3:0], а для 4 цветового [7:6],[5:4],[3:2],[1:0]
Color Paletter
Конвертирует 8 бит в 12 бит. Для этого имеет таблицу 512 байт. При заполнении таблицы (как и в Alesta EX) данные могут транслироваться в 12 битный формат. Поддерживаются форматы:
12 bit
CPC
MSX2+ RGB
MSX2+ YJK
Также палитра имеет автоинкремент и модификатор цвета для использования банков цвета
Scan Doubler
Конвертирует одну 12-bit на пиксел строку в две HDMI строки
HDMI Controller
Сериализует данные в HDMI интерфейс, и формирует основной кадровый и строчный темп в системе.
UART Bridge
Отладочное устройство которое позволяет управлять системой с хост компьютера. Оно осуществляет доступ к Wishbone шине через последовательный интерфейс.
6845 Mod
Модифицированная версия контроллера которая наряду со стандартной версией имеет следующее:
Имеет дополнительные регистры управления которые позволяют: адресоваться к 24 битной памяти, изменять bpp, изменять скорость потока данных,а также использовать линейный режим. Последнее было одной из нереализованных идей в EX. В этом адрес по окончании первой строки переходит во вторую. Кроме этого контроллер поддерживает burst, для этого он меняет адрес через +2, а также может это делать 2 раза в символе.
Итоговый список режимов стал такой: cpc режимы и linear. Вторые разбиты на три группы 16КБ страница, 32КБ страница и 64КБ страница. Теоретически можно использовать 128КБ но не используется.
cpc: mode0, mode1, mode2
linear: 16KB (4bpp,2bpp,1bpp), 32KB (8bpp-160x200, 4bpp-320x200, 2bpp-640x200), 64KB (8bpp-320x200, 4bpp-640x200)
Синхронизация
Wishbone работает на частоте 54МГц
Видео-подсистема на частоте 27МГц
Память на частоте 108МГц
Основной цикл состоит из 16 тактов 27МГц. У некоторых тактов есть назначение:
T04 - Sync 1 запуск цикл доступа в память для получения 32 бит. (и загрузка в выходной буфер если необходимо)
T12 - Sync 2 загрузка 32 бит данных из памяти в выходной буфер (и запуск нового доступа если необходимо)
T15 - Конец символа
В зависимости от режима пиксель clk формируется в T{0,2,4,6,8,10,12,14} тактах, в самом медленном случае T{0,4,8,12}
В целом диаграмма подобна то которая используется в Myst/Myster для CPC.
Следующий этап
Процессор и периферия.
А на базе чего вообще делается проект? Это какая-то готовая плата или собственная разработка?Цитата:
Сообщение от Sherlock
Отличный вопрос.Цитата:
Сообщение от breeze
В качестве базовой FPGA была выбрана микросхема ECP5 от компании Lattice. Альтернативным вариантом рассматривался чип от Gowin. Ключевым аргументом в пользу ECP5 стала поддержка открытых инструментов разработки: Verilator, Yosys и NextPNR.
В качестве конструктива решено использовать SODIMM-модуль, на котором размещаются сама FPGA, память SDRAM и FLASH для прошивки. Для этих целей хорошо подходит плата ICE Sugar Pro.
Была разработана материнская плата XiAletse, однако в связи с известными событиями проект пришлось приостановить. Как это часто бывает, со временем подход пересмотрели в сторону снижения стоимости и оптимизации.
В итоге появился проект FPGA LX, который стал символом минимализма — напоминанием о том, что разработчик должен ограничивать свои «хотелки» на каждом шагу. В то же время Xi олицетворял максимализм и стремление к идеальной, но избыточной реализации.
После завершения работы над FPGA-ядром будет спроектирована новая печатная плата — это будет сильно оптимизированная версия Xi.
Планируемые изменения:
• Wi-Fi-чип и аналогичные модули будут удалены с платы — вместо них появится PMod-разъём для подключения внешних периферийных устройств.
• Legacy Edge-коннекторы будут полностью убраны — они занимают много места, недостаточно надёжны, а при текущих ценах на память их необходимость сошла на нет.
• Встроенный J-Link отладочный интерфейс, вероятно, также будет удалён.
• MIDI-разъёмы заменят на Mini DIN — более компактный и современный вариант.
• ЦАП и АЦП будут заменены на более доступные коммерческие аналоги.
• Звуковая шина станет основной, а PCIe-разъёмы уступят место компактным 40-контактным прямоугольным коннекторам.
• Микроконтроллер будет заменён на более дешёвую модель (без чрезмерного удешевления — разница составит несколько долларов).
• Аудиоразъём, вероятно, будет заменён на Mini-JACK.
• VGA, вероятно, будет удален.
• Габариты платы будут уменьшены.
Для простоты понимания левая часть платы будет удалена, а на правой компоненты заменены по принципу меньше, дешевле -> лучше.
https://cdn.hackaday.io/images/2940161671369141291.jpg
# [bОтчет о прогрессе проекта Aleste-LX FPGA[/b]
Что было реализовано
Мы собрали первую рабочую версию системы, которая объединяет:
• Видеоконтроллер - выводит изображение на экран
• Систему на Z80 - центральный процессор
• Два менеджера памяти - legacy и native режимы
• Арбитр шины - управляет доступом к памяти и устройствам
• Отладочное устройство для Z80 - позволяет удаленно отлаживать код
Отладочная система
Отладочное устройство подключено через UART-мост и позволяет:
- Загружать программы в память
- Управлять процессором (сброс, прерывания)
- Выполнять пошаговую отладку
- Устанавливать точки останова
- Мониторить состояние процессора
Трудности и их решение
Что сейчас работаетЦитата:
Видеоконтроллер
Заработал сразу, но показывал только черный экран - это уже был прогресс!
UART-мост
Больше всего времени ушло на отладку UART-моста. Проблемы:
• Не проявлялись в симуляции
• В железе работали непредсказуемо
• Сигналы игнорировались или терялись
Решение: Пришлось обновить библиотеку последовательного интерфейса новым кодом.
Отладочная программа на Python
Разработка заняла 1-2 дня. Сегодня мы запустили первую программу!
Компонент Статус Видеоконтроллер ✅ Работает Процессор Z80 ✅ Работает Менеджер памяти ⚠ Требует тестов Удаленный отладчик ✅ Работает Загрузка программ ✅ Работает
[Пример кода для тестирования
Сессия отладкиКод:; Test program for Z80 debugger
; Loads at address 0xC00000
org 0x0000 ; Logical Z80 address
start:
jp 0x0005 ; Jump to main code
org 0x0005 ; Main program starts here
main:
ld a, 0x55 ; Load value 0x55 to register A
ld (0x0003), a ; Store A to memory address 0x0003
halt ; Stop CPU execution
; Program ends here (total 10 bytes)
; Bytes: C3 05 00 55 32 03 00 76
Пример запуска трассировки
Код:$ ./dbg.py trace -a 0xC00000 -n 10 test.bin
============================================================
НАЧАЛО ТРАССИРОВКИ
============================================================
1. Включаем сброс CPU...
2. Загружаем программу...
LOAD: 10 bytes at 0xC00000
3. Настраиваем трассировку...
4. Начинаем трассировку...
Шагов: 10
Останов на: inst
============================================================
step: 1 addr:0xC00000 pc:0x0000 bus:0xC3 type:FETCH dis:JP 0x0005
step: 2 addr:0xC00001 pc:0x0001 bus:0x05 type:FETCH dis:db 0x05
step: 3 addr:0xC00002 pc:0x0002 bus:0x00 type:FETCH dis:db 0x00
step: 4 addr:0xC00005 pc:0x0005 bus:0x55 type:FETCH dis:LD A,0x55
step: 5 addr:0xC00006 pc:0x0006 bus:0x32 type:FETCH dis:LD (0x0003),A
step: 6 addr:0xC00007 pc:0x0007 bus:0x03 type:FETCH dis:db 0x03
step: 7 addr:0xC00008 pc:0x0008 bus:0x00 type:FETCH dis:db 0x00
step: 8 addr:0xC0000A pc:0x000A bus:0x76 type:FETCH dis:HALT
STOP: CPU halted at 0x000A
============================================================
ТРАССИРОВКА ЗАВЕРШЕНА
============================================================
[свернуть]
Что дальше
- Запускать более сложные программы для тестирования платформы
- Добавлять native устройства (таймеры, контроллеры прерываний)
- Тестировать legacy устройства (старые Z80 периферийные чипы)
- Разрабатывать простую операционную систему или монитор
Система готова для дальнейшего развития!
"Один маленький шаг для Z80, но гигантский скачок для нашей FPGA-платформы!"
---
Проект Aleste-LX FPGA продолжает развиваться. Следите за обновлениями!