Просмотр полной версии : Вместо HALT
Привет, м.-ув. All.
Есть два взаимоисключающих вопроса:
1)
Если может знает кто, какие бывают короткие программные замены инструкции HALT, если разрешать прерывания нежелательно, а делать процессору пока как бы нечего? Конечно, желательно соответствие именно по задержке, считая либо "максимальную длину HALT", либо "HALT минус среднее время на обработчик прерывания", на более-менее стандартной конфигурации машины (3,5МГц без турбо, при 50Гц, при разрешенных прерываниях и при более-менее стандартной прошивке ПЗУ). Подошел бы любой из двух вариантов, там, наверное, будут константы для подгонки.
То есть, например, если включен IM 1 на стандартном 48к, и при этом в коде две подряд команды HALT, то нужна процедура задержки, по времени соответствующая второй команде HALT (так как первая команда HALT могла быть и короткой).
2)
Может, проще отследить начало кадра? Хотя почему-то помнится, что без HALT тут нет простых аппаратно-независимых решений.
Не совсем понятно, зачем это все. Если описать первопричину, то, возможно, можно было бы и что-то посоветовать)
Или говоря иносказательно, зачем ехать в Киев через Магадан? Только если в Магадане живет очень любимый родственник. А если родственника нет, то... HALT.
Если это своя программа - тут понятно.
Если это модификация другой программы, а прерывания там запрещены, а IM1 будет портить некоторые ячейки, а IM2 потребует over 256 байт...
Если это своя программа - тут понятно.
Если это модификация другой программы, а прерывания там запрещены, а IM1 будет портить некоторые ячейки, а IM2 потребует over 256 байт...
Это не обьяснение. Зачем нужна имитация HALT? Особенно в чужой программе.
NEO SPECTRUMAN
09.10.2017, 04:03
HALT, если разрешать прерывания нежелательно
А как это там применяются halt-ы при запрещенных прерываниях????? о_О
Если у тебя резинка ei im1 и прет rst38
то цитирую
003A ld hl,($5c78)
003D inc hl
003E ld ($5c78),hl
из чего не сложно догадаться как получить синхронизацию с интом без halt-ов и im2-ов
ну а если DI то... :v2_confu:
через IFF2 инт не увидишь...
разве что воспользоваться портом FF
+там еще понадобится счетчик
чтоб определить а не посреди ли paper-а начался этот "типо хальт"
Spectramine
09.10.2017, 08:28
IM2 потребует over 256 байт...
Это только на глючном компе с постоянно нестабильной шиной данной, на всех нормальных спек-совместимых компах в момент прерывания на шине строго #FF, соответственно, хватит двух байт для вектора прерывания, плюс 7 байт на инициализацию IM 2 (LD A,N: LD I,A: IM 2: EI), плюс, возможно, пару байт на обработчик прерывания (EI:RET). (Естественно, в целях совместимости, не стОит назначать вектор прерывания в медленной памяти - будет дико тормозить на синклеровских моделях. Без головняка - строго в адресах #8000-#BEFF.)
Я не знаю, почему большинство программ так стараются забить 257 байт одним байтом для однозначного вектора прерывания, но реальных причин для этого нет. Достаточно по адресу #IIFF вписать произвольный адрес процедуры прерывания. (Иначе в 128к модели в 48бейсик-странице ПЗУ не использовали бы свободный участок - потеряли бы совместимость. А он использован, но для совместимости по адресам #xxFF оставлено #FFFF (Амстрад, кстати, в своей редакции 48бейсик-страницы ПЗУ на это забил, за что и поплатился потерей совместимости)).
Это только на глючном компе с постоянно нестабильной шиной данной, на всех нормальных спек-совместимых компах в момент прерывания на шине #FF
Двухбайтник в наше время был признаком весьма плохого тона) Все игры, где была двухбайтная таблица прерываний, приходилось переделывать под 257 байт. Даже в том же Диззи-7, который мы релизили с Исайкой (к слову сказать, у Исайчика Пентагон на котором нестабильная шина данных из-за неправильно подключенного AY, на сколько я помню), - пришлось переделывать 2-х байтник на 257.
Spectramine
09.10.2017, 09:01
Двухбайтник в наше время был признаком весьма плохого тона) Все игры, где была двухбайтная таблица прерываний, приходилось переделывать под 257 байт. Даже в том же Диззи-7, который мы релизили с Исайкой (к слову сказать, у Исайчика Пентагон на котором нестабильная шина данных из-за неправильно подключенного AY, на сколько я помню), - пришлось переделывать 2-х байтник на 257.
Да, это имеет смысл для глючных машин. Правда, ещё для машин с подключенной периферией, выставляющей на шину нужный младший байт в момент своего прерывания, я про это забыл, а ведь есть такая AMX мышь, которая таким страдает (и которую пришлось бы отключать, запуская на 128к машинах старые игры с вектором в ПЗУ, как Bomb Jack). А больше причин нет, насколько я понимаю, и на подавляющем большинстве машин двухбайтный вектор будет работать ок.
Не вполне понятно, что тебе надо, TomCaT.
Если просто нужна задержка, чтобы притормозить чужую программу, то можно ведь тупо нагрузить процессор.
LD H,D
LD L,E
LD BC,3333
LDIR
Семь байт занимает. :v2_dizzy_ass:Естественно не один байт HALT-а.
Для стандартного спека возможно использовать порт #FF. У Next'а есть порт, через который можно узнать текущую строку.
ld d,63 ; Номер строки
call WaitYLine
WaitYLine ld bc,$243b
ld a,30
out (c),a
inc b
.lp in a,(c)
and 1
jr nz,.lp
ld bc,$243b
ld a,31
out (c),a
inc b
.lp2 in a,(c)
cp d
jr nz,.lp2
ret
shurik-ua
09.10.2017, 11:08
пока вы будете узнавать какая строка - она скорее всего закончится )
можно ведь тупо нагрузить процессор.
LD H,D
LD L,E
LD BC,3333
LDIR
Семь байт занимает.
Именно что-то такое и нужно.
Так понимаю, получается около 70000, ну, а обработчик уже тут можно вычесть...
- - - Добавлено - - -
Двухбайтник в наше время был признаком весьма плохого тона
Совершенно верно. Даешь максимальную совместимость.
DenisGrachev
10.10.2017, 05:37
Именно что-то такое и нужно.
Так понимаю, получается около 70000, ну, а обработчик уже тут можно вычесть...
- - - Добавлено - - -
Совершенно верно. Даешь максимальную совместимость.
Т.е. тебе нужно ждать нужное кол-во тактов?Так бы стразу и сказал :)
ld bc,нужное число тактов
call DELAY;ждёт нужно число тактов из bc>141такта
; Z80 delay routine
; by Jan Bobrowski, license GPL, LGPL
DELAY: ; wait bc T (including call; bc>=141)
; destroys: af, bc, hl
ld hl, -141
add hl, bc
ld bc, -23
_loop add hl, bc
jr c, _loop
ld a, l
add a, 15
jr nc, _g0
cp 8
jr c, _g1
or 0
_g0 inc hl
_g1 rra
jr c, _b0
nop
_b0 rra
jr nc, _b1
or 0
_b1 rra
ret nc
ret
NEO SPECTRUMAN
13.01.2018, 14:36
в EmuZwin
при запрещенных прерываниях
можно поймать начало фрейма при помощи ;)
ld a,r
jp pe,vsync_hit
ld a,r
jp pe,vsync_hit
ld a,r
jp pe,vsync_hit
...
но срабатывает не всегда
тк сам интервал детекции начала фрейма
видимо может проскочить между командами
но усердное курение доков
и отсутствие этого в других эмуляторах
говорит нам, что это просто бага эмузвина
проще определить факт прерывания исполнения кода обработчиком прерываний.
или то что прога запущенна в эмузвине :v2_dizzy_roll:
Spectramine
13.01.2018, 16:37
в EmuZwin
при запрещенных прерываниях
можно поймать начало фрейма при помощи ;)
ld a,r
jp pe,vsync_hit
ld a,r
jp pe,vsync_hit
ld a,r
jp pe,vsync_hit
...
но срабатывает не всегда
тк сам интервал детекции начала фрейма
видимо может проскочить между командами
но усердное курение доков
и отсутствие этого в других эмуляторах
говорит нам, что это просто бага эмузвина
проще определить факт прерывания исполнения кода обработчиком прерываний.
или то что прога запущенна в эмузвине :v2_dizzy_roll:
Что-то тут не так. Есть известный баг Z80, но он работает с точностью до наоборот - при _разрешенных_ прерываниях в момент прихода импульса прерывания команда LD A,R выставляет флаг P/O в 0 (PO) (как будто они запрещены). Вот тут про это подробно: http://ivr.webzone.ru/articles/ldar_new/ .
NEO SPECTRUMAN
13.01.2018, 20:36
Этот баг исправлен в CMOS-версиях Z80.
да кому надо такое исправлять
они хоть знали про это?
что то упрощали\переделывали
а оно исправилось само по себе
...с таким же успехом они и out (c),0 "исправили"...
Spectramine
13.01.2018, 22:02
да кому надо такое исправлять
они хоть знали про это?
что то упрощали\переделывали
а оно исправилось само по себе
...с таким же успехом они и out (c),0 "исправили"...
Баг есть баг, по вышеприведенной ссылке у автора программа время от времени из-за него висла. Возможно, кстати, что и не исправили. Тут вот люди не уверены, что исправлено (http://www.worldofspectrum.org/z88forever/dn327/z80undoc.htm).
А out (c),0 не документирована, исправлять там нечего. Поменялось поведение, и всё.
NEO SPECTRUMAN
13.01.2018, 22:29
Баг есть баг, по вышеприведенной ссылке у автора программа время от времени из-за него висла.
этот "баг" уровня недокументированной фичи
и элементарно обходится
и нужно достаточно постараться чтобы из за него все повисло...
(и вообще делать такую операцию без двойной проверки...
...ну я бы не стал...
мало ли где один бит сам по себе появится\исчезнет...
тем более когда время выполнения не критично...)
а вот от потери out C,0
легко перестают работать правильно кучи софтов...
а просто так его обойти без потери производительности уже нельзя...
- - - Добавлено - - -
А out (c),0 не документирована
но чавота про всякие iff-ы
я узнал из всяких статей с названиями недокументированный возможности...
...хотя в статье выше упоминается что в оригинальной ранней документации данная возможность описывалась
- - - Добавлено - - -
Тут вот люди не уверены, что исправлено.
ВНЕЗАПНО нашел для себя новую недокументированную команду IM ?
Spectramine
13.01.2018, 23:10
этот "баг" уровня недокументированной фичи
и элементарно обходится
и нужно достаточно постараться чтобы из за него все повисло...
(и вообще делать такую операцию без двойной проверки...
...ну я бы не стал...
мало ли где один бит сам по себе появится\исчезнет...
тем более когда время выполнения не критично...)
Да фича-то достаточно бесполезная, как бы. Со включенными прерываниями словить начало кадра и так ума много не надо. А вот баг неприятный, ибо не все о нём знают.
а вот от потери out C,0
легко перестают работать правильно кучи софтов...
а просто так его обойти без потери производительности уже нельзя...
Это да. А вот нефиг недокументированные команды юзать, дабы ибо.
но чавота про всякие iff-ы
я узнал из всяких статей с названиями недокументированный возможности...
...хотя в статье выше упоминается что в оригинальной ранней документации данная возможность описывалась
Да опять же - где ж там возможность, когда баг. Что мешает в обработчике свой флаг выставить, а вне обработчика его проверять, вместо того, чтобы ерундой страдать.
ВНЕЗАПНО нашел для себя новую недокументированную команду IM ?Там сворее всего дублирование IM 0 или IM 1, но проверять всем лень.
прерывания, нюансы. я для PMD-85 делал так:
w:
ld a,(flg)
or a
jp nz,w
xor a
ld (flg),a
;vector
intvec:
push af
ld a,0
ld (flg),a
pop af
ret
flg: db 0
Spectramine
14.01.2018, 12:19
А зачем обнулять flg в основной программе, если он уже обнулен? Там скорее его в не-ноль надо выставить.
NEO SPECTRUMAN
14.01.2018, 12:32
А зачем обнулять flg в основной программе, если он уже обнулен? Там скорее его в не-ноль надо выставить.
"токое" делали даже PROгеймо писатели за деньги в 80-х... (натыкался в некоторых гамах...)
а вопрос зачем так и остается...
...хотя умя самого такая конструкция иногда проскальзывает...
SoftFelix
14.01.2018, 13:05
Парни, а напишите тестовую программку для точной идентификации Z80 (NMOS-CMOS), наличие-отсутствие у него бАга с флагами для LD A,R и как выполняется OUT (C),0. Сразу масса вопросов отпадёт при некорректной работе некоторого софта.
shurik-ua
14.01.2018, 13:26
Парни, а напишите тестовую программку для точной идентификации Z80 (NMOS-CMOS)
HorrorFasTest уже умеет.
Spectramine
14.01.2018, 13:41
HorrorFasTest уже умеет.
Ага, ща проверил - если вместо OUT (C),0 идет OUT (C),$FF, он пишет вместо Z80 - Z84.
Вообще на 128м проверить NMOS/CMOS легко:
LD BC, #BFFD ; порт выбора регистра AY
XOR A
OUT (C),A ; выбираем регистр 0
LD B,#FF ; BC=#FFFD - порт записи в регистр
OUT (C),0 ; недокументированная команда, на NMOS z80 пишет в порт #00, на CMOS z80 - #FF
LD B,#BF ; BC=#BFFD - порт чтения регистра AY
IN A,(C) ; читаем регистр 0 AY с выставлением флагов
JR NZ,lCMOSz80 ; если в нем 0 - процессор NMOS, иначе CMOS
На 48м - вроде как только с помощью вопроса пользователю после вывода в порт #FE.
SoftFelix
14.01.2018, 13:58
HorrorFasTest уже умеет.
Это понятно, многие тесты именно это умеют. Просто собрать всё перечисленное в одну программку с элементарным текстовым выводом.
- - - Добавлено - - -
LD BC, #BFFD ; порт выбора регистра AY
Только перед этим нужно протестировать наличие AY'а. :)
Spectramine
14.01.2018, 15:00
Только перед этим нужно протестировать наличие AY'а. :)
Ой, правда. Я и забыл, что на некоторых реалах AY может не быть) Значит, будем индицировать NMOS/CMOS цветом бордюра)
- - - Добавлено - - -
Сваял простой тест: 63707.
Если бага LD A,R у Z80 нет, программа повисит 10 секунд, и выдаст сообщение. Если есть - отработает быстрее.
NMOS/CMOS сразу индицируется цветом бордюра (черный - NMOS, белый - CMOS).
- - - Добавлено - - -
Потестил эмули - ZXSpin, Zero и EmuzWin о баге не знают, Spectaculator, SpecEmu, Fuse, Unreal и ZXMAK2 знают.
SoftFelix
14.01.2018, 15:08
Сваял простой тест
Гляну чуть позже. Спасибо. p.s. А можно в архив сразу класть хобету, SCL или TRD?
Spectramine
14.01.2018, 15:42
Ага, добавил scl в архив.
- - - Добавлено - - -
Если у кого на реале стоит CMOS z80, прогоните тест, плиз, надо ж выяснить, есть на нем баг LD A,R или нет.
http://zxpress.ru/article.php?id=8963
А зачем обнулять flg в основной программе, если он уже обнулен? Там скорее его в не-ноль надо выставить.
а подумай.
Spectramine
14.01.2018, 16:35
а подумай.
Не, ниасиливаю. Выход из цикла предполагает, что в переменной и так уже ноль. А для повторного вылавливания прерывания надо в переменную занести не-ноль.
тьфу ты. ошибся.
ld a,1 в прерывании.
Spectramine
14.01.2018, 19:21
тьфу ты. ошибся.
ld a,1 в прерывании.
Если ld a,1 в прерывании, тогда, по идее, и jp z,w в основной программе.
Забыл( на PMD работал так
SoftFelix
14.01.2018, 21:25
Ага, добавил scl в архив.
Комп (KAY-1024_2010, Z84C020PEC) просто зависает с белым бордером. Надо предусмотреть хоть какую-то текстовую подсказку этапов и результатов выполнения тестов.
Spectramine
14.01.2018, 21:31
Раз зависает, значит, ошибки нет. Он не совсем зависает, через 10 секунд выйдет в бейсик с сообщением, что бага нет. Там всего-то надо временную константу поправить в коде, чтобы развисал быстрее, но мне уже лень)
- - - Добавлено - - -
Так что таки исправили баг в CMOS процах.
- - - Добавлено - - -
Надо будет добавить опцию NMOS/CMOS Z80 в эмуль.
SoftFelix
14.01.2018, 21:37
через 10 секунд выйдет в бейсик с сообщением, что бага нет.
Не выходит. Если ТУРБО включено - не выходит, сколько не жди. Если ТУРБО выключено, то выходит.
Spectramine
14.01.2018, 21:48
Странно, там на прерываниях висит уменьшение обратного счетчика тиков, по достижении 0 должен выходить в Бейсик. Понятия не имею, чем этому включенный ТУРБО мешает.
SoftFelix
14.01.2018, 21:53
Понятия не имею, чем этому включенный ТУРБО мешает.
Значит надо и этот момент отловить. Я ж не выдумываю, что в ТУРБО комп весит намертво. Если выйти по Теневику (МОА), то крутится на инструкции L1: LD A,R; JP,PE,L1.
Spectramine
14.01.2018, 21:58
Так он и должен крутиться, а в прерывании по достижении счетчиком нуля должен выходить. Возможно, Турбо режим отключает прерывания.
SoftFelix
14.01.2018, 22:02
Турбо режим отключает прерывания.
Точно не отключает.
Spectramine
14.01.2018, 22:10
Посмотри в теневике, меняется ли содержимое регистра BC со временем. Если не меняется - что-то с турбо режимом, почему-то, если он включен, отключены прерывания.
- - - Добавлено - - -
Листинг кода, может, кто-то шарит в особенностях Турбо-режима Кая, разберется, почему виснет:
; CLEAR 32255 (#7DFF)
ORG 32700
LD C,#FE
OUT (C),0
LD HL,#7E00
LD DE,#7E01
LD BC,256
LD (HL),#7F
LDIR
LD BC,500 ; время определения ошибки z80 в 1/50 секунды
LD A,#7E
LD I,A
IM 2
EI
L1 LD A,R
JP PE,L1
LD BC,1
LEND IM 1
LD A,#3F
LD I,A
EI
RET
ORG #7F7F
PUSH AF
DEC BC
LD A,B
OR C
JR Z,L3
POP AF
L2 EI
RET
L3 POP AF
POP AF
JP LEND
Barmaley_m
16.01.2018, 01:20
В турборежиме может случиться так, что прерывание приходит не в любой такт, а только в такой такт, чтобы не затронуть команду LD A,R. Точно это зависит от кол-ва тактов в прерывании и от логики WAIT в турборежиме. А вообще классная тема, спасибо всем, кто высказался, открыли мне глаза на важный баг Z80!
Правда, позанудствую немного. Мне кажется, иметь такие подпрограммы, которые проверяют, разрешены ли прерывания - это дурной тон. В любой момент исполнения программы программисту известно, запрещены прерывания или разрешены. Можно иметь две точки входа в подпрограмму, одна из которых разрешает прерывания по выходу, а другая - нет, и вызывать ту из них, которая соответствует режиму работы процессора в данный момент. Мне только в одной ситуации нужно было проверять состояние IFF2 - в обработчике NMI. Но в этот момент работа команды LD A,R не может быть нарушена, т.к. IFF1=0 и прерывания фактически запрещены.
Spectramine
16.01.2018, 01:36
В турборежиме может случиться так, что прерывание приходит не в любой такт, а только в такой такт, чтобы не затронуть команду LD A,R. Точно это зависит от кол-ва тактов в прерывании и от логики WAIT в турборежиме. .
Там неважно, в какой такт, лишь бы прерывание вообще происходило, тогда по истечении 10 секунд программа выйдет в бейсик. А оно, похоже, не происходит вообще, по каким-то причинам, соответственно, программа повисает насовсем.
SoftFelix
16.01.2018, 02:02
А оно, похоже, не происходит вообще, по каким-то причинам, соответственно, программа повисает насовсем.
Вспомнил. У меня ещё 2012-ом году отказалась работать игра Terra Cresta (http://zx-pk.ru/threads/5076-novye-tr-dos-relizy.html?p=539953&viewfull=1#post539953). У других владельцев КАЯ она тоже не заработала. Там от ссылки и далее по топику. Я так и не понял тогда, из-за чего эта проблема: то ли из-за CMOS Z80 (Z84C0020PEC, но на Фениксе работает!), то ли из-за схемы формирования /INT'а в КАЕ на ИР16. В общем, определится бы с причиной и решить эту проблему.
- - - Добавлено - - -
И вот отсюда и далее по топику (http://zx-pk.ru/threads/13770-kay-1024-sl-4-turbo-v2010-nemofdc-nemoide.html?p=540265&viewfull=1#post540265) тоже можно почитать (вроде, всё-таки, из-за процессора).
Spectramine
16.01.2018, 07:19
Ну, вроде, разобрались (http://zx-pk.ru/threads/13770-kay-1024-sl-4-turbo-v2010-nemofdc-nemoide.html?p=552013&viewfull=1#post552013) - разработчики пофиксили баг LD A,R в CMOS Z80 очень мощно - после LD A,R/LD A,I не может произойти прерывание (как после EI во всех Z80), а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.
- - - Добавлено - - -
Так что и из-за процессора и из-за Кая, комплексно.
SoftFelix
16.01.2018, 09:51
после LD A,R/LD A,I не может произойти прерывание (как после EI во всех Z80), а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.
Это можно отловить программно для доработки теста? В Тесте INT'а Ковалевского, у меня длительность ровно на границе Мало-Норма.
Spectramine
16.01.2018, 19:39
Это можно отловить программно для доработки теста? В Тесте INT'а Ковалевского, у меня длительность ровно на границе Мало-Норма.
Так оно ж программно и отлавливается - если тест виснет, это показатель того, что INT надо фиксить, или будут и в играх проблемы.
Тут вроде как не тест надо дорабатывать, а Кай - 2 цикла M1 на INT это явно маловато. В стандартном спеке длительность INT 32 такта, если брать по 4 такта на цикл M1 - это 8 циклов M1 надо.
Слегка поправил тест - поставил время проверки 2 секунды, и предупреждение, что, если программа виснет, INT проблемный:63716
shurik-ua
16.01.2018, 20:40
В стандартном спеке длительность INT 32 такта
а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.
а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.
Потому, что так проц INT# не пропустит (если в схеме триггер используется), да и не все игры корректно работают, например в Cybernoid играть становится труднее, игра делается что-ли динамичнее. Поначалу понять не мог в Spec256 в чём дело, пока не убрал INTA# и не вернул стандартную длительность INT# и автоматом сразу добавилась проблема в турбо, нужно эту длительность ещё в разы удлинять для турбо, из-за проблем работы игр.
Barmaley_m
19.01.2018, 23:10
а почему нигде не используется схема подтверждения прерывания по даташиту на проц z80 ? - а именно INT_ACK = /IORQ OR /M1.
В "Орель БК-08" используется такая схема. Никаких проблем, проц никогда не "просыпает" INT, потому что во время действия сигналов M1, IORQ прерывание уже подтверждено. С другой стороны, если подтверждение прерывания не приходит в течение около 25 тактов (при запрещеных прерываниях) - то запрос снимается до следующего кадра. Возможно, в Spec256 нет автоснятия запроса, из-за этого пропущенное прерывание срабатывает сразу после EI.
Почему в других клонах не используется - вероятно, разработчики таким образом экономят логический элемент. Они ведь были в те годы на вес золота. Ну и место на печатной плате, и сложность разводки.
NEO SPECTRUMAN
20.01.2018, 01:08
В любой момент исполнения программы программисту известно, запрещены прерывания или разрешены.
если у тя вся машина в твоем распоряжении то да
а если тебе выделило какойто время некоторая многозадачная ОС то уже не совсем...
а так функция местами полезная
и че за бред понаписан в http://zxpress.ru/article.php?id=8963
непонятно
чем не устраивает элементарное двойное чтение?
зачем было править проц
много железа бажит или дает ложный результат при первом чтении
- - - Добавлено - - -
а так да
тема внезапно стала еще интересней
опять всплыли всякие кривые клоны
и их кривые глюки
про которые нигде особо и не написано...
CodeMaster
20.01.2018, 08:31
а если тебе выделило какойто время некоторая многозадачная ОС то уже не совсем...
Много народа на Спеке работает под многозадачными ОСями...
SoftFelix
20.01.2018, 13:10
а в Кае длительность INT - два цикла M1, как раз на одну команду LD A,R.
Я так понимаю, что эту длительность задаёт комбинация на входах D0...D3 сдвигового регистра. D1 и D2 посажены на GND. Это и задаёт длительность INT'а в два цикла /M1? А сколько это в тактах?
http://photo.qip.ru/photo/softfelix/3868246/xlarge/108361726.jpg (http://photo.qip.ru/users/softfelix/3868246/108361726/)
Вот что на КАЕ показывает Тест INT'а Ковалевского. В ТУРБО-неТУРБО длительность всегда одинаковая и находится ровно на границе МАЛА-НОРМА. Когда-то давно комрад Шепелёв (насколько я помню) опубликовал в журнале "Радиолюбитель" тест длительности INT'а. Там давалась норма 28...32 тактов процессора. На КАЕ сейчас данный тест во всех режимах показывает "Too short!".
ТУРБО включено.
http://photo.qip.ru/photo/softfelix/3868246/xlarge/110949401.jpg (http://photo.qip.ru/users/softfelix/3868246/110949401/)
ТУРБО выключено.
http://photo.qip.ru/photo/softfelix/3868246/xlarge/110949402.jpg (http://photo.qip.ru/users/softfelix/3868246/110949402/)
Ближе.
http://photo.qip.ru/photo/softfelix/3868246/xlarge/110949403.jpg (http://photo.qip.ru/users/softfelix/3868246/110949403/)
Я так понимаю, что если INT чуть удлинить, то проблема с подвисанием уйдёт? На вскидку 5-ую ногу регистра отцепляем от +5В и сажаем на GND. Железячники тут есть? Ход мысли правильный (с ответом можно переместится в эту (http://zx-pk.ru/threads/13770-kay-1024-sl-4-turbo-v2010-nemofdc-nemoide.html) тему)?
Spectramine
20.01.2018, 15:07
Вот довольно точный тест длительности INT:63747 (minfo.tap).
SoftFelix
20.01.2018, 15:19
minfo.tap
У меня TR-DOS only.
NEO SPECTRUMAN
20.01.2018, 17:06
Много народа на Спеке работает под многозадачными ОСями...
а з80 только в спеке будто....
CodeMaster
20.01.2018, 20:02
а з80 только в спеке будто....
Даже если не учитывать, что раздел называется "ZX Spectrum Software", то существует не более 1.5 штук многозадачных ОС и то в состоянии бета-версий. Ну, да SymbOS вроде как целостный продукт, но вещь сама в себе и кроме как автором ничем не поддерживается.
Barmaley_m
20.01.2018, 23:30
если у тя вся машина в твоем распоряжении то да
а если тебе выделило какойто время некоторая многозадачная ОС то уже не совсем...
Автор исходной программы не использовал такую ось.
А вообще в многозадачных осях пользовательскому коду строго запрещено разрешать или запрещать прерывания. В процессорах с MPU инструкции вроде DI или CLI являются привилегированными, так что этот запрет реализуется принудительно. При написании драйверов принудительного ограничения нет, но все равно надо следовать документации на ось, иначе драйвер будет глючным.
Если автор драйвера считает необходимым нарушить запрет на изменение состояния прерываний - то лучше ему подумать еще раз, а надо ли. Зачем это может быть надо? Варианта два:
1) блокировка многопоточного доступа к данным. Вместо запрещения прерываний следует пользоваться функциями блокировки, предоставляемыми осью, например, KeAcquireSpinLock в случае винды;
2) обеспечение исполнения критичного по времени кода. Снова-таки, либо ось может быть для этого по определению не предназначена, либо в ней должны быть функции, фактически запрещающие или разрешающие прерывания, но автору драйвера до этого не должно быть дела, его задача - вызвать нужные функции и полагаться на их работу.
Это общие принципы построения осей, им следуют как минимум крупные оси, а мелкие - тут все зависит от компетентности их авторов.
Spectramine
08.07.2018, 20:39
Сваял простой тест: 63707.
Если бага LD A,R у Z80 нет, программа повисит 10 секунд, и выдаст сообщение. Если есть - отработает быстрее.
NMOS/CMOS сразу индицируется цветом бордюра (черный - NMOS, белый - CMOS).
- - - Добавлено - - -
Потестил эмули - ZXSpin, Zero и EmuzWin о баге не знают, Spectaculator, SpecEmu, Fuse, Unreal и ZXMAK2 знают.
Развивая тему: http://zx-pk.ru/threads/27033-prokhozhdeniya-igr-v-formate-rzx.html?p=970613&viewfull=1#post970613 (на случай, если тут тему кто-то не читал).
Судя по всему, Spectaculator и ZXMAK2 эмулируют этот баг Z80 не вполне правильно - иногда при поступлении импульса прерывания во время команды LD A,R во флаг P/V заносится 1, и мой новый тест по ссылке выдает на них ошибку. А вот Fuse, Unreal и SpecEmu всегда в этом случае в флаг P/V заносят 0, и тест виснет, как положено. Желающие могут запустить тест на фирменных реалах или Пентагоне (на Скорпионах и других клонах бесполезно), сравнить поведение реала с эмуляторами.
Spectramine
09.07.2018, 12:42
Кому интересно, благодаря daniel, запустившему новый тест на своих реалах, выяснилось, что на реальных компах тест виснет, как и ожидалось, то есть Spectaculator и ZXMAK2 не вполне правильно эмулируют работу команды LD A,R. Это может влиять, ну например, на эмуляцию программ, использующих регистр R как генератор случайных чисел. В частности, неправильно пишутся/читаются RZX, например вот этот RZX (http://www.rzxarchive.co.uk/b/beastiefeastie.rzx) воспроизводится без ошибок только на Спектакуляторе, на котором он был записан.
У меня вопрос на ту же тему. Как между делом, пока у меня выполняется много кода с запрещёнными прерываниями, понять что прерывание таки случилось? Я ведь правильно понимаю, оно не случается "вдогонку"? Дело в том, что код использует стек в качестве переносчика данных, а прерывание может туда нагадить. Вот я и думаю, как бы в промежутках кода проверять не случилось-ли оно, и вызывать обработчик.
Как между делом, пока у меня выполняется много кода с запрещёнными прерываниями, понять что прерывание таки случилось?
с чего ему случаться если оно запрещено ?
работать нетрадиционно со стеком можно и при разрешённых прерываниях.
тут два варианта.
1 как в ЧерномВороне. процедура на im2 правит сама испорченные данные.
2 как в Zub/Amaurote. постоянная проверка целостности данных и их коррекция
NEO SPECTRUMAN
08.10.2019, 01:19
У меня вопрос на ту же тему. Как между делом, пока у меня выполняется много кода с запрещёнными прерываниями, понять что прерывание таки случилось? Я ведь правильно понимаю, оно не случается "вдогонку"? Дело в том, что код использует стек в качестве переносчика данных, а прерывание может туда нагадить. Вот я и думаю, как бы в промежутках кода проверять не случилось-ли оно, и вызывать обработчик.
скорей всего никак
на многих клонах можно вообще словить 2+ обработчика прерываний подряд
если обработчики короткие
...по моему на msx-ах прерывание будет висить до тех пор пока не произойдет его подтверждение
на некоторых спетрумах по моему максимум что есть
это прекращение сигнала инта при его подтверждении
чтоб не ловить 2 подряд
(не уверен уже есть ли точно(и расчитывать на это в любом случае нельзя))
при наличии порта FF можно поймать факт начала\конца экрана
и вызвать обработчик
но это должны быть чем то оправданно
так как на большим количестве спектрумов это поделие работать не будет
да и сама проверка будет длительной
тк в строке 96 тактов бордюра
да и над самим экраном, по моему, все не так просто читается
можно попытаться поймать 50Гц-ный фон с матафонного входа
(тоесть вообще можно попробовать получить опорные 100Гц дополнительно)
но это особое извращение для знающих толк
(которого вполне может ни у кого больше не быть)
и врятли оно эмулируется
ну и 50Гц сети явно не будут совпадать с 50Гц экрана...
ДЕТКИ НЕ ПЫТАЙТЕСЬ ПОВТОРИТЬ ЭТО ДОМА! :)
ну разве что это будет wild demo
где такое можно и нужно
Как между делом, пока у меня выполняется много кода с запрещёнными прерываниями, понять что прерывание таки случилось?
1 как в ЧерномВороне. процедура на im2 правит сама испорченные данные.
2 как в Zub/Amaurote. постоянная проверка целостности данных и их коррекция
3. Если известно сколько именно времени исполняется "много кода", то посчитать. Можно использовать также замер_времени после "много кода" до следующего прерывания.
скорей всего никак
...
Жалко... Как я понимаю, чтение из регистра R, это из той же оперы?
можно попытаться поймать 50Гц-ный фон с матафонного входа...
А это вообще взлом Матрицы!
- - - Добавлено - - -
с чего ему случаться если оно запрещено ?
работать нетрадиционно со стеком можно и при разрешённых прерываниях.
тут два варианта.
1 как в ЧерномВороне. процедура на im2 правит сама испорченные данные.
2 как в Zub/Amaurote. постоянная проверка целостности данных и их коррекция
Интересная мысль! Буду думать в этом направлении. Спасибо!
я тут недавно долго ловил баг. прога работала при IM1, но через какое-то время (в турбе быстрее) сбрасывалась.
вот кусок кода висящий на прерываниях в ROM. увеличение системной переменной (frames)
LD HL,(#5C78)
INC HL
LD (#5C78),HL
LD A,H
OR L
JR NZ,L0048
INC (IY+#40) !!!!!
L0048: PUSH BC
в моём случае это был муз.плейер который использовал IY для работы с данными.
оказалось такое встречается и в играх, например JoeBlade2 48k
SoftFelix
08.10.2019, 15:51
INC (IY+#40)
А что там за переменная BASIC'а? И только в ТУРБО сбрасывалась?
допустим у тебя в программе IY используется для своих целей
INC (IY+#40) естественно что-то испортит.
испортит и не в турбо (просто в турбо это произойдёт быстрей)
Bedazzle
08.10.2019, 22:00
я тут недавно долго ловил баг. прога работала при IM1, но через какое-то время (в турбе быстрее) сбрасывалась.
Это защита от долгого сидения за игрой. :) :) :)
NEO SPECTRUMAN
08.10.2019, 22:41
Жалко... Как я понимаю, чтение из регистра R, это из той же оперы?
регистром R можно мерять время условно
основная проблема что у регистра R всего 7 бит (128 значений)
им много не намеряешь (интервалы 512-1200+ тактов всего)
да и инкриментится он с разной скоростью
его можно пускать по одноподобному коду
тогда он дает более менее вменяемые результаты пригодные к использованию
можно использовать вместо счетчика когда нет свободных регистров
в атаче поделие в котором я как то юзал регистр R для измерения расстояния на которое пролетает луч
после там несколько низкоточных коррекций результата
и в итоге много артефактов
так же обработчик прерываний должен восстанавливать значение регистра
на некоторых эмулях у меня оно иногда восстанавливает с ошибкой
что как бы намекает на кривость эмуляции местами или какие еще то подводные камни
Spectramine
04.10.2022, 20:47
Так оно ж программно и отлавливается - если тест виснет, это показатель того, что INT надо фиксить, или будут и в играх проблемы.
Тут вроде как не тест надо дорабатывать, а Кай - 2 цикла M1 на INT это явно маловато. В стандартном спеке длительность INT 32 такта, если брать по 4 такта на цикл M1 - это 8 циклов M1 надо.
Слегка поправил тест - поставил время проверки 2 секунды, и предупреждение, что, если программа виснет, INT проблемный:63716
goodboy выявил несовершенство моего теста - на его сером +2 тест то выдавал ошибку процессора, то не выдавал. Не выставил начальный TStates при заходе в тестовый цикл, и при определенных условиях за 2 секунды ошибка проца ни разу не ловилась. Исправил тест, если кому интересно:77899
при определенных условиях
ещё и `снег` на экране появлялся (комп подключал к телеку по ВЧ - качество было неважное),
хотя вот он в эмуле (и в новом варианте теста тоже снежит)
https://pic.maxiol.com/thumbs2/1664906183.3645247878.snow.png (https://pic.maxiol.com/?v=1664906183.3645247878.snow.png&dp=2)
Spectramine
04.10.2022, 20:58
Снег законный, я же I в медленную память всунул. Правда, это тоже косяк) Надеюсь, тест не будет сбрасываться на некоторых машинах, т.к. теперь отрабатывает быстро.
- - - Добавлено - - -
Зато тест можно и на Спектрум 16кб запускать)
Надеюсь, тест не будет сбрасываться на некоторых машинах
я с таким сталкивался. +2issue1 сбрасывался с игрой FantasyWorldDizzy,
там в процедуре вывода семпла регистр I использовался как переменная.
на более старшей версии платы работало с тормозами, но не сбрасывалось.
Spectramine
04.10.2022, 22:23
Исправил снег, и убрал регресс с CMOSZ80 (на нем тест повисал очень надолго):77901.
проверил на +2 и +2A ; бордюр чёрный, bug present
Эта тема мне навеяла воспоминание, что не так давно на оригинальных +3 был найден порт #ff. Кто помнит где про это написано было?
Spectramine
05.10.2022, 16:08
Эта тема мне навеяла воспоминание, что не так давно на оригинальных +3 был найден порт #ff. Кто помнит где про это написано было?
С какой целью интересуетесь? Вот тут я впервые упомянул эту фичу на этом форуме: https://zx-pk.ru/threads/23797-testirovanie-emulyatorov.html?p=891256&viewfull=1#post891256, ниже чутка обсуждение,
а потом в этой теме она была исследована на WOS:https://worldofspectrum.org/forums/discussion/55142/need-help-from-people-with-a-2a-3. Кратко результаты:
1. It is found on different ports.
The formula for the port number is (1 + (4 * n) && n < 0x1000) (that is ports 1, 5, 9, 13 . . . 4093)
2. The bus always returns $FF if bit 5 of port 32765 is set (i.e. paging is disabled).
3. However, if bit 5 is reset, the port read returns the value currently read by the ULA ORed with 1 (i.e. bit 0 is always set).
4. During non-contended intervals (that is, when the ULA is drawing the border or during the four T states in between reading the two pairs bitmap+attribute bytes of the display file), the bus retains the value that was last read from contended memory (usually, the last attribute byte read) and not $FF, as would be the case on the 48K/128K/+2.
5. Reading and writing from/to slow memory pages by Z80 (including operation code fetching) affects on floating bus too. So, (the value of the last operation with slow memory (pages 4,5,67) by Z80 or ULA) OR 1, will be returned by reading of floating bus ports.
Порты, с которых читается плавающая шина +2А/+3, это вроде бы порты их параллельного порта, с шаблоном: Centronics port decoding (0000 ---- ---- --0-). С порта #FF читаться не будет.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot