Народ! Уже несколько месяцев без пищи и воды я пишу операционку (не Linux подобие). И постиг её страшный баг. Когда процессор находится в защищённом режиме и я пишу в самые старшие адреса памяти, происходит эффект дублирования, т.е. когда я пишу в последний, к примеру, байт памяти, это же значение оказывается и по другому адресу. Очень прошу помочь или хотябы намекнуть на столь неприятный баг.

До встречи

В догонку, это происходит на 486 проце, на Athlon XP вроде бы всё нормально. Может A20 надо как-нибудь особо открывать, хотя не знаю. Не ужели такой вполне ощутимый баг нигде не описан???

Kirk
Может на данной плате просто не проверяются состояние страрших линий адресной шины? Или младшие биты этих адресов не совпадают?

М-да нет, всё вроде бы корректно. И винда работает 95, 98... Интересен момент вот в чём, когда я пишу скажем в последний-512 байт, то это значение записывается также несколькью байтами ниже, причём разница - очень странное число, не похожее на степень двойки. Более того есть процедура (глюк с ней не связан, это так сказать в довершение) которая работает сразу после перехода в PMODE и определяет размер всей оперативной памяти путём записи значения в память и чтения его с проверкой оттуда. Так вот, пришлось последовательно писать одно значение, сверять его, а затем повторять то же для другого значения. Иначе возникает ещё один глюк:
запуск 1: размер верен
"-"-" 2: больше на 32 байта
3: верен
4: > 32 байта
. . . и т.д.
Не то, чтобы меня так сильно интересовал 486, но так как я пишу ось, хотелось бы наибольшей совместимости (сей старый комп у меня как своего рода полигон).

Скорее всего это просто баг где-то в коде.
Хотелось бы взглянуть на кусок кода который память подсчитывает.

; Memory test
	@WriteStr (aMem)
	mov	ax,SEL_FLAT_DS
	mov	es,ax
	mov	ds,ax
	mov	ecx,1024*1024*2		; scan from 2 mb to end
	mov	ah,1
	mov	bh,2
  @@:	mov	al,[ecx]
	mov	[ecx],ah
	cmp	[ecx],ah
	jne	@f
	mov	[ecx],bh ; это 2е сравнение, за счёт которого удалось избежать бага
	cmp	[ecx],bh
	jne	@f
	mov	[ecx],al
	add	ecx,512 ; шаг - 512 байт, на момент ошибки было 16 (так, на всякий случай)
	jmp	@b
  @@:	mov	eax,ecx
	mov	fs:total_memory,eax
	shr	eax,20
	@printnum eax
	@WriteStrFS (aMb)
	@CrLf

SEL_FLAT_DS - селектор всей оперативной памяти;
fs - указывает на локальный сегмент 32-битных данных

Kirk
Может причина этого бага та же что и бага с CALL?
Проверь все обращения к переменным и значения в сегментных регистрах, а также дескрипторы.

Что касается дублирования адресов, то вряд ли (я конечно поробую ещё как-следует всё посмотреть), а вот тест памяти по всей видимости так и делают. Мне попались исходники, аналогичные моим, но только там память тестировалась в unreal-режиме. Там тоже проверялись два значения, а объяснения на этот счёт не давались:-(

Тут на счёт дублирования адресов идея есть. Листал тут как то на lowlevel.ru статьи по разводу ОС и интсрукции по проникновению в ОСиный улий, ну и наткнулся во 2 статье на место, где товарищ утверждает, что в конце адресного пространства (по его утверждениям именно вообще, а не 1 Мб) находится EPROM. Может это то большое ТО, почему туда нельзя писать данные??? А???