1). Режим чистой БК0011М (набор №1 прошивок fpga) - полная совместимость с оригиналом
2). Режим чистой БК0011М + СМК512 (набор №2 прошивок fpga) - полная совместимость с оригиналом





1. Стандартный 256*256*2бит (размер экрана 16КБ)
2. Стандартный 512*256*1бит (размер экрана 16КБ)
Расширенные:
3. 256*256*16бит (размер экрана 128КБ)
4. 512*256*16бит (размер экрана 256КБ)
5. 512*384*16бит (размер экрана 512КБ)
6. 640*288*16бит (размер экрана 360КБ)
6. 640*480*16бит (размер экрана 600КБ)
7. 800*600*16бит (размер экрана 937КБ)
8. 1024*768*16бит (размер экрана 1.5МБ)- только для БК12.

Переключение видеорежимов осуществляется через специальный регистр [ожидается назначение], общий объем доступной GPU видеопамяти составляет 8МБ, куда зеркалируется видео-ОЗУ стандартных режимов БК11М.
В каждом расширенном видеорежиме доступно два видеобуфера, доступ к которым имеет как GPU, так и ВМ1 посредством страничного доступа через регистр [ожидается назначение] в диапазоне адресов [ожидается назначение, предположительно - окно Бейсика]


Общий объем ДОЗУ БК12 составит 64МБайт (два банка по 32), адресуемые как последовательным, так и страничным методом. В эти 64МБ будет включено 512Кб, адресуемые контроллером СМК, стандартное ОЗУ БК11М - 128КБ (либо 4МБ адресного пространства режима PDP-11/70) и 8МБ видеопамяти расширенных режимов. Оставшийся из 64МБ объем свободной памяти будет использован под пользовательские нужды.
Последовательный доступ ко всему объему 64МБ реализован с помощью регистров [ожидается назначение].
Страничный доступ реализуется двумя методами, доступными для пользования одновременно:
1. Плавающее окно. В двух 16-разрядных регистрах [ожидается назначение] задается начальный адрес ЭД в диапазоне 0-64МБ, от которого отсчитывается страница размером 16КБ, подключаемая в диапазон [ожидается назначение, предположительно - окно Бейсика]. В старшем бите старшего регистра задается размер плавающего окна (по умолчанию 0 -16КБ, 1 - 8КБ). Если размер окна задан 8КБ, то подключение производится в диапазон [ожидается назначение].
2. Адресация фиксированными окнами. Используются те же самые два регистра, старший бит старшего - размер страницы (16/32КБ), младшие биты - номер страницы от 0 до 4095 при размере страницы 16КБ или от 0 до 2047 при размере страницы 32 КБ. Страница монтируется в те же диапазоны, что и при работе плавающего окна.


РАБОЧИЕ ИЗМЫШЛЕНИЯ
------------------------------------------------------------
? Voland - 22.04.2013 20:08
>> ЭД - устройство с последовательным доступом к памяти.
Разработчик говорит, что можно использовать оба режима, они никак не конфликтуют. Т.е. и последовательную заливку и страничный доступ из адресного пространства БК. Но придется продумывать куда именно подключать. Например, как тут уже предлагали - вместо окна бейсика.
? anonymous - 22.04.2013 20:13
На правах бреда: возвращаясь с субботника в субботу, видимо от усталости, подумалось, а не скрестить ли ужа с ежом? Что если добавить в MMU еще немного регистров, а при адресации командами @Rx выдавать в MMU номер регистра-источника адреса для адресации памяти суммой его содержимого и содержимого дополнительного регистра MMU, для каждого РОН - своего, по примеру x86? При сбросе в дополнительные регистры, адресуемые на шине, будут заноситься одинаковые значения и совместимость не пострадает. Глубоко не продумывал, но идея не нереализуемая.
? gid @ - 22.04.2013 21:02
>>? Voland @ - сегодня 20:08
[Разработчик говорит, что можно использовать оба режима, они никак не конфликтуют.]
В таком случае, будет полезным реализовать плавающее окно, которое подключается как страница, начальный адрес которого задаётся теми же регистрами, которые задают адрес в ЭД, а режим работы задаётся некой командой, дополнительно к тем, что задают режим работы ЭД (чтение/запись). Шаг окна можно сделать фиксированным в 16 байт, а можно так же сделать настраиваемым (это необязательно).
И если сделать память ЭД наращиваемой неограниченно (до 4Гб для 32бит), то доп.память СМК действительно станет не нужна. И если видеопамять будет в этом же диапазоне адресов, для прямого доступа к ней через ЭД.
А уж если ввести сегментные регистры, т.е. не в том смысле как в x86, а некие заранее программируемые окна, между которыми можно быстро переключаться, например заданием номера сегментного регистра в каком-нибудь управляющем регистре, то будет очень неплохо, для манипуляции данными.




