Универсальная плата расширения

Так как большинство серийных ПЭВМ имело набор разных карт расширения, хотелось бы иметь нечто подобное и под РАДИО-86РК.
В своё время различные источники (журналы Радио или Радиолюбитель) публиковали схемы с модификацией дешифрации адреса, внося в саму схему РЛК коррективы.

Данная тема - совсем о другом...

Из личных опытов (частично проверенных на своём КР-03 в железе) было замечено:

1. К580ВВ55 при чтении 8003 возвращает FE или FF (видео)
2. К580ВТ57 игнорирует запись в E009-E00F (проверил с помощью ME009 и кодом 80)
3. К580ВГ75 игнорирует запись в C000 без предварительной команды в C001

Первые два пункта я проверил более-менее (видимо в ВТ57 стоит нечто типа К155ИД6, который первые девять комбинаций использует; а ВВ55 нужно ещё проверить на импенданс при непредусмотренном чтении режима, можно ли сажать его ШД на "ноль" и откуда берётся "рандом" между FF и FE тогда?), а вот до записи в C000 всякого "мусора" - ещё руки не доходят (в Emu80 это просто игнорируется).

Что мы при этом получаем?
(В двоичном коде будет яснее):

• 10XX_XXXX_XXXX_XX11 - 8003..BFFF на чтение до 4 Кб с шагом по 4 байта
• 110X_XXXX_XXXX_XXX0 - C000..DFFE на запись до 4 Кб с шагом по 2 байта (в эмуляторе у меня там перезаписывается знакогенератор как "вариант#2")
• 111X_XXXX_XXXX_1YYY - E009..FFFF на запись до 3.5 Кб (3584 байтов) с шагом по 16 байтов (в эмуляторе у меня там перезаписывается знакогенератор как "вариант#1")

То есть, не ломая нативную схему дешифрации того же (моего) КР-03, можно прямо в параллель ВВ55/ВТ57/ВГ75 включать свои дополнительные интерфейсы.
(Не нарушая нативной целостности архитектуры...)

Тем самым, теоретически, можно ли просто разработать под все РК-совместимые ПК универсальную плату расширения, подключаемую в параллель всей цельной (не перерезая ни одной дорожки!) схемы?
(Так как ПЗУ знакогенератора обычно на панельке, схема перезагружаемого знакогератора, вставляемая в панельку, не нарушает целостность!)

P.S.: Всё пока на уровне теории.

На 30 лет опоздал :)

Сейчас новоделы надо клепать ;)

В новоделах дырки в адресации выискивать ненадо - сразу нужную дешифрацию делаем и всего делов :v2_dizzy_botan:

Да не то чтобы опоздал... Хотя да, опоздал... Но если за основу взять северную пальмиру, то может идея не так уж и плоха. Для раритетов смысла нет, так как, я где-то уже писал, вероятность разработки новых аппаратных средств (ну там программаторы и проч) для РК стремится к нулю...

Цитата:

---

Сообщение от Zidane

Да не то чтобы опоздал... Хотя да, опоздал... Но если за основу взять северную пальмиру, то может идея не так уж и плоха. Для раритетов смысла нет, так как, я где-то уже писал, вероятность разработки новых аппаратных средств (ну там программаторы и проч) для РК стремится к нулю...

---

Северная Пальмира - довольно новая разработка. То есть, архитектура на 100% не устоявшаяся, тогда как оригинальный РАДИО-86РК можно собрать почти с закрытыми глазами.
Сейчас в моём распоряжении имеется только Электроника КР-03 с клавиатурой МС 7007. Соответственно, там диодами всё уместилось в матрицу 8x8 (нет Рус/Lat, УС и СС на PC ППА ВВ55), что даже удобнее - больше битов свободно.
(Но это касательно именно КР-03.)

Тем не менее...

