Я хочу писать/читать сектора на BDI так, чтобы использовать на это минимум памяти. Мне это для игрушки, но, думаю, для ОС на обычный 128й тоже надо будет. Так чтобы прошить её код вместо 128го бейсика. (Так 128й по-моему ещё останется "обычным" 128м, каким он уже наверное не будет, если мы прошьём свой код вместо TRDOS, или в 4ю страницу ПЗУ.)
Я не знаю, нужна ли для TRDOS память(для посекторного доступа, без ФС, сами найдём куда писать), используемая бейсиком, не знаю какую память использует сама TRDOS для своих переменных и буферов. Что по минимуму(а не целиком страницу) нужно сохранять? Или, как вариант, можно ли затереть эту память, а потом подёргать процедуры её инициализации(если при этом надо будет дёргать дисковод, уже плохо).
Последний раз редактировалось NovaStorm; 20.11.2014 в 20:23.
Тут лежит для ZX-Pentevo. Пока что грузится только по ком-порту и не видит ещё дисков.
https://github.com/salextpuru/FUZIX
А я вообще не планирую дисководы поддерживать. Нафига они? Оставлю только IDE и SD. Зато будут поддерживаться MBR-партиции, до 4х на устройство, несколько физ. устройств - т.е. партиций будет 8 или больше (выбирать минорным номером). Т.е. можно будет такую SD-карту переставлять из Ориона в PC и все будет совместимо. У меня сейчас так под CP/M - схема с MBR-разделами, довольно удобно: разделы можно подмонтировать/отмонтировать "на лету".
---------- Post added at 22:22 ---------- Previous post was at 22:18 ----------
Утилиту BD (block dump) кто-нить собирал? Что она выводит на экран (по свой сборке не пойму никак)? Если запустить к примеру так "bd 0: 1".
Никак не пойму, а описания нет.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Я от Юзикс сейчас собираю. При помощи CPM-овского Hitech C.
Т.е. на волне интереса к FUZIX предпринимаю очередной заход на Uzix (как на данный момент более полный дистрибутив). PogrammersNotepad, проект, makefile - пытаюсь делать как принято, чтобы потом не только мне было понятно что да как. От него, набравшись шишек и отладив низовые платформеннозависимые вещи, уже к FUZIX попробую. Только я наверное в оконцовке опять попробую Hitech C использовать и для FUZIX тоже - он более эффективный код дает.
Думаю, в версии для FUZIX и в версии для Uzix утилиты на экран должны одно и то же выводить, почему и спрашиваю.
---------- Post added at 23:11 ---------- Previous post was at 23:07 ----------
Кстати, дистрибутив UZIX, гуляющий в интернетах -несобираемый. Т.е. какие-то небольшие вещи HitechC не воспринимает в принципе, надо править (ассемблерные вставки, етс). Не знаю - может у авторов была не бесплатная V3.09, а какая-то чуть более другая, например платная HitechC более старших версий.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Нашел полную херню.
Почему в crt0.s секция _INITIALIZER копируется вдруг в _COMMONMEM ?!
Это ж полная х%::%:я!
По всем правилам надо так.; move the common memory where it belongs
ld hl, #s__INITIALIZER
ld de, #s__COMMONMEM
ld bc, #l__COMMONMEM
ldir
; move the common memory where it belongs
ld bc, #l__INITIALIZER
ld a, b
or a, c
jr Z, gsinit_next
ld de, #s__INITIALIZED
ld hl, #s__INITIALIZER
ldir
gsinit_next:
Я так подробно не разбирался с этим вопросом. Но все переменные TR-DOS занимают 133 байта с 23734.
http://zxpress.ru/book_articles.php?id=1353
Еще здесь посмотри, может найдёшь ответ. http://zx-pk.ru/archive/index.php/t-7056.html
Последний раз редактировалось Sergey; 21.11.2014 в 08:39.
С уважением,
Gris / Red Triangle.
_____________________________________
ZX-EVO/TS-Labs config/NGS/HDD/SD-card
Amiga A1200/Blizzard 1230@50/32/60GB
Amiga A1200/Apollo 1260@66/32/60GB
UnAmiga (C5) AGA GM7123 VideoDAC
Это всё часть великого колдунства. Вторая половина в tools/binman. Там явно надо что-то чинить для zx128, т.к. у нас нет дыры между основной частью и commonmem, и какая-то специальная обработка не нужна. А то счас интересные эффекты - если удлинить commonmem на 1 байт, то образ удлиняется на два. А если удлинить достаточно сильно (байт на 100), то отваливаются прерывания и клава перестаёт работать.
Секция INITIALIZED, по мнению компилятора SDCC, располагается в ОЗУ и её нужно инициализировать из кода, который может быть и в ПЗУ (из INITIALIZER).
Поскольку ядро грузится в ОЗУ, данное копирование излишне и данные из секции INITIALIZER утилита binman копирует сама (тут надо отметить, что после преобразования .ihx в .bin все сегменты располагаются на своих местах, а утилита binman пытается сжать слепок памяти, убрав дырки). На освободившееся место, которое обычно в самом конце кода ядра, и откуда будет начинаться распределяемое в процессе работы ядра ОЗУ, binman копирует данные секции COMMONMEM, которые располагаются отдельно от кода ядра в непереключаемой области. Именно они и копируются потом при запуске ядра на своё место, т.е. из секции INITIALIZER в секцию COMMONMEM.
Секцию DISCARD можно расположить где-нибудь в конце кучи и копировать туда перед запуском. Соответственно в binman нужно добавить копирование её в конец COMMONMEM.
Последний раз редактировалось b2m; 21.11.2014 в 12:56. Причина: Про DISCARD
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)