[концепт решения с постраничным обменом]
Нашёл. В этой ветке, искать на странице эту строку "? gid @ - 22.04.2013 21:02"
Речь зашла о двух разных режимах доступа к электродиску: последовательном и оконном.
Для последовательного доступа обмен обычно делается как при работе с FDD/HDD, там вообще много разных вариантов, просто нужно выбрать оптимальный и проще реализуемый.

Для ЭД организуются два 16-разрядных регистра. Регистр адреса/данных и регистр команд.
При последовательном доступе регистр команд с помощью установки определённых битов управляет, как надо интерпретировать данные, которые пишутся/читаются в регистр адреса/данных. Передачу данных можно организовать как блочную (как в HDD) так и пословную.

Вот моя концепция.
Допустим адресация электродиска изначально будет 32х разрядной, а обмен пословный (мне так проще).
Тогда нужны команды:
1) установка начального адреса чтения/записи, в счётчик-указатель текущего адреса.
После подачи команды в регистр адреса/данных передаются 2 слова (мл. и ст. части адреса)
2) чтение текущего значения счётчика-указателя текущего адреса (полезно для организации seek from current pos, да и вообще полезно знать, куда мы собираемся что-то записать)
После подачи команды из регистра адреса/данных принимаются 2 слова (мл. и ст. части адреса)
3) бит-флаг режима обмена данными: 0 - чтение, 1 - запись. при этом, читаем/пишем из/в регистр(а) адреса/данных текущее слово, после чего счётчик-указатель текущего адреса автоинкрементируется на 2 (т.к. обмен пословный, а организация данных традиционно байтовая).
Можно в общем-то как в ВП1-128 сделать, пишешь в регистр адреса/данных - значит режим записи, читаешь - значит режим чтения. Просто отдельный бит добавляет детерминированности.
4) опционально, направление чтения/записи 0 - вперёд, 1 - назад, при этом счётчик-указатель текущего адреса автодекрементируется. (нужен ли такой режим - большой вопрос)
При пословном режиме обмена не нужно задавать длину передаваемого массива, просто читаешь/пишешь сколько нужно, пока не надоест.

И оконная организация. Режим работы задаётся битом в регистре команд.
Организуется плавающее окно, адрес начала фрейма которого задаётся так же как для последовательного режима.
Окно подключается либо в область памяти 100000-140000 как обычная страница памяти. Либо в область 140000-160000 вместо ПЗУ монитора БК11. Для БК10 можно использовать 120000-160000 или 140000-160000 соответственно.
режим обмена данными тут уже играет роль защиты от записи. 0 - запись запрещена, 1 - разрешена.
У диапазона 100000-140000 достоинство: сразу 16Кб доступно становится, недостаток: в этом месте мог бы быть полезный код пользовательской программы.
У диапазона 140000-160000 достоинство: не отбирает полезное адресное пространство, недостаток: всего 8кб доступно.
Полезность оконного режима в том, что можно сразу из памяти ЭД выполнять подпрограммы из библиотеки подпрограмм / оверлея. Так же возможен ускоренный обмен данными с ЭД, для этого как раз более подходит диапазон 140000-160000.
Шаг плавающего окна - слово, чтобы не городить лишнего.

