Soviet Union ZX Spectrum CommunityЧетверг, 28.11.2024, 18:25
Вы вошли как Гость | Группа "Гости" | RSS
 [ · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Pentagon by Northwood
Black_CatДата: Среда, 01.07.2020, 16:12 | Сообщение # 1
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
1. Сигналы DOS/, IODOS/ для NemoBus v.1.2



Цепи DOS/, DOS на выходе DD29 идущие на дешифрацию портов разорвать, и в разрыв врезать схему. Цепи, идущие на выборку ПЗУ оставить как есть.
Прикрепления: 8323490.png (30.3 Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Четверг, 27.08.2020, 00:49 | Сообщение # 81
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
На DD55 строб не забыл, а отложил на потом. И уже сделал.
Я решил всё-таки сделать упрощённую версию многозадачности, поскольку ограничен в площади платы для новых корпусов микросхем:

Поддерживаться будут только 4 задачи, по 1 МБ на каждую, т.е. для каждой задачи можно будет выбирать, в каком мегабайте она будет находиться. Естественно, всё это будет доступно только при установке 4-МБ модуля SIMM.
Для задачи можно активировать ограничение "только 128 КБ". Таким образом, маска не нужна, достаточно одного бита порта BIOS, что избавляет от необходимости добавление ещё одного нового порта BIOS. Так же это позволяет явно разграничить назначение D5 и D6 #1FFD для определения позиции в памяти задачи, а все остальные разряды расширения памяти для самих задач, что значительно упрощает схему.

Поэтому триггеры DD55 будут доступны через порт #1FFD в случае, если мы находится в BIOS, или если включен режим ALL_RAM.


Сообщение отредактировал Northwood - Четверг, 27.08.2020, 00:52
 
NorthwoodДата: Четверг, 27.08.2020, 06:45 | Сообщение # 82
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Последние наработки:
D5 и D6 #1FFD на DD55 доступны из двух режимов: ALL_RAM и BIOS, иначе это режим MultiTask, в котором изменить состояние этих двух триггеров нельзя.
В режиме MultiTask D5 и D6 #1FFD определяют, в каком мегабайте работает задача. В этом режиме в адресах с #4000 по #BFFF, а при включении режима ROMRAM и с #0000 по #3FFF, подставляются страницы из выбранного мегабайта.
В режиме AllRam и BIOS в нижних адресах стандартно 5, 2 и 0-я страница ОЗУ, т.е. только из 0-го мегабайта.

В режиме MultiTask D5 и D6 #1FFD так же проецируют экраны на выбранный мегабайт.
В режиме AllRam и BIOS экран нацелен на 5 и 7 страницы только в 0-й мегабайте.

Оптимизировал коммутацию типа установленного модуля SIMM - DD124 КП12 заменил на КП2, что позволило упростить схему и проще скоммутировать экраны.
Прикрепления: 5162164.pdf (659.0 Kb)


Сообщение отредактировал Northwood - Четверг, 27.08.2020, 06:47
 
NorthwoodДата: Четверг, 27.08.2020, 08:42 | Сообщение # 83
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Ещё одно упрощение схемы коммутации типов модуля SIMM, которое позволило выкинуть из схемы микросхему КП11. Но джампер выбора объёма модуля теперь 3-х контактный: 1-2 - 1МБ, 2-3 - 4 МБ. Единственное "но" - нельзя замыкать все 3 контакта сразу, т.к. микросхеме DD124 это очень не понравится, но штатными перемычками это сделать и не получится.

Добавлено (27.08.2020, 14:42)
---------------------------------------------
До меня только что дошло, что прошлое обсуждение того, где лучше хранить сохранённые регистры процессора - в CMOS, КЕШе, в последней странице ОЗУ, это до одного места. Единственное верное место для этого, это стек в текущем адресном пространстве программы, потому что любая команда обращения к любому порту испортит содержимое регистров. В том же стееке можно будет сохранить и 4 байта данных системных портов. Единственное, что нужно будет хранить отдельно, это адрес для перехода к ранее прерванной программе, 2 байта на задачу, где она расположена в памяти и надо ли включать ограничение в 128 КБ. В твоём случае было бы значение маски. И для этого уже вполне достаточно CMOSа. Ура, я не буду использовать КЕШ, ограничивая тем самым возможность использования его 0-й страницы для эмуляции ПЗУ Gluk Rese Service.
Прикрепления: 6129207.pdf (657.2 Kb)


Сообщение отредактировал Northwood - Четверг, 27.08.2020, 14:43
 
Black_CatДата: Четверг, 27.08.2020, 15:00 | Сообщение # 84
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Шо в твоём понимании значит сигнал ROM_SP?

"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Четверг, 27.08.2020, 15:43 | Сообщение # 85
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
ROM_SP = ROM Spectrum. Включение этого разряда порта в 1 включает основное ПЗУ Spectrum, а если 0 - включает ПЗУ BIOS.

ROM_SP = 0 = ПЗУ BIOS;
ROM_SP = 1 = ПЗУ Spectrum.

Добавлено (27.08.2020, 15:47)
---------------------------------------------
Я пока ещё не сделал переключение на ПЗУ BIOS при нажатии кнопки NMI.


Сообщение отредактировал Northwood - Четверг, 27.08.2020, 17:19
 
Black_CatДата: Четверг, 27.08.2020, 22:38 | Сообщение # 86
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
ROM_SP = ROM Spectrum. Включение этого разряда порта в 1 включает основное ПЗУ Spectrum, а если 0 - включает ПЗУ BIOS.

Понятно, суррогатный недокернел :) . А зачем RAM_128, я чото не улавливаю?

Цитата
Единственное верное место для этого, это стек в текущем адресном пространстве программы

Это худшее место :)

