Консольные войны Z0Z5

Sotnik

Total Vacuum писал(а):

С наскока заработала PS/2-клавиатура ... получается гигантская бодипозитивная таблица сканкодов ... софтовый switch

"софтовый switch" обработка нажатий - по времени редко.
Обычная подпрограмма обработки редкого прерывания.

Hishnik

Total Vacuum писал(а):

И вот дальше задумался. Там же получается гигантская бодипозитивная таблица сканкодов. И нужен либо в верилоге жирный case, либо софтовый switch уже в самом процессоре. Вот мне и стало интересно, как умные люди из этой ситуации выходят. И почему, кстати, такие странные сканкоды? Словно код каждой кнопке назначал генератор случайных чисел.

Код:

: KEY
  0 LASTKEY !
  20001 INPORT 8 0 DO SHR LOOP 255 AND 0xF0 = NOT
  IF
    20001 INPORT 255 AND
    DUP 0x16 = IF 0x31 LASTKEY ! THEN
    DUP 0x1E = IF 0x32 LASTKEY ! THEN
    DUP 0x26 = IF 0x33 LASTKEY ! THEN
    DUP 0x25 = IF 0x34 LASTKEY ! THEN
    DUP 0x2E = IF 0x35 LASTKEY ! THEN
    DUP 0x36 = IF 0x36 LASTKEY ! THEN
    DUP 0x3D = IF 0x37 LASTKEY ! THEN
    DUP 0x3E = IF 0x38 LASTKEY ! THEN
    DUP 0x46 = IF 0x39 LASTKEY ! THEN
    DUP 0x45 = IF 0x30 LASTKEY ! THEN    

и так далее...

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

И PS/2 вот такой, там есть захват фронта PSCLK с защитой от метастабильности.

Код:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity ps2key is
    Port ( clk : in STD_LOGIC;
           psclk : in STD_LOGIC;
           psdata : in STD_LOGIC;
           dq : out STD_LOGIC_VECTOR (31 downto 0));
end ps2key;

architecture Behavioral of ps2key is

signal clkr1, clkr2, clkr3 : std_logic := '0';
signal keystate : integer range 0 to 15 := 0;

signal keycnt : integer range 0 to 255;
signal keyreg : std_logic_vector(7 downto 0);
signal qreg  : std_logic_vector(31 downto 0);

begin

process(clk)
begin
  if rising_edge(clk) then
    clkr1 <= psclk;
    clkr2 <= clkr1;
    clkr3 <= clkr2;
  end if;
end process;


process(clk)
begin
  if rising_edge(clk) then
    case keystate is
      when 0 => if clkr3 = '1' and clkr2 = '0' then keystate <= 1; end if;
      when 1 => if clkr3 = '1' and clkr2 = '0' then keystate <= 2; keyreg(0) <= psdata; end if;
      when 2 => if clkr3 = '1' and clkr2 = '0' then keystate <= 3; keyreg(1) <= psdata; end if;
      when 3 => if clkr3 = '1' and clkr2 = '0' then keystate <= 4; keyreg(2) <= psdata; end if;
      when 4 => if clkr3 = '1' and clkr2 = '0' then keystate <= 5; keyreg(3) <= psdata; end if;
      when 5 => if clkr3 = '1' and clkr2 = '0' then keystate <= 6; keyreg(4) <= psdata; end if;
      when 6 => if clkr3 = '1' and clkr2 = '0' then keystate <= 7; keyreg(5) <= psdata; end if;
      when 7 => if clkr3 = '1' and clkr2 = '0' then keystate <= 8; keyreg(6) <= psdata; end if;
      when 8 => if clkr3 = '1' and clkr2 = '0' then keystate <= 9; keyreg(7) <= psdata; end if;
      when 9 => if clkr3 = '1' and clkr2 = '0' then keystate <= 10; keycnt <= keycnt + 1; qreg <= qreg(23 downto 0) & keyreg; end if;
      when 10 => if clkr3 = '1' and clkr2 = '0' then keystate <= 0; end if;
      when others => keystate <= 0;
    end case;
  end if;
end process;

dq <= conv_std_logic_vector(keycnt, 8) & qreg(23 downto 0);

end Behavioral;

Total Vacuum