• ИМС ПЗУ Монитора - РФ5 на панельке
• ИМС ПЗУ Знакогенератора - РФ5 на панельке
• ИМС ППА D14 без панельки

Хотя плату уже сотни раз пропаивал, выпаивал и впаивал панельки (выпаять D14 и впаять панельку - ничего не стоит: Освободится место и под ВИ53), именно концептуально я интересуюсь вопросом, как самым мягким образом расширить всю схему.

Естественно, с ПЗУ всё просто: Вынимаем из панелек и стряпаем на макетнице переходник под РФ4 с подтягиванием адреса A11.
Получим 4 Кб под Монитор (можно и 8 Кб) и 4 Кб под Знакогенератор.
Это - как минимум. Так как ПЗУ и ПДП делят единое пространство, КНГМД подключить не получится без перерезания дорожек - пусть просто будет 8 Кб под Монитор, БСВВ или что-там ещё можно?
(К тому же, идея КНГМД уже давно устарела и, лично мне, возиться с приводами НГМД от моего "Поиска" нет желания.)

Клавиатура
Для опроса клавиатуры нужен код маски в 8000 хотя бы с один нулевым битом, чтобы из 8001 прочитать что-то отличное от FF.
Тем самым, ситуацию, когда в 8000 код FF, с помощью К155ЛА2 можно легко отлавливать и "третьим устройством" вместо матрицы клавиатуры возвращать в ППА "невозможный код" (код, который матрица никогда не вернёт, так как на всех линиях - "1"). При всех 8 Кб - это 2 Кб ввода "чего-то".

Причём, это - самая "мягкая" из доработок и требует минимума "врезок" в "сердцевину схемы".

Как использовать?
Идей пока нету...
(Но, смотрите ниже...)

ПЗУ Монитора
Можно удалить все ненужные сейчас подпрограммы и директивы, оставив только ввод с клавиатуры и вывод на экран.
Интерфейс организовать на более высоком интерактивном уровне.

Интернет
Можно "поднять" некий сервер, который будет обслуживать все запросы от РК.
То есть, необходимо разработать некий адаптер (хоть на Arduino, хоть на Raspberry Pi Zero), который организует некий "шлюз" между самим РАДИО-86РК и удалённым сервером.

Например, при FF в 8000 через 8001 (смотрите выше) возвращать байт из интернета (организовать "виртуальную удалённую клавиатуру"). Тогда формально "интернет" будет работать как "клавиатура": Что читается из 8001, то и возвращается по F803/F81B.
Отправка "запроса в интернет" - код FF по адресам 8000-9FFC (100X_XXXX_XXXX_XX00).

Код:

---

I8255A:        EQU        08000H
I8255B:        EQU        08001H

;;;;;;;;;;;;;;;;;;;;;;;;
;        Чтение "сети"
;        ;;;;;;;;
;        A - данные
;;;;;;;;;;;;;;;;;;;;;;;;
GETNET:        XRA        A
        CMA
        STA        I8255A
        LDA        I8255B
        RET

;;;;;;;;;;;;;;;;;;;;;;;;
;        Отправка в "сеть"
;        ;;;;;;;;
;        C - символ
;;;;;;;;;;;;;;;;;;;;;;;;
PUTNET:        PUSH        B
        PUSH        H
        LXI        H,I8255A
        MVI        B,000H
        DAD        B
        DAD        B
        DAD        B
        DAD        B
        MVI        M,0FFH
        POP        H
        POP        B
        RET

---

И будет непрактично, так как сервак будет завязан на одного, максимум трех человек. Ну и жить он будет столько же (и это в самом оптимистичном варианте). Принимая во внимание возраст большинства РК-любителей, идея так себе. При этом я не против, но учитывая крайне низкую распространенность этих машин идея несколько утопична. Даже ZX BBS отжил свое, насколько я знаю, а спектрумистов куда как больше чем, наверное, всех любителей советских компьютеров вместе взятых. Хотя если использовать РК как терминал....

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

