Можно ли процедурно определить количество циклов, которые выполняет конкретная инструкция на 6502?

Да — так и пишутся почти все точные эмуляторы*; см. такие документы, как 64doc.txt. Однако это ненамного сложнее, чем простой подсчет доступа к памяти — 6502 будет выполнять доступ к памяти каждый отдельный цикл, обычно он может получить значимый результат в течение оставшейся части цикла после доступа (т. е. я немного махаю руками, чтобы избежать обсуждение того, что конвейерно, а что нет; см. документацию).

Так, например. для ADC #54 процессор должен (i) прочитать код операции; (ii) прочитать операнд. Это два цикла.

Для ADC ($32), Y это:

1. прочитать код операции
2. читать операнд
3. читать от $32, чтобы получить младший байт адреса
4. прочитайте от $33, чтобы получить старший байт адреса, добавьте Y к младшему байту адреса
5. читать из (старший байт адреса): (младший байт адреса + Y), так как было время только для выполнения вычисления младшего байта
6. о, подождите, если был перенос, то последний результат был неправильным, лучше перечитайте еще раз. Если нет то отлично, все нормально, не заморачивайтесь с этим циклом.

Так что это либо 5, либо 6 циклов.

Вы всегда можете эмулировать доступ к памяти как пошаговую синхронизированную вещь и выполнять фактическую операцию как ортогональный шаг. Также легко использовать одну и ту же логику для чтения, записи или чтения-изменения-записи: операции чтения и записи имеют одинаковое время, но в конце выполняют разный доступ к памяти, все операции Tead-Modify-Write записывают прочитанное значение обратно в течение цикла. пока отрабатываете реальный результат, то и напишите реальный результат.

*) потому что одновременное выполнение всех обращений к памяти, не включая избыточных, приводит к небольшому сдвигу времени вперед, что абсолютно не похоже на реальное оборудование. И это сбивает вас с толку, как только доступ к памяти будет осуществляться с независимой концепцией времени — таймером или чем-то, что может генерировать прерывания, или просто самой ОЗУ, если машина сканирует ОЗУ для вывода видео; не берите в голову, что это требует от вас добавления особых случаев вокруг таких инструкций, как CLI и SEI**. Эмуляторы больше не должны быть структурированы так, как они были в 1990-х годах.

**) Статус IRQ выбирается в предпоследнем цикле каждой операции. CLI и SEI настраивают бит во время последнего цикла. Таким образом, даже если ожидается прерывание, CLI не приведет к прерыванию до тех пор, пока не будет выполнена инструкция после CLI. Что само по себе может быть SEI. Таким образом, пара CLI/SEI во время ожидания прерывания должна привести к обращению к обработчику прерывания после выполнения SEI с установленным флагом прерывания. Это происходит естественным образом, если вы эмулируете цикл за циклом поведение 6502, и имеет тенденцию быть огромным взломом, если вы работаете с операцией за операцией и деформацией времени. Или, что более вероятно, такие эмуляторы просто неправильно себя ведут.