Board.KolibriOS.org

svn --reintegrate

Я не имел в виду физический перенос, который можно осуществить, а способ работы как таковой: если есть 2 варианта работы, но один из них по всем параметрам лучше другого (strictly better), то используется первый вариант, а второй выбрасывается. Если же у обоих есть и преимущества, и недостатки, то тогда решить, что оставить, а что выбросить, гораздо сложнее. Изменения CleverMouse, по вашему мнению, strictly better чем текущий транк? Если да, то может сделать их транком? А если нет, то каковы их недостатки перед текущим транком?

рамдиск использует две константы

RAMDISK             equ (OS_BASE+0x0100000)
RAMDISK_FAT         equ (OS_BASE+0x0280000)

но там жесткая привязка в коде к размеру 1.44

Загрузка с дискеты и CD идет на абс. адрес 100000h через int 15h и еще где-то сидит привязка, некогда искать.

Если стало тесно в kolibri.img - надо официально переходить на HD-загрузку (а для встроенных систем - на BIOS Boot ) и не париться.

Надо переходить на загрузку, не стесненную одним размером.

Мне пока не тесно, и если Flash ROM chip на 2 мегабайта, то хватит и на BIOS, и на Колибри. Но для широкой аудитории, думаю, тесно. А рассчитывать надо на большинство.

yogev_ezra
А зачем вообще хранить образ рамдиска (включая FAT) в ROM, если ядро будет грузиться через BIOS Boot?
Ведь rdsave работать не будет все равно.
Подгрузить шрифты, иконки и обои (а также, возможно, и драйверы) можно и с фиксированных ROM-адресов, а с остальным работать или на HD/BD, или сделать поддержку CBFS.

На eBox EEPROM, там можно и записывать (если использовать функцию "Virtual Floppy" от производителя), правда небольшое число раз, а потом он испортится.

Если будет поддержка CBFS, то можно и так, ты прав. Я просто шёл по минимуму сопротивления. Для eBox "минимум сопротивления" - это узнать, как включить заводскую функцию "Virtual Floppy", и тогда не понадобится ни допиливать CoreBoot, ни менять что-либо в Колибри.

Изменения в ветке kolibri-cfg призваны показать, что конкретную задачу настройки экрана загрузки внешним файлом несложно решить на основе существующего кода. У этой ветки следующие недостатки по сравнению с транком:
- отсутствует сохранение параметров; надо заметить, что на столь ранней стадии загрузки, по-видимому, сохранение параметров прямо конфликтует с текстовым файлом настроек;
- несогласованность образов дискеты при разных способах загрузки: при загрузке с дискеты все файлы, естественно, читаются с неё; при остальных видах загрузки файл образа дискеты всё ещё нужен, но файлы ядра и настроек должны лежать вне ядра;
- отсутствует перезапуск ядра из памяти.

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

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

То есть, если сейчас я использую утилиту HD_boot от diamond-а для загрузки kolibri.img с SD-карточки, то в ветке kolibri-cfg это работать не будет?

Ну это лично мне ещё никогда не нужно было.

Можешь, пожалуйста, объяснить про параметр vbemode в конфиг-файле (я не понял, что он делает), а также, где задавать цветность (32 бита, 256 цветов и т.д.)?

"Ну если все нужные параметры уже читаются из конфиг-файла, то их и сохранять не придётся, верно?" - это спорный вопрос, поэтому я его специально выделила. Если пользователь поменял какие-то настройки в загрузочном экране, он может хотеть, чтобы они сохранились, и тогда сохранение настроек прямо из загрузочного экрана удобно. На всякий случай: у меня нет чёткой позиции по вопросу, что в этом случае лучше.

"То есть, если сейчас я использую утилиту HD_boot от diamond-а для загрузки kolibri.img с SD-карточки, то в ветке kolibri-cfg это работать не будет?" - нет, не будет, ядро из kolibri-cfg несовместимо по загрузке с ядром из транка. Я не в курсе, что такое HD_boot; если ты имеешь в виду HD_load/USB_Boot/inst.exe из дистрибутива, то ему надо подсунуть скомпилированный kolibri-cfg/bootloader/fat32/bootsect.asm в качестве BOOT_F32.BIN, а скомпилированный kordldr.f32.asm скопировать на целевой FAT32-том - сейчас inst.exe копирует MTLD_F32.

"Ну это лично мне ещё никогда не нужно было." - ну, лично мне тоже, я упоминаю для полноты.

"Можешь, пожалуйста, объяснить про параметр vbemode в конфиг-файле (я не понял, что он делает)" - "если вы не знаете что это - оно вам не надо" ©. Я серьёзно.

"где задавать цветность (32 бита, 256 цветов и т.д.)?" - я ориентировалась на существующий код, а он не сохраняет цветность, записывает только разрешение и указатель на вход в таблице видеорежимов - если по последней части возник вопрос, смотри цитату выше. В любом случае, VESA-режимы на 256 цветов не поддерживаются, только на 32bpp и 24bpp, а между ними особой разницы нет.

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

"а скомпилированный kordldr.f32.asm скопировать на целевой FAT32-том"... и ещё туда же скопировать kernel.mnt. Файл с аналогичным именем из образа в kolibri-cfg будет игнорироваться и может просто отсутствовать, так что простая замена файла kolibri.img на свежескачанную "ночную сборку" не пройдёт.

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

Центровая фишка в Синем Меню (и, между прочим, шедевр программирования на ассемблере i8086) - это окошко выбора VBE-режимов (VESA BIOS Extension). Загрузчик выцарапывает из VBIOS все доступные режимы и предлагает юзеру самому сделать себе выбор. Такое остроумное решение позволяло избежать лавины претензий типа "а че у меня экран такой кривой?", с которыми чайники атаковали сайты всех ОСей во времена ЭЛТ-мониторов.

Если по ходу дела юзеру надо было поиграть с разными VESA-режимами, он мог это сделать и в 32-битной среде с помощью vbemode. Именно для этого была нужна соответствующая опция в меню.

Короче, CleverMouse как всегда права: если ты до сих пор не знал, что это такое -- оно тебе не надо!

"Объяснение понял, для тестирования пойдёт, но если клиент будет доволен результатом и захочет за это заплатить, то как перенести это в транк?" - отличия между kolibri-cfg и trunk не слишком большие и в местах, которые изменяются довольно редко. Я могу внедрить kolibri-cfg в trunk условной компиляцией, контролируемой переменной окружения или специальным inc-файлом.

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

Я наблюдаю какое-то гробовое молчание в ответ на слова "Я могу внедрить kolibri-cfg в trunk". Я, пожалуй, уточню: если возражений не поступит, я ведь внедрю kolibri-cfg в trunk.

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