Проект ОС

Цитата:

---

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

Не-не-не! ИМХО BIOS должен быть и HAL, если у нас есть дискета/винт/SD, то доступ к ним должен быть просто по LBA.

---

Я привел пример функционала ВГ93. Драйвер дискеты должен делать всё, что умеет ВГ93 (ну по возможности, я не имею ввиду разные выкрутасы, а общий набор функций). Доступ по LBA делать для дискеты - ну несколько извратно, при том, что LBA предполагает нумерацию секторов внутри треков подряд с единицы, постоянное их количество на всех треках и т.д. В общем, для дискеты лучше юзать CHS в порядке исключения.

Цитата:

---

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

Опрос клавы должен идти по прерываниям, а это уже ISR и дело ОС. Потому на мой взгляд и сложно БИОС от ОС оторвать.

---

В идеале конечно да, как сделано в ПЗУ бейсика спектрума и как сделано в драйвере на профи (в цпм). если у нас не демка или игра, то можно юзать обработчик в ПЗУ, или его же скопированного в ОЗУ. Сейчас я расписывать не буду, скажу личшь что это возможно. Ну а если программиста это не устраивает, то он может отключить этот функционал запретив прерывания. И читая клаву сам.

Цитата:

---

Что этот БИОС должен будет делать? И что в нём должно лежать?

---

вот ответ

Цитата:

---

отключать ПЗУ может более 50% клонов

---

Далее биос самокопируется в озу, оставшееся место по усмотрению юзера/прогера/оси

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

не лезте в дебри. есть стандартная формула перевода CHS в lba и обратно. лба это посути логическая адресация. все современные винты работающие по стандартам ата-6 и 7 (или даже с 5й) про цхс даже не знают. поддержу физической адресации убрали...про всякие сд карты говорить не буду, не изучал этот вопрос. для дискеты лба как палка в калесо...

Цитата:

---

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

кстати. насчёт автоматики, если внимательно таки почитать про рестарты. то каждый первый/второй/третий рестарт заставляет юзера выполнять те задачи. с которыми должна справляться сама система. очень порадовал вот этот рестарт:

т.е. мало того. что работа с кэшами и каналами возложена на плечи юзера (создать, отчистить, обновить, записать, прочитать и прочее), так ещё и тупо чтение одного единственного сектора тоже выкинуто в отдельный рестарт и кинуто на плечи юзера. капец. про File Control Block когда-нибудь слышал? вкурсе что при его помощи прочитать одну запись (в рамках цпм - 128байт, в рамках q-dos - до одного байта), как два пальца об асфальт? не? или таки да, раз говорим местами про цпм (видимо всё таки в курсе)? очень тогда подозрительно выглядит этот спор...

---

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

Цитата:

---

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

Ежу понятно, что дополнительные функции (рестарты) были созданы для удобства пользователя в ограниченном адресном пространстве и работать с конкретным байтом файла удобней через чтение и запись его через кэш.

---

А мне вот непонятно зачем так. Если система может работать с файлами, то зачем лазить в кэш другими функциями? Мы указали конкретную запись файла, указали сколько надо читать или писать и всё. При чем тут кэш? Одно понятно, авторы понаделала кучу костылей, что бы хоть как то работать. Причина конечно ясна - 48К ОЗУ, и там должно было фунциклировать, но они же могли сделать ориентир и на 128К, но не сделали.

Цитата:

---

дополнительные функции (рестарты) были созданы для удобства пользователя

---

и в чём заключается удобство? что удобнее когда есть одна и таже функция (системный вызов) выполняющая любую приходь кодера/юзера или на каждый чих пихать вызова? я уже привёл пример с FCB из цпм и q-dos когда с точность до байта размер записи можно указать. грузи хоть весь файл, не проблема. вот это удобно. это первое, второе - при условии 48кб логичнее экономить, а тут нет никакой экономии. рестаров как собак наплодили. в чём экономия? в чём удобство?

Друзья мои, пожалейте моё и своё (что более важно) время! Перестаньте пороть горячку и писать непотребности! Мне тяжело вычленивать зерно обсуждения из того хлама который вы сюда вываливаете! Если вам так хочется что-нибудь написать - подождите с полчасика, пусть мысли примут стройную форму и уже потом пишите.
И не забывайте - что форум посвещён нашему обожаемому Спекки во всех его проявлениях, а тема эта посвящена разработке ОС на оном. Пишите касательно этой темы, а лучше, если, кроме концепций, мой глаз засвидетельствует ещё и пример искромётного кода!

Цитата:

---

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

Реально надо идти по пути аналогичному MSX. Делаем конфигурацию, при которой уже нет никакого ПЗУ с бейсиком в адресах 0-4000. Экран убираем в скрытую страницу, в первые 16К подключаем страницы ПЗУ. Вообще нужно сделать 4 окна и включать все по выбору. Или ПЗУ или ОЗУ. В ПЗУ (флешку), пишем начальный загрузчик с БИОСом. И всё, можем пускать любые ОСи. Даже тазик не проблема прикрутить.

Предвосхищая возражения что машинка уже не будет спектрума говорю - будет. Если так рассуждать то и спек 128 не спек. И 48 тоже не настоящий. Ведь MSX1 был с ПЗУ бейсиком в 32К+ 32К ОЗУ, ну расширение предполагалось ОЗУ, а MSX-2 конфигурацию совершенно сменила! Хотя вариант с бейсиком остался одним из подрежимов.

---

Есть такая машинка. Называется ATM Turbo 2. За последние 7 лет их выпустили больше 200 штук, включая пентевы.

Факты показывают, что под железо NedoPC пишут софт. Или, если вам угодно, новый софт с наворотами работает на железе NedoPC.