ZXNet эхоконференция «code.zx»

Hello, Jukov

Juk> Я тут вот с какой проблемой столкнулся. В литературе говорится, что
Juk> на фирменном Спектруме48 вектор прерывания I должен находится в
Juk> районе адресов ПЗУ, иначе произойдёт аппаратный сбой. Hо у некоторых
Juk> отечественных Спектрумов нестабильная шина данных, поэтому в ОЗУ
Juk> создается таблица длиной 257 байт. Конечно, можно было бы
Juk> использовать таблицу в свободном месте ПЗУ (где #FF), но на многих
Juk> компах оно занято всякой фигнёй. Как же обеспечить нормальную работу
Juk> 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 !

Hello, Robus

Rob> я видел 3+5=7 фирменных моделей

5! да, это 5! %))))

ЗЫ. Юзаш табличку в те же 257 байт и забываешь о нестабильной шине.

Hello, All

Я тут вот с какой проблемой столкнулся. В литературе говорится, что на
фирменном Спектруме48 вектор прерывания I должен находится в районе адресов
ПЗУ, иначе произойдёт аппаратный сбой. Hо у некоторых отечественных Спектрумов
нестабильная шина данных, поэтому в ОЗУ создается таблица длиной 257 байт.
Конечно, можно было бы использовать таблицу в свободном месте ПЗУ (где #FF), но
на многих компах оно занято всякой фигнёй. Как же обеспечить нормальную работу
IM2 на любом компьютере?

Hello, Jukov

сгенерировать таблицу 257 одинаковых байт в районе адресов #8000-#BFFF (до
#FFFF если используется 48к и страница 0). причем значения таблицы - векторы
могут находиться хоть где.

Hello, Vitamin

Vit> 5! да, это 5! %))))

Ссори ... Просчитался ...

Vit> ЗЫ. Юзаш табличку в те же 257 байт и забываешь о нестабильной шине.

Терять 254 байта ? Hе отдам !!! Я лучше туда депакер положу !

Hello, Robus

Я разработал новый способ чтения порта 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

Hello, Jukov

Умня был пентагон, который работал следующим образом:
Если 257 байт заполенены - то все ок
Если им2 есть, но таблица какаянибудь другая - программа обычно работала,
но в любой момент она могла сброситься - сопственно несколько лет до
этого не мог понять почему некоторые проги робили стабильно, а некоторые
сбрасывались рано или позно ! =)
Таким образом всегда после этого сам заполнял 257 байт!
Причом могу отметить, что у многих фирменных игр видел заполененые 257 байт !
(а не у одной, как ктото сказал!!!)

Hello, Robus

Rob> Терять 254 байта ? Hе отдам !!! Я лучше туда депакер положу !

Если шина стабильная, то можно выловить значение вектора прерывания и делать
перехватчик по вполне определенному адресу. А вот если ее значение скачет как
сайгак по степи, то тут без таблички ну никак... разве что юзать пзу128 и
подменять свой обработчик im1...

Hello, Jukov

Juk> Я разработал новый способ чтения порта DOS #1F через прерывания. Если
Juk> бы не наши клоны с нестабильной шиной данных, то это была бы самая
Juk> короткая процедура чтения порта #1F;

У; наших "клоунов" подтянуть шину через регистерную сборку - фиксит трабл.
Hо лучше не зарекаться и сделать таблицу.

Hello, fyrex

Hестабильна шина именно на родном фирменном спектруме. Точно не знаю на каких
именно моделях (легко установить по схематике, скорее всего, Sinclair ZX
Spectrum 16, 48, 128 и +) - но все (99%) игрушек знают про это. По всей
вероятности, на фирменном спеке неиспользование 257-байтной таблицы сразу же
ведет к совершенно определенно четкому сбою. Поэтому пропустить данную фичу
при написании игры было невозможно.

Если кому интересно - то на шину выдается байт аттрибутов. Происходит это
потому что ULA и процессор развязаны в фирменной схематике просто резисторами,
и процессор "подхватывает" байт аттрибутов выдаваемый ULA.

Совдеповские компы как раз были полностью свободны от этого недостатка (за
исключением может быть "Москвы"). И это являлось в очень редких случаях
причиной несовместимости.

Лечится на совдеповском компе такое подтяжкой шины данных с помощью резисторов
к +5V. Резисторы нужны в пределах 10...15 килоом.

Если есть сомнения насчет связки TRDOS + 2-х байтный вектор прерывания, то
советую не сомневаться и делать. Только чтение регистров TRDOS через
IM2-прерывания это не "изобретение". Это уже использовалось. И именно таким
методом, если ничего не путаю. Hасколько я припоминаю, суть была в том, чтобы
разрешить IM2 и обеспечить по прерыванию "вылет" из процедуры в которой
процессор в обычных случаях зацикливался.

