Board.KolibriOS.org

# Это я, почтальон Печкин. Принёс вам посылку. Только я вам её не отдам, потому что у вас докУментов нету.

yogev_ezra, ну да, так и есть.

yogev_ezra
Кроме собственно загрузчика существует проблема еще и с наличием места в карте памяти - участок в который загружен образ не является частью памяти, которую перераспределяет менеджер памяти. И соответственно не может быть выделен по произвольному адресу. Оставлять больше чем 1,44 Мб под эту возможность для универсальной системы - это бесполезная растрата памяти. Вероятно возможно исхитриться и написать адаптивный код, но пока этого никто не сделал - очевидно в виду его достаточной сложности и наличии множества корректировок которые надо произвести при переопределении статических участков памяти. В свое время такая же ситуация была с участком памяти выделяемым под фоновую картинку, но там я при помощи Serge откорректировал код и память стала выделятся уже после начала работы менеджера памяти, но даже тогда это потребовало от Serge большой работы по корректировке расположения множества других участков памяти. Если бы все было так просто как на словах, то много чего мы бы уже исправили, но "увы и ах".

Тогда имеет смысл выкинуть из загрузчика поддержку всех других размеров, кроме 1.44МБ, раз всё равно ими никто не пользуется. А освободившееся место занять чем-то более полезным, как art_zh предлагает.

Только как вариант. И с 2.88М стоит повозиться, рано еще все выкидывать.
К тому же сдается мне, что почтальон Печкин все правильно доставил.
Просто те, у кого докУменты были в порядке, не стали по каким-то своим соображениям отдавать посылочку конечным юзерам.
Ибо 1.44М образ очень хорошо вписывался в концепцию минимальной, аскетичной ассемблерной ОСи, а 2.88М - уже нет.

2.88 Мб не менее хорошо вписывается, просто это не распространенный формат дискет - сам я их в живую не видел, но доходили слухи, что стоимость такой дискеты была в 3-5 раз выше чем у 1,44 Мб. Плюс необходимость наличия также мало распространенного дисковода под этот формат.

Ещё 1.44 MB вписывается в BIOS от eBox, а 2.88 MB - нет

Я и 1.44 MB уже лет 5 в Израиле не видел, да и компьютеры все давно продаются без флоппи-дисководов. 1.44 MB был хорошим размером, когда такие дискеты на самом деле использовались, но сейчас уже неважно, будет это 1.44 или 2.88 - нет ни того, ни другого. Вот если мы вставим Колибри в BIOS, тогда чем меньше - тем лучше.

#1940: в первичном загрузчике свободно около 150 байт. Никаких новых функций пока не добавлено.
_______________________

какие дискеты? кто-нибудь в наше время еще грузит Колибри с флоповода ?!

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

Я создала отдельную ветку для ядра, считывающего настройки загрузочного экрана из внешнего файла config.ini, kernel/branches/kolibri-cfg, r1942. Подробности в http://redmine.kolibrios.org/projects/k ... readme.txt .
Собранный образ на базе r1937 я выложила в http://ftp.kolibrios.org/users/CleverMouse/kolibri-cfg/ , там есть образ дискеты и образ ISO, последний для разнообразия с kolibri.img в виде отдельного файла для рамдиска, а не загрузочного образа дискеты.

_________________
Сделаем мир лучше!

CleverMouse: ты ненормальная? Это ты за выходные всё это написала? Я в шоке

А почему это должно быть несовместимо с транком?

"ты ненормальная?" - ну, может быть, и да.
"Это ты за выходные всё это написала?" - разумеется, не всё, это фактически trunk + sec_loader/boot, а остальное - простой разбор конфига и мелкие правки, которые пишутся за несколько часов с отладкой.
"А почему это должно быть несовместимо с транком?" - схема загрузки принципиально разная. Транк предполагает, что есть один файл kolibri.img и внутри него находится всё остальное, начиная с ядра kernel.mnt. При этом на момент загрузки ядра из транка образа в случае дискеты образа просто нет, так что конфигурационные файлы догрузить невозможно. sec_loader предполагает, что первичный загрузчик умеет загружать много разных файлов, он, насколько я понимаю, планировался с отказом от одного файла kolibri.img; в частности, вторичный загрузчик и конфигурационный файл должны присутствовать как отдельные файлы. В качестве вторичного загрузчика в kolibri-cfg выступает прямо ядро, и оно подгружает kolibri.img.

_________________
Сделаем мир лучше!

Clever Mouse
Отличная работа, спасибо!

yogev_ezra
Все возвращается на круги своя (из старого форума) :



Проверил на 2.88М-диске, ядро отлично грузится, но потом при загрузке рамдиска затирает часть системных переменных. Попытка расширить область рамдиска (#1941, const.inc) позволила выловить пару старых багов, но все-таки большие диски пока не грузятся.

Без динамического выделения памяти под рамдиск игра с размерами не стоит свеч.

Mario
Согласен на все 100.
Только сложно будет вычесать всех реликтовых багов из ядра - большая часть работы с рамдиском идет через абсолютные адреса.
У меня сейчас нет ни времени, ни терпения, ни желания чтобы все это перелопачивать - просто было интересно посмотреть в чем проблема с большими img-файлами.

Я имел в виду в хорошем смысле, ты как Энштейн (это был комплимент)
Объяснение понял, для тестирования пойдёт, но если клиент будет доволен результатом и захочет за это заплатить, то как перенести это в транк? Он же захочет заказать ещё изменения, не только загрузчика. Для каждого изменения делать ветку - слишком накладно, и потом долго собирать это вместе.


Я тебя огорчу, но кто-то (Марио?) уже скопировал все сообщения старого форума сюда, так что мог туда не ходить: viewtopic.php?f=34&t=335&start=25