Цитата
И для этого уже вполне достаточно CMOSа.

Часы лучче не трогать.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 10:50 | Сообщение # 87
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
А зачем RAM_128, я чото не улавливаю?

RAM_128 - режим ограничения доступного объёма памяти в 128 КБ.

Цитата Black_Cat ()
Это худшее место :)

Ну а что ты предлагаешь ?

Вот нажата кнопка NMI, проц сразу сохраняет в стек адрес для возврата в прерванную программу и переходит на адрес #0066. В этот момент ты не можешь воспользоваться никакими командами обращения к каким-либо портам, т.к. потеряешь содержимое регистров, т.е. как минимум предварительно нужно выполнить PUSH AF, чтобы сохранить регистры A и флаги. Поэтому в твоём распоряжении только команды PUSH xx и LD (#xxxx),A. В качестве адреса #xxxx ты можешь указать только область ОЗУ в пределах текущих 48 КБ, разумеется, ничего кроме стека трогать нельзя. А так же может быть доступна, а может быть и не доступна КЕШ память. Хочу заметить, что этой командой LD (#xxxx),A ты сможешь сохранить только регистр A, а регистр флагов можно сохранить исключительно командой PUSH AF в стек. Ты можешь лишь частично обойти это ограничение командами условного перехода только для 4-х флагов - Z (нуля), C (переполнения), P (отрицательного результата) и ещё одного, не помню точно как называется - полу-переноса. Но ещё есть флаг прерываний и другие флаги. Здесь у тебя нет выбора - полностью регистр флагов можно сохранить только в стек. Можно конечно его тут же извлечь из стека командой POP в другую регистровую пару, но зачем ? Он уже будет в стеке.

В моём варианте, в зависимости от настроек BIOS, либо включится КЕШ-память 0 или 2 страница, либо ПЗУ принтера.
Здесь нужно продумать логику, поскольку ПЗУ принтера нужно только при печати. Проблема в том, что LPRINT использует тот же порт #FB/#7B, что и КЕШ-память. В текущей схеме я могу в настройках BIOS запретить использование КЕШа через порт #FB/#7B, но ПЗУ принтера включается всегда, когда заблокирована КЕШ-память.