Относительно подпрограмм Монитора:

Код:

---

GETKEY:        EQU        0F803H        ; Чтение "локальной клавиатуры"
GETNET:        EQU        0F806H        ; Чтение "глобального потока"
PUTCHR:        EQU        0F809H        ; Вывод на "локальный дисплей"
PUTNET:        EQU        0F80CH        ; Вывод в "глобальный поток"
PUTLOG:        EQU        0F80FH        ; Печать "лога"
CHEKEY:        EQU        0F812H        ; Опрос "локальной клавиатуры"
PUTHEX:        EQU        0F815H        ; Вывод байта на "локальный дисплей"
PUTEXT:        EQU        0F818H        ; Вывод текста на "локальный дисплей"
INKEY:        EQU        0F81BH        ; Ввод "локальной клавиши"
GETCUR:        EQU        0F81EH        ; Чтение позиции курсора/светового пера
GETSCR:        EQU        0F821H        ; Чтение символа "локального дисплея"
GETBLK:        EQU        0F824H        ; Чтение "глобального файла"
PUTBLK:        EQU        0F827H        ; Запись "глобального файла"
GETCRC:        EQU        0F82AH        ; Подсчёт контрольной суммы
SETSCR:        EQU        0F82DH        ; Установка режима "локального дисплея"
GETMEM:        EQU        0F830H        ; Чтение границы памяти
SETMEM:        EQU        0F833H        ; Установка границы памяти

---

Практически всё то же самое, но с "нюансами".
(Например, если при вызове F818 в HL адрес 8000..DFFF, старший бит обнуляется под адрес 0000..5FFF, откуда читается индекс потока для ввода/вывода.)

Цитата:

---

Сообщение от Zidane

И будет непрактично, так как сервак будет завязан на одного, максимум трех человек. Ну и жить он будет столько же (и это в самом оптимистичном варианте). Принимая во внимание возраст большинства РК-любителей, идея так себе. При этом я не против, но учитывая крайне низкую распространенность этих машин идея несколько утопична. Даже ZX BBS отжил свое, насколько я знаю, а спектрумистов куда как больше чем, наверное, всех любителей советских компьютеров вместе взятых. Хотя если использовать РК как терминал....

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

---

Хм...
Но ничто не мешает же сам "сетевой адаптер" использовать за "сервак"?
Типа, на Raspberry Pi Zero при открытии You-Tube-клипа кадры ASCII-фильтром переводить в ASCII-поток и выдавать на ППА.:v2_dizzy_vodka:

Rasperry Pi Zero может с десяток РК сэмулировать одновременно :)
Рудимент в виде раритетного РК в данной системе ненужен ;)

Цитата:

---

Сообщение от Shaos

Rasperry Pi Zero может с десяток РК сэмулировать одновременно :)
Рудимент в виде раритетного РК в данной системе ненужен ;)

---

Вложение 80201

О - ты можешь проверить сколько эмуляторов оно выдержми?
Запускай пока нагрузка проца не досигнет 100% :)

Цитата:

---

Сообщение от Shaos

О - ты можешь проверить сколько эмуляторов оно выдержми?
Запускай пока нагрузка проца не досигнет 100% :)

---

Так тема не про "эмуляцию РК на Pi", а про "эмуляцию Pi на РК":p

- - - Добавлено - - -

Доработка подпрограмм Монитора / DirectDraw-86RK
Итак, как известно, подпрограмма вывода символа на экран поддерживает только одну Escape-последовательность для установки позиции курсора.
В прошлых опытах я уже добавлял поддержку "окон" прямо на уровне ПЗУ.
Думаю, можно добавить также Escape-последовательность с передачей ей адреса на пользовательский буфер, который будет отображён максимально быстро в указанной прямоугольной области.
(Скажем, буфер "стакана" Тетриса отображать как суббуффер экрана.)
В этом случае, программа становится максимально независимой от архитектурных особенностей РК и организации экранной памяти.
(Даже на уровне Бейсика программа посредством нечто типа «PRINT AT X,Y;CHR$(27);"@";CHR$(ADDR(BF$)-INT(ADDR(BF$)/256)*256);CHR$(INT(ADDR(BF$)/256))» может моментально отобразить строковой массив)

