Код эмуляции i8080 на С

[Patron]

суть в том что главный луп эмуляции реально потактовый

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

[medvdv]

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

Ну видимо я и имел ввиду эмуляцию по циклам процессора или шины, не по совсем уж тактам физически =) - тут терминология просто разошлась

вообще если гнаться за реальной точностью эмуляции по какой либо причине - то это скорее всего будет PC и там если честно в наше время глубоко все равно хватит и по циклам и даже по тактам если с умом написать - не суть важно - скорее важно чтобы было проще разрабатывать и отлаживать

а если шить эмулятор в контроллер на арме - там да - и памяти и скорости будет возможно впритык. но скажем сейчас 30 долларов стоит распберри и она по сути идеальный контроллер для эмулятора в коробочке - и разрабатывать / отлаживать удобно и выход на телек уже есть и скорости достаточно пожалуй даже для потактной эмуляции или типа того.

[uart]

У себя я использую не такты процессора, а "такты" кварца. Процессор берет их с *коэффициентом 9, ВГ75 - 12. Выполнение каждой команды это обязательный вызов FETCH плюс, в зависимости от кода команды, необязательные обрамленные RD и/или WR. Из этих трех функциях и вызывается DMA, а заодно и обслуживание ВГ75.
Но реализовано немного кривовато, в лоб, поэтому интересно было бы посмотреть на другую реализация.
На оптимизацию пока забил, IMHO больше времени тратится на прорисовку эмуляции ВГ75, чем на все остальное. Да и все равно с большим запасом хватает...

[medvdv]

У себя я использую не такты процессора, а "такты" кварца.

Я вот думал и пришел к выводу что можно сделать разумно компромиссную архитектуру - некий секвенсер кучи параллельно работающих устройств с разными циклами длительности

скажем есть текущее время в каких то условных тиках которые мельче любых устройств в машине

обычно это как минимум пиксель клок который раза в 2 чаще чем такты CPU ну или даже еще мельче

clock = 0

while emulationOn {
next_clock = 0
foreach chip in chips[] {
if chip.local_clock <= clock { chip.local_clock += chip.execute() }
if (next_clock == 0) || (next_clock > chip.local_clock) { next_clock = chip.local_clock }
}
clock = next_clock
}

chip.execute() возвращает количество проэмулированных тиков и мы плюсуем их к локальному времени устройства

соответственно эмуляция это куча устройств (вывод на экран тоже становится устройством и можно реально попиксельно обновлять / сканировать наш виртуальный телек соотв с эмуляцией всей фигни типа динамической смены палитр по ходу сканирования и бордера от звука в спектруме и тд) так вот устройства тут все - и клавиатура и сканер картинки и видео процессор если надо и дма и все что угодно - и каждое после атомарной операции сообщает на сколько тиков вперед оно просчиталось и соответственно мы не трогаем его раньше времени.

теперь можно сделать что CPU будет не покомандно работать а по своим там внутренним циклам или просто потактно а можно и по старинке покомандно - это не меняет сути самого секвенсера и спрятано внутри объекта цпу или иного устройства

вот как то так видится

а внутри того же CPU в .execute() просто меняются стейты FETCH / DECODE / EXECUTE / RD / WR
так же внутри DMA и прочих устройств

ticks cpu::execute()
{
switch(.state) {
case FETCH: ... .state = DECODE; return 4;
case DECODE:
case RD:
case EXECUTE:
case WR:
}

[b2m]

каждое после атомарной операции сообщает на сколько тиков вперед оно просчиталось и соответственно мы не трогаем его раньше времени

В моём эмуляторе примерно так и сделано. Только у меня две величины:
- время в тиках, которое проэмулировано
- время, когда нужно вернуться к эмуляции данного устройства снова (т.е. попросту таймер), каждое устройство само решает, на сколько оно засыпает

Т.е. у меня не эмулируется "наперёд", а наоборот, откладывается на некоторое время. Это важно, поскольку если устройства взаимодействуют между собой, то "доэмулировать" до нужного времени (до момента, когда происходит взаимодействие) можно, а вот откатить назад - нафиг надо.

[medvdv]

Т.е. у меня не эмулируется "наперёд", а наоборот, откладывается на некоторое время. Это важно, поскольку если устройства взаимодействуют между собой, то "доэмулировать" до нужного времени (до момента, когда происходит взаимодействие) можно, а вот откатить назад - нафиг надо.

Хорошо значит сделано

Ну это уже вопрос терминологии / трактовки внутри объекта - можно сказать что вернул сколько ему спать дальше, или насколько тиков текущий стейт будет валиден, так то понятно что считаться надо до текушего времени <= clock скорее чем clock + еще сколькото, это верно, раз-ся

[Advertiser]