sPycialist - эмулятор ПК Специалист на Python

[CityAceE]

У 8255 есть режим быстрого сброса/установки бит в порту C.

Да, но здесь не тот случай. До меня почему-то сразу не могло дойти, что порты A, B и C соединены друг с другом через клавиатуру. И в случае с бегущим нулём мы программируем один порт на ввод, а второй на вывод. После чего отправляем в порт байт и ловим его на другом порту. Если кнопки нажаты не были, то байт приходит неизменным, а если нажимались, то соответствующий бит изменяется. Вот и вся премудрость. Но у меня в эмуляторе пока реализовано только считывание данных с портов. Таким образом метод бегущего нуля пока не работает.

обратил внимание на то, что нету привязки к времени и если где-то принудительно не задан VSYNC, то программа молотит на 100% ядра.

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

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

Да, ничего не скажешь, элегантно получилось. Я с pygame вообще не знаком, поэтому о таком трюке даже не подозревал, но нутром чувствовал, что точками рисовать - это очень медленно. Получилось быстрее моего способа, несмотря на то, что у тебя выводится каждый кадр, даже если на нём и не было никаких изменений. Используя твой способ, я попробовал обновлять экран только в случае изменений на нём, но скорости это практически не добавило, хотя в сцене из ZOO можно пропустить порядка 1500 кадров, которые не имеют отличий. Всё сжирают проверки изменений. Однако, существенный минус твоего способа для меня лично состоит в дополнительном использовании numpy. Мне хотелось обойтись только одной внешней библиотекой pygame.

В общем, svofski, спасибо, что заморочился и помогаешь улучшить скрипт!

[Advertiser]

[svofski]

С наступившим!

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

Мне показалось, что тут есть некоторое противоречие, поэтому включаю режим капитана Очевидность и заранее прошу прощения. Задержка в современном понимании -- это засыпание процесса до какого-то события, обычно таймера. Если нет задержки, значит основной цикл крутится постоянно, не отдавая времени системе вообще. pygame.Clock.tick() отмеряет время между вызовами, и включает задержку, если они случаются чаще, чем указанный fps. То, что Python.exe не показывает 100% в Диспетчере задач, так это потому что проц многоядерный. Если ядра 4, там покажется 25%. 25% проца, но 100% одного ядра.

У меня с моими изменениями загрузка опускается до где-то 20%, хотя не всегда. То есть, если реальный Специалист делает INT_TICKS за 1/50 сек, у меня он уже догоняет реал и оставляет 1/5 времени. Убедиться в том, что в принципе tick() отдает время системе, можно сбросив INT_TICKS в два раза, например - тогда моя загрузка падает до 12%. Убедиться в том, что tick() именно уступает время, можно заменив tick() на tick_busy_loop(), который делает задержку, крутясь в цикле -- тогда загрузка не меняется.

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

Используя твой способ, я попробовал обновлять экран только в случае изменений на нём, но скорости это практически не добавило, хотя в сцене из ZOO можно пропустить порядка 1500 кадров, которые не имеют отличий. Всё сжирают проверки изменений. Однако, существенный минус твоего способа для меня лично состоит в дополнительном использовании numpy. Мне хотелось обойтись только одной внешней библиотекой pygame.

По-моему экономить на рефреше экрана в эмуляторах это не лучший выбор, потому что он должен крутиться исправно в самом сложном случае. Эта игра нечасто обновляет кадры, а что делать в той, которая обновляет каждый кадр?

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

В общем, svofski, спасибо, что заморочился и помогаешь улучшить скрипт!

Меня просто удивило, что для Питона Специалист оказался почти неподъемным. Хотя, казалось бы...

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

[svofski]

CityAceE, я попробовал еще несколько разных вещей, рассказываю:

1) вынес регистры в один bytearray со сквозной адресацией, чтобы избавиться от доступа к ним через globals()
Морально лично мне это приятней, но на моем компьютере объективный толк замерить трудно.
С флагами то же самое сделать оказалось сложней, и выходит по-моему слишком много обмена шила на мыло, поэтому их не пробовал.

2) попробовал вынести процессор в класс. Пришлось немного поработать поиском-заменой, но в общем это нетрудно. Я надеялся, что сужение скопа и избавление от globals ускорит эмулятор, но по-моему получилось наоборот. Может быть можно попробовать разобраться, в чем тормоз, но пока отложил.

3) заметил, что цикл опроса очереди событий запускается каждую инструкцию. Его прекрасно хватит одного раза на прерывание. Вот это сразу скинуло мне загрузку в два раза, то есть до 10% и спокойного вентилятора.

Файлы крошечные, поэтому просто сюда их прицеплю: spyc-events.zip

[CityAceE]

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

Сравниваем изменения по сравнению с твоей предыдущей версией и реальной скоростью в Emu80:

[CityAceE]

Если нет задержки, значит основной цикл крутится постоянно, не отдавая времени системе вообще.

В моём представлении без задержек эмулятор должен работать на полную катушку - всё должно летать. Но не летает! Потому что скорость выполнения скрипта меньше скорости работы реального Специалиста. Если бы она была выше и я бы поставил холостой цикл для задержки, тогда действительно процессор был бы нагружен постоянной дурной работой. А сейчас же он работает на полную, но не успевает сделать свою работу, так что и задержки ему не требуются. Это в моём представлении.

По-моему экономить на рефреше экрана в эмуляторах это не лучший выбор, потому что он должен крутиться исправно в самом сложном случае. Эта игра нечасто обновляет кадры, а что делать в той, которая обновляет каждый кадр?

Я с тобой полностью согласен! Но такой метод может сгодится, когда больше нет возможности что-то улучшить/ускорить. Но по твоим последним изысканиям, оказывается, что резервы для оптимизации её имеются

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

Теперь, видя, такую скорость, никак не хочется её уменьшать. Это если вдруг удастся достигнуть превышения скорости, чтобы остались ресурсы для переписывания вывода плоскости без использования numpy, то тогда уже можно будет подумать об этом.

Меня просто удивило, что для Питона Специалист оказался почти неподъемным. Хотя, казалось бы...

И тем не менее уже что-то вырисовывается!

[svofski]

Так я и сам смотрел на это место два дня и мог бы обратить внимание, но в упор не видел. Заметил только когда напечатал табличку профайлера и посмотрел на число вызовов event.get().

Оставшееся всё вполне равномерно, вряд ли можно что-то принципиально улучшить в эмуляции процессора.

Самые популярные функции (отсортировано по количеству вызовов). По общему времени лидер - j<cond>, но у нее и количество вызовов большое, так что вроде пропорционально.

Tue Jan  1 16:19:19 2019    prof.out

         28186074 function calls (28179897 primitive calls) in 24.967 seconds

   Ordered by: call count

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  8216227    1.807    0.000    1.807    0.000 i8080.py:338(inc_pc)
  6406851    3.577    0.000   18.481    0.000 i8080.py:1128(core)
  3540402    0.678    0.000    0.678    0.000 i8080.py:315(read_mem)
  1598541    0.494    0.000    0.494    0.000 i8080.py:63(get_conditions)
  1595476    3.415    0.000    5.177    0.000 i8080.py:865(b11000010)
  1428592    1.612    0.000    1.925    0.000 i8080.py:669(b01000000)
  1412212    1.731    0.000    1.731    0.000 i8080.py:170(or_a)
  1398364    1.536    0.000    3.577    0.000 i8080.py:783(b10110000)
  1394605    1.400    0.000    1.714    0.000 i8080.py:494(b00001011)
   127088    0.092    0.000    0.092    0.000 i8080.py:353(dec_reg)
   125392    0.141    0.000    0.256    0.000 i8080.py:536(b00000101)
   117377    1.023    0.000    1.023    0.000 i8080.py:245(byte2mem)
    83329    0.163    0.000    0.163    0.000 i8080.py:181(cp_a)
    50121    0.084    0.000    0.084    0.000 i8080.py:148(and_a)
    49003    0.100    0.000    0.157    0.000 i8080.py:469(b00111010)
    48731    0.068    0.000    0.180    0.000 i8080.py:1016(b11100110)
    47052    0.066    0.000    0.188    0.000 i8080.py:1040(b11111110)
    41886    0.052    0.000    0.077    0.000 i8080.py:661(b01110000)
    41688    0.047    0.000    0.056    0.000 i8080.py:477(b00000011)
    39268    0.043    0.000    0.060    0.000 i8080.py:435(b00001010)
    36239    0.041    0.000    0.120    0.000 i8080.py:799(b10111000)
    21200    0.020    0.000    0.020    0.000 i8080.py:343(inc_reg)

[ivagor]

Вариант того, что можно сделать с клавиатурой (на базе v0.3). Изящества и красоты здесь нет, все тупо, но вроде работает. Еще в spyc_keyboard.py можно убрать fill_matrix. А по хорошему надо нормальный 8255.

[CityAceE]

ivagor, отличное решение с клавиатурой - не заполнять память последовательностью, а отдавать нужный байт при чтении соответствующей ячейки памяти! Спасибо за процедуру! Я её слегка оптимизировал и вынес за пределы эмулятора процессора. Также вынес за пределы эмулятора процессора и вывод экрана. Хочу чтобы эмулятор процессора был максимально чистым, и чтобы в случае чего его можно было задействовать в любом другом проекте.

Сейчас клавиатура работает везде, где не работала (тест С.Рюмика, игры Gold и Jet-Set Willi), однако остаются следующие проблемы:
1. Не работает кнопка НР.
2. Идёт залипание кнопок на пересечениях столбцов и рядов. То есть, если нажать две кнопки по диагоналям воображаемого прямоугольника на клавиатуре, то "нажмутся" ещё две по оставшимся углам прямоугольника.

Сходу понять почему это происходит и, соответственно, устранить у меня не получилось.

Также после оптимизации svofski сломался мой монитор регистров в i8080.py, вызываемый при запуске этого файла. Во-первых, теперь перепутаны местами значения регистровой пары AF. А во-вторых, приложение крашится на коде #21, при выводе содержимого памяти HL (или DE при коде #11). Опять же сходу сообразить что там не так не получилось.

Обновил версию 0.4 в первом посте и на гитхабе.

P.S. Приаттачил к сообщению пропатченый тест C.Рюмика, чтобы не ждать прохождения всех тестов, а чтобы сразу запускался тест клавиатуры. Там удобно увидеть все возникающие проблемы с клавиатурой.

[ivagor]

НР можно починить малой кровью, а чтобы диагональ не превращалась в квадрат нужно сильно переделывать.

[Q-Master]

2) попробовал вынести процессор в класс. Пришлось немного поработать поиском-заменой, но в общем это нетрудно. Я надеялся, что сужение скопа и избавление от globals ускорит эмулятор, но по-моему получилось наоборот. Может быть можно попробовать разобраться, в чем тормоз, но пока отложил.

Смысла нет ровным счетом никакого. Доступ к переменным класса и ф-циям класса в питоне несколько медленнее, т.к. везде передается self и еще там куча всякой магии.