При использовании ЭД как структурированного хранилища данных заданного формата, всю работу по форматированию и блочному обмену данными (напр. в точности как в драйвере дисковода) выполняет программный драйвер.
? gid @ - сегодня 13:20
Ещё пришло в голову пара мыслей.
Для последовательного доступа можно сделать раздельные счётчики-указатели для режимов чтения и записи.
Тогда если в них задать одинаковые значения, а бит-флаг режима обмена данными не использовать, то можно будет модифицировать данные непосредственно читая и записывая данные в регистр адреса/команд. Например такой командой BIS #NNN,@#REG$AD
Или можно будет читать из одной области ЭД, а записывать при этом в другую, не модифицируя для каждой операции счётчик-указатель.
Для оконного режима в таком случае можно будет подключать сразу две области памяти в разные цчастки окна.
Например 100000-120000 - фрейм окна счётчика-указателя чтения, 120000-140000 - фрейм окна счётчика-указателя записи. Тут правда ещё додумать концепцию нужно. И нужно ли оно вообще.

? Дмитрий - сегодня 14:13
>> все отрисовки будут при любом количестве битности цвета быстро отрабатывать через команды в графический контроллер
Даже копирование картинки на экран? С графическими примитивами все ясно - там будет работать АПИ. А допустим, мне надо отобразить картинку с диска на экран. Вливать массив графических данных картинки в видеопамять кто будет? ВМ1 или АПИ через ПДП? Этот момент не совсем ясен...

? MM @ - сегодня 14:43
1. Окно по адресам 100000-137777 ( 16 кбайт ) , регистр номера окна - 177666, сбрасываемый по команде 000005 ( только 11 ( М ))
2. Окно по адресам 120000-137777 ( 8 кбайт ), регистр номера окна - 177666, сбрасываемый по команде 000005 ( совместим с БК10 и 11М )
Почему сбрасываемый - что бы при пуске там всегда была 0 страничка ЭД, а в ней - начальный загрузчик.
3.Даже есть Э3 этого дела, и даже материалы куплены ( включая колодку под 72-пин СИММ ) - нет сборщика.
4.Можно расположить в адресах BS7 - регистр режима, регистр адреса, регистр старшего адреса, регистр данных - не особо сложнее выйдет, чем п.1 и п.2.
? gid @ - сегодня 14:54
>>? MM @ - сегодня 13:28
Это сложно? на мой взгляд довольно просто. Не с точки зрения схемотехники, конечно.
Просто кто-то хочет ЭД с последовательным доступом, устроенный по типу накопителя на магнитной ленте.
Я считаю такой ЭД при наличии HDD избыточным анахронизмом, но чтобы угодить и нашим и вашим предложил двухрежимный ЭД.

И да. Про видеобуфер забыл.
Тут вон подняли вопрос про как помещать спрайт в видеопамять.
Опять же самый простой способ - плавающее окно, поскольку объём видеопамяти превышает 64кб, то другого удобного способа обращаться туда нет.
Ну ещё можно включить адресное пространство видеопамяти в область адресов 4Мб ВМ3 и использовать его диспетчер памяти.
Но учитывая что для нормального отображения видео нужно минимум 2 видеобуфера - первичный и вторичный, так же видеопамять для хранения спрайтов, чтобы ими манипулировал графический процессор без участия ВМ1 и шины МПИ вообще, то для каждого режима надо объём памяти увеличить минимум в 4 раза, а лучше сразу в 8 раз, чтобы потом не переделывать всё.
Так что тут даже 22разрядного адресного пространства ВМ3 может не хватить, а для 1024х768 не хватит точно.
[Должны ли в памяти как-то пересекаться/накладываться стандартные видеорежимы с расширенными]
Не знаю. Тут от сложности аппаратной реализации зависит. К тому же расширенные режимы в принципе не совместимы со стандартными, так что скорее всего проще сделать так - копировать экранную память стандартного режима в память отведённую для расширенного - способ копирования например наложение адресных пространств, и отрисовывать уже оттуда новыми методами графического процессора. При этом с обычного видеовыхода будет доступен дубликат стандартного режима. При использовании стандартного режима конечно.


anonymous:
Блок ИРПС БК перемычками может устанавливаться на 0176560..0176567, на 0176570..0176577 и на 0177560..0177567, одна перемычка - в составе блока переключателей, от вывода 23 ВП1 - позволяет выбрать между 0176560 и 0177560, а вторая - дорожкой на плате от 24 вывода ВП1. Четвертая комбинация позволяет задавать свои любые адреса, т.к. при этом выборка будет производиться по сигналу BS.

[будет ли пересекаться с тем регистром, который использовался в БК для ИРПС/КМК]
Наверно ММ по этому поводу будет сильно возражать. А как же тогда подключать терминал 15ИЭ-00-013 и юзать его в РТ-11?
Ведь есть же свободные диапазоны.
Например 177550-177557, там по стандарту перфоленточное устройство ввода вывода PC11/PR11 для PDP11.
Или 177500-177507 - Накопитель на кассетной магнитной ленте TA11
или 177160-177167 - Устройство вода с перфокарт CM11/CR11 / устройство CD11
Есть ещё куча диапазонов, которые в книжках по RT-11 считаются зарезервированными на будущее, т.к. они не знали, что в СССР кто-то не очень с их мнением считается, и размещает в тех диапазонах порты своих устройств.
Навряд ли кто-то будет использовать подобные устройства на БК, правда насчёт совместимости с ДВК не знаю, т.к. составить полную таблицу распределения портов среди множества ДВКшных девайсов никто так и не смог до сих пор.









? gid @ - сегодня 22:02
>>? Voland @ - сегодня 18:16
[я начал формировать "скелет" документации программиста]
Почитал, что там написано. И у меня появились такие мысли.
1. Электродиск не нужен. Вообще. Проще сделать памяти побольше и с помощью драйвера формировать виртуальный диск, для максимального быстрого доступа к нужным данным. Электродиск имеет смысл только если он будет энергонезависимым устройством. Но в этом качестве наверно проще использовать обычную USB-флешку, это будет менее затратно.
2. Если для видео ОЗУ планируется страничный доступ с регистрами, а так же для доступа к доп. памяти используется страничный режим, то не проще ли их совместить? Всё равно понадобится диспетчер памяти, предлагаю использовать под это дело стандартные регистры диспетчера памяти ВМ3.
Надо просто расширить существующий диспетчер памяти и добавить ещё один режим. 29-разрядный. Вот 32-х разрядный адрес как я ни думал, никак без ввода ещё одной порции регистров PAF не получается.
В регистре управления ДП SR3(MMR3) есть бит AS (04), он управляет шириной адреса, 0 - 18 разрядов, 1 - 22 разряда. и есть бит UM (05), говорят, что этим битом можно подключать к ВМ3 свой внешний ДП, но т.к. делается свой процессор, то можно сделать по другому. Вводим ещё один бит, например (03), его установка будет включать 29-разрядную адресацию.
Физический адрес будет формироваться так

29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
-------------------------------------------------------------------------------------------
..........................................| ...... Виртуальный 16 разрядный адрес ....... |
-------------------------------------------------------------------------------------------
..........................................| . APF. | ... ... BN ... ... | .. .. DIB .. .. |
-------------------------------------------------------------------------------------------
| ... ... ... Регистр адреса страницы ... ... .... |
----------------------------------------------------
| ... ... ... ... ... PAF ... ... ... ... ... .... |
-------------------------------------------------------------------------------------------
Физический 29-разрядный адрес
-------------------------------------------------------------------------------------------
| ... ... ... ... ... ... PAF · BN ... ... ... ... ... ... ... ... .... | .. .. DIB .. .. |
¤

Т.е. теперь старшие 23 разряда образуются конкатенацией полей PAF и BN, а не сложением как раньше.
А говоря точнее, BN выкидывается, DIB поглощает поля BN, т.к. при таком способе расчёта адреса мы больше не можем двигать 8-кбайтное окно по памяти с шагом в 64 байта.
Что делает данную модель полностью несовместимой со стандартными 22- и 18-разрядными моделями. И с РТ-11, без доработки её напильником в некоторых местах. Зато будет можно включить в единое адресное пространство видео ОЗУ и единообразным способом адресоваться к нему и к расширенному ОЗУ.
¤
Альтернативный вариант - добавляем ещё 8 регистров PAF, и можем использовать 22+16=38 разрядную адресную шину с полным сохранением совместимости с моделью памяти РТ-11 (она по прежнему будет видеть свои 4Мб, а при доработке - и остальное), недостаток здесь: больше регистров - дольше переключение, больше кода.
¤
и это, адреса портам и регистрам можно будет назначить и позже, когда будет определено примерное количество используемых портов и регистров (для их логической группировки по функциональному назначению), а так же какие порты и регистры будут у уже существующих устройств, используемых совместно с БК12. Просто на данном этапе нужно дать им уникальные имена и создать табличку с именами, описаниями, что это такое и пустым полем, куда потом будет вписан адрес или заполнить значением существующего адреса у уже существующего устройства.
Например 177130, 177132 будут использованы контроллером дисковода и т.п. поэтому потом надо будет рассчитать так, чтобы блок новых регистров не пересекал занятые адреса.
? MM @ - сегодня 22:39
1.UMAP - по крайней мере почти стандартное решение, без вариантов. Только лучше его до 4 Гбайт ( 32 бит ) довести - с прицелом на будущее.
2.Можно ЭД с адресом регистра 177666 запрячь на полную катушку ( только в плюшевом варианте ) - что бы он организовывал доступ вообще ко всей памяти новодела, включая регистры - т.е. фактически небольшой ДП получается. Достоинство - из режима ВМ1 тоже будет доступна переферия высших адресов ВМ3.
3.Или пойти совсем большой дорогой - присмотреться к Ваксе - при переходе на нее дело как раз была такая проблема - нехватка и адресов, и быстродействия, и вообще всего. Но тут есть небольшой плюсик - Вакса ( с серпом и молотом ) коммерчески доступна в настоящее время, цены коммерческие, производительность ( максимальная ) - 5 лимонов - 10 мгц. Совместимость - читаем руководства.
( Или , может, отдельный блочок для опытов с ней собрать ? )
( Кстати, в 1839ВМ1 используется ПЗУ микрокоманд внешнее - а не сменить ли его на СОЗУ, да и не подзаписать ли туда своего коду ? ).


? gid @ - сегодня 15:39
>>? Александр... @ - сегодня 10:45
[ДЕМОС по нашим временам - это уже игрушечный ОС]
PDP-11/70 по нашим временам тоже, в принципе, игрушечный процессор.
Так что игрушечному процессору - игрушечную ОС. Это вполне нормальное решение.
---------
Кстати, знаете как в RT-11 компилируется С-код и паскаль?
Сперва он транслируется в ассемблерный текст с набором своих макрокоманд, а затем уже обычным MACRO11 компилируется. Потому и не нужен был libc, вместо него были макробиблиотеки.
Были ли созданы компиляторы, которые сразу бинарник создавали, не в курсе, наверняка кому-то такая идея приходила в голову и её реализовали.
¤
Компиляция любых сишных исходников на PDP, написанных не для PDP - дело весьма трудоёмкое, т.к. их нужно тщательно допиливать до возможности скомпилироваться, а потом чтоб ещё и работали.
---------
>>? Voland @ - сегодня 10:12
[Вот лично мне нравится вариант, для которого как раз позарез нужна 32-разрядная архитектура]
И вы постараетесь наступить на все грабли, не пропуская ни одной, повторяя путь архитектуры х86 со своими префиксами?
Если нужна 32-разрядная архитектура, нужно сразу за основу брать 32 разрядный процессор. И уже на нём делать обратно совместимый 16-разрядный режим PDP-11 в виде виртуальной машины.
Посмотрите на Эльбрус-2С+, у него своя архитектура с 64 разрядной шиной, своя система команд, весьма непростая и не имеет ничего общего с х86, но имеется аппаратная эмуляция архитектуры х86. Он вообще может исполнять х86 прогу как свою родную. Что-то подобное по слухам делает 1801ВМ1 - берёт инструкции PDP-11 и перекодирует их в свои инструкции 1801ВЕ1 и уже их выполняет ядро ВЕ1, хотя наверно врут, как обычно.
Или посмотрите на мотороловские процессоры 68000, не зря ведь БКшники, увидевшие амигу, после этого пинком запинывали БКшку куда подальше. Система команд и методы адресации очень похожи на PDPшные, т.к. процы создавались под её влиянием, но регистры 32х разрядные, адресация 32х разрядная. Ограничения в 64кб нету, раздолье прям, пиши-не хочу.
Или взять архитектуру PDP-11 и расширить её до 32хбит, как когда-то планировали сами DECовцы. Тогда эта идея не прошла, т.к. слишком длинные команды получались и проги слишком много места занимали, а память была дорогая, поэтому победил VAX, как более продвинутый в этом плане. Сейчас-то память стоит дёшево и на размер кода можно не обращать внимания, если нет стремления сделать именно компактный код.
¤
Тут уже начали забывать, для чего всё это задумывалось. Вроде бы хотелось возрождения БК и его популяризации. Так что наверно надо делать упор именно на доступности собственно БК, а не лепить химеры ради самого процесса вылепливания.
Самый простой вариант, который мне приходит в голову:
В качестве процессора повторить 1801ВМ3, не обязательно досконально внутренне, достаточно будет 1801ВМ1 с набором команд от ВМ3 (хотя можно и конвейеризацию добавить) и диспетчер памяти от PDP-11/70 или даже 1:1 от ВМ3.
Затем добавить расширенный диспетчер памяти, где регистры PAR будут 32-разрядные (основной набор от стандартного ДП + ещё 2 по 8 16-разрядных регистров на user и kernel mode, где хранятся старшие биты поля PAF), для преодоления рубежа 4мб.
Продвинутую видеокарту оформить как внешнее устройство сидящее на МПИ со своей памятью, своим диспетчером памяти, регистры которого будут тоже 32 разрядные PAR (можно без PDR для простоты, просто будут 8кб сегменты с шагом 8кб, но можно и усложнить задачу, чтобы было плавающее окно с шагом 64 байта, как по стандарту), тупо скопировать этот кусок от диспетчера памяти проца. Доступ к видеопамяти видеокарты процессором осуществлять через фиксированное окно, например по адресам 100000-140000 (два стандартных сегмента BS4, BS5) или 120000-160000, но это с идеологией БК не очень совместимо, т.е. достаточно двух 32 разрядных регистров PAR, и свои регистры управления (как стандартные MMR0-MMR3, но по своим адресам), в которых спец.битами подключается/отключается видеопамять в сегменты указанной области, т.е. можно подключить один из двух, не обязательно оба сразу. И тут как раз будет полезен режим ПДП.
При отсутствии продвинутой видеокарты никто ничего не заметит и будет общаться с внешним миром или через стандартную ВП1-037 или через порты терминала 15-ИЭ-0013 на 177560.
Примечание. Вместо МПИ, читай название своей шины. Например LPC. Просто на БК используется МПИ и я её и беру за пример и основу.