Эмуляторы I8080/КР580ВМ80A и Радио-86РК на JavaScript

[alexcp]

Видео записал, см. вложения.

При записи понял, куда делся "=": при вводе текста в промпт Монитора в симуляторе ракладка клавиатуры не совпадает с PC-шной, поэтому "=" - это Shift+"-", а не та кнопка, на которой "=" и "+". Круглые скобки - Shift+8 и Shift+9, а не привычные Shift+9 и Shift+0, и так далее.

[Shaos]

Видосы сюда можно цеплять как видосы
Аттачем а потом его урл в тэг video

[alexcp]

Размер ограничен 5МБ, а получилось восемь. Сжать было проще, чем перекодировать, да и интереса это видео большого не представляет. Удивительно, что ужалось в пять раз - вроде бы MP4 должен быть уже сжат.

[Shaos]

Ну можно было пережать с уменьшением разрешения
Наверное у тебя кодек фиговый юзался (типа mjpeg) если так хорошо сжалось
Обычно если это реально MPEG4, то он уже не сжимается

P.S. mp41isom?

Code: Select all

Playing Screen Recording 2026-06-20 174934.mp4.
libavformat version 58.45.100 (external)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f4f57885180]Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO:  [H264]  1154x616  24bpp  30.000 fps  2849.2 kbps (347.8 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.91.100 (external)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
 major_brand: mp42
 minor_version: 0
 compatible_brands: mp41isom
 creation_time: 2026-06-20T21:49:12.000000Z
Load subtitles in ./
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, floatle, 192.0 kbit/6.25% (ratio: 24000->384000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.87:1 - prescaling to correct movie aspect.
VO: [vdpau] 1154x616 => 1154x616 Planar YV12 
A:  22.1 V:  22.1 A-V:  0.033 ct:  0.104   0/  0 13%  4%  0.3% 4 0 

2849.2 kbps это ту мач - ща пережму

[alexcp]

Быстро Я, правда, тоже пережал.

[Shaos]

Быстро Я, правда, тоже пережал.

Ну тогда вот твои файлы в обрамлении тэга video

[begoon]

Разгадка «загадки» E008 → A4

Короткий ответ: ассемблер(ы) и .rk-файл абсолютно корректны — в E008 лежит E1. Значение портится уже в эмуляторе, потому что адрес E000 выбран неудачно: он попадает прямо на регистры контроллера ПДП (DMA) К580ВТ57.

Цепочка фактов (всё проверено экспериментально):

1. Ассемблер корректен. И классический i8080asm, и asm8 дают E006: CD DA E1 (CALL E1DAh), то есть E008 = E1.
2. .rk-файл корректен. На диске байты ... 21 DB E1 CD DA E1 .... Сборщик .rk (заголовок big-endian start/end + контрольная сумма) собирает их правильно.
3. Сразу после загрузки память тоже корректна. Если загрузить файл и не запускать процессор, в E008 честно лежит E1.
4. Портит значение монитор, а не программа. Я проверил вариант с HERE: JMP HERE (программа крутится на месте и ничего не пишет в E000) — её собственные байты на E009 уцелели, а E004/E005/E008 всё равно затёрлись.
5. Кто именно пишет. Трассировка записей показала, что монитор (ПК в ПЗУ, адреса FAEC–FAFB) выполняет инструкции записи в E004/E005/E008:

   Code: Select all

   E008 = 80    ; сброс команды ВТ57
   E004 = D0,76 ; адрес видеопамяти 0x76D0 (мл./ст. байт)
   E005 = 23,49 ; счётчик
   E008 = A4    ; команда «разрешить ПДП»
   

   Итог: E004=76, E005=49, E008=A4 — ровно наша «порча».

Почему именно эти ячейки. E000–E008 — это регистры ВТ57 (4 канала ПДП + регистр режима). Видео РК86 работает через канал 2 (E004/E005) и регистр режима (E008). Поэтому монитор трогает только их, а E000–E003, E006/E007 (другие каналы) сохраняют байты программы — отсюда «выборочная» порча.

Механизм в эмуляторе. Это запись (store), а не чтение. В memory.write() байт сначала кладётся в ячейку (if (addr < 0xF800) buf[addr] = byte) — поэтому мы его потом и видим, — а затем та же запись по маске addr & 0xE00F интерпретируется как программирование ВТ57.

Весь диапазон E000–FFFF — это периферия и ПЗУ (выборка по A15..A13 = 111), а не ОЗУ: E000–E008 — ВТ57, C000/C001 — ВГ75, 8000–8003 — ППА.

Для информации -- rk86_memory.ts

[begoon]

Забыл добавить: кнопка "upload" в моем ассемблере загружает результат ассемблирования в эмулятор без запуска, чтобы не нужно было постоянно через точку останова останавливать запуск.

[alexcp]

Спасибо! Про регистры ПДП я не подумал. Однако такое поведение эмулятора не соответствует поведению РК в железе. В железе при чтении по адресам E000-FFFF читается ПЗУ, а при записи по тем же адресам пишутся регистры ПДП. (Кстати, старшие биты адреса при записи не декодируются, поэтому 16 регистров ПДП занимают все 8Кб, но вряд ли кто этим пользуется.) Прочитать регистры ПДП на РК невозможно в принципе. Что ни запишешь по адресу E006, прочитаешь оттуда всегда один и тот же байт из ПЗУ.

[begoon]

О как! Я этого в точности не знал -- как именно дешифруется регион с E000 по F7FF -- что читается и что пишется.

Исправим.

[begoon]

Будет так:

1. В read() для addr >= 0xe000 возвращать зеркало ПЗУ (buf[0xf800 | (addr & 0x07ff)]) вместо buf.
2. В write() сузить запись в ОЗУ до addr < 0xe000 (а не < 0xf800), убрав фантомное ОЗУ E000–F7FF и заодно случайное загрязнение buf на DMA-адресах.

[alexcp]

Это будет корректно для оригинального РК, но не для варианта со статической памятью и 8Кб ПЗУ.

Нельзя ли сохранить возможность грузить из ассемблера и отлаживать код в ПЗУ по адресам E000-FFFF? Собственно, код, который я грузил в эмулятор, предназначен для ПЗУ. Я с самого начала хотел разместить что-то полезное в дополнительных 6Кб по адресам E000-F7FF.

[begoon]

Может так?

Загрузка внешнего файла, например, из ассемблера, может ложится куда угодно из 0000-7fff и E000-F7FF.

Запись E000-F7FF работать НЕ будет, но чтение - будет.

[alexcp]

Замечательно! Это позволит отлаживать код в ПЗУ, в том числе Монитор. В железе такая отладка невозможна без доп. оборудования, так что симулятор - единственный практический вариант.

[begoon]

Готово. Сейчас твой код для региона E000 не должен искажаться.

e2.png

e1.png