Может внимательнее посмотреть на дешифратор этого адреса, может он срабатывает ещё и на другие адреса или обращение к памяти... ну что-то в этом духе...Цитата:
Сообщение от Saar
Вид для печати
Может внимательнее посмотреть на дешифратор этого адреса, может он срабатывает ещё и на другие адреса или обращение к памяти... ну что-то в этом духе...Цитата:
Сообщение от Saar
Короче, картина немного другая вырисовывается:
Поменял загрузчик на 512 байтный, который не умеет грузиться с FDC. И демка стала работать.
Но от этого яснее не стало.
Как загрузчик может влиять на дальнейшую работу программы?
Может я что-то упускаю при инициализации?
- - - Добавлено - - -
блин... ерунда какая-то..
После некоторых игр демка запускается даже при включенном FDC (в моем эмуляторе можно загрузить и запустить ROM во время работы без выхода в ПЗУ загрузчика).
Где-то что-то не ресетится правильно. Но при этом я не могу понять каким образом FDC влияет на прогу, его не использующую. У FDC нет DMA и он никак не вмешивается в работу если не опрашивать его регистры и не записывать в них...
При этом другие программы работают...
Не исключено, что M/COLOR просто читает из этого порта, думая, что там будет $FF.
Я думаю, что проблема в другом. Я экспериментально выяснил, что для загрузчика достаточно только запись и чтение регистра сектора (0x19) чтобы определить наличие FDC и вывести изображение дискеты.
Думаю, это активирует какие-то настройки в других устройствах, которые и воздействуют на демку. Думал, что может быть таймер - но его полное отключение не изменило ситуацию. То, что с 512 байтным загрузчиком без поддержки FDC (с с его наличием) не создает проблемы mcolor - как бы указывает что FDC не является непосредственной причиной а лишь триггером каких-то скрытых изменений.
Значит надо копать загрузчик и смотреть что там происходит при наличии FDC.
Нет ли где дизассемблированного с комментариями стандартного 2КБ загрузчика?
Кстати, помнится я высказывал предположение, что загрузчик прописывает JMP 100 в нулевой адрес, но было высказано сомнение в этом.
Код:seg000:02B8 ld a, 0C3h
seg000:02BA ld (sub_0), a
seg000:02BD ld hl, 100h
seg000:02C0 ld (sub_0+1), hl
Зачем Тимошенко Александр (aka TIMSoft) это сделал не совсем понятно, поскольку это не совсем корректно.Цитата:
Сообщение от Saar
Он предположил, сто Ось всегда будет грузиться с адреса 100h, но это не совсем так.
Утилита записи на системные дорожки даёт возможность указать начальный адрес загружаемой программы, и он может быть любой (с шагом 100h) и этот адрес записывается в служебную область дискеты. Нормальный загрузчик читает эти данные и использует их по назначению.
Соответственно установка в "нулевой" адрес команды перехода, в общем случае лишняя примочка, и указывает на НЕ универсальность данного загрузчика с дискеты.
Насколько я понимаю, автор 512 - Темиразов, 2048 - Соколов и Темиразов. Tim0xA дизассемблировал 2048, а 512 вероятно дизасмил Михаил Таланов
Вот блин, а я мучился не мог понять, почему в эмуляторах с образа дискеты ОСь не грузится с нулевого адреса...
Когда я это указываю в образе дискеты.
А в них используется загрузчик 32К с аналогичными "заглушками"... :(
Saar, спасибо за инфу, буду знать/учитывать...
правильно ли я понимаю, что если дискеты нет в дисководе, то загрузчик зацикливается в этом месте?
- - - Добавлено - - -Код:RAM:043F ld a, (word_DED0)
RAM:0442 out (1Ch), a
RAM:0444 in a, (1Bh)
RAM:0446 rlca
RAM:0447 ret nc
RAM:0448 jp sub_43F
KTSerg,
тот кусок был из другого загрузчика (zagr512), из эмулятора svofski. Он по внутренностям отличается от того что дал ivagor в котором нет данной конструкции.
- - - Добавлено - - -
Охренеть! Проблема в PPI2 (USER PPI). Если загрузчик находит FDC то он не инициализирует PPI2 и mdemo глючит. Если FDC загрузчик не находит (или держать F2) то PPI2 инициализируется и mdemo работает.
Вот как в той истории "корова пёрнула - рога отвалились". Причем тут PPI2 - непонятно.