Вид для печати
RT11DSK лежит в исходниках -- ничего не мешает если не просто скомпилить то поправить и скомпилить под юниксами. Кстати, было бы интересно услышать о возникших проблемах.Цитата:
Сообщение от AlecV
http://code.google.com/p/ukncbtl/sou...nk/src/rt11dsk
Господа хорошие,
я Олег Ховайко -- тот, от которого WDROM ... by Oleg H.
Задавайте вопросы по винчестеру - постараюсь ответить.
Сейчпм же сообщу, что все исходники, за исключением программы WDROM,
выложены здесь:
http://uknc.narod.ru/Suvorov/index.htm
Программа WDROM предназначена для изготовления образа РФ2 из SAV-файла WDBOOT.SAV. Если действительно нужна, могу снять УКНЦ с полки, и поискать там.
Экземпляр УКНЦ, вместе с винчестером и дебаг-контроллером винта,
ранее принадлежавший моему отцу, я передал Арсению. Так что спрашивайте его, если что.
Как я уже говорил выше, интересны особенности подключения винчестера к УКНЦ, из того что ещё не упомянуто Alex_K.Цитата:
Сообщение от olegh
Исходники программы зашитой в РФ2 конечно не помешали бы.
Также интересны те версии прошивки, которых у нас сейчас нет.
AlecV, если вы о PUTR V2.01, то исходники можно взять здесь: http://www.dbit.com/pub/putr/, но они, к сожалению, на ассемблере.Цитата:
Сообщение от AlecV
---------- Post added at 16:03 ---------- Previous post was at 15:57 ----------
Здравствуйте, Олег! Очень рад видеть Вас на этом форуме.Цитата:
Сообщение от olegh
Программа WDROM есть, ее исходники мне передавал Арсений. А интересуют последние исходники WDBOOT, по ссылке сверху там версия 1.07, а у Арсения в ПЗУ зашита версия 1.10. Также программа разбивки на разделы WDX - исходники версии 1.00, а бинарники версии 1.14.
Хочу понять, зачем вам это надо.
Если только для эмулятора - то проще драйвер ещё один написать, специально
под псевдоустройства, создаваемые эмулятором.
Если же есть желание восстановить разработку "в железе" - тогда да, надо копаться с УКхой.
По поводу более свежих версий --
Я попробую сделать ревизию, чего у меня имеется на эту тему.
Кстати, имейте в виду, что моя разработка поддерживает до 24х разделов - WD/WE/WF. Должны быть где-то ещё драйвера WE/WF.
WE/WF - не bootable, только для данных...
Восстановить в железе.Цитата:
Сообщение от olegh
По поводу WE/WF: есть исходники WE, но в нем для доступа к дополнительным разделам присутствует параметр SUBSET, т.е. SET WE SUBSET=1 обеспечивает доступ к разделам 8-15.
Есть еще вопрос: что такое скрытый раздел? В чем его смысл?
по 2001вый, в школе #76 САО г. Москвы, на диске весь софт который пользовался для обучения детей, работы детей, игры и кое-какие базы данных. еще была куча дискет с этим же софтом, но они утеряны.Цитата:
Сообщение от nzeemin
был еще один точно такой же диск с контроллером, с подобным содержанием, из этой же школы, но до моих (а в последствии и до рук nzeemin) он не дошел, его забрал какой-то товарищ-спец по УКНЦ в том же году, как их списали.
1. WE - хорошо, что у вас есть! Значит, не потерялось.
Чтоб сделать WF - надо просто переименовать и установить subset=2
2. Касаемо скрытого раздела:
Смысл в том, что если вам попал в руки винтовод с локально размещённой группой BAD-блоков (например, царапина на блине), то можно битые блоки вынести в отдельный раздел, и после того - обьявить раздел скрытым. В результате, винт для пользователя выглядит полностью исправным.
Последующие разделы при этом смещаются на -1.
rzk, а файлы с расширением *.CEF - это что ?
Так, господа хорошие...
Полез на полку делать ревизию - нашёл два винчестера, два КЖД, монитор, БП - но самой УКхи не нашёл!!! Не знаю, куда делась! Буду искать.
Скажите, можно ли как-то в эмуляторе прицепить винт или образ винта к PC, и получить доступ к файлам rt-11? Или какие есть ещё варианты слить инфу с винтов? Инфа, насколько я помню, примерно одинакова - один из них был backup.
Есть такая идея: могу слепить образ винта 1:1, залить его на filefactory.
Если у Вас есть кжд - пропишите образ на другой винт. Скорее всего, должно потом заработать.
Касаемо геометрии - по идее, котроллер читает мастер-блок, вынимает оттуда ожидаемую геометрию,
и программирует винт под эту геометрию, и далее с ней работает. Поэтому винт даже с другой
геометрией наверное будет работать корректно тоже.
Процесс тут в треде в общем уже описан:Цитата:
Сообщение от olegh
1. Прицепить винчестер к PC
2. Утилитой HxD снять полный дамп
3. Инвертировать битики в дампе
4. Выделить разделы в отдельные .dsk-файлы
5. Дальше с .dsk-файлами можно работать утилитами PUTR или RT11DSK
Ну либо просто выложите слитый дамп, дальше мы сами 8-)
а загрузится с снятых dsk образов эмулятором возможно? так я бы и вспомнил что за CEF файлы там.
извиняюсь за нубняк, если что. (:
upd: попробовал, не получается.
Эмулятор не работает с такими огромными дисками.Цитата:
Сообщение от rzk
Используйте утилиту rt11dsk из комплекта эмулятора, например:
rt11dsk.exe e WDC170_0.dsk rossia.pnt
Это файлы от графического редактора AHEAD, они содержат Esc-последовательности графики, их можно выводить на экран командой TYPE.Цитата:
Сообщение от AlecV
В эмуляторе для простоты управления в эмуляторе сделаю так:
1. командой Cartridge 1 или Cartridge 2 выбирается HDD ROM image (.bin)
2. после этого командой Hard Drive 1 или Hard Drive 2 выбирается HDD image (.img?) и слот переключается в режим эмуляции жёсткого диска.
Очень надеемся вскоре увидеть новую версию эмулятора ;)
да, тоже жду с большим нетерпением, давненько новенького не ыло :)
Насколько геометрия критична для эмуляции?Цитата:
Сообщение от olegh
То есть есть образ слитый в порядке секторов LBA -- можно ли назначить количество цилиндров/головок/секторов от балды, лишь бы их произведение * 512 давало полный объём диска?
В данном случае критична, так как резидентный драйвер в ПП работает с регистрами IDE в режиме CHS, а не LBA. Если бы работа шла в режиме LBA, то и проблем бы не было.Цитата:
Сообщение от nzeemin
А, увидел -- первые два байта это spt и heads, проблемы нет.Цитата:
Сообщение от Alex_K
Со стороны UI эмуляцию сделал, порты IDE читаются и пишутся, геометрию из образа получаю, осталось сделать эмуляцию на уровне реакции на чтение/запись портов, реализацию команд.
Застрял пока вот на этом -- крутится в цикле по адресам 001264--001274, ожидая статуса BUSY (код прошивки Олега):
Но я тут не вижу причин почему бит BUSY должен возникнуть -- команд в IDE до этого не передавалось, сброса тоже не было.Код:001250 MOV #000006, R0
001254 MOV #177014, R1
001260 CALL 001406
001264 CALL 001402
001270 MOVB @#110000, R4 ; Чтение статуса IDE
001274 BPL 001264 ; Проверяем бит 7 == BUSY, переход если сброшен
...
001372 MOV R5, @#177054 ; Отключение портов IDE
001376 MTPS R0
001400 RTS R2
001402 JSR R2, 001372
001406 MOV @#177054, R5
001412 MTPS (PC)
001414 MOV #000006, @#177054 ; Включение ПЗУ и портов IDE
001422 RETURN
С моей стороны возвращается статус 000100 (DRIVE_READY).
UPD: Блин, я идиот -- передаваемые данные же инвертируются шиной QBUS, здесь ожидается снятие сигнала BUSY а не установка!
Насколько мне помнитсо, ждать BUSY вечно нельзя...
Код, правда, для Protect386, но суть байки от этого не меняется.
Код:wait_busy:
push eax ecx edx
mov ecx,timer_tic
add ecx,deley
loc1:
cmp ecx,timer_tic
jb wb_err
mov dx,3f6h
in al,dx
test al,80h
jnz loc1
wb_exit:
pop edx ecx eax
ret
wb_err:
or byte ptr ide_s[ebp].ide_num,40h
jmp wb_exit
Можно. Но смысла нет. :)Цитата:
Сообщение от Atari
В первый раз прочитал сектор -- команда 20h начала работать:
http://img-fotki.yandex.ru/get/3810/...d95a038_XL.jpg
На прошивке Олега, правда, пока ничего не получилось.
rzk, а ты не помнишь какой загрузчик использовался с этим винчестером -- этот или Олега?
кажется Олега, я помню строчку про Oleg H., но я не уверен.
Вообще-то в этих образах везде драйвер ID.SYS от "Электронных работ", а драйвера WD.SYS от Олега Ховайко нигде нет.Цитата:
Сообщение от nzeemin
Кстати, там еще подпорчена таблица разделов, их реально 6, а не 8, как в таблице. Еще размеры реальных разделов другие. Надо подправлять таблицу и контрольную сумму в конце первого сектора.
nzeemin, как понимаю, драйвер Oleg H требует чтобы команда IDENTIFY работала.
http://www.win.tue.nl/~aeb/linux/Lar....html#identify
Да до этого не доходит даже, там что-то другое совсем.Цитата:
Сообщение от AlecV
А команды я реализую по мере необходимости.
А прошивка от Олега спотыкается на этом кусочке кода:Цитата:
Сообщение от nzeemin
Тут такое дело, что регистры с 1F1 по 1F7 являются 8-битными, т.е. старший байт не задействован. По идее он (старший байт) висит в воздухе, а это электрически "единица", QBUS инвертирует их в логический "ноль". Так что надо, чтобы в эмуляторе регистры с 110000 по 110014 читались с нулевым старшим байтом.Код: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
Cчас доступа к полному исходнику у меня нет, поэтому отвечаю по памяти, что за 10 лет не выветрилось.
Тот кусок кода:
TstHDD = :.+2
11$: mov #-1,r0
bmi 11$
Смысл его такой:
Крутим цикл ожидания до тех пор, пока другой процесс из ПП не заменит "-1"
внутри команды "mov" на код возврата. Тогда этот цикл разблокируется и бежит анализировать код возврата. Там действительно, насколько я помню, при копировании старший байт передаётся как 0, что сбрасывает флаг N и разблокиркет цикл, так как BMI не срабатывает.
Извините за несколько "лихой" стиль программирования, но когда писал драйвер - стремился выжать его как по скорости, так и по обьёму. А что эмулятор будет - тогда догадаться не мог...
Кстати, когда сравнивал быстродействие своего драйвера с ЭРовским, мой на ~20% быстрее работал при прямом копировании.
И мой ЦП не завешивает в ожидании завершения I/O. Всё честно через виртуальное прерывание сделано, по Power Halt...
При загрузке ПЗУшкой от "Электронных работ" (трасса записи в порты винчестера):
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
Действительно странно как-то, чувствую надо дизассемблировать IDDRIV.SAV для того, чтобы понять логику работы.Цитата:
Сообщение от nzeemin
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
// Чтение доп.части вторичного загрузчика
Ошибочка при исполнении этой команды:
HDD COMMAND 20 (READ MULT): C=0, H=3, SN=26, SC=33
Здесь запрашивается чтение файла операционной системы : читается с блока 0176(8) 020142(8) слов по адресу 0117270(8). Соответственно с адреса 117270 по 130267 данные расположены на 0-м цилиндре 3-й стороны, с адреса 130270 должно читаться с 1-го сектора 4-й стороны 0-го цилиндра, а фактически начинает читаться с 34-го сектора 3-й стороны 0-го цилиндра, т.е. неправильно осуществляется переход на следующую сторону/цилиндр.
Нашел ошибку в void CHardDrive::NextSector() : при переходе на следующую сторону надо m_cursector = 1;, а не 0. Загрузилась система, но эмулятор вылетел по ошибке - нет отработки команды с кодом 30 (собирал как Release, а не Debug).
Еще надо в файле образа заменить таблицу разделов на вот такую:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 22 0A EE D8 ED D8 ED D8 ED D8 ED D8 ED D8 00 00
00000010 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
В данном случае она отражает реальное состояние дел. Загрузиться можно только с разделов с 0 по 4, на 5-м разделе "No boot on volume".
Исправил. Если соберёшь в режиме Product -- то мы уже загружаемся, показывается интерфейс настройки драйвера печати, затем выходим на командную строку, и команда DIR даже работает.Цитата:
Сообщение от Alex_K
http://img-fotki.yandex.ru/get/3908/...7387365_XL.jpg
Во вложении -- прошивки и exe-файл. Также выложил новую бету эмулятора на сайте.
А вообще-то все правильно. Запрашивается команда чтения одного сектора, он прочитывается во внутренний буфер винчестера, и если не было ошибок при чтении, то SC устанавливается в ноль и в регистре статуса соответствующие биты. А далее уже программа должна прочесть из буфера эти 256 слов. А так как в самом первом слове находится геометрия, то соответственно она подготавливает данные для выполнения команды с кодом 91h.Цитата:
Сообщение от nzeemin
Если предположить, что буфер имеет размер одного сектора, то он сначала целиком читается в буфер, уменьшается CS, устанавливаются соответствующие биты в регистре статуса и далее с регистра данных считываются данные. При записи соответственно сначала надо заполнить буфер, а потом уже винчестер записывает нужный сектор, декрементирует SC и устанавливает в регистре статуса и ошибок результат записи сектора.
Реализовал команду 30h (WRITE MULTI) -- это было уже совсем просто.
Так что на прошивке ide_hdbootv0400.bin уже загружается, пишет в файлы и каталог.
Серьёзных тестов не делал, поэтому осторожнее, делаем бэкапы образа винчестера.
UKNCBTL.exe во вложении.
P.S. Принимаю заявки на реализацию других IDE-команд -- только говорите сразу какие программы их генерируют и при каких условиях -- чтобы проверять.
С ide_wdromv0110.bin запись тоже заработала, да и грузится стало.Цитата:
Сообщение от nzeemin
Наверное 21h - работает так же как и 20h, и соответственно 31h - аналогично 30h. Надо ECh(Identify drive), эту команду должны употреблять IDINST.SAV от "Электронных работ" и WDX.SAV от Олега Ховайко.Цитата:
Сообщение от nzeemin
Можно еще ввести в команды чтения и записи выход по ошибке с установкой бита ABRT в регистре ошибок, если запрашиваемая геометрия выходит за пределы.
Еще можно ввести работу с инверсными образами, определить автоматом по смещению 0x1F0-0x1FB в мастер-блоке - если там 0xFF - то и образ инверсный. Можно также по геометрии, если кол-во сторон и секторов больше 128, то также образ можно считать инверсным.
Начал бы кто печатки рисовать и схему править под 2х2716..
У меня только один образ есть, с диска rkz. С него через wdboot не грузится, говорит -- ?WDROM-F-Некорректный boot-блокЦитата:
Сообщение от Alex_K
Кстати, а по инструкции Арсения можно загрузочный образ создать? пригодилось бы.