Просмотр полной версии : IM2, вектор прерывания
Я тут вот с какой проблемой столкнулся. В литературе говорится, что на фирменном Спектруме48 вектор прерывания I должен находится в районе адресов ПЗУ, иначе произойдёт аппаратный сбой. Но у некоторых отечественных Спектрумов нестабильная шина данных, поэтому в ОЗУ создается таблица длиной 257 байт. Конечно, можно было бы использовать таблицу в свободном месте ПЗУ (где #FF), но на многих компах оно занято всякой фигнёй. Как же обеспечить нормальную работу IM2 на любом компьютере?
сгенерировать таблицу 257 одинаковых байт в районе адресов #8000-#BFFF (до #FFFF если используется 48к и страница 0). причем значения таблицы - векторы могут находиться хоть где.
Я тут вот с какой проблемой столкнулся. В литературе говорится, что на фирменном Спектруме48 вектор прерывания I должен находится в районе адресов ПЗУ, иначе произойдёт аппаратный сбой. Но у некоторых отечественных Спектрумов нестабильная шина данных, поэтому в ОЗУ создается таблица длиной 257 байт. Конечно, можно было бы использовать таблицу в свободном месте ПЗУ (где #FF), но на многих компах оно занято всякой фигнёй. Как же обеспечить нормальную работу IM2 на любом компьютере?
У меня фирменный Speccy 128+Beta, в котором нет проблем с плаванием вектора I. Вообще-то за всю жизнь я видел 3+5=7 фирменных моделей. Первые три, один из них мой, были произведены в Польше, остальные пять были в компьютерном клубе и где их собрали мне не известно. Все модели я тестировал на этот глюк и его небыло.
Однако, речь шла о нахождении регистра I в диапазоне от 0 до 63, но IM при этом не 2 а 1 ! Сколько я не капался в буржуйских работах, я не видел, что бы вектором I при IM2 пользовались ПЗУшкой, за исключением польской демы "Song In Lines". Рекомендуется в 48к модели держать вектор в любом диапазоне, кроме от 64 до 127. Иначе в момент выборки байт для генерации видео любая команда будет исполняться с торможением, и это ощутимо. А если ещё при этом всём и исполнять программу в диапазоне от 16384 до 32767, то торможения могут быть в 5-6 раз. А это строгое правило, затирать 257 байт одним числом, я встречал только у Durrel Software, но так же они при чтении регистра порта клавиатуры они их любили инвертировать, это то же считать стандартом ? Мне кажется, что эти недаработки с глюком вектора пошли от клонов Speccy !
я видел 3+5=7 фирменных моделей
5! да, это 5! %))))
ЗЫ. Юзаш табличку в те же 257 байт и забываешь о нестабильной шине.
5! да, это 5! %))))
Ссори ... Просчитался ...
ЗЫ. Юзаш табличку в те же 257 байт и забываешь о нестабильной шине.
Терять 254 байта ? Не отдам !!! Я лучше туда депакер положу !
Я разработал новый способ чтения порта DOS #1F через прерывания. Если бы не наши клоны с нестабильной шиной данных, то это была бы самая короткая процедура чтения порта #1F:
IN1F LD BC,(#5BFF)
LD HL,INT
LD (#5BFF),HL
LD A,#5B
LD I,A
IM 2
LD (COPYSP+1),SP
LD A,#FF
AGAIN LD D,1
LD IY,#2D87
EI
CALL DOS
INT DI
COPYSP LD SP,0
BIT 7,A
JR NZ,AGAIN
LD (#5BFF),BC
***
DOS PUSH IY
JP #3D2F
***
#2d87 IN A,(#1F)
AND #7F
RET Z
DEC D
PUSH HL
PUSH DE
JR NZ,#2D7B
HALT
Терять 254 байта ? Не отдам !!! Я лучше туда депакер положу !
Если шина стабильная, то можно выловить значение вектора прерывания и делать перехватчик по вполне определенному адресу. А вот если ее значение скачет как сайгак по степи, то тут без таблички ну никак... разве что юзать пзу128 и подменять свой обработчик im1...
Я разработал новый способ чтения порта DOS #1F через прерывания. Если бы не наши клоны с нестабильной шиной данных, то это была бы самая короткая процедура чтения порта #1F:
У наших "клоунов" подтянуть шину через регистерную сборку - фиксит трабл.
Но лучше не зарекаться и сделать таблицу.
Умня был пентагон, который работал следующим образом:
Если 257 байт заполенены - то все ок
Если им2 есть, но таблица какаянибудь другая - программа обычно работала,
но в любой момент она могла сброситься - сопственно несколько лет до
этого не мог понять почему некоторые проги робили стабильно, а некоторые сбрасывались рано или позно ! =)
Таким образом всегда после этого сам заполнял 257 байт!
Причом могу отметить, что у многих фирменных игр видел заполененые 257 байт !
(а не у одной, как ктото сказал!!!)
Нестабильна шина именно на родном фирменном спектруме. Точно не знаю на каких именно моделях (легко установить по схематике, скорее всего, Sinclair ZX Spectrum 16, 48, 128 и +) - но все (99%) игрушек знают про это. По всей вероятности, на фирменном спеке неиспользование 257-байтной таблицы сразу же ведет к совершенно определенно четкому сбою. Поэтому пропустить данную фичу при написании игры было невозможно.
Если кому интересно - то на шину выдается байт аттрибутов. Происходит это потому что ULA и процессор развязаны в фирменной схематике просто резисторами, и процессор "подхватывает" байт аттрибутов выдаваемый ULA.
Совдеповские компы как раз были полностью свободны от этого недостатка (за исключением может быть "Москвы"). И это являлось в очень редких случаях причиной несовместимости.
Лечится на совдеповском компе такое подтяжкой шины данных с помощью резисторов к +5V. Резисторы нужны в пределах 10...15 килоом.
Если есть сомнения насчет связки TRDOS + 2-х байтный вектор прерывания, то советую не сомневаться и делать. Только чтение регистров TRDOS через IM2-прерывания это не "изобретение". Это уже использовалось. И именно таким методом, если ничего не путаю. Насколько я припоминаю, суть была в том, чтобы разрешить IM2 и обеспечить по прерыванию "вылет" из процедуры в которой процессор в обычных случаях зацикливался.
На не-совковые компы рассчитывать незачем. TRDOS у буржуев крайне непопулярна. А у совковых компов шина стабильна. Если у кого и нестабильна, то это очень редкое исключение (Совковый спек + TRDOS + нестабильная шина). Такие люди встречаются очень редко и ими можно пренебречь.
Если кому интересно - то на шину выдается байт аттрибутов. Происходит это потому что ULA и процессор развязаны в фирменной схематике просто резисторами, и процессор "подхватывает" байт аттрибутов выдаваемый ULA.это так, только вот висят там эти атрибуты исключительно, когда луч идет по экрану, и соответственно во время ИНТа там #FF
И именно таким методом, если ничего не путаю. Насколько я припоминаю, суть была в том, чтобы разрешить IM2 и обеспечить по прерыванию "вылет" из процедуры в которой процессор в обычных случаях зацикливался.ага, это было описано в древнючем zx review ;)
На не-совковые компы рассчитывать незачем. TRDOS у буржуев крайне непопулярна. А у совковых компов шина стабильна. Если у кого и нестабильна, то это очень редкое исключение а вот это заблуждение, в оригинальном пентагоне128 нестабильна шина данных, когда подключено пзу трдос. во время инта вектор берется с трдосного порта #FF
Такие люди встречаются очень редко и ими можно пренебречь.нельзя =( преценденты были и довольно жестокие
ага, это было описано в древнючем zx review ;)
Между тем способом, что написал я и ревюшным есть большая разница (взгляните хотя бы на длину процедуры). В Ревю необходимо было подобрать задержку между прерываниями так, чтобы при вызове TRDOS сразу после считывания 1F происходило прерывание. Это ведь потеря оборота диска. А как быть если время у разных компов между прерываниями разное? Мой способ лишен этих недостатов. Во-вторых, если регистр 1F равен нулю, считывание регистра происходит мгновенно.
так я не про твой способ, а тот, что Raider написал - цитата-то на что указана...
Lethargeek
19.09.2006, 08:25
Насчет того, почему фирменные игрушки используют 257 байт таблицу - я как-то читал буржуйскую доку по программированию (увы, сейчас не нашел), и там было сказано что-то вроде "во время инта по идее таки должно быть FF, но всякие внешние устройства у конкретного юзверя могут гадить на шину, так что лучше подстраховаться". В качестве примера таких "устройств" (кажется) назывался интерфейс-1, а также "в некоторых случаях" даже AY!
"во время инта по идее таки должно быть FF, но всякие внешние устройства у конкретного юзверя могут гадить на шину, так что лучше подстраховаться"
Книга "Как написать игру..." тоже так прямо и указывает. Там, правда, забыли про быструю память и шуруют в последних адресах -- явно все под 48к.
moroz1999
19.09.2006, 16:24
а кто-нибудь может более-менее доступным языком объяснить термины "маскируемые" и "немаскируемые" прерывания? А еще почти во всех статьях умалчивают про im0 и im1. где они используются и как работают?
SAM style
19.09.2006, 16:50
"Маскируемые" - это те, обработку которых можно запретить или разрешить программно (di, ei). Это все INT (im0, im1, im2). С немаскируемыми такого сделать нельзя. Пример - NMI, по аппаратному сигналу насильно вызывается прога по адресу 102 в DOS
сигнал INT с частотой 50Гц подаётся на процессор и тот решает, что в таком случае делать
обработка запрещена - ничего
разрешена - согласно текущему режиму (im0, im1, im2):
im0 - с шины данных снимается и выполняется команда. Только всегда получается так, что это #FF (rst 56), поэтому работает оно так же как и im1 (если никакая железяка на шине в это время не мусорит)
im1 - вот тут у меня точно провал в памяти (вроде, просто делается call 56)
im2 - с адреса <I*256+(состояние шины данных)> снимаются 2 байта, это адрес процедуры обработки прерываний. Туда и делается переход
moroz1999
20.09.2006, 01:15
спасибо! но про im1 всё же интересно.
спасибо! но про im1 всё же интересно.Режим IM 1 используется в маленьких вычислительных системах, где достаточно одного-единственного вектора маскируемого прерывания. При поступлении запроса прерывания микропроцессор сохраняет адрес возврата в прерванную программу в стеке и осуществляет переход на адрес 0038h. Таким образом, в этом режиме маскируемые прерывания обрабатываются точно тем же способом, что и немаскируемые. Разница заключается в возможности их маскирования и в адресе обработчика прерываний.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot