Я могу проверить только в эмуляторе, но на реале должно быть аналогично. На скриншоте паразитная точка справа, если еще порестартить, то еще добавятся.
Вид для печати
Я могу проверить только в эмуляторе, но на реале должно быть аналогично. На скриншоте паразитная точка справа, если еще порестартить, то еще добавятся.
К сожалению, после замены результат тот же 1 в 1... %)
контрольная сумма MD-5 файла с замененным байтом 2E2E69C64E91C0923358486DC1084146 ...
В эмуляторе все получилось, в точности с точечкой как на скриншоте..
Пойду перепроверю, что я на дискете отнес вектору ))))
Ок, все заработало и на реале... ))) Спасибо ! :v2_dizzy_heart:
Контрольная сумма правильная. Этот вариант должен работать и на реале, стоит проверить например SIDом, что по адресу 0000 байт F7.
А вот насчет запрета прерывания я стормозил, после ресета проц их и так запретит.
Точки обязаны быть и в эмуляторе и на реале. Стек в районе D7xx, после RST там будет адрес возврата 1, а это одинокая точка. Т.к. дос работает со стеком, указатель немного изменяется и точки при нескольких рестартах образуют группу, но строго в одной колонке и все примерно рядом. При скролле они уедут, но если еще рестарить, то обязательно вернуться.
Альтернативный патч mdos31h без мусорения на экране (без rst), на первый взгляд работает.
Патч работает, в целом, если учитывать то, что нажимать "ввод+блк" если и нужно будет - то совсем не часто - то это 100% работает.
Эксперимента ради я понажимал "ввод+блк" с пристрастием, и в эмуляторе и на реале, и это дало разные результаты. В эмуляторе мусор на экране я так и не увидел, полосок не было. Изредка мигала "карта памяти" на экране, зеленая на черном фоне, при зеленом цвете шрифта, белая - при белом... примерно раз в двадцать нажатий, но на долю секунды. А вот на реальном векторе "полоски" все же иногда вылезали на экран, так же где то раз в двадцать - тридцать нажатий, так же прокручивались, и исчезали в верху экрана. Причем, на этот раз это были не точки а именно полоски, одна максимум две, в одну строку друг от друга. И так же артифакт "карта памяти" иногда на экране мелькал на доли секунды. Все это крайне не существенно, и в целом не требует внимания, потому как такие действия с системой проводятся достаточно редко, и то в виде однократного нажатия "ввод+блк"...
Благодарю !!!
- - - Добавлено - - -
Доброго времени ! Спасибо за патч!
На сколько я понимаю, это первые строки кода оси ? То есть они должны быть такими 21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9 ? Я не достаточно еще в коде ориентируюсь, вставил приведенный вами код с адреса 00H и получил в целом не совсем работающюю систему. Загрузка ее из ком. строки системы показывает сразу приглашение системы "A>" и в целом все работает, заголовка в левом верхнем углу "микроДОС 3.1 Р ...." нету, и точки иногда таки выскакивают. А вот записав систему в загрузочную область загрузку не получил... Наверняка я что то не понял, куда нужно этот код встраивать ? Судя по адресам - 000H - 000С... или я ошибаюсь ?
- - - Добавлено - - -
У меня есть вопрос такого содержания. Я делал в своей программе выход в МДОС, алгоритм такой, выключаю КД, для освобождения экранной области копирую все с адреса E000H до FFFFH на адресс 5000H - 7FFFH (адресс установил опытно-наблюдательным путем), счетчик стека ставлю на 4FFFH, копирую код из адресов 0001H, 0002H, 0039H, 0040H в переменные и заменяю адресами старта приложения и обработчика прерывания, и потом при выходе все это возвращаю на место, включаю КД и делаю CALL 0005H с 00H в регистре С. Вчера доработал программу, для работы в РДС - она читает адресс системы из 0006Н, 0007H и дальше считает по этим цифрам сколько и куда копировать, и в соответствии с этим же ставит адресс указателя стека. В итоге - в РДС все отлично, огромное количество свободной памяти, а в других системах обратная реакция, для приложения остается совсем не много. В итоге, написал, чтобы если в 0006Н, 0007Н цифра меньше E000H то как предел принимается E000H. Потому что после отключения КД - c адреса, лежащего в 0006H, 0007H - нули и изредка какой то мусор, типа куски символов из консоли, которые уже были на экране, до адреса E000H, и только с этого адреса находится то, что при утере не дает вернуться систему. Пока во всех системах адресс E000H одинаково актуален, кроме РДС, там гораздо меньше, тем не менее очень интересно, есть ли в микродосе и CP/M универсальное место, где можно получить адресс того куска, который нужно скопировать из ОЗУ для того чтобы освободить экранную область, а потом восстановить работоспособность системы ? Ну или, может есть какие то альтернативные алгоритмы выхода в систему для приложений ?
Это строки, которые должны получится в памяти Вектора после старта МДОС по адресам 0000h и далее. Немного поясню, что это и как работает:
Это всего двумя командами отличается от того, что сделал ivagor в своём патче и принципиальных отличий в работе не имеет, но наложить это на файл mdos31h.com просто так не получится, надо править исходники так, чтобы при старте МДОС в память заносились эти значения.Код:21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9
^^ -- стандартно тут JMP, в первом патче менялось на RST 6, а в этом варианте меняем на LXI
^^^^^ -- это адрес перехода на МДОС, используется программами
^^ -- тут свободный байт, меняем его на LXI, чтобы отключить JMP в адресе 00005h
^^ -- а вот сюда МДОС пишет номер текущего диска, менять этот байт нельзя
^^^^^^^^ -- на самом деле тут JMP 0B600h, который вызывается по CALL 5
И далее идут команды на включение КД и переход в МДОС.
- - - Добавлено - - -
Что-то как-то всё сложно... Для выхода в МДОС достаточно сделать JMP (или RET) на нулевой адрес. Ну и не трогать в программе память от 0000h до 0100h, а также выше адреса, записанного в ячейках 0001-0002, считается, что это нижняя граница МДОС.
И при оригинальном патче (с rst) и при модифицированном видел такую штуку - иногда мигал зеленым бордюр, насчет "карты памяти" не уверен, может это были видеоэффекты залезающие не только на бордюр, но и в активную область. Вероятность таких видеоэффектов вроде была больше при скролле экрана, т.е. при многократном рестарте когда курсор уже внизу и бывает скролл. Детально не разбирался, но предполагаю, что это случается, если рестартовать во время прерывания, поправить это малой кровью вряд ли возможно. Насчет полосок на экране могу тоже предположить, что это связано с прерываниями, но с механизмом возникновения надо разбираться.
- - - Добавлено - - -
Ну и отличия реала от эмуляторов в данном вопросе вряд ли есть, тут я сомневаюсь. Скорее чуть различаются условия запуска и использования.
Программа работает со всеми четырьмя плоскостями, то есть с 8000 до FFFFH все стирается и меняется. Хотелось бы еще добавить, что программе нужен максимально прямой доступ к ОЗУ, чтобы не тормозить, по этому отключается КД чтобы избежать переадресации части озу на КД.
Так же меняются адреса в 002H, 003H и 039H, 040H чтобы при нажатии "сбр+блк" и наличии прерывания управление передавалось функциям программы. Изначально я пробовал никуда ничего не копирывать (имею в виду с E000H до FFFFH), но система после такого вмешательства не работает.
- - - Добавлено - - -
С этим вообще ничего не понятно пока, простите мне мою глупость, но вы ведь написали код,
Вот этот код как раз и есть 21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9 ...
Прошу прощения, не могли бы вы пояснить этот момент ?!?
electroscat, Improver написал то, что должно быть в работающем досе, чтобы так получилось надо поменять несколько байт в разных местах инициализатора mdos31hp2
В таком случае проще будет перезапустить МДОС через БЛК-ВВОД, например с КД, чем всё сохранять и восстанавливать. Или использовать КД с доработкой Баркаря, который позволяет подменять квазидиском все верхние 32кб памяти.
Да, это он и есть. Я написал этот код для ivagor, в его варианте сделано так: 01 03 B6 01 00 C3 00 B6 3E 23 D3 10 2A 00 01 E9.
Возможно он примет эти исправления и внесёт их в свой патч, но даже если он этого не сделает -- не страшно, на функционал mdos31hp2.com он не влияет.
- - - Добавлено - - -
Для сведения... МДОС (и РДС тоже) состоит из нескольких модулей, а именно из двух частей БСВВ (базовая система ввода-вывода) и собственно ДОС. И есть инициализатор, который раскидывает эти части в нужные участки памяти и настраивает их. И всё это собрано в один файл, который грузится и запускается с адреса 0100h. И если захотите дизассеблировать ДОС, то инициализатор -- это первое, с чем придётся столкнуться, всё остальное будет в виде массивов данных. :)
У меня это реализовано в CM.COM. В целом, добавляется пара килобайт кода, но зато и все видео озу доступно, и дос на 100% работает, правда после возврата всего на место и включения КД..... У меня есть идея написать просмотрщик картинок. На данный момент я только один нашел адекватный, но он работает только под Т34, Т35 и Е72, а хотелось бы более универсальный... В итоге, принцип такой же, при желании использовать все видео озу (для просмотрщика графики это актуально)
По другому ничего и не получится наверное. Но не понятно, как одновременно использовать и все экранное озу и возможности mDOS, такие как подгрузка файлов в озу и т.д. В общем, у меня в вязи с этим пока много пробелов. Но интересно..
Наверное нужно начинать с дизасемблирования адекватного просмотрщика и анализа его в дебагере на ос, на которых он не работает.
Насчет борьбы с иногда мелькающим при рестарте зеленым бордюром. Это явно связано с попаданием момента рестарта на программирование палитры. В патч можно добавить зануление бордюра. В более новых досах большинства этих проблем нет, там и палитру постоянно не долбят, и стек за пределами экранной области и область переходов на подпрограммы доса.
electroscat, если разрабатывается новая программа, требующая доступа ко всем экранным плоскостям или просто ко всей основной памяти, то возможно есть смысл ориентироваться на РДС, там же есть для этого специальный режим.
И вспомнил, вроде в каком-то номере байта был пример освобождения памяти от (более-менее классического, не РДС) доса с последующим восстановлением.
Да это на самом деле не имеет значения, я же писал, не в упрек, так, ради чистоты эксперимента. Даже первый патч - уже очень круто. Все работает, и если учитывать, что важен просто перезапуск системы, то результат 100% удовлетворителен, а полоски и зеленый бордюр - не значительные дополнения.
В целом, да, у меня была такая идея, но хотелось бы какой то универсальности, либо систему которая впитает в себя все самое лучшее из всех остальных, либо код, работающий на всех системах одинаково. Пока хорошо получилось второе.
- - - Добавлено - - -
Поищу, спасибо, может что то дополню еще !
electroscat, похоже я ошибался, отличия в отношении рестарта между некоторыми эмуляторами и реалом есть, хотя пока не ясно, влияет ли это на визуальные эффекты или хотя бы некоторые из них.
Прошу простить мне мою назойливость, но очень хочется понять.... Помогите пожалуйста...
Я сравнил код системы mdos31h.com с базиса и патченной системы mdos31hp2.rom от ivagor, изменения внес в таблицу:
И не могу понять вообще соответствия... Изменены байты которых нету в опубликованном вами коде, количество измененных байт разное... В общем, мне хочется верить что вы не колдуны какие то, но разум такая штука, он все что по полкам не может разложить, считает каким то колдовством :D Помогите разобраться хоть немного....
electroscat, упоминавшийся инициализатор доса распихивает байты в нужные места.
1. Базисная версия записывала F7 по адресу 0000, я заменил записываемый байт на 01 и адрес на 0003, отсюда две первые строки сравнения.
2. Раньше фрагмент кода обработки rst пересылался по адресу 0030, теперь с адреса 0008, отсюда третья строка.
3. После пересылки патча был переход по адресу 0103, теперь нужно еще кое-что сделать, поэтому переход на 02B1, отсюда 4 и 5 строки.
4. Строки 6-8 для записи байта 01 по адресу 0000.
5. Строки 9-12 для перехода по адресу 0103.
6. Последняя строка пропатчена, чтобы байт C3 не переписал 01 по адресу 0000.
Чтобы было понятнее надо трассировать в отладчике.
Спасибо за ответ !!!
То есть есть часть кода, которая формирует из загруженного массива операционную систему, так ?
И это конфигуратор, вы патчите его, чтобы он формировал систему в памяти так как нужно...
Полегчало ))) А конфигуратор, судя по всему находится с адреса 110H по 1B0H (в базисной версии) или по 1B8H в патченой, по крайней мере конфигуратор области с 0000H по 0100H.... ?
В целом, если разобрать его код, наверняка станет понятнее, буду пробовать. Благодарю за пояснение !!!
electroscat, для большего понимания (или запутывания) работы инициализатора могу привести его дизассемблированный код:
Это всё получено из файла с Базиса, большие части файла, состоящие из наборов данных (DB...) из текста я просто вырезал, их я дизассемблирвал только частично, в отличие от Т-34 и Т-72, приведённых тут ранее. При необходимости можете посмотреть и восстановить их из исходного файла mdos31h.com...mdos31h.asm
Код:ORG 00100h
L_0100: JMP L_0210
;---------------------
L_0103: LHLD L_0201 ; загрузить в HL данные с адреса L_0201 (= 2000h)
MOV B, H
MOV C, L ; в BC -- сколько
LDA 00002h ; в А из памяти с адр.00002h
SUB B ; вычесть B из А
MOV D, A
MVI E, 000h ; в DE -- куда
PUSH D
PUSH B
PUSH D
LXI H, L_0300 ; откуда
L_0115: MOV A, B
ORA C
JZ L_0122
DCX B
MOV A, M ; считать по адресу в HL
STAX D ; записать по адресу в DE
INX D
INX H
JMP L_0115
;
L_0122: POP D
POP B
PUSH H
MOV H, D
DCR H
L_0127: MOV A, B
ORA C
JZ L_0145 ; ---------->>>>>>>>
DCX B
MOV A, E
ANI 007h
JNZ L_0138
XTHL
MOV A, M ; ?????? (02300h...026FFh)
INX H
XTHL
MOV L, A
L_0138: MOV A, L
RAL
MOV L, A
JNC L_0141
LDAX D
ADD H
STAX D
L_0141: INX D
JMP L_0127
;
L_0145: POP H
RET ; ==============>>>>>>>>>>>>>>> запуск (0B500h)
; --- вырезано цензурой --------------------------------------------
L_0200: db 000h ; <_> - | | (offset 0100h)
L_0201: db 000h ; <_> - | | (offset 0101h)
db 020h ; < > - | ■ | (offset 0102h)
; --- вырезано цензурой --------------------------------------------
;
L_0210: DI
LXI SP,0100h ; стек == 0100h
LXI H, 0D00h ; сколько
LXI D, L_2700 ; откуда
LXI B, 0F300h ; куда
CALL L_02A6 ; переброска данных
CALL 0F800h ; вызов START BIOS (в т.ч. включение КД)
PUSH H ; ??? -- он и так сохранится...
MVI A, 0C0h
LXI B, 0A020h
MVI B, 0A0h ; почему не LXI B,0A020h ???
MVI C, 020h
;;; LXI B, 0A020h
L_022A: MVI D, 008h ; от HL=0EF00h до HL=0F100h
L_022C: MOV M, A ; заполняем "C0 A0...", "C1 A1...", ...
INX H
MOV M, B
INX H
DCR D
JNZ L_022C
INR A
INR B
DCR C
JNZ L_022A
POP H ; восстанавливаем HL (0EF00h)
LXI B, 00200h
DAD B ; HL = HL+DE = 0F100h
MVI A, 080h
MVI C, 000h
L_0243: MOV M, A ; от HL=0F100h до HL=0F300h
INX H ; заполняем строки "80 80 40 40 ... 01 01"
MOV M, A
INX H
RRC
DCR C
JNZ L_0243
MVI C, 01Bh ; символ очистки экрана
CALL 0F809h ;-BIOS-(вывод символа)----->>>>>>>>>>
MVI C, 045h ; установка латинской клавиатуры
CALL 0F809h ;-BIOS-(вывод символа)----->>>>>>>>>>
LXI H, 128Eh ; сколько
LXI D, L_3400 ; откуда
LXI B, 0D800h ; куда
CALL L_02A6 ; переброска данных (часть 2)
CALL L_468E ; инициализация НЖМД
LXI H, 0D500h ;
SHLD 00001h ; заносим 00 по адресу 0001 и 0D5h по адресу 0002
MVI A, 0F7h
STA 00000h ; заносим RST 6 по адресу 0000
LXI D, L_029E ; откуда
LXI B, 00030h ; куда
LXI H, 00008h ; сколько
CALL L_02A6 ; переброска данных (для RST 6)
IN 001h
ANI 040h ; нажата клавиша УС?
CZ 0D81Bh ; форматнуть КД
MVI A, 081h
OUT 004h
MVI A, 0FFh
OUT 005h
OUT 006h
MVI A, 00Dh
OUT 007h
MVI A, 0EFh
OUT 005h
MVI A, 0FFh
OUT 005h
OUT 007h
JMP L_0103
;
L_029E: db 03Eh ; <>> - | ■■■■■ | (offset 019Eh) (для RST)
db 023h ; <#> - | ■ ■■| (offset 019Fh)
db 0D3h ; <╙> - |■■ ■ ■■| (offset 01A0h)
db 010h ; <_> - | ■ | (offset 01A1h)
db 02Ah ; <*> - | ■ ■ ■ | (offset 01A2h)
db 001h ; <_> - | ■| (offset 01A3h)
db 000h ; <_> - | | (offset 01A4h)
db 0E9h ; <щ> - |■■■ ■ ■| (offset 01A5h)
;
L_02A6: LDAX D ; ПП переброски данных
STAX B
INX D
INX B
DCX H
MOV A, L
ORA H
JNZ L_02A6
RET
;
; --- вырезано цензурой --------------------------------------------
L_0300: db 021h ; <!> - | ■ ■| (offset 0200h)
; --- вырезано цензурой --------------------------------------------
L_0D00: db 00Dh ; <_> - | ■■ ■| (offset 0C00h)
db 03Ah ; <:> - | ■■■ ■ | (offset 0C01h)
; --- вырезано цензурой --------------------------------------------
db 000h ; <_> - | | (offset 21FFh)
;
db 020h ; < > - | ■ | (offset 2200h)
db 002h ; <_> - | ■ | (offset 2201h)
; --- вырезано цензурой --------------------------------------------
db 000h ; <_> - | | (offset 25FEh)
db 000h ; <_> - | | (offset 25FFh)
;
L_2700: db 000h ;(offset 2600h) BIOS >>> F300h
;==== вырезано цензурой =============================================
;
L_3400: db 0C3h ;(offset 3300h) часть 2 >>> D800h
;==== вырезано цензурой =============================================
;
L_468E: XRA A
STA 0E86Fh ; дорожка, =0
MVI A, 0FFh
STA 0E86Dh ; сектор, =-1 (FFh)
CALL 0D82Dh ; ---------->>>>>>>>>>>> грузит сектор в EB00-ED00
JNZ L_468E
LDA 0EB80h ; читает из буфера EB00-ED00 количество секторов
MOV L, A
MVI H, 000h
PUSH H ; (в стек сектора)
SHLD 0D88Dh ; -- сохр. количество секторов НЖМД
CALL L_46CD ; HL = -(HL * 10h) + 1
SHLD 0D887h ; -- патч драйвера НЖМД
POP D ; (сектора из стека)
LXI H, 00000h
LDA 0EB81h ; читает из буфера EB00-ED00 количество головок
L_46B4: DAD D
DCR A
JNZ L_46B4 ; HL = секторов * головок
SHLD 0D8FAh ; -- патч драйвера НЖМД
CALL L_46CD ; HL = -(HL * 10h) + 1
SHLD 0D8F4h ; -- патч драйвера НЖМД
LHLD 0EB84h ; читает из буфера EB00-ED00 количество дискет на НЖМД
CALL L_46D8 ; инверсия HL
DCX H
SHLD 0D920h ; -- патч на максимальное количество дискет НЖМД
RET
;
L_46CD: MVI B, 010h
XCHG
LXI H, 00000h
L_46D3: DAD D
DCR B
JNZ L_46D3
L_46D8: MOV A, H
CMA
MOV H, A
MOV A, L
CMA
MOV L, A
INX H
RET
;
END
[свернуть]
Можно еще добавить, что фрагмент с L_0122 до L_0145 адаптирует дос на рабочие адреса из "перемещаемого" формата.
Решил я поизучать тему "заворота" на жёстких дисках начиная с дискеты №42 (2Bh), на примере MDOS31H. В кратце, никаких новых результатов не было найдено, всё, что обнаружил уже обсуждалось тут в форуме, поэтому прячу под спойлер:
Ничего нового...
1. На количество секторов и количество головок НЖМД отводится по 8 бит, но в расчётах используется формула 1 - (сектора * головки)*10h с сохранением результата в 16 бит, поэтому (сектора * головки) <= 1000h (= 4096), и, соответственно, может быть, например, не больше 16 секторов Х 256 головок, 32х128, 63х65... (По стандарту НЖМД может иметь до 256 головок и до 63 секторов, головки считаются с нулевой, а сектора с первого). По последним данным, есть ограничение (секторов*головок)<256.
2. Количество цилиндров на НЖМД сохраняется в 16 битах (при положенных для стандарта CHS десяти битах), но оно особого значения не имеет и не учитывается, при обращении расчёты ведутся по количеству дискет, секторам и головкам.
3. В БДОС применяется сквозная нумерация секторов (почти как LBA), для этого используется 24 бита, и это даёт максимальный размер диска 8 Гб (при размере сектора 512 байт), после этой границы будет "заворот".
4. Размер дискеты равен 622h (= 1570) секторов, смещение первой на +2 сектора. Первые 8 дорожек дискеты НЖМД системные (8*10 секторов * 512байт = 40960 байт), эта область одна для всех дискет на НЖМД.
5. Максимальное количество целых дискет исходя из п.3 и 4 равно 29BEh = 10686, что укладывается в отведённые 16 бит для хранения их числа, нераспределённый остаток в конце диска до границы в 8 Гб равен 57 секторов или 29184 байта.
6. Обращение к диску в МДОС осуществляется по номеру дорожки и номеру сектора, на оба значения отводится по 8 бит, отсюда ограничение теоретического максимального размера дискеты будет 256*256*128 (размер сектора в МДОС) и равно 8Мб, практически же МДОС видит дискету 164 дорожки * 40 секторов * 128 байт = 839 680 байт.
7. При обращении к НЖМД в БДОС читаются/пишутся по два сектора диска (2*512=1024 байта), что соответствует восьми секторам МДОС (МДОС понимает один размер сектора, 128 байт). БДОС при последовательном чтении копирует данные из буфера в 1кБайт в буфер дисковых операций. При изменении на НЖМД запись данных производится также в размере двух секторов, даже если один из секторов не изменялся.
8. БСВВ (БДОС) выполняется перерасчёт данных полученных от МДОС: лог.номер сектора = 10 * дорожка + 2 * (сектор - 1)/8, что соответствует дискете на 820 кб. Результат сохраняется в 16 бит и потом суммируется с начальным номером сектора дискеты в 24 бит.
9. Максимальное значение дорожки, получаемое БДОС от МикроДОС равно 164 (A4h), при большем значении БДОС возвращает ошибку. Исключение -- можно считать с НЖМД дорожку 0FFh (это нулевой цилиндр с записанной при инициализации конфигурацией).[свернуть]
В общем, могу резюмировать, что никаких особых багов на эту тему в MDOS31H не выявил, диски до 8Гб включительно должны там работать без "заворотов". Есть только предположение, что глюк с "заворотом" может возникать, если прерывание прилетит точно в момент расчёта и передачи на НЖМД номера цилиндра по "OUT 055h" - "OUT 054h", из-за чего там будет большой разрыв по времени и старшие биты обнулятся. Либо, как предполагал ранее, некоторые программы обращаются к функциям БДОС напрямую, при этом сами имеют такой баг.-- Баг найден.
Но есть и положительные моменты, в ходе разборок с НЖМД собрал версию МикроДОС Т-72 с драйвером жёсткого диска, вот архив с новой версией и исходниками, Т-72h: Вложение 72071
Отличия от предыдущей версии:
- Добавлена команда "9" -- выбор дискеты жёсткого диска (работает аналогично mdos31h).
- Из-за нехватки памяти убран драйвер для флоповодов (думаю, его следует вернуть, но для этого понадобится немного подвинуть МДОС, да и сам драйвер надо будет немного переделать). Сейчас при обращении к флопикам просто выдаётся ошибка.
Добавленный драйвер НЖМД, по сравнению с mdos31h, существенно переработан, а именно:
- Добавил запрет прерываний на время записи конфигурации НЖМД, посмотрим, как устранит это глюк с заворотом...
- Размер буфера драйвера уменьшил до одного физического сектора НЖМД, т.е. до 512 Байт.
- Исправил проблему с линией "RESET" на IDE, из-за чего приходилось отключать вывод 1 у жёсткого диска. Теперь тормозов нет, даже если он подключён.
Погонял новую версию МДОСа на эмуляторе и на своём реальном Векторе, работает хорошо и с одним, и с двумя квази-дисками. :-) В новой версии по тестам копирование файлов с одной дискеты НЖМД на другую выполняется раза в полтора быстрее, замерял и по тактам (в эмуляторе), и по времени. Единственный ньюанс: программа FDIR не работает, подвисает до сброса. Надо будет как-нибудь сделать ей замену, уж больно глючна...
Improver, это здорово, но пока проблема с заворотом осталась, по крайней мере у меня. До дискеты 2A включительно все нормально, начиная с 2B - заворот.
Может что-то с параметрами hdd, вот строка из конфига emu
drive[0].geometry=255C16H18S
Или проблема с командой 1 доса, которой я пишу файл
Еще попробовал скопировать файл POWERом - тоже заворот
И всё-таки проблема с геометрией, конкретно с головками-секторами, т.к. на моих дисках глюка нет. Копаем дальше. :)
- - - Добавлено - - -
Обращение к диску идёт по CHS, просто расчёты ведутся по методу, похожему на LBA. Основное отличие от последнего в битности, LBA использует 28 бит, а Вектор -- 24.
- - - Добавлено - - -
С такой геометрией даже команда "D" даёт заворот.
Насколько я понял код "патча", количество секторов/головок читается из загрузочного сектора (по смещению 80h/81h). То есть параметр в конфиге должен соответствовать образу, т.к. используется CHS. Максимальный номер флоппи-образа должен зависеть от количества дорожек в параметре конфига. Однако природа "заворота" мне до сих пор не ясна.
Заинтересовал код расчёта номера сектора:
Он везде такой или только у Improver-а?Код:LXI H, 0F3BEh ; = 2 - 0622h * 2
MVI A, 0FFh
INX B
LaD96A: LXI D, 00622h ; суммарное количество секторов на одной дискете
DAD D
ACI 000h
DCX B
MOV D, A
MOV A, B
ORA C
MOV A, D
JNZ LaD96A
- - - Добавлено - - -
Вот выкинуть бы всё похожее и сделать нормальные процедуры умножения/деления.
- - - Добавлено - - -
Я так полагаю, кто-то захотел больше 255 образов на винте, но сделал это криво.
В mdos31h так, в rds не так (как в rds - надо искать)
- - - Добавлено - - -
В РДС3 с моей геометрией тоже заворот на дискете 2B (копировал файл POWERом, на 2A заворота нет).
- - - Добавлено - - -
Оказывается в РДС3 практически аналогичный фрагмент, только поменяли ролями DE и BC, поэтому по сигнатуре я сразу не нашел
А если сделать DCR C и выкинуть модификацию D, то заворот останется?
Но указанный фрагмент вроде работает правильно, проблема где-то еще
В общем, пробемка с расчётом номера цилиндра, на дискете 2B вместо "00E4h" получаем "0001h". Возможно есть ограничение (головок*секторов)<256, но это не точно, завтра продолжу поиски...