Техраздел UZIX

[Error404]

Ещё вопрос, образ под SD или IDE?
В выходные хочу достать свой Орион-512 и потестить...

Образ универсальный, заливать можно 1:1 хоть на IDE, хоть на SD (изменится только Монитор-загрузчик или пункт в MBOOT). От устройства IDE/SD зависит только как в CP/M должен запускаться драйвер idebdos (он запускается из autoexec.bat перед UZIX). Для IDE он запускается без параметров, для варианта SDCard он запускается с параметром SD.

Если параметр выставлен несоответствующим (т.е. выставлен в варианте для отсутствующего устройства), то просто IDEBDOS не загрузится резидентом и ЮЗИКС не стартанет тоже, останемся в промпте CPM.
Тогда можно будет ручками набрать
idebdos sd
uzix 2:
или
idebdos
uzix 2:

Если IDEBDOS загрузился но криво, его в CP/M можно грохнуть (выгрузить из памяти) командой
kill idebdos*

Также есть особенности монтирования устройств (см. команды ASSIGN в config.sys в user 0), но загрузится при любых настройках, - диск С: будет всегда

[Advertiser]

[Error404]

Начал ковырять исходники LIBC.
Первая проблема которую предстоит решить в том, что компилятор прогеры Юзикс на самом то деле использовали какой-то более продвинутый, чем используемая мной сохранившаяся в PublicDomain HitechC CP/M-версия 3.09 образца 1987 года, не понимающая оператор asm("operand") в C-коде, или вот такие ассемблерные конструкции в ASM-коде:

	psect	text,class=CODE
	psect	strings,class=CODE
	psect	const,class=CODE
	psect	data,class=DATA
	psect	bss,class=DATA
	psect	_bssend,class=DATA

или

	global	_access
	signat	_access,8250
	global	_exit
	signat	_exit,4152	; arg in DE

Выделенное жирным, HitechC v3.09 образца 1987 года не понимает от слова совсем.

Собственно, это не новость, я с этим столкнулся еще в ядре. Но там этого встречалось мало и я тупо взял и переписал по смыслу. А тут надо будет обдумать и как передаются параметры (v3.09 образца 1987 года не умеет никак кроме как по стеку, а в исходника мы видим размещение в регистрах, причем несколько вариантов в зависимости от числа в signat), и как после С-компиляции сегменты в исполняемом бинаре лягут - надо чтобы в требуемом порядке.

[Totem]

Начал ковырять исходники LIBC.
Первая проблема которую предстоит решить в том, что компилятор прогеры Юзикс на самом то деле использовали какой-то более продвинутый, чем используемая мной сохранившаяся в PublicDomain HitechC CP/M-версия 3.09 образца 1987 года, не понимающая оператор asm("operand") в C-коде, или вот такие ассемблерные конструкции в ASM-коде:

	psect	text,class=CODE
	psect	strings,class=CODE
	psect	const,class=CODE
	psect	data,class=DATA
	psect	bss,class=DATA
	psect	_bssend,class=DATA

или

	global	_access
	signat	_access,8250
	global	_exit
	signat	_exit,4152	; arg in DE

Выделенное жирным, HitechC v3.09 образца 1987 года не понимает от слова совсем.

Собственно, это не новость, я с этим столкнулся еще в ядре. Но там этого встречалось мало и я тупо взял и переписал по смыслу. А тут надо будет обдумать и как передаются параметры (v3.09 образца 1987 года не умеет никак кроме как по стеку, а в исходника мы видим размещение в регистрах, причем несколько вариантов в зависимости от числа в signat), и как после С-компиляции сегменты в исполняемом бинаре лягут - надо чтобы в требуемом порядке.

забавно UZI180 собрана им. а она вроде позже написана.
ты не смотрел ее исходники?

[Error404]

забавно UZI 180 собрана им. а она вроде позже написана.
ты не смотрел ее исходники?

Когда-то давно смотрел исходники первой UZI, которая для Z80. Там автор прямо писал, что использовал Codeworks C (который вообщето малоинтересен т.к. не ANSI и не умеет long). А так - да, про UZI Z180 пишут, что использовался HitechC (опять же не пишут какой версии, а про него известна версия 3,09 для Z80, 5.х мультиплатформенная древняя платная - подозреваю ею и компилировали MSX UZIX, и 7х современные платные):
https://groups.google.com/forum/#!to...pm/xbcVQ8vt_TU

UZI для меня менее интересен чем UZIX, т.к. последний болеее развит, и имеет все исходники (ядро, приложения, libc), а для UZI сохранились только исходники ядра (по крайней мере начальной версии от Z80)

Как бы там ни было, придумал как все будет в LIBC со стареньким HitechC v3.09, осталась мелочь - начать да закончить.

[shurik-ua]

Теряюсь в догадках. Какого хека?

Восьмеричная система.

[shurik-ua]

А как отличать от десятичных констант

скорее всего во всех исходниках в пределах архива константы в восьмеричной системе - я думаю это перешло от компов pdp-11.

[PPC]

Отчего именно ТАК переполняется, надо смотреть как в компиляторе устроен алгоритм преобразования строки в int.
А приведение к long не помогает?
В стиле
#define S_IFMT ((long)0170000) /* file type mask */

---------- Post added at 12:13 ---------- Previous post was at 12:12 ----------

Возможно, лидирующие нули означают восьмиричное число. Я и забыл уже

[Error404]

Отчего именно ТАК переполняется, надо смотреть как в компиляторе устроен алгоритм преобразования строки в int.
А приведение к long не помогает?
В стиле
#define S_IFMT ((long)0170000) /* file type mask */

---------- Post added at 12:13 ---------- Previous post was at 12:12 ----------

Возможно, лидирующие нули означают восьмиричное число. Я и забыл уже

Не, меня то что С как-то сам с этим разбирается устраивает вполне. Просто я сейчас некоторые функции из LIBC на ассемблере переписал, а раньше они были на С. Соответственно начал с константами разбираться и по первости не сразу врубился, потому что там записано прям рядом такое:
#define S_IFCHR 0020000 /* character special */
#define S_IFPIPE 0010000 /* pipe */
и такое:
#define S_VAR1 8 /* something */
#define S_VAR2 9 /* something */
причем первое - восьмеричное, а второе десятичное.

[shurik-ua]

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

[Q-Master]

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

Ну каг-бэ: 0xЧисло - шестнадцатеричная, 0число - восьмеричная. И такое уже очень с давних времен тянется. Количество цифр не играет никакой роли в данном случае.