Да, наверное, будет не совсем правильно, если перекодировать из PS2 в ASCII на стороне ПЛИС. Другой вопрос, как сделать на стороне процессора. Для скорости, возможно, вместо switch лучше предварительно инициализированный массив с кодами, ну либо два массива для кодов с префиксом 0xE0 и без оного. Если же важен размер кода, то тут надо смотреть, какой вариант более компактный код дает: switch, массив или несколько if.
Если делать а-ля текстовый редактор, то достаточно иногда опрашивать регистр, в котором хранится код последнего нажатия/отжатия. Для слепого однопальцевого метода и простых комбинаций вроде Alt+Shift вполне хватит. Более того, какие-то события безболезненно можно пропустить - тут это не смертельно, т.к. всегда можно удалить и напечатать заново, если что-то не то "нажалось".
А вот для игр это может быть критично. Там порой надо обрабатывать сразу несколько одновременных нажатий. Например, одновременно давим стрельбу и 2 стрелки (бежим по диагонали), да еще и подпрыгиваем время от времени. Тут много времени уходит на обсчет сцены и отрисовку, поэтому какие-то события рискуем пропустить. И остается либо распихивать по всем щелям вызов процедуры чтения регистра, утяжеляя тем самым код и уменьшая лимит времени для "полезной" работы, либо часть работы все же поручить ПЛИС. Например, в ПЛИС можно организовать битовый массив, каждый бит которого будет хранить текущее состояние клавиш. При нажатии соответствующий бит устанавливается в 1, а сбрасываться будет по 0xF0 + код. Места и времени много не займет.

Hishnik

Ооо, это все очень интересно, поскольку вовлекает разноплановые активности в проектировании. Действительно, есть несколько уровней подключения периферии (даже встречается классификация Driver Level 0, Driver Level 1). В целом оно бывает как-то так:
1. Абсолютный минимум по аппаратуре.
В случае PS/2 это просто подключить к процессору линии CLK, DATA, и действовать по аналогии с Arduino Software Serial - периодически проверять, что там есть и программно выделять посылки.
2. Контроллер уровня "буфер для скан-кодов".
Тут уже может быть FIFO, счетчик кодов и т.д. Преобразования в ASCII и прочие функции вида "теперь надо прыгнуть влево-вверх" остаются на процессоре.
3. Контроллер с преобразованием к API прикладной программы.
Это красиво с точки зрения программы, поскольку в ней может быть действительно программный интерфейс вида "бег влево", "бег вправо", "прыжок" и т.д. Однако преобразования ложатся на HDL. Это и ресурсы (хотя и не так много), и необходимость отладки нюансов с Caps Lock + Shift (а если еще добавить Рус/Lat, то совсем интересно). Мы тут как раз в коллективе недавно подобное сравнивали - ну вот вариант 2, который выше, занял 86 строк на VHDL (там еще осталась шапка из комментариев, которую вставляет Vivado), а вариант 3 уже перевалил за 300 строк на System Verilog, и пока вроде бы не совсем завершен.

В целом же вот это все очень красиво с точки зрения архитектуры, и в этом в определенной степени сила подхода hardware&software. Совсем интересно то, что преобразование "сканкод - ASCII" с точки зрения того же hard&soft попадает в раздел "сделайте на софт-процессоре" (!). То есть теоретически к основному "процессору приложений" можно добавить еще и процессор, преобразующий коды клавиатуры в формат API прикладной программы (например, игры). Для этого уже довольно давно использовали PicoBlaze, который довольно маленький даже для старых ПЛИС. И совсем интересно, что попытка написать преобразование на HDL будет понемногу приближать получающуюся схему... к процессору! Только очень и очень специализированному, без того, чтобы сначала завести в нем много регистров, АЛУ (да еще и конвейер branch prediction :))

какой-нибудь), а потом обнаружить, что все, что ему нужно - обращаться к таблицам при очень неторопливом внешнем вводе. Так что тут очень даже интересное поле для маневрирования, и очень продуктивным оказывается практический пример. Действительно, когда оно на экране нормально бегает и прыгает от клавиатуры, это результат. И то, что помогает такой результат получить - хорошо и правильно. А теоретизировать насчет ячеек и мВт/МГц можно сколько угодно... только вот нажимаешь - а не прыгает. Поэтому и полезные вещи появляются, когда задача ставится от практики.

Total Vacuum

