Как по мне дак совсем не обязательно такому куску как ЯДРО, уметь печатать и форматировать текст так круто как может printf() вполне себе элементарного get/put хватало бы в какую-нибудь виртуальную "консоль", а тут выходит вот такой пример (утрированный), есть грубо говоря 3 куска кода занимающих всю память, 1-й ядро, 2-й printf(), 3-й прога LS например... они как не крути всю память зажрали, если printf() часть ядра то ясное дело что для LS нет маневра, даже тогда если LS решит токо половину printf-a использовать... вот и вся логика.Сообщение от NovaStorm
А вообще со времен прочтения про modula2 для pdp11 пришло понимание того что надо "уметь" разбивать прогу любой длинны и сложности на куски размером с 1 страницу (для zx это 16kB), тогда можно будет имея пачку свободных страничек + какой-то рабочий буфер выполнять и код ядра и код задач несмотря на ограниченное адресное пространство.
---------- Post added at 05:45 ---------- Previous post was at 05:16 ----------
Я так понимаю что "некоторые" варианты pdp11, (такие как тот же f11 применявшийся в pdp11/23) работают в той же "скоростной категории" что и z80, просто потому что это все те же 5мкм и соответственно примерно равные частоты, а битность на скорость влияет не так сильно как частота и кэши. Так вот многозадачность там работает, в том плане что может сидеть там паралельно человек 5 и набивать текст ed-ом и потом, компилировать его и играть там в rogue... Про графику забудьте, даже в самых простых динамических играх типа manic miner 90% скорости процессора потраченно на графику, так что надо вешать к спектруму еще один Z80 + память (шото типа general sound) и пускать тогда уже unix на нем, такая идея обкатанна на acon bbc b с его tube интерфейсом и множеством видов "second processor"-ов.
Ответить с цитированием