Интересный вопрос появился.
Если в журнале РАДИО за 1993 год публиковалась схема КНГМД с ПЗУ на E000-EFFF, то возникает некий нюанс.
После "Сброса" тригерром ТМ2 блокируется ИД7 до прихода A15 и DBIN, принудительно активируя выборку ПЗУ Монитора. Само ПЗУ обычно дублируется четыре раза по диапазону E000-FFFF. Получается, процессором после Сброса считывается команда JMP F836 с адреса 0000 и именно JMP снимает блокировку ИД7.
(Иначе говоря, после Сброса ПЗУ с командой JMP 0036 также сработает в пределах ПЗУ, но ИД7 при этом не включается и всё РК'шное адресное пространство остаётся в "тени".)

Что получается?

1. Заменив РФ2 на РФ4 на месте (без всяких КНГМД), Монитор будет стартовать с адреса E000 (формально: Логически - с 0000), тем самым, код нужно планировать со стартовой позиции по E000
2. Если заменить РФ2 на своё или на РУ8/РУ10, при условии, что старшие 32 Кб мы не будем никак "трогать", процессор будет продолжать работать в "вакууме" (без ОЗУ, ПДП, ППА и т.д.) и все нижние 32 Кб можно искусственно "на макетке" создать свои (схема РК превратится в "отладочный комплекс")

Вот "Момент #2" - самый любопытный!
Так как без перерезания дорожек мы имеем отключенный ИД7 и полные 32 Кб под своё распоряжение и можем тестировать любую архитектуру ПЭВМ.
Под "универсальную плату расширения" этот "режим" тоже надо учитывать!

P.S.: Если я не ошибаюсь, вставленное вместо Монитора экспериментальное ПЗУ будет работать даже с таким кодом:

Код:

---

    .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000 C3 03 00 21 20 00 16 FF 7E B7 CA 03 00 FB 3C C2
0010 0E 00 7E F3 3C C2 14 00 15 C2 08 00 23 C3 06 00
0020 7B BD DE EF F7 89 C4 E2 F1 F8 96 CB E5 F2 F9 00

---

Причём, ИД7 так и останется заблокированным!

Цитата:

---

Сообщение от Alikberov

Интересный вопрос появился...

---

https://i.ibb.co/jgdkN7D/image.png
Возьмите кусок пальмиры. Там вопрос дешифрации и совместимости решен. хочешь используй 20 кб а хочешь - пользуйся адресным рк86

Цитата:

---

Сообщение от Ведущий_специалист

Возьмите кусок пальмиры. Там вопрос дешифрации и совместимости решен. хочешь используй 20 кб а хочешь - пользуйся адресным рк86

---

Это слишком сложно и не так сразу!
Пока обошёлся покупкой BlueTooth-ресивера для загрузки файлов без всяких переходников и паразитных наводок.

Например, думаю по директиве «O», «O,,F», «O,,11» и т.д., когда передаётся всего 1 байт на разных скоростях, удалённая система (хоть тот же Raspberry Pi) должна подготовиться к передачи соответствующего файла…
Например:

• O / O0 / O0,0 - Запрос на загрузку основной оболочки
• O1 / O1,1 - Выбор пункта #1 в списке оболочки
• O2 / O2,2 - Выбор пункта #2 в оболочке
• и т.д.

Т.е. сначала пользователь в ручном режиме даёт директиву O, после чего сразу вводит директиву I, потом запускает по G.
После чего все эти трюки с обменом файлами будут выполняться кодом самой оболочки.

P.S.: Другими словами, на первом этапе можно обойтись платой расширения в виде BT-свистелок и сервера на Python 'е.

Как мною выяснилось, внутреннее устройство ИМС ВТ57 напоминает нечто похожее на ИД6 - двоично-десятичный дешифратор адреса при доступе к нему процессором.
Если запись кода 80 по адресу E008 отключает цикл ПДП, то запись по E009-E00F просто игнорируется: Реально только девять комбинаций обрабатывается внутренней схемой ВТ57.

Так как регистры ИМС ВГ75 в основном используются на запись при программировании формата отображения, как и ВТ57 этот ВГ75 можно также использовать в режиме "только запись".
Чтение бита статуса из C001 используется после настройки режима ВГ75 перед запуском ВТ57, чтобы синхронно с началом нового кадра запустился ПДП и экран никуда не "съехал".
Однако, если мы принудительно вставим код F3 ("Конец ПДП") в конец буфера экрана - 3FF2/7FF2, то ВГ75 и ВТ57 "сами договорятся" где стартует буфер экрана.
(Это легко проверить, прописав по адресам FAE2..FAE6 байты "3E F3 32 F2 7F/3F" и слегка доработать цикл очищения экрана FDA3..FDB7.)

Правка ПЗУ

Код:

---

    .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FACE -- -- -- -- -- -- -- -- -- -- -- -- -- -- E5 21
FAD0 0D E0 36 00 2B 36 4D 36 1D 36 99 36 93 23 36 27
FAE0 2E 08 36 80 2E 04 36 D0 36 76 23 36 23 36 49 2E
FAF0 08 36 A4 E1 C9 XX XX XX XX XX XX XX XX

    .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FDA3 -- -- -- 21 D0 76 11 F2 7F 0E 00 CD ED F9 36 F3
FDB0 23 71

---

[свернуть]

Собственно, если не собираться использовать "световое перо", можно обойтись без чтения ВГ75.
Получается, добавив ещё один логический элемент, порт ИМС ВГ75 можно сместить и посадить на адрес E00A/E00B или E00C..E00F.

Тем самым, все 8 Кб C000..DFFF освободятся!
(Несколько игровых программ (как "Lode Runner" и "The Ball") нужно будет слегка подправить.)

Если перерезать сигнал от вывода 10 D10 ИД7 к выводу 6 D14 ВВ55 и вывести наружу в совокупности с ША A0-A12 и ШД D0-D7 с управлением, фактически можно получить окно A000-BFFF в 8 Кб, не теряя возможности использовать D14.
Соответственно, внешнюю схему следует усилить буферами ВА86 и ИР82 или аналогичными - это элементарный момент.

Но, в "рамках импортозамещения" я тут вдруг подумал, а что особенного такого в STM32 или Raspberry Pi, что нельзя под РАДИО-86РК заиметь совместимую с привычным уже GPIO-интерфейсом?
То есть, появилась идея снабдить РАДИО-86РК, если не таким же, то подобным интерфейсом.

Так как на GPIO имеются ШИМ, UART, I²C и т.д., на плате расширения, соответственно, необходимо иметь ИМС ВВ51, ВИ53, ВВ55 и пр.
Причём, ВВ55 понадобится штуки три, так как GPIO-пины могут индивидуально программировать на ввод или вывод. Непосредственно выводить ВВ55 на них не получится.
Один ВВ55 должен работать всегда на ввод, второй - всегда на вывод, а третий - управлять ключами/оптронами.

Это - как минимум...

К тому же, помимо всех этих дополнительных интерфейсных ИМС в области A000-BFFF необходимо иметь и ПЗУ с базовым API для управления всем этим.
Конечно, Python-подобную программную среду в 8 Кб не уместишь. Но минимальные средства, думаю, можно.

P.S.: Вот какой степени сложности получается задача, чтобы, если не полностью, то максимально совместимее обеспечить GPIO-интерфейс?