Т.е. программа в памяти CPU в этом месте ожидает, что ей PPU передаст адрес блока /загруженного с дисковода?/, а PPU ей его не передает?Сообщение от Alex_K
Т.е. программа в памяти CPU в этом месте ожидает, что ей PPU передаст адрес блока /загруженного с дисковода?/, а PPU ей его не передает?
В этом месте программа в ЦП строит блок параметров для работы с дисководом и передает через канал 2 адрес ентого блока ПП. А он (ПП то есть) уже считывает по этому адресу блок себе, разбирает его и выполняет соответствующее задание. Потом в младший байт первого слова блока передается ответ.
Все описано в книге "Работа с внешними устройствами", да и листинги ПЗУ помогут.
Мне бы ссылку на то, и на это)
Судя по всему, это совсем стандартный драйвер. Тогда еще страннее, что именно в этих играх он глючит.
---------- Post added at 01:48 ---------- Previous post was at 00:32 ----------
Приделал сниффер к этой функции на предмет того, чего она должна отправлять.
Как видно, и меню, и все игры, выглядят в виде одинаковых дампов памяти размером 0x6100. Загрузка игры происходит успешно, а потом что-то вешается и опять уходим в загрузчик меню. Но проблема явно не в загрузчике судя по всему, т.к. он не работает уже после какой-то иной внештатной ситуации.Код:Packet to source-2: 0801, 8002, 0402, 0400, 6100 Loading OKAY! Команда чтения, сторона 1, сектор 4, трек 2, адрес ЦП 0x400, загружать 0x6100 слово Меню загружено успешно Переходим к загрузке игры Lode Runner: Packet to source-2: 0801, 8002, 041D, 0400, 6100 Loading OKAY! Команда чтения, сторона 1, сектор 4, трек 29, адрес ЦП 0x400, загружать 0x6100 слово. Игра загружена успешно Write 0001 at ADRSP_CON at location PC = 0xAB56 Первое ругательство драйвера кассеты ПЗУ Packet to source-2: 0801, 8002, 0402, 0400, 6100 Loading error! Response 0x01, instead 0x00 Как видно, попытка грузить опять меню, но загрузка не проходит, т.к. PPU уже не отвечает правильным образом. Write 0001 at ADRSP_CON at location PC = 0xAB56 Packet to source-2: 0801, 8002, 0402, 0400, 6100 И так по кругу.
Примерно добрался до туда, где зависает.
Значит загружается Lode Runner корректно, затем делает всякие свои действия, а потом хочет загрузить еще фрагмент уже самостоятельно. Подготавливает корректный блок данных для загрузки с дисковода, и оптравляет его в канал-2 функцией с адресом 27064. Все данные корректно считываются программой обработчиком прерываний в PPU (а именно, адрес массива и заглушка 0xFF, вторая 0xFF не считывается, чтобы канал-2 побыл пока занятым для CPU). Значит все считывается в буфер 23200, устанавливается флаг на 7062, сигнализирующий о том, что считали данные в буфер, а затем программа ППУ возвращается к тому месту, где была прервана.
Но если в тех случаях, когда все грузилось нормально, основная программа была примерно такая:
174206 4770 165150 JSR @-$12630(R0)
--> переход на 111144, где чуть дальше проверяется 7062, и идет всякая обработка,
то в случае с Lode Runner'ом, после
174206 4770 165150 JSR @-$12630(R0)
--> переход на 125030, где какая-то другая программа, которая совсем не хочет проверять 7062, и программа успешно повисает.
Вот пока до куда примерно я дошел.
Titus, еще раз БОЛЬШАЯ ПРОСЬБА писать все адреса и данные в восьмеричной форме, листинги ПЗУ все в восьмеричных адресах, а то переводить приходится.
Сами листинги находятся здесь. В шестой части по адресу 175762 находится обработчик прерываний от канала 2. В ячейке 23200 содержится принятый адрес, а в 23202 - счетчик принятых байтов. После того как принят четвертый байт, устанавливается флаг вызова в ячейке 7062. А далее уже диспетчер процессов вызывает обработчик массива параметров канала 2 по адресу 125030.
Обработчик массива параметров преобразует адрес для загрузки в регистр адреса планов и читает из массива параметров байт со смещением 2 (смещение 1 в формате адреса планов). Биты с 7 по 3 содержат код устройства. Если он больше 3, то идем на кассету ПЗУ, а если это дисковод (код 0), а контроллер отсутствует (7044 меньше нуля), то также на кассету ПЗУ.
Так что сниффер надо ставить на адрес 125030, и уже смотреть, что в ячейке 23200, это и есть адрес массива параметров.
Еще все дело в том, что драйвер на диске ITO90 не ждет чтения четвертого байта драйвером канала 2. Он просто ложит в байт ошибки единицу и ждет очищения этого байта, если он не очистился, то ошибка.
---------- Post added at 11:14 ---------- Previous post was at 11:04 ----------
А судя по всему где-то происходит сбой в подсчете принятых байтов, в 23200 оказывается "левый" адрес, читается совершенно другое, естественно прочитанный код устройства не укладывается в рамки 0-3, ну и обращаемся к кассете ПЗУ. Так что надо капитально проверить работу канала 2, как в режиме опроса флагов, так и прерываний.
Alex K, ты немножко невнимательно читаешь то, что я написал.
Драйвер загрузчика игр ITO90 действительно не ждет четвертого байта. Но этот драйвер работает нормально. А вот уже драйвер загрузчика ВНУТРИ самих игр (в частности Lode Runner'а), работает иначе. Он ждет четвертый байт.
Далее, сбой счетчиков байтов происходит, но он происходит не из-за сбоев работы канала-2, т.к. это все проверено, канал-2 действительно правильно получает все байты адреса и правильно складывает их в буфер. А вот уже сам диспетчер НЕ вызывается, и обработчик массива по адресу 125030 тоже. Или же вызывается как-то криво. Из-за этого и происходит сбой счетчика байтов, после чего все окривевает.
p.s.: Я уж и так стараюсь все переводить в восьмеричный вид, когда выкладываю на форум. А у меня все в шестнадцатиричном, т.к. восьмиричную систему я не воспринимаю)
---------- Post added at 14:53 ---------- Previous post was at 14:22 ----------
Кажется нашел глюк, буду проверять)
Фух, наконец-то нашел глюк и исправил.
Все было связано с битами разрешения прерываний PPU от приемников 0,1,2. Они и так там хитрые, из-за чего одно время не работала игра Saper. Оказалось, что не учел одну особенность, и это вылезло в играх от ITO. Теперь, надеюсь, все будет работать, и другие программы не окривеют. Если кто знает программы, критично относящиеся к правильности устройства каналов 0,1,2 - сообщите.
Так же добавил бит определения типа дисковода, благодаря чему теперь головки в дисководе на всех системах перемещаются быстро (спасибо Alex_K).
Плюс ко всему прочему, теперь второй диск тоже грузится по умолчанию под именем Work.dsk (по просьбе трудящихся).
Смотрите обновленную версию в первом посте.
Titus, сорри, но я внимательно читаю. И расписал алгоритм работы драйвера канала 2, из-за чего это может происходить. Пришлось так анализировать, т.к. встроенного отладчика нет, исходники недоступны, поэтому я и расписал ситуацию, из-за чего вызывается драйвер кассеты ПЗУ.
Очень рад, что ошибка нашлась. А поподробнее можно узнать, если это не секрет.
Диск с JEK-ом от группы KUARKO не грузится. Там в ПП загружается модуль KUARKO.SAV, который фактически заменяет собой системное ПЗУ. Ну и на этапе загрузки подвисает. Там кстати текущим диском назначается MZ1, поэтому лучше грузить с первого привода, или после успешной загрузки с нулевого дать команду DEA DK.
Не секрет. При обновлении регистра состояния приемников 177066, при каждой записи анализировалось, что если И бит разрешения прерывания, И бит готовности канала установлены, то устанавливался запрос на прерывание. Это неверно, т.к. при любой записи в этот регистр происходил повторный взвод запроса на прерывание, если оба бита были в 1. Теперь сделал все тоже самое, но запрос на прерывание устанавливается только если при записи в конкретные биты разрешения прерывания был переход 0->1. Если же было 1->1, то запрос прерывания заново не устанавливается.
А jek не использует ловушку? У меня она не реализована.
Это верно только для канала 0 со стороны ЦП. А для каналов 1 и 2 и 0 со стороны ПП немного по другому, я это описывал. UKNCBTL так же подвисал. В исходниках можно глянуть алгоритм работы.
Нет, не использует, насчет этого можете не беспокоится. С ловушкой работает драйвер GD, который выкладывал Vamos, JEK кстати тоже от него. У меня тоже есть JEK, дискета сделана чуть по другому, но зависает также.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)
Ваши права
Ответить с цитированием