Номер страницы КЕШ-памяти 0 и 2, если она включилась по кнопке NMI либо командой IN A,(#FB), выбирается с помощью D4 #7FFD, но при условии, что 2-я страница теневого ОЗУ не занята под эмуляцию ПЗУ Menu-128, в противном случае всегда включается 0-я страница.

Чем плохо использовать КЕШ память ? Тем что она может быть использована любой программой в любой момент и данные сохранённых задач могут быть утеряны. Более того, КЕШ память может быть использована одной нужной пользователям утилитой "Cash Remember", за убийство которой сохранением туда своих данных, пользователи точно спасибо не скажут. Плюс 0 и 2 страница КЕШ может быть использована под эмуляцию ПЗУ Gluk Reset Service и Menu-128. Если включена эмуляция ПЗУ Menu-128, то остаётся доступной только 0-я страница КЕШ. Если включена эмуляция Gluk Reset Service, то КЕШ память становится недоступной. Страницы теневого ОЗУ 1 и 3 используются только для эмуляции ПЗУ TR-DOS и Basic-48. Таким образом, отключается доступ к КЕШу эмуляцией только той страницей ПЗУ, которая будет эмулироваться реже всего.

Цитата
Часы лучче не трогать.

Тогда остаётся только стек, который хочешь ты или нет, но всё-равно будет использован процессором в момент нажатия кнопки NMI для сохранения адреса возврата. КЕШ-память лучше не трогать, потому что его будут использовать программы, такие как "Cash Remember". Поэтому все регистры процессора нужно сохранять только в стек, в крайнем случае какие-то ещё пару байт можно будет сохранить в CMOS, т.к. 8 свободных байт для 4-х задач найти точно можно. Но скорей всего будет так: всё основное будет в стеке, а в CMOS - в одном байте список загруженных задач - 4 бита на признак присутствия самих задач и 4 бита на признак ограничения ОЗУ в 128 КБ на каждую задачу, во втором байте по 2 бита на задачу - состояние D5 и D6 #1FFD - номер магабайта, в котором располагается задача.


Сообщение отредактировал Northwood - Пятница, 28.08.2020, 12:41
 
Black_CatДата: Пятница, 28.08.2020, 12:39 | Сообщение # 88
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Чем плохо использовать КЕШ память ? Тем что она может быть использована любой программой в любой момент и данные сохранённых задач могут быть утеряны.

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


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 12:45 | Сообщение # 89
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
Правильно, поэтому организацию кэша надо переделать так, чтоб режиму ядра была выделена его собственная страница памяти, недоступная вне этого режима, и автоматически подключаемая при входе в режим ядра.


Не будет этого, потому что все 4 страницы теневого ОЗУ уже расписаны под другие задачи.
 
Black_CatДата: Пятница, 28.08.2020, 12:55 | Сообщение # 90
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Не будет этого, потому что все 4 страницы теневого ОЗУ уже расписаны под другие задачи.

Мы до этого обсуждения ещё не дошли :) . А вааще-то режим ядра - это отдельная аппаратная виртуальная машина, и если минимальная аппаратная виртуальная машина у тебя 1Мб, то под спековские задачи остаются две-три АВМ. Вполне достаточно чтоб поиграться с переключением задач :) .


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 13:03 | Сообщение # 91
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
и если минимальная аппаратная виртуальная машина у тебя 1Мб, то под спековские задачи остаются две-три АВМ.

У меня их будут 4. Я не буду забирать основное ОЗУ у задач для переменных АВМ. Единственная проблема, которая здесь всплывает - это экран первой задачи, который будет потерян полностью или частично из-за необходимости отобразить меню выбора и настройки задачи BIOS-ом.


Сообщение отредактировал Northwood - Пятница, 28.08.2020, 13:06
 
Black_CatДата: Пятница, 28.08.2020, 13:10 | Сообщение # 92
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Я не буду забирать основное ОЗУ у задач для переменных АВМ.

Нипалучицца :) . Ядро, это тебе не сетап, в который ты входишь перед программным сбросом машины, и у тебя доступны все ресурсы компа. Ядро - это полноценная АВМ. В ядро ты так же попадаешь по NMI, когда все ресурсы компа уже заняты, а тебе надо задавать параметры АВМ, отображать их на экране в диалоговом режиме, а экран у тебя токо в ОЗУ :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 13:19 | Сообщение # 93
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Как вариант, можно реализовать АВМ в виде загружаемой в КЕШ программы, аналогично, как загружается в КЕШ "Cash Remember". Тогда к BIOS-у АВМ вообще не будет иметь никакого отношения и в распоряжении будут 16 КБ КЕШ. Но тогда всё это будет доступно только если пользователь не использует эмуляцию ПЗУ "Gluk Reset Service".
 
