Проблемы с чтением CF через int13h на некоторых старых BIOS
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Gleb, большое спасибо, пригодится!
Можно еще дизассемблировать существующий POWER IDE и second.exe, посмотреть, как точно там
сделано. Ну это потом, на будущее.
Можно еще дизассемблировать существующий POWER IDE и second.exe, посмотреть, как точно там
сделано. Ну это потом, на будущее.
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Gleb, к вопросу о перехвате int 13h, вот что я нашел в исходниках DOS 6
; there is a bug in some versions of ibm's at rom bios.
; interrupts are not disabled during read operations.
;
; use: this program should be chained in line with the disk
; interupt 13h, it intercepts read calls to the hard disk
; and handles them appropriately. for other functions it
; passes controll to old13, which should contain the
; address of the at rom disk routine. the entry point for
; this program is ibm_disk_io.
Там же есть указание
cli ;disable interrupts (bug was forgetting this)
; M062 -- some of these old machines have intermittent failures
; when the read is done at full speed. Instead of using
; a string rep instruction, we'll use a loop. There is
; a slight performance hit, but it only affects these
; very old machines with an exact date code match, and
; it makes said machines more reliable
;
;M062 repz insw ;read in sector
rsct_loop: ; M062
insw ; M062 read in sector
loop rsct_loop ; M062
sti
Во многих старых BIOS REP не используют, но в том что я дорабатывал (D286)
уже REP.
И возвращаясь к тому, что Вы упоминали (извините за настырность, просто хочется разобраться).
команду, и сколько секторов должно быть записано/прочитано, это просто часть операции
подготовки task_file, регистр 1F2. Может быть Ваш MFM контроллер имел баг (или особенность такую,
типа как у FDC)? Я когда делал поддержку MFM для FreeBSD (с 16-битным контроллером WD) ничего
такого не заметил. Или может такая особенность у старых 8-битных контроллеров?
; there is a bug in some versions of ibm's at rom bios.
; interrupts are not disabled during read operations.
;
; use: this program should be chained in line with the disk
; interupt 13h, it intercepts read calls to the hard disk
; and handles them appropriately. for other functions it
; passes controll to old13, which should contain the
; address of the at rom disk routine. the entry point for
; this program is ibm_disk_io.
Там же есть указание
cli ;disable interrupts (bug was forgetting this)
; M062 -- some of these old machines have intermittent failures
; when the read is done at full speed. Instead of using
; a string rep instruction, we'll use a loop. There is
; a slight performance hit, but it only affects these
; very old machines with an exact date code match, and
; it makes said machines more reliable
;
;M062 repz insw ;read in sector
rsct_loop: ; M062
insw ; M062 read in sector
loop rsct_loop ; M062
sti
Во многих старых BIOS REP не используют, но в том что я дорабатывал (D286)
уже REP.
И возвращаясь к тому, что Вы упоминали (извините за настырность, просто хочется разобраться).
Вообще говоря, BIOS не должен заниматься переключением цилиндров, головок, он только подает ATAGleb писал(а): ↑29.07.2020,13:52 Как минимум для буферизации на старых системах, где установлены диски с низким числом секторов на дорожку, и для чтения большого количества секторов за один вызов int13h, нужно переключать не только головки, но и цилиндры. БИОС этого не делал.
А после подмены вектоа ДОСом становится возможным считывать большее количество секторов за раз (до 127 [7Fh]).
И если при написании собственного обработчика int13h исключить из цепочки этот обработчик DOS, а передавать прямо в оригинальный БИОС-овский int13h, то можно столкнуться с ситуацией, когда маленькие файлы читаются, а большие нет.
Столкнулся с этим на XT с классическим 17-ти секторным MFM диском.
В более современных системах это возможно иррелевантно, не проверял.
команду, и сколько секторов должно быть записано/прочитано, это просто часть операции
подготовки task_file, регистр 1F2. Может быть Ваш MFM контроллер имел баг (или особенность такую,
типа как у FDC)? Я когда делал поддержку MFM для FreeBSD (с 16-битным контроллером WD) ничего
такого не заметил. Или может такая особенность у старых 8-битных контроллеров?
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Я доделал резидент на int13h, для работы CF. В основном эта программа нужна для отладки, чтобы
попробовать реализовать основную идею. Но вдруг пригодится кому, если устроит старт с FDD, или
в системе есть и HDD и CF.
Программа встает резидентом, подменяя адрес оригинального int13h (70h:b4h). но я пробовал
вставать и сразу на int13h, при этом DOS-patch обходится, так тоже работало. Код обработчика
можно еще основательно оптимзировать, и переместить часть кода в верхнюю часть PSP, что
уменьшит занимаемую память. Исходник для MASM6 тоже прилагается.
проверял на AMI 89 года с CF багом и древнем AWARD 3.01
попробовать реализовать основную идею. Но вдруг пригодится кому, если устроит старт с FDD, или
в системе есть и HDD и CF.
Программа встает резидентом, подменяя адрес оригинального int13h (70h:b4h). но я пробовал
вставать и сразу на int13h, при этом DOS-patch обходится, так тоже работало. Код обработчика
можно еще основательно оптимзировать, и переместить часть кода в верхнюю часть PSP, что
уменьшит занимаемую память. Исходник для MASM6 тоже прилагается.
проверял на AMI 89 года с CF багом и древнем AWARD 3.01
- Вложения
-
- cfrfix05.zip
- (4.39 КБ) 100 скачиваний
-
- Advanced Member
- Сообщения: 440
- Зарегистрирован: 30.10.2016,20:46
- Откуда: Прага
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
i8088 писал(а): ↑31.07.2020,16:04 И возвращаясь к тому, что Вы упоминали (извините за настырность, просто хочется разобраться).
Вообще говоря, BIOS не должен заниматься переключением цилиндров, головок, он только подает ATA
команду, и сколько секторов должно быть записано/прочитано, это просто часть операции
подготовки task_file, регистр 1F2. Может быть Ваш MFM контроллер имел баг (или особенность такую,
типа как у FDC)? Я когда делал поддержку MFM для FreeBSD (с 16-битным контроллером WD) ничего
такого не заметил. Или может такая особенность у старых 8-битных контроллеров?
Вы не так поняли. Я как раз писал, что БИОС этого не делает, а вот ДОС, после подмены int13h "начинает делать". В кавычках потому что сам ДОС непосредственно ничего не переключает, просто он разбивает один вызов на несколько обращений к БИОС - см. ниже.
Я выделил это в своей цитате:
Gleb писал(а): ↑29.07.2020,13:52 Как минимум для буферизации на старых системах, где установлены диски с низким числом секторов на дорожку, и для чтения большого количества секторов за один вызов int13h, нужно переключать не только головки, но и цилиндры. БИОС этого не делал.
А после подмены вектора ДОСом становится возможным считывать большее количество секторов за раз (до 127 [7Fh]).
И если при написании собственного обработчика int13h исключить из цепочки этот обработчик DOS, а передавать прямо в оригинальный БИОС-овский int13h, то можно столкнуться с ситуацией, когда маленькие файлы читаются, а большие нет.
Столкнулся с этим на XT с классическим 17-ти секторным MFM диском.
В более современных системах это возможно иррелевантно, не проверял.
Я описываю то, с чем столкнулся лично.
Конкретный пример: если обратиться напрямую к оригинальному БИОС с просьбой прочитать 127 секторов подряд, то как минимум на XT (8 бит) с классическим MFM контроллером (порты 32х, не 1Fх) с подключенным к нему 17-ти секторным диском он вернет ошибку.
Но если вызвать int13h (который к тому моменту уже перехватил ДОС), то один такой вызов int13h с запросом на 127 секторов до оригинального БИОС дойдет как последовательность нескольких вызовов, каждый из которых не превысит 17 секторов. Потом ДОС у себя их "склеит" и вернет, как результат одного вызова int13h.
А ДОС при чтении длинных файлов просит сразу много секторов (если файл лежит подряд, ДОС знает это из FAT). Это видно любым интерсептором.
Это я имел в виду под буферизацией, это один из доводов, зачем ДОС забирает int13h. Но не единственный, поэтому я и писал "как минимум". Еще один Вы привели выше из ДОС6. Есть скорее всего и другие доводы.
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Gleb, спасибо! Я еще раз уточню на AT (порты 1Fx), сколько можно прочитать
секторов за раз. Хотя это должно зависеть исключительно от контроллера HDD,
который для ATA дисков совмещен с механикой. Скорее всего эта проблема только
для XT 8-битных контроллеров.
секторов за раз. Хотя это должно зависеть исключительно от контроллера HDD,
который для ATA дисков совмещен с механикой. Скорее всего эта проблема только
для XT 8-битных контроллеров.
-
- Advanced Member
- Сообщения: 440
- Зарегистрирован: 30.10.2016,20:46
- Откуда: Прага
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Насчет портов 1Fx (IDE, ATA) - наверное Вы правы. Но точно не скажу, если и знал - то не помню, давно это было.
Дело в том, что ХТ-шными вещами я снова начал заниматься сейчас из интереса, поэтому и вспомнилось многое, а вещи поновее XT пока так и остались в прошлом.
Дело в том, что ХТ-шными вещами я снова начал заниматься сейчас из интереса, поэтому и вспомнилось многое, а вещи поновее XT пока так и остались в прошлом.
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Gleb, я проверил на 286 AMI BIOS 89года - прочиталось максимум 128 секторов с ST3660A и CF
(больше просто размер буфера ES:BX не позволяет). Впрочем это заслуга IDE HDD, а не BIOS конечно.
А вот что я нашел еще в исходнике (MSINT13.ASM), разработчики страхуются от прерывания длинных
запросов в случае ECC и DMA ошибок (последнее для 286 не актуально, тк AT диск всегда PIO)
Перенос делается, если номер запрошенного сектора больше SECTORSPERTRACK. Те можно
одинаково работать с дисками, имеющими разный SECTORSPERTRACK. И с HEAD примерно похоже.
Но это правда не часть int13h, а подготовка для int 13 request, хотя там есть еще
патчи для PS2 машин, патч ecc bug Жаль нет исходников старого DOS, вот там
должно быть wrap в патче обработчика.
(больше просто размер буфера ES:BX не позволяет). Впрочем это заслуга IDE HDD, а не BIOS конечно.
А вот что я нашел еще в исходнике (MSINT13.ASM), разработчики страхуются от прерывания длинных
запросов в случае ECC и DMA ошибок (последнее для 286 не актуально, тк AT диск всегда PIO)
Код: Выделить всё
; check_wrap is a routine that adjusts the starting sector, starting head
; and starting cylinder for an int 13 request that requests i/o of a lot
; of sectors. it only does this for fixed disks. it is used in the sections
; of code that handle ecc errors and dma errors. it is necessary, because
; ordinarily the rom would take care of wraps around heads and cylinders,
; but we break down a request when we get an ecc or dma error into several
; i/o of one or more sectors. in this case, we may already be beyond the
; number of sectors on a track on the medium, and the request would fail.
;
; input conditions:
; all registers set up for an int 13 request.
;
; output:
; dh - contains starting head number for request
; cx - contains starting sector and cylinder numbers
; (the above may or may not have been changed, and are 0-based)
; all other registers preserved.
check_wrap proc near
assume ds:Bios_Data,es:nothing
push ax
push bx
push es
push di
call find_bds ; get pointer to bds for drive in dl
jc no_wrap ; finished if DOS doesn't use it
test es:[di].bds_flags,fnon_removable
jz no_wrap ; no wrapping for removable media
mov bx,es:[di].BDS_BPB.BPB_SECTORSPERTRACK
mov ax,cx
and ax,3fh ; extract sector number
cmp ax,bx ; are we going to wrap?
jbe no_wrap
div bl ; ah=new sector #, al=# of head wraps
; we need to be careful here. if the new sector # is 0, then we are on the
; last sector on that track.
or ah,ah
jnz not_on_bound
mov ah,bl ; set sector=BDS_BPB.BPB_SECTORSPERTRACK if on boundary
dec al ; also decrement # of head wraps
not_on_bound:
and cl,0c0h ; zero out sector #
or cl,ah ; or in new sector #
xor ah,ah ; ax = # of head wraps
inc ax
add al,dh ; add in starting head #
adc ah,0 ; catch any carry
cmp ax,es:[di].BDS_BPB.BPB_HEADS ; are we going to wrap around a head?
jbe no_wrap_head ; do not lose new head number!!
push dx ; preserve drive number and head number
xor dx,dx
mov bx,es:[di].BDS_BPB.BPB_HEADS
div bx ; dx=new head #, ax=# of cylinder wraps
; careful here! if new head # is 0, then we are on the last head.
or dx,dx
jnz no_head_bound
mov dx,bx ; on boundary. set to BDS_BPB.BPB_HEADS
; if we had some cylinder wraps, we need to reduce them by one!!
or ax,ax
jz no_head_bound
dec ax ; reduce number of cylinder wraps
no_head_bound:
mov bh,dl ; bh has new head number
pop dx ; restore drive number and head number
dec bh ; get it 0-based
mov dh,bh ; set up new head number in dh
mov bh,cl
and bh,3fh ; preserve sector number
mov bl,6
xchg cl,bl
shr bl,cl ; get ms cylinder bits to ls end
add ch,al ; add in cylinder wrap
adc bl,ah ; add in high byte
shl bl,cl ; move up to ms end
xchg bl,cl ; restore cylinder bits into cl
or cl,bh ; or in sector number
no_wrap:
clc
pop di
pop es
pop bx
pop ax
ret
no_wrap_head:
mov dh,al ; do not lose new head number
dec dh ; get it 0-based
jmp short no_wrap
check_wrap endp
одинаково работать с дисками, имеющими разный SECTORSPERTRACK. И с HEAD примерно похоже.
Но это правда не часть int13h, а подготовка для int 13 request, хотя там есть еще
патчи для PS2 машин, патч ecc bug Жаль нет исходников старого DOS, вот там
должно быть wrap в патче обработчика.
-
- Advanced Member
- Сообщения: 440
- Зарегистрирован: 30.10.2016,20:46
- Откуда: Прага
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Любопытно, спасибо за информацию.
Насколько старого ДОС интересуют исходники ?
Я думаю, что первая и вторая версии не интересны, хотя они опубликованы официально.
Для DOS 3.30 в сети есть неофициальные исходники. Если не найдете - скажите, выложу.
Насколько старого ДОС интересуют исходники ?
Я думаю, что первая и вторая версии не интересны, хотя они опубликованы официально.
Для DOS 3.30 в сети есть неофициальные исходники. Если не найдете - скажите, выложу.
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Исходники любой старой версии до 5 включительно интересны. А где опубликованы
исходники 1 и 2 версии? И да, если можно, я бы хотел посмотреть исходники MS-DOS 3.3
А исходники 6 версии у Вас есть? Если нет, я выложу.
upd. 1.25 и 2 нашел на archive.org
3.3 скачать не получается
-
- Advanced Member
- Сообщения: 440
- Зарегистрирован: 30.10.2016,20:46
- Откуда: Прага
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Официально они на github-е, но вы уже нашли. (https://www.3dnews.ru/976247)
3.30 я выложил у себя: https://www.gleb.cz/ES1841/Soft/MSDOS33 ... pdated.zip
Шестерка у меня есть такая : https://www.gleb.cz/ES1841/Soft/MS-DOS-600-With-SRC.zip
Если у вас другая - было бы любопытно взглянуть.
У меня разбросаны по архивам исходники разных ОС, когда-то интересовался. Кроме MS там был и PTS (физтехсофт) DOS - на мой взгляд один из достойных клонов. И какие-то винды (по моему nt4.0 и 2к).
Но архивы в порядок так и не привел, в одно место все не сложил.
Если это реально интересно - могу как-нибудь попробовать найти все что есть.
3.30 я выложил у себя: https://www.gleb.cz/ES1841/Soft/MSDOS33 ... pdated.zip
Шестерка у меня есть такая : https://www.gleb.cz/ES1841/Soft/MS-DOS-600-With-SRC.zip
Если у вас другая - было бы любопытно взглянуть.
У меня разбросаны по архивам исходники разных ОС, когда-то интересовался. Кроме MS там был и PTS (физтехсофт) DOS - на мой взгляд один из достойных клонов. И какие-то винды (по моему nt4.0 и 2к).
Но архивы в порядок так и не привел, в одно место все не сложил.
Если это реально интересно - могу как-нибудь попробовать найти все что есть.
-
- Advanced Member
- Сообщения: 4384
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Gleb, спасибо большое, посмотрю!
А вот то что у меня есть (скорее всего то-же самое, но нужно внимательно посмотреть).
NT4 и 2K я тоже находил.
Да, и int12h в 3-х основных BIOS -AMI, AWARD и PHOENIX - просто чтение 40h:13h,
я думаю декремента этой ячейки должно быть достаточно
А вот то что у меня есть (скорее всего то-же самое, но нужно внимательно посмотреть).
NT4 и 2K я тоже находил.
Да, и int12h в 3-х основных BIOS -AMI, AWARD и PHOENIX - просто чтение 40h:13h,
я думаю декремента этой ячейки должно быть достаточно