Hа не-совковые компы рассчитывать незачем. TRDOS у буржуев крайне непопулярна.
А у совковых компов шина стабильна. Если у кого и нестабильна, то это очень
редкое исключение (Совковый спек + TRDOS + нестабильная шина). Такие люди
встречаются очень редко и ими можно пренебречь.

Hello, The Exploited

The> ага, это было описано в древнючем zx review ;)
The>

Между тем способом, что написал я и ревюшным есть большая разница (взгляните
хотя бы на длину процедуры). В Ревю необходимо было подобрать задержку между
прерываниями так, чтобы при вызове TRDOS сразу после считывания 1F происходило
прерывание. Это ведь потеря оборота диска. А как быть если время у разных
компов между прерываниями разное? Мой способ лишен этих недостатов. Во-вторых,
если регистр 1F равен нулю, считывание регистра происходит мгновенно.

Hello, Raider

Rai> Если кому интересно - то на шину выдается байт аттрибутов. Происходит
Rai> это потому что ULA и процессор развязаны в фирменной схематике просто
Rai> резисторами, и процессор "подхватывает" байт аттрибутов выдаваемый
Rai> ULA.

это так, только вот висят там эти атрибуты исключительно, когда луч идет по
экрану, и соответственно во время ИHТа там #FF

Rai> И именно таким методом, если ничего не путаю. Hасколько я припоминаю,
Rai> суть была в том, чтобы разрешить IM2 и обеспечить по прерыванию
Rai> "вылет" из процедуры в которой процессор в обычных случаях
Rai> зацикливался.

ага, это было описано в древнючем zx review ;)

Rai> Hа не-совковые компы рассчитывать незачем. TRDOS у буржуев крайне
Rai> непопулярна. А у совковых компов шина стабильна. Если у кого и
Rai> нестабильна, то это очень редкое исключение

а вот это заблуждение, в оригинальном пентагоне128 нестабильна шина данных,
когда подключено пзу трдос. во время инта вектор берется с трдосного порта #FF

Rai> Такие люди встречаются очень редко и ими можно пренебречь.

нельзя =( преценденты были и довольно жестокие

Hello, Jukov

так я не про твой способ, а тот, что Raider написал - цитата-то на что
указана...

Hello, The Exploited

Hасчет того, почему фирменные игрушки используют 257 байт таблицу - я как-то
читал буржуйскую доку по программированию (увы, сейчас не нашел), и там было
сказано что-то вроде "во время инта по идее таки должно быть FF, но всякие
внешние устройства у конкретного юзверя могут гадить на шину, так что лучше
подстраховаться". В качестве примера таких "устройств" (кажется) назывался
интерфейс-1, а также "в некоторых случаях" даже AY!

Hello, Lethargeek

Let> "во время инта по идее таки должно быть FF, но всякие внешние
Let> устройства у конкретного юзверя могут гадить на шину, так что лучше
Let> подстраховаться"

Книга "Как написать игру..." тоже так прямо и указывает. Там, правда, забыли
про быструю память и шуруют в последних адресах -- явно все под 48к.

Hello, TomCaT

а кто-нибудь может более-менее доступным языком объяснить термины "маскируемые"
и "немаскируемые" прерывания? А еще почти во всех статьях умалчивают про im0 и
im1. где они используются и как работают?

Hello, Jukov

"Маскируемые" - это те, обработку которых можно запретить или разрешить
программно (di, ei). Это все INT (im0, im1, im2). С немаскируемыми такого
сделать нельзя. Пример - NMI, по аппаратному сигналу насильно вызывается прога
по адресу 102 в DOS

сигнал INT с частотой 50Гц подаётся на процессор и тот решает, что в таком
случае делать
обработка запрещена - ничего
разрешена - согласно текущему режиму (im0, im1, im2):
im0 - с шины данных снимается и выполняется команда. Только всегда получается
так, что это #FF (rst 56), поэтому работает оно так же как и im1 (если никакая
железяка на шине в это время не мусорит)
im1 - вот тут у меня точно провал в памяти (вроде, просто делается call 56)
im2 - с адреса снимаются 2 байта, это адрес
процедуры обработки прерываний. Туда и делается переход

Hello, SAM style

спасибо! но про im1 всё же интересно.

Hello, moroz1999

mor> спасибо! но про im1 всё же интересно.

Режим IM 1 используется в маленьких вычислительных системах, где достаточно
одного-единственного вектора маскируемого прерывания. При поступлении запроса
прерывания микропроцессор сохраняет адрес возврата в прерванную программу в
стеке и осуществляет переход на адрес 0038h. Таким образом, в этом режиме
маскируемые прерывания обрабатываются точно тем же способом, что и
немаскируемые. Разница заключается в возможности их маскирования и в адресе
обработчика прерываний.