Т.е. программа в памяти CPU в этом месте ожидает, что ей PPU передаст адрес блока /загруженного с дисковода?/, а PPU ей его не передает?Цитата:
Сообщение от Alex_K
Вид для печати
Т.е. программа в памяти CPU в этом месте ожидает, что ей PPU передаст адрес блока /загруженного с дисковода?/, а PPU ей его не передает?Цитата:
Сообщение от Alex_K
В этом месте программа в ЦП строит блок параметров для работы с дисководом и передает через канал 2 адрес ентого блока ПП. А он (ПП то есть) уже считывает по этому адресу блок себе, разбирает его и выполняет соответствующее задание. Потом в младший байт первого слова блока передается ответ.Цитата:
Сообщение от Titus
Все описано в книге "Работа с внешними устройствами", да и листинги ПЗУ помогут.
Мне бы ссылку на то, и на это)Цитата:
Сообщение от Alex_K
Судя по всему, это совсем стандартный драйвер. Тогда еще страннее, что именно в этих играх он глючит.
---------- 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, то запрос прерывания заново не устанавливается.Цитата:
Сообщение от Alex_K
А jek не использует ловушку? У меня она не реализована.
Это верно только для канала 0 со стороны ЦП. А для каналов 1 и 2 и 0 со стороны ПП немного по другому, я это описывал. UKNCBTL так же подвисал. В исходниках можно глянуть алгоритм работы.Цитата:
Сообщение от Titus
Нет, не использует, насчет этого можете не беспокоится. С ловушкой работает драйвер GD, который выкладывал Vamos, JEK кстати тоже от него. У меня тоже есть JEK, дискета сделана чуть по другому, но зависает также.Цитата:
Сообщение от Titus
Если у меня не верно, почему тогда все работает?Цитата:
Сообщение от Alex_K
JEK - это что за программа?
При запуске спрашивает ввод чего-то.
---------- Post added at 19:36 ---------- Previous post was at 19:34 ----------
Что такое DEA? Я знаю только ASS.
Просто на эти особенности натыкается модуль KUARKO. Эта особенность возникает, если произошло прерывание от канала, а байт данных не был прочитан/записан.Цитата:
Сообщение от Titus
Графический редактор.Цитата:
Сообщение от Titus
DEA - сокращенно от DEASSIGN. ASSIGN назначает логическое имя, DEASSIGN отменяет его. Соответственно DEASSIGN DK возвращает DK равное SY.Цитата:
Сообщение от Titus
Посмотрю тогда.Цитата:
Сообщение от Alex_K
Интересно, зачем сделали разный алгоритм работы каналов.
Я думаю первоначально алгоритм работы каналов был везде одинаковый. Но с таким алгоритмом RT-11 точно работать не будет (имеется ввиду регистры терминала). Потом видно и переделали. Но вот почему не для всех каналов - для меня большой вопрос. Потому что последовательный порт на 1801ВП1-065 работает нормально, т.к. логически и надо, когда идет переход с 0->1.Цитата:
Сообщение от Titus
Пытался посмотреть в UKNCBTL Road Fighter с диска ITO91, т.к. у меня там в игре присутствует мерцающий байтик, хотел сравнить так же в UKNCBTL или нет. В итоге вообще не смог внятно запустить эту игру. Максимум доходит до заставки, а то и до нее не доходит, повисает. Эмуль от 2.10.2011. Кстати, у меня она тоже через раз запускается, виснет на заставке.
Короче, выяснил такую закономерность. В версии UKNCBTL от 2.10.2011 до заставки вообще не доходит, а в версии от 28 июля 2010 работает как и у меня, через раз запускаясь, и мерцающий байт в самой игре на дороге присутствует.
Да запускается все в UKNCBTL, может правда иногда дисковод подвиснуть, но передергиваешь дискету и все нормально.
А что это за мерцающий байт?
В версии от 2 октября 2011 не запускается у меня.Цитата:
Сообщение от Alex_K
Сделай черно-белый режим, в нем лучше видно. Ехай по дороге, и увидишь его, он будет померцивать.
Есть более поздние версии. Кстати в EmuStudio тоже иногда на заставке виснет.Цитата:
Сообщение от Titus
Да, такое и заметишь не сразу. Интересно, а как на реале?Цитата:
Сообщение от Titus
Да, у меня тоже через раз на заставке виснет.Цитата:
Сообщение от Alex_K
На реале не смотрел.
Кстати, раз такой эффект в обоих эмуляторах, то я думаю, что нормально. Ведь изображение в этой игре не двигают, на УКНЦ это слишком муторно и медленно. Перелопачивают скорее всего таблицу описания видеострок, ну где-то чего-то не учли ...
Titus, будет ли поддержка винта реального ?
Понимаю,что прошу слишком много но вдруг у автора будет возвышенное вдохновение и не чем будет заняться - мячты;)
Реального? Это в виде железки или образа?Цитата:
Сообщение от Mad Killer/PG
Может всё таки стоит сделать образ (считать её) для архива ?Цитата:
Сообщение от Alex_K
Hobot, не нашел еще игр, которые глючат в эмуляторе?
А зачем? Есть же уже в архиве диски U1.DSK и U2.DSK.Цитата:
Сообщение от hobot
Обе позиции в опросе не участвуют;)?Цитата:
Сообщение от Titus
Лично мне железный хард вообще не нужен для подключения к эмулятору. Софтварный тоже пока особо не зачем, есть же дискетки.Цитата:
Сообщение от Mad Killer/PG
Тогда к ним нужно подробное описание, у меня в UKNCBTL с ними ничего не получается + они читаются через раз, глюк с загрузкой - это раз, второй моментЦитата:
Сообщение от Alex_K
как редактор запускать? И иметь "немного другую" копию в архиве, почему нет? )))
Пока нет, но отпишу если попадутся, с Таблицей рекордов в некоторых игрушках(ИТО) - это глюк такой "ломаной" версии игропакетов (скорее всего), то есть когда делал gif файлыЦитата:
Сообщение от Titus
http://savepic.net/2291933.gif
http://savepic.net/2292957.gif
- нужны были кадры разных стадий игр, тогда и обнаружилось что у некоторых игр вылетает "Стоп" при попытке отобразить Таблицу, а у некоторых всё норм, титры также не у всех игр удалось посмотреть, поэтому эти моменты и не вошли в анимацию. Я тут копаюсь в "странных" образах - которые эмулируют КЦГД для УКНЦ и тут есть ссылка на игры под КЦГД - вот этот момент и изучаю сейчас, самих файлов с этими играми в образах нет, только в тексте описание. LANDR - я гляжу добавился это хорошо )))
Сейчас версию EmuStudio в архиве обновлю - только я ITO диск там уберу из архива, поскольку если добавлять ИМХО:надо оба, а так они же есть в хламнике - легко ищутся теперь )))
--------------------------------------------------
Другой момент честных версий нет, вот это плохо.(!) Но (наверное) честные не считаешь и работать будут только на реале и сетевых версий то же нет, а ведь реальные дискеты у кого-то должны быть? :confused_std:
Да, у меня тоже какая-то игра вылетела в стоп после игры.Цитата:
Сообщение от hobot
Сомневаюсь, что можно эмулировать КЦГД для УКНЦ. У КЦГД в ширину до 800 точек, например. И цветов больше.
http://zx.pk.ru/showpost.php?p=447211&postcount=201Цитата:
Сообщение от Titus
Я ничего не утверждаю, я похожий образ нашёл в другом источнике, с другой документацией и другими описаниями - вот и читаю сам пытаюсь понять как это
всё должно было работать по замыслу "гениев-создателей" )))
---------- Post added at 01:16 ---------- Previous post was at 01:15 ----------
Понимаю так - хотели полностью заменить ( и в живой сетке наверное ) УКНЦшкой ДВКа машины !!! Дешево и сердито !!! )))
Выкладывай)Цитата:
Сообщение от hobot
Давно уже в сети и тебе очень давно я просил(рекомендовал) к изучению раздел HD1 из этого архиваЦитата:
Сообщение от Titus
где ИМХО:очень много по теме данной интересного, но тогда я ещё
не знал про твой эмулятор и про его способности(видео-гибрида), теперь это ещё интересней стало.
Кстати, этот эмулятор VT200 на моем эмуле не запускается)
почему и попал под пристальное внимание архивариуса )))))))))))))))))))))))Цитата:
Сообщение от Titus
---------- Post added at 01:31 ---------- Previous post was at 01:30 ----------
Но hd1 из архива (который в хламнике) интереснее в разы !!!!!! Там похоже сам дистрибутив всей этой поделки )))
Вот это место поподробней расписать можно?Цитата:
Сообщение от Alex_K
Сейчас у меня сделано так:
Со стороны ПП:
Приемники 0, 1, 2:
Запрос на прерывание снимается при:
1. Чтении регистра данных приемника
2. При сбросе РП в 0.
3. При совершении прерывания
4. (наверно неправильно, но пока есть) при сбросе бита БГ в регистре 177066
Запрос на прерывание устанавливается при:
1. Записи в регистр данных со стороны ЦП в источник при РП = 1.
2. При переходе РП 0->1, и уже установленном БГ = 1.
3. (наверное неправильно, но пока есть) при записи в регистр 177066 в бит БГ 0->1 при установленном РП.
Источники 0, 1:
Запрос на прерывание снимается при:
1. При совершении прерывания
Запрос на прерывание устанавливается при:
1. Чтении регистра данных приемника со стороны ЦП, при РП = 1.
2. (наверное неверно) Если при записи в 177076 (БГ .AND. РП) = 1. (БГ можно писать!)
Со стороны ЦП:
Источники 0, 1, 2:
Запрос на прерывание снимается при:
1. При совершении прерывания
Запрос на прерывание устанавливается при:
1. Чтении регистра данных приемника со стороны ПП, при РП = 1.
2. При записи в регистр состояния источника РП = 1, при установленнном БГ = 1.
Приемники 0, 1:
Запрос на прерывание снимается при:
1. При совершении прерывания
Запрос на прерывание устанавливается при:
1. Записи в регистр данных источника со стороны ПП при установленном РП = 1.
2. При записи в регистр состояния приемника РП = 1, при установленнном БГ = 1.
Пока никто не отвечает, задам еще несколько вопросов.
1. Что делает 6-й разряд в регистре 177066? Написано 'разрешение прерывания по команде RESET на магистрали ЦП'. Что это означает? Какое прерывание, где, зачем?
2. 2-й разряд в регистре 177076. "Выключение регистров канала-0 из адресного пространства ЦП". Как это работает и зачем это нужно?
Да уж в этой теме ранее вопрос поднимался, я описывал принцип. В каком-то другом топике тоже. Неохота десять раз одно и тоже писать. Есть исходники UKNCBTL, там же все посмотреть можно (файл Board.cpp).Цитата:
Сообщение от Titus
Плюс к тому же рабочая неделя началась, уже времени на общение меньше.
Программа в ЦП дает команду RESET, процессор по этой команде на шину выставляет INIT. Так вот этот INIT идет соответственно и на 1801ВП1-120. Регистры со стороны ЦП сбрасываются, а со стороны ПП возникает запрос на прерывание при установленном 6-м разряде 177066.Цитата:
Сообщение от Titus
Это значит, что при обращении к адресам 177560-177567 происходит TRAP4, т.е. регистры исчезают из адресного пространства ЦП. Но в UKNCBTL это пока не сделано, есть тонкий вопрос: если для приемника разрешили прерывание, в ПП запретили эти регистры, а со стороны ПП в источник канала 0 записали значение. Возникнет ли прерывание?Цитата:
Сообщение от Titus
---------- Post added at 18:54 ---------- Previous post was at 18:52 ----------
Еще вдобавок: биты готовности можно только читать, писать их нельзя.
Насколько я понимаю - чтение и запись регистра данных влияют на установку прерывания через сигнал готовности.
Поэтому, есть смысл полностью забыть про чтение/запись регистра данных и говорить только про состояние сигнала (бита) готовности.
В портах "в стиле ДВК" запрос прерывания устанавливается при установке логического произведения (операция AND) битов БГ и РП в 1 и сбрасывается при обнулении этого произведения (а также при передаче вектора и при сбросе шины сигналом INIT).
В портах "в стиле УКНЦ" (насклько я понял) бит готовности влияет на формирование запроса прерывания не напрямую, а через "промежуточный бит" ПБ.
Правила при этом таковы:
1. Если БГ устанавливается - ПБ устанавливается.
2. Если БГ сбрасывается - ПБ сбрасывается.
3. Запрос прерывания выдаётся по AND ПБ и РП.
4. При передаче вектора ПБ сбрасывается.
Вся хитрость (и единственное отличие) здесь в том, что после передачи вектора - бит ПБ сбрасывается.
Поэтому, даже если бит БГ остался равен 1 - новый запрос прерывания станет возможен только тогда, когда бит ПБ будет установлен в 1 (а для этого бит БГ должен "передёрнуться" 1-0-1).
Кстати о прерываниях. В другой теме - не помню в которой, написал здесь - помнится недавно говорилось, что при разрешении прерывания в 177564, оно будет лупить пока не запретить. Ради интереса проверил: ни на одном из имеющихся в моем распоряжении DL-подобных устройств прерывание не повторяется - то есть происходит одно прерывание и все. Следующее не происходит если не было записи в 177566.Цитата:
Сообщение от Patron
"Внеочередное" прерывание произойдёт, если выполнить последовательность команд:Цитата:
Сообщение от form
Ни одна из этих команд не пишет в 177566.Код:BiC #100, @#177564
BiS #100, @#177564