Black_CatДата: Пятница, 28.08.2020, 13:22 | Сообщение # 94
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Как вариант, можно реализовать АВМ в виде загружаемой в КЕШ программы

Ты всё время забываешь про экран :) , не вслепую же ты будешь настраивать АВМ :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 13:25 | Сообщение # 95
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
Ты всё время забываешь про экран :) , не вслепую же ты будешь настраивать АВМ :)


Ну так я же написал:

Цитата Northwood ()
и в распоряжении будут 16 КБ КЕШ


Для сохранения экрана 0-й задачи нужно 6912 байт, так что 16 КБ хватит и на экран, и на все переменные. Экраны остальных 3-х задач сохранять не нужно. Но стек всё-равно будет использовать минимум 4 байта - под адрес возврата в прерванную программу и для регистров AF.

Добавлено (28.08.2020, 13:30)
---------------------------------------------
P.s. использовать дополнительные видеорежимы во время настройки АВМ я не буду, чтобы не портить дополнительные области ОЗУ под экран.


Сообщение отредактировал Northwood - Пятница, 28.08.2020, 13:35
 
Black_CatДата: Пятница, 28.08.2020, 13:39 | Сообщение # 96
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Но стек всё-равно будет использован минимум 4 байта - под адрес возврата в прерванную программу и для регистров

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

Добавлено (28.08.2020, 13:51)
---------------------------------------------
Цитата Northwood ()
RAM_128 - режим ограничения доступного объёма памяти в 128 КБ.

А зачем такое ограничение? Мы же специально боролись за автоматизацию определения #7FFD, именно чтоб не нужен был именно этот тумблер! И сейчас у нас менеджер памяти прозрачен для любых корректно написанных программ без всяких тумблеров :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 15:51 | Сообщение # 97
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
А зачем такое ограничение? Мы же специально боролись за автоматизацию определения #7FFD, именно чтоб не нужен был именно этот тумблер!

Для того чтобы...

Цитата Black_Cat ()
если нужно ограничить память до 128к

Цитата Black_Cat ()
Для программ под классический Спек 128 он задаст 128к,

потому что, если...