Пожалуй, да, пойдем от простого к сложному. Да и то лишь в случае, если самый простой вариант PS/2 вдруг не будет справляться.

Да, кстати, может сложиться впечатление, что в постах выше я как бы противопоставляю ПЛИС и процессор. На самом деле там все внутри ПЛИС, в т.ч. и процессор. Правильнее было писать "на верилоге/hdl" vs. "на си/форте/асме". Наверное, это и без пояснений понятно, но на всякий, чтобы не было недопонимания.

Total Vacuum

Надо будет сюда какой-нибудь простенький Basic запилить. Тогда станет совсем лампово

Sotnik

Total Vacuum писал(а):

Надо будет сюда какой-нибудь простенький Basic запилить. Тогда станет совсем лампово

Не помешает такое гендерное разнообразие.

Ты лучше популярно расскажи где брать и как туда прошивку залить, и на Форте писать.
Какой камень купить, какие параметры выжимаются, где перемотать синей православной изолентой.

И вообще - как это всё выглядит, для работы независимо от ПК.

Total Vacuum

Sotnik писал(а):

Не помешает такое гендерное разнообразие

Это вопрос или утверждение?
А вообще Basic планируется лишь в качестве теста клавиатуры.

Посему Бейсику быть. Что-то типа такого: https://en.wikipedia.org/wiki/Tiny_BASIC

Sotnik писал(а):

где брать и как туда прошивку залить

