Винчестер УКНЦ

[b2m]

Насколько мне помнитсо, ждать BUSY вечно нельзя...

Можно. Но смысла нет.

[Advertiser]

[nzeemin]

В первый раз прочитал сектор -- команда 20h начала работать:



На прошивке Олега, правда, пока ничего не получилось.

rzk, а ты не помнишь какой загрузчик использовался с этим винчестером -- этот или Олега?

[Alex_K]

rzk, а ты не помнишь какой загрузчик использовался с этим винчестером -- этот или Олега?

Вообще-то в этих образах везде драйвер ID.SYS от "Электронных работ", а драйвера WD.SYS от Олега Ховайко нигде нет.
Кстати, там еще подпорчена таблица разделов, их реально 6, а не 8, как в таблице. Еще размеры реальных разделов другие. Надо подправлять таблицу и контрольную сумму в конце первого сектора.

[Alex_K]

На прошивке Олега, правда, пока ничего не получилось.

А прошивка от Олега спотыкается на этом кусочке кода:

TstHDD	= :.+2
11$:	mov	#-1,r0
	bmi	11$
	
	tstb	r0
	beq	14$
	cmpb	r0,#377
	bne	17$
	.Eprint	NoPwr
14$:	.Eprint	NoCab

17$:	Call	sb$r			; Читаем мастер-блок

...............................................................................

	mov	#TstHDD/2,@#Rap
	mov	@#110000,@#Rdp

Тут такое дело, что регистры с 1F1 по 1F7 являются 8-битными, т.е. старший байт не задействован. По идее он (старший байт) висит в воздухе, а это электрически "единица", QBUS инвертирует их в логический "ноль". Так что надо, чтобы в эмуляторе регистры с 110000 по 110014 читались с нулевым старшим байтом.

[rzk]

кажется Олега, я помню строчку про Oleg H., но я не уверен.

[AlecV]

nzeemin, как понимаю, драйвер Oleg H требует чтобы команда IDENTIFY работала.

http://www.win.tue.nl/~aeb/linux/Lar....html#identify

[nzeemin]

nzeemin, как понимаю, драйвер Oleg H требует чтобы команда IDENTIFY работала.

http://www.win.tue.nl/~aeb/linux/Lar....html#identify

Да до этого не доходит даже, там что-то другое совсем.
А команды я реализую по мере необходимости.

[olegh]

Cчас доступа к полному исходнику у меня нет, поэтому отвечаю по памяти, что за 10 лет не выветрилось.
Тот кусок кода:

TstHDD = :.+2
11$: mov #-1,r0
bmi 11$

Смысл его такой:
Крутим цикл ожидания до тех пор, пока другой процесс из ПП не заменит "-1"
внутри команды "mov" на код возврата. Тогда этот цикл разблокируется и бежит анализировать код возврата. Там действительно, насколько я помню, при копировании старший байт передаётся как 0, что сбрасывает флаг N и разблокиркет цикл, так как BMI не срабатывает.

Извините за несколько "лихой" стиль программирования, но когда писал драйвер - стремился выжать его как по скорости, так и по обьёму. А что эмулятор будет - тогда догадаться не мог...
Кстати, когда сравнивал быстродействие своего драйвера с ЭРовским, мой на ~20% быстрее работал при прямом копировании.
И мой ЦП не завешивает в ожидании завершения I/O. Всё честно через виртуальное прерывание сделано, по Power Halt...

[nzeemin]

При загрузке ПЗУшкой от "Электронных работ" (трасса записи в порты винчестера):

HDD Write 1f4 <-- 0xffff
HDD Write 1f4 <-- 0xff00
HDD Write 1f4 <-- 0xffff
HDD Write 1f4 <-- 0xff00
HDD Write 1f6 <-- 0xff00
HDD Write 1f5 <-- 0xff00
HDD Write 1f4 <-- 0xff00
HDD Write 1f3 <-- 0xff01
HDD Write 1f2 <-- 0xff01
HDD Write 1f7 <-- 0x0020
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=1, SC=1
HDD Write 1f2 <-- 0xf522
HDD Write 1f6 <-- 0x0009
HDD Read sector complete
HDD Write 1f7 <-- 0x0091
HDD COMMAND 91 (SET CONFIG): H=9, SC=33

Вот здесь непонятка -- получается что сначала задаются параметры следующей команды, но затем завершается передача сектора, что приводит к декременту sector_count (SC, порт 1F2). В результате команда 91h получает параметр SC=33, что конечно неверно и в дальнейшем приводит к ошибкам позиционирования.
Либо я тут неправильно понимаю логику SC и он должен уменьшаться до завершения передачи данных сектора -- но неясно в какой момент.

Если быть точным, то установка параметров команды 91h происходит сразу же после чтения первых двух байт сектора:
HDD Read 1f7 0xffd0
HDD Read 1f7 0xffd0
HDD Read 1f7 0xff58 ; Снят сигнал BUSY
HDD Read 1f7 0xff58
HDD Read 1f0 0xf5dd ; Прочитаны первые два байта 1-го сектора
HDD Write 1f2 <-- 0xf522 ; Установка параметров команды 91h
HDD Write 1f6 <-- 0x0009
HDD Read 1f0 0x5d4d
HDD Read 1f0 0x5d4d

UPD: В общем, сделал пока декремент счётчика непосредственно перед началом чтения -- вроде как работает.

Сейчас уже загружает ряд блоков, но в итоге всё равно выпадает в СТОП:

HDD COMMAND 20 (READ MULT): C=0, H=0, SN=1, SC=1
HDD COMMAND 91 (SET CONFIG): H=9, SC=34
; Тут выбор раздела 0
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=2, SC=1 ; 0-й блок тома: начальный загрузчик
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=4, SC=4 ; 2-5 блоки: загрузчик монитора
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=8, SC=2 ; 6-7 блоки: каталог
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=10, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=12, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=14, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=16, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=23, SC=1
HDD COMMAND 20 (READ MULT): C=0, H=5, SN=27, SC=1
HDD COMMAND 20 (READ MULT): C=0, H=5, SN=27, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=22, SC=1
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=26, SC=33
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=25, SC=1

[Alex_K]

Вот здесь непонятка -- получается что сначала задаются параметры следующей команды, но затем завершается передача сектора, что приводит к декременту sector_count (SC, порт 1F2). В результате команда 91h получает параметр SC=33, что конечно неверно и в дальнейшем приводит к ошибкам позиционирования.
Либо я тут неправильно понимаю логику SC и он должен уменьшаться до завершения передачи данных сектора -- но неясно в какой момент.

Если быть точным, то установка параметров команды 91h происходит сразу же после чтения первых двух байт сектора:
HDD Read 1f7 0xffd0
HDD Read 1f7 0xffd0
HDD Read 1f7 0xff58 ; Снят сигнал BUSY
HDD Read 1f7 0xff58
HDD Read 1f0 0xf5dd ; Прочитаны первые два байта 1-го сектора
HDD Write 1f2 <-- 0xf522 ; Установка параметров команды 91h
HDD Write 1f6 <-- 0x0009
HDD Read 1f0 0x5d4d
HDD Read 1f0 0x5d4d

Действительно странно как-то, чувствую надо дизассемблировать IDDRIV.SAV для того, чтобы понять логику работы.

HDD COMMAND 20 (READ MULT): C=0, H=0, SN=1, SC=1
// Читается мастер-блок с информацией о разделах
HDD COMMAND 91 (SET CONFIG): H=9, SC=34
; Тут выбор раздела 0
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=2, SC=1
// Чтение первичного загрузчика (он же содержит драйвер чтения)
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=4, SC=4
// Чтение вторичного загрузчика
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=8, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=10, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=12, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=14, SC=2
HDD COMMAND 20 (READ MULT): C=0, H=0, SN=16, SC=2
// Чтение каталога. Здесь вторичный загрузчик ищет сам файл операционной системы, драйвера
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=23, SC=1
// Чтение доп.части вторичного загрузчика
HDD COMMAND 20 (READ MULT): C=0, H=5, SN=27, SC=1
// Чтение нулевого блока драйвера винча ID.SYS
HDD COMMAND 20 (READ MULT): C=0, H=5, SN=27, SC=2
// Чтение всего драйвера ID.SYS. Здесь вторичный загрузчик должен переместить его в ОЗУ ближе к 160000, примерно 157*** с чем-то
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=22, SC=1
// Чтение доп.части вторичного загрузчика
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=26, SC=33
// Чтение самой операционной системы. Читается KMON, USR и RMON
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=25, SC=1
// Чтение доп.части вторичного загрузчика