MATRIX

[Zet9]

32М ограничение на размер FS в юзиксе оттого, что это 16-битная FS - у разработчика UZI в мхомпоросших 80-х годах прошлого века компилятор не умел 32 бит int, а при переводе на Hitech C (т.е. в UZIX) ничего кардинально не переписывалось. Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА.

Вот когда кто-нибудь перепишет драйвер винта для Nemo IDE на 32 бит, добывит в UZIX драйвер FAT16/32 (причем можно взять готовый), а потом обеспечит возможность запускать UZIX на Спеке - ну хотя бы таким образом - вот Вам набор файлов на винте - загрузите первый их них на адрес #6000 (например) и сделайте JP туда же и система UZIX дальше сама загрузиться и вот она готова к использованию - показывает приглашение на вход,
вот тогда мы (Спектрумисты) начнём изучать эту СИСТЕМУ,
а пока для больших винтов с FAT32 и cd/dvd приходиться использовать ту систему, которая есть, и УЖЕ запускаеться практически на любом Спектруме-128 b , и более

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

А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
пока система грузит следующую картинку, прога РАСПАКОВЫВАЕТ уже загруженную на 2-й экран,а пользователь видит на 1-м экране предыдущую картинку,раскпаковалась картинка на 2-й экран, прога включает его (ну естественно перед этим сделав getscr1,2)
пользователь видит картинку на 2-м экране, прога проверяет сообщение от системы и видит что уже следующая картинка загружена, дает собщение загружай очередную картинку, а сама начинает её только что заруженную распаковывать на 1-й экран

вот КОНКРЕТНЫЙ ПРИМЕР использования вызовов функции системы БЕЗ ОЖИДАНИЯ выполнения этого вызова

и сложно, все-таки. Но какой-то уровень совместимости, хотя бы с ранними типа "Систем 5" или подобными был бы крайне полезен.

а какие там отличия от Систем 7, например,выложите плз,желательно на русском

Думаю, нужно как-то заложить (на уровне условной компиляции или еще как) генерацию системы в две версии - одну из них под продвинутое железо.

конечно будет в виде условной компиляции - разные сборки ядра - например,ядро использует возможность подключать ОЗУ (кэш или страницу памяти) на адрес 0, или там для АТМ2- своя версия ядра и т.д.

---------- Post added at 12:19 ---------- Previous post was at 12:08 ----------

Зря вы сразу на окна накинулись. Ни к чему это. По крайней мере пока. Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.

Согласен, на начальном этапе этогобудет достаточно
Ну,на том и порешили
Да будет ТАК!

И заметьте, в большинстве случаев программы на ПЦ под "окошки" всегда раскрыты на полный экран.

и ещё обычно панель задач убирают с экрана

Как переключаться между окнами программ если на экране только видно только одно окно
Alone предлагает нажимать Caps Shift и Symbol Shift
Или дать возможность настраивать 2 варианта-
1) панель задач всё время торчит на экране в самой верхней строке
2) как в журналах (Deja Vu, Adventure) панель задач появляется вверху только тогда, когда подводишь стрелку в самый верх экрана

---------- Post added at 12:25 ---------- Previous post was at 12:19 ----------

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

планируется вызов wait - про него сказано на первой странице
чтобы не ждать прихода прерывания, прога размещает сообщение в почтовом ящике
и делает
call addr1 и тем самым ДОСРОЧНО прерывается её процесс и проиходит переключение на системный процесс, причем это процесс сначала доделает то, то он делал, и потом он выполняет вызов этой проги - таким образом НЕТ времени ожидания (до прихода прерывания), которое тратиться в пустую.