Готовой прошивки нет и быть не может. Даже если ПЛИС в точности такая же, но плата чуть другая, то в ней с вероятностью 100% не заработает, т.к. в ПЛИС (внезапно!) можно (и нужно!) переназначать ноги, да и частота "кварца" почти наверняка будет другой. Поэтому ставить среду (ISE для Spartan-3/6 или Vivado для новых Xilinx, для Gowin брать образовательную с их сайта, Altera сейчас на руках нет, для них Quartus), переназначать ноги (в файле *.ucf/*.cst для Xilinx/Gowin) и настраивать тактирование (модуль DCM/PLL в Xilinx/Gowin). И это лишь верхушка айсберга, еще придется переписывать, например, модуль вывода графики, т.к. в Spartan-3E Starter Kit VGA, а в Tang Nano 9/20K - HDMI и т.д. и т.п.

Sotnik писал(а):

на Форте писать

Если речь про мои поделки, то под них только на самодельных Си/Форте/ассемблере, компилировать на стороне ПК и шить. "Традиционного" консольного Форта нет и пока не планируется. Ну а бодипозитивному ANSI-совместимому жирдяю здесь точно не место.

Sotnik писал(а):

Какой камень купить

Любой. На свой страх и риск. Какие на руках у меня, писал в постах выше, по ним в меру своих сил/возможностей смогу подсказать.

Sotnik писал(а):

какие параметры выжимаются

Никакие. Как раз наоборот: искусственно ограничиваем объем памяти (до 64Kb) и частоту ядра (1.5МГц), чтобы оставаться в той же весовой категории, что и условные ZX Spectrum/NES.

Sotnik писал(а):

как это всё выглядит, для работы независимо от ПК.

Уже выкладывал в теме пару файлов *.bit с играми, их можно залить в Spartan-3E Starter Kit.

Total Vacuum

Наткнулся на забавный проект https://www.tinyjoypad.com/tinyjoypad_attiny85
Точнее, сначала на мини-консоль на базе ch32v003 https://github.com/wagiminator/CH32V003-GameConsole
А уже там написано, что все игры взяты с tinyjoypad. Так что оттуда тоже что-нибудь позаимствуем.

Наконец-то выдалась свободная минутка, в Spartan-3E Starter Kit зашевелился "редактор" с построчным вводом с PS/2-клавиатуры. Пока в упрощенном варианте: распознаются только нажатия с shift и без оного, backspace для удаления и enter для завершения ввода текущей строки. Не фонтан, но для простенького бейсика вполне достаточно. Так что и его сюда натянем при случае.

Кстати, пока отлаживал, понял, что, например, shift+A, как оказалось, нажимаю разными способами:
- нажать shift -> нажать A -> отпустить A -> отпустить shift
- нажать shift -> нажать A -> отпустить shift -> отпустить A
Или, например, некоторые комбинации вроде qwerty: следующую клавишу в комбинации нажимаю не дожидаясь отпускания предыдущей.
Короче, сейчас текст вводится нормально, каких-то отличий от ввода на обычном компьютере вообще не чувствую

Total Vacuum

Ну, допустим, PACMAN. Неувядающая классика

Оригинал есть тут: https://github.com/phoenixbozo/TinyJoypad/blob/main/TinyJoypad/Attiny85%20(Tinyjoypad)/GAMES/tinypacman%20(GPLv3)%20Tinyjoypad%20attiny85%2016mhz%20(FTD).zip
В эмуляторе: https://felipemanga.github.io/ProjectABE/?hex=https://raw.githubusercontent.com/eried/ArduboyCollection/master/Arcade%2F3in1A%2F3in1A.ino.leonardo.hex
Мне удобнее было переделывать из уже переделанной из Ардуино в Си версии: https://github.com/wagiminator/CH32V003-GameConsole/tree/main/software/tiny_pacman/src
После компиляции моим транклюкатором получается примерно такое (частоту кадров в сравнении с оригиналом уменьшил раза в 2, иначе слишком сложно играть):http://totalvacuum.ru/BATTLE/pacman.htm
Управление WASD

upd. Без проблем скомпилировалось под Форт-процессор в ПЛИС и под Irbis Forth.
Прошивка для Spartan-3E Starter Kit: http://totalvacuum.ru/BATTLE/pacman.bit
Управление четырьмя кнопками, расположенными на плате.
HTML-версия: http://totalvacuum.ru/BATTLE/pacman.zip
Пересобирается через rebuild.bat. Сначала в дело вступают препроцессор и транслятор Си, а затем к полученному файлу pacman.f при помощи команды copy в хвост и гриву добавляются пролог и эпилог (intro.htm и outro.htm), в результате чего получается "исполняемый" в браузере файл pacman.htm
Под Irbis: http://totalvacuum.ru/IRBIS/pacman.zip
Тоже через rebuild.bat пересобирается.
Что-то заметил, что у меня Irbis не всегда с первого раза запускается, пишет иногда Out of memory. Видимо, ему сразу много надо при старте.

Оригинальный исходник местами очень жуткий, тем удивительнее, что оно работает достаточно хорошо и вполне себе играбельно. Сразу же поубирал goto, т.к. этот оператор в моем трансляторе Си-в-Форт только в версии под uf \ micro forth \ реализован, а при трансляции в классические Форты не поддерживается.
Или, например, код вроде такого

Код:

uint8_t checkDotPresent(uint8_t  DotsNumber){
uint8_t REST=DotsNumber;
uint8_t DOTBOOLPOSITION=0;
DECREASE:
if (REST>=8) {REST=REST-8;DOTBOOLPOSITION++;goto DECREASE;}
return ((dotsMem[DOTBOOLPOSITION])&(0b10000000>>REST));
}

void DotsDestroy(uint8_t DotsNumber){
uint8_t REST=DotsNumber;
uint8_t DOTBOOLPOSITION=0;
uint8_t SOUSTRAIRE;
DECREASE:
if (REST>=8) {REST=REST-8;DOTBOOLPOSITION=DOTBOOLPOSITION+1;goto DECREASE;}
switch(REST){
  case (0):SOUSTRAIRE=0b01111111;break;
  case (1):SOUSTRAIRE=0b10111111;break;
  case (2):SOUSTRAIRE=0b11011111;break;
  case (3):SOUSTRAIRE=0b11101111;break;
  case (4):SOUSTRAIRE=0b11110111;break;
  case (5):SOUSTRAIRE=0b11111011;break;
  case (6):SOUSTRAIRE=0b11111101;break;
  case (7):SOUSTRAIRE=0b11111110;break;
}
dotsMem[DOTBOOLPOSITION]=dotsMem[DOTBOOLPOSITION]&SOUSTRAIRE;
}

сразу же менял на

Код:

uint8_t checkDotPresent (uint8_t DotsNumber) {
   return dotsMem[DotsNumber>>3]&(0b10000000>>(DotsNumber&7));
}

void DotsDestroy (uint8_t DotsNumber) {
   dotsMem[DotsNumber>>3]^=0b10000000>>(DotsNumber&7);
}

Но пока не везде сделал замены, там еще менять и менять.

ссылка на изображение

Total Vacuum

Немного легкого чтива на ночь. Продолжаем издеваться над здравым смыслом

Сейчас у нас такое:
- интерпретатор, который написан не на ассемблере, а на самодельном Си, который компилирует не в ассемблер, а в самодельный Форт, и лишь из Форта транслируем в самодельный же ассемблер;
- в высшей степени примитивный интерпретатор, без каких-либо намеков на оптимизации и попыток хоть немного ускорить выполняемый код, например, при помощи предкомпиляции, вот как ввели код - в том же виде его храним и выполняем;
- да и видеорежим не текстовый, а заметно более прожорливый и оттого более медленный графический.
Если в двух словах, у нас оооочень медленный Бейсик. А как его сделать еще медленнее? Правильно, уменьшить частоту процессора. Кто в здравом уме станет этим заниматься, спросите вы? Я не в здравом, поэтому мне простительно

Команды peek/poke позволяют обращаться из Бейсика напрямую к регистрам периферийных устройств, например, по адресам 0xE000+ расположены регистры модуля VGA, по адресу 0xF000 лежит код последнего события PS/2-клавиатуры. Но самое интересное у нас по адресу 0x7FFF - там делитель частоты тактов ядра. Если быть точным, это не делитель, а маска, которая накладывается по И на 16-битный счетчик тактов, команды выполняются только в случае, если после наложения маски на счетчик выходит 0. Таким образом, если маска 0, то команды выполняются на каждом такте (равносильно тому, что делитель равен 1), если маска 1, то выполняем только на четных тактах (по сути делитель равен 2), если маска 3, то выполняем на каждом 4-м такте и т.д. Для простоты можно считать, что в качестве делителя допускаются только степени числа 2, а в маску надо писать число на единицу меньше. Но называть все равно будем "делитель".
После включения в этом регистре 31, что означает, что базовая частота 50MHz делится на 32, т.е. получается примерно 1.5MHz - чуть меньше, чем в NES. Если выполнить poke 32767 15, то станет "чуть меньше, чем в ZX Spectrum", а именно 3MHz.
Ну а если уменьшить частоту? Пишем в регистр 511, выставляя тем самым частоту 100KHz. И ничего страшного не происходит. Даже если очень быстро текст набирать, нажатия кнопок не теряются, редактор все успевает прожевать и выплюнуть на экран. Очистка экрана или вывод на экран текста по командам list и load явно меньше секунды. Да, не мгновенно, но и не смертельно. Не знаю, были ли в природе ретро-компьютеры, процессоры в которых работали бы на такой низкой частоте, но мы продолжим

Если ставим делитель 1023(50KHz), экран обновляется достаточно быстро, но уже начинают изредка пропадать нажатия клавиш при слишком быстром наборе текста.
С делителями 2047(25KHz) и 4095(12KHz) обновление экрана уже занимает пару секунд, нажатия могут теряться чаще, но все еще имеем возможность набирать текст достаточно быстро.
Делитель 8191(6KHz), экран обновляется секунд за 5, быстро набирать текст все еще можем, но лучше уже начинать переходить к слепому однопальцевому методу.
К этому и, естественно, ко всем предыдущим делителям вполне можно приноровиться, какого-то отторжения не вызывают, будь у меня хотя бы такое в детстве - был бы счастлив

С делителем 16363(3KHz) обновление экрана уже занимает около 10 секунд, если текст вводить однопальцевым методом, то нажатия почти не пропадают.
Делитель 32767(1.5KHz) уже привозит секунд под 20 к обновлению экрана, а текст лучше вводить в режиме "нажал-подержал-отпустил", иначе не всегда "пропечатывается":) И даже видно, как каждая отдельная буква прорисовывается на экране слева направо.
Но все же как так-то?! Как оно вообще работает?! Тут уже частоты в несколько Килогерц. Не Мегагерц, Карл! Килогерц!

Их даже ухом можно услышать. Если к ПЛИС ухо приложить, то можно услышать, как шестеренки скрипят

Но мы ведь не закончили. Еще в запасе 65535. Делим. "Стрелка осциллографа" (с) показывает 763Hz.

Это дно, друзья.
Экран обновляется секунд за 35, кнопку надо нажать, подержать и отпустить, тогда через секунду на экране плавно появится буква. Или не появится. Надо повторить - тогда точно появится. Но это не точно...

А теперь надо запустить что-нибудь, но об этом как-нибудь в другой раз...

P.S. Кто-нибудь знает, у какого серийного компьютера в природе самая низкая частота процессора? Мне пока нагуглился 1MHz в C64, но наверняка где-то должны быть и более низкие частоты.

Да, кстати, есть и другая крайность. Если поставить делители 0/1/3 (50/25/12MHz), то процессор начинает "догонять" "видеопроцессор" (который всегда работает на частоте 50MHz), код, который написан на Бейсике, выполняется правильно и быстро, однако "ломается" прописанная на Форте (и оттого слишком быстрая) процедура очистки экрана. Т.е. для высоких частот, возможно, придется искусственно замедлять некоторые процедуры.

Hishnik

Интересная штука получилась!

Для клавиатуры можно добавить аппаратный модуль, который будет работать на нормальной частоте и всегда сможет отдать принятый символ. Тогда "подержать и отпустить" уже будет не надо.

А откуда проблемы с видеопроцессором? У них же с процессором должно быть разделение функций либо по двупортовой памяти, либо по FIFO для команд, если видеопроцессор достаточно мощный для такого.

Total Vacuum

Hishnik писал(а):

Интересная штука получилась!

Сам не нарадуюсь

Получается инструмент, который позволяет на собственной шкуре почувствовать, "что было бы, если бы..." А также дает возможность найти бутылочные горлышки и сделать "быстрее, выше, сильнее". Или наоборот поворчать в духе "теперича не то, что давеча"

Hishnik писал(а):

Для клавиатуры можно добавить аппаратный модуль, который будет работать на нормальной частоте и всегда сможет отдать принятый символ. Тогда "подержать и отпустить" уже будет не надо.

Сейчас сделано в самом примитивном варианте: модуль PS>>1 (работает на высокой частоте) складывает в регистр 0xF000 код последнего события, а процессор в ПЛИС в цикле опрашивает этот регистр на предмет "не случилось ли чего". Если вдруг что-то нажалось, то процессор с учетом статуса shift-а переводит сканкод в ASCII-код по таблице (слепил ее на верилоге, лежит по адресу 0xD000), добавляет символ к строке и начинает выводить на экран. И если тактовая низкая, то от момента нажатия до окончания вывода на экран может пройти много времени, за это время содержимое регистра статуса клавиатуры может поменяться несколько раз, если слишком быстро текст набивать, но процессор после выхода из запоя заметит лишь последнее из этих событий. Вот только эффект пропадания нажатий наблюдается при экстремально низких частотах, так что, наверное, нет смысла сильно переживать по этому поводу. Ради спортивного интереса, конечно, оптимизирую цикл опроса и подумаю над тем, как подкрутить модуль PS/2 на верилоге, чтобы поменьше терялось или не терялось вовсе. Может вообще печать нажатых символов отдельно вынесу, а в цикле оставлю только добавление символа в буфер.

Hishnik писал(а):

А откуда проблемы с видеопроцессором? У них же с процессором должно быть разделение функций либо по двупортовой памяти, либо по FIFO для команд, если видеопроцессор достаточно мощный для такого.

Это скорее даже не проблема, а приятные хлопоты.

Процессор имеет возможность писать в модуль VGA либо по одному пикселу (адрес 0xE000), либо сразу по 16 (0xE007) с учетом палитры (0xE009), маски (0xE00B) и прочего. При очистке экрана скармливает сразу по 16 пикселов за раз. Но вот сам модуль VGA распихивает эти 16 пикселов по видеопамяти поштучно, по одному пикселу за такт. И если вдруг идет запись в 0xE007, а предыдущие 16 пикселов еще не дорисованы, то старые данные сбрасываются, начинают обрабатываться новые. Можно сделать (более того, так и было сделано изначально) буфер побольше, но нет гарантии, что и этот увеличенный буфер не переполнится, поэтому оставил 16 пикселов и сброс при записи в 0xE007. Проще в софте паузу добавить для слишком шустрых процессоров.

Total Vacuum

Просто для иллюстрации... Насколько медленно рисует процессор, если поставить частоту 763Hz. Пока отрисовывает надпись "hello, world", спокойно успеваю сфотать несколько раз.

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

Total Vacuum

А вот так из Бейсика можем опрашивать клавиатуру

ссылка на изображение
или рисовать

ссылка на изображение

Консольные войны Z0Z5

Кто сейчас на конференции