Цитата Black_Cat ()
юзер задаст ограничение в 512к, и ессно, там не будут корректно работать проги под классический Спек128, юзающие out(#fd),a .


А раз я предположил не внедрять гибкую систему задания размера ОЗУ с помощью маски, а раздавать прогам по 1 метру ОЗУ, то нужно хотя бы простое ограничение размера доступного ОЗУ в 128 КБ.

-----------------------------------------------------------------------------------------------------------------------------

Но начнём сначала... Я ещё раз перечитал твои предыдущие сообщения:

Цитата Black_Cat ()
Насамделе все предпосылки для реализации механизма ограничения адресного пространства у тебя уже появились вместе с поддержкой NemoBus v.1.2

а так же...

Цитата Black_Cat ()
Дык вот, к DMA USC надо будет добавить два регистра доступных только в режиме ядра (у тебя это режим BIOS'а): регистр старших адресов размещения программы, и регистр маски старших адресов.

и...

Цитата Black_Cat ()
а кому надо ещё DMA и аппаратная многозадачность, тот докупает плату системного расширения, подключаемую к краевому разъёму.

Т.е. аппаратную поддержку многозадачности нужно создавать всё-таки не на материнке, а на плате расширения ? По меньшей мере, два регистра - адреса ОЗУ для задания расположения задачи и маски. Тогда для чего я выделял в отдельные регистры ТМ2 биты D6 и D5 #1FFD ? Получается, что это не нужно и их можно вернуть обратно в состав ТМ9 DD49 ?

Но если аппаратную поддержку многозадачности выносить во внешнее устройство, тогда меня ничто не ограничивает для полной её реализации, с использованием регистра маски, только минимальный объём задачи я бы сделал в таком случае 128 КБ, тогда все данные по свёрнутым задачам стоит хранить в основном ОЗУ в последних 128 КБ, которые не должны быть доступны для загружаемых задач. КЕШ память я тем более не хочу трогать.

Цитата Black_Cat ()
Так же, попасть в ядро можно при нажатии кнопки NMI во время исполнения программы (в режиме TR-DOS кнопка заблокирована). При этом происходят следующие действия: подключается ПЗУ ядра, и исполняется обработчик NMI, который сохраняет в области ОЗУ ядра значения регистров процессора и системных портов, включая регистры портов и маски,


Надо учитывать, что не редко программы используют адресное пространство #C000 - #FFFF для указателя стека SP. Поэтому нажатие кнопки NMI приведёт к тому, что именно в этой области адреса произойдёт сохранение адреса возврата к прерванной программе. Но можно сделать так, чтобы внешнее устройство включило некую страницу ОЗУ из области ядра, т.е. из последних 128 КБ, вот только запись в стек адреса возврата произойдёт раньше, чем переключится страница.

Ну хорошо, карта расширения включила страницу ОЗУ, принадлежащую ядру, мы можем для таких случаев, когда в SP у нас оказался адрес в области #C000-#FFFF, выждав минимальную паузу, необходимую для того, чтобы успела включиться нужная страница ОЗУ, в стек сохранить регистры HL, BC, AF. затем необходимо получить значение из SP в HL, опять его сохранить в стеке. Поэтому в области ядра из всех 128 КБ нужно выделить 16 КБ для данного сохранения, которое может оказаться в любом месте в #C000-#FFFF. А дальше, переключая страницы ОЗУ, можно скопировать то что только что сохранили в другое заранее определённое место ОЗУ.

Но если делать вот такую полную реализацию многозадачности, т.е. с маской и дроблением ОЗУ до 128 КБ, тогда на материнке нужно как минимум сделать так, чтобы экраны могли проецироваться в любом месте ОЗУ, хоть через каждые 128 КБ.


Сообщение отредактировал Northwood - Пятница, 28.08.2020, 15:56
 
Black_CatДата: Пятница, 28.08.2020, 17:31 | Сообщение # 98
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
А раз я предположил не внедрять гибкую систему задания размера ОЗУ с помощью маски, а раздавать прогам по 1 метру ОЗУ, то нужно хотя бы простое ограничение размера доступного ОЗУ в 128 КБ.

Т.е. это у тя такая недомаска из двух сигналов. Хорошо, примем пока в качестве костыля-времянки.

Цитата Northwood ()
Т.е. аппаратную поддержку многозадачности нужно создавать всё-таки не на материнке, а на плате расширения ?

Это был экспромт, но я забыл про экранный сканер, так что к сожалению не получицца разместить вне мамки, как минимум регистр маски должен быть на мамке, а где один, там уже нет смысла экономить и на втором. Так что облом - токо на мамке.
Хотя, если минимальный размер АВМ ограничить 128к... Надо подумать, мож в каком-то урезаном варианте чо и получицца, но это очень костыльно.

Добавлено (28.08.2020, 18:20)
---------------------------------------------
А почему возник вопрос? У тебя закончилось место под микрухи? :) Выкинь слот под +3 :) и сделай переходник с +3 на NemoBus :) - появится место под микрухи :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 28.08.2020, 18:34 | Сообщение # 99
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Не вижу ничего костыльного в том, чтобы под множество задач нарезать по 128 КБ. В случае установки модуля SIMM 1Mb получится запускать до 7 задач, что уже неплохо, а если имеется 4 МБ, тогда до 31 задачи, что очень круто. Кроме этого, если разбивать память по 128 КБ, то нам нужно 5 бит на маску и 5 бит на адрес размещения программы, они же должны задавать адрес области ОЗУ для размещения экранов. А т.к. экранов у нас 2 штуки - в 5 и 7 страницах, то разбивка ОЗУ на меньшие куски, чем 128 КБ, означает неоправданные сложности с управлением экранами, иначе говоря, ненужный геморрой.

Добавлено (28.08.2020, 20:57)
---------------------------------------------
Кстати, в твоей логике дробления памяти на участки ОЗУ разного размера, не всё хорошо. Чтобы тебе было понятней, рассмотрим пример распределения адресного пространства для 3-х задач следующего размера: 512 КБ, 128 КБ и 1МБ:

Код
A21    A20    A19    A18    A17

0    0    0    1    1    Mask
0    0    0    0    0    Position

0    0    0    0    0    Mask
0    0    1    0    0    Position

0    0    1    1    1    Mask
0    0    1    0    1    Position


Рассмотрим, что получилось:
1-я задача размером 512 КБ - всё хорошо. Выделяем ей 512 КБ ОЗУ, выставляя в маске 2 единицы 00011, а адрес ставим 00000.
2-я задача размером 128 КБ - тоже всё хорошо. Выделяем ей 128 КБ ОЗУ, выставляя в маске все нули 00000, а адрес ставим следующий доступный после 512КБ - 00100.
А вот с 3-й задачей размером 1МБ проблема: Выделяем ей 1МБ ОЗУ, выставляя в маске 3 единицы 00111, но следующий свободный адрес у нас 00101. Однако, 3 младших бита A17, A18 и A19 у нас маскированные и мы не можем в них выставить адрес расположения программы. Вернее, можем, но тогда нужно производить арифметическое сложение адреса, который выставляет программа, с адресом расположения области, а это сделать на рассыпухе можно, но очень затратно и это приведёт к большим задержкам распространения сигналов.
Следующий адрес, который мы сможем выставить с минимальными затратами, это 01000. Но в таком случае мы потеряем 896 КБ ОЗУ.

Т.е. границы выделенных областей в ОЗУ обязательно должны быть кратны размеру этой области, это как с кластерами на диске, иначе не получится придерживаться логики, что в младших разрядах выставляем в маске 1-ы, а во всех остальных немаскированных старших разрядах выставляем адрес расположения программы.

Максимум, что можно сделать в этой ситуации, это следить за картой заполнения ОЗУ и предлагать пользователю занимать свободные участки, если размер новой задачи в них вписывается. Например, в приведённом примере у нас между 2-й и 3-й задачей остаётся незанятый участок размером 896 КБ. В нём поместятся 7 задач по 128 КБ, либо 3 задачи по 256 КБ + 1 задача 128 КБ, либо 1 задача 512 КБ + 3 задачи по 128 КБ, и т.д.


Сообщение отредактировал Northwood - Пятница, 28.08.2020, 21:09
 
Black_CatДата: Суббота, 29.08.2020, 00:42 | Сообщение # 100
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Кроме этого, если разбивать память по 128 КБ, то нам нужно 5 бит на маску и 5 бит на адрес размещения программы

Ну получается всё равно корпус на адрес, и корпус на маску, и тут уже всё равно какой этот корпус - ТМ2 или ИР35, в любом случае корпуса два!

Цитата Northwood ()
Кстати, в твоей логике дробления памяти на участки ОЗУ разного размера, не всё хорошо

:) ОЗУ и не должно заполняться подряд, и ничего страшного если будут незаполненные участки. Это не программная многозадачность, где память может выделяться подряд, произвольного объёма, и с произвольного адреса. Возможный объём ОЗУ АВМ строго дискретен. Я предполагал выделить для каждой АВМ 64 байта для хранения регистров процессора и системных портов в специальной 16к странице. Соответственно, максимальное количество АВМ будет 256, из которых одна - ядро, а остальные - пользовательские АВМ. Для начала достаточно реализовать аппаратную коммутируемую многозадачность - аналог программной вытесняющей многозадачности, предоставив пользователю возможность переключаться между задачами. Впоследствии, на более сложных машинах использующих FPGA, возможна реализация многозадачности реального времени с минимальным квантом в один кадр. Т.е. при равном приоритете задач, каждый новый кадр будет исполняться следующая задача, создавая видимость параллельности.

Цитата Northwood ()
Максимум, что можно сделать в этой ситуации, это следить за картой заполнения ОЗУ и предлагать пользователю занимать свободные участки

Да, в идеале, у ПО ядра должна быть одна из функций автоматически выбирать оптимальное место для размещения АВМ разного размера.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
Поиск:

Copyright MyCorp © 2006Сайт управляется системой uCoz