А что у команд бывают разные такты? Тут насколько я знаю вся разница с z80 что inc RP и inc R занимают по 5 тактов а не 6 и 4, ну по крайней мере так было в таблице что я нашел. Может есть еще какие хитрости в отличие от z80?
кстате для тех кто не понимает мнемоники 8080 как мну
Вложение 60149
Код:8080 z80
MOV A,A 5 4 LD A,A
MOV A,B 5 4 LD A,B
MOV A,C 5 4 LD A,C
MOV A,D 5 4 LD A,D
MOV A,E 5 4 LD A,E
MOV A,H 5 4 LD A,H
MOV A,L 5 4 LD A,L
MOV A,M 7 7 LD A,(HL)
LDAX B 7 7 LD A,(BC)
LDAX D 7 7 LD A,(DE)
LDA word 13 13 LD A,(word)
MOV B,A 5 4 LD B,A
MOV B,B 5 4 LD B,B
MOV B,C 5 4 LD B,C
MOV B,D 5 4 LD B,D
MOV B,E 5 4 LD B,E
MOV B,H 5 4 LD B,H
MOV B,L 5 4 LD B,L
MOV B,M 7 7 LD B,(HL)
MOV C,A 5 4 LD C,A
MOV C,B 5 4 LD C,B
MOV C,C 5 4 LD C,C
MOV C,D 5 4 LD C,D
MOV C,E 5 4 LD C,E
MOV C,H 5 4 LD C,H
MOV C,L 5 4 LD C,L
MOV C,M 7 7 LD C,(HL)
MOV D,A 5 4 LD D,A
MOV D,B 5 4 LD D,B
MOV D,C 5 4 LD D,C
MOV D,D 5 4 LD D,D
MOV D,E 5 4 LD D,E
MOV D,H 5 4 LD D,H
MOV D,L 5 4 LD D,L
MOV D,M 7 7 LD D,(HL)
MOV E,A 5 4 LD E,A
MOV E,B 5 4 LD E,B
MOV E,C 5 4 LD E,C
MOV E,D 5 4 LD E,D
MOV E,E 5 4 LD E,E
MOV E,H 5 4 LD E,H
MOV E,L 5 4 LD E,L
MOV E,M 7 7 LD E,(HL)
MOV H,A 5 4 LD H,A
MOV H,B 5 4 LD H,B
MOV H,C 5 4 LD H,C
MOV H,D 5 4 LD H,D
MOV H,E 5 4 LD H,E
MOV H,H 5 4 LD H,H
MOV H,L 5 4 LD H,L
MOV H,M 7 7 LD H,(HL)
MOV L,A 5 4 LD L,A
MOV L,B 5 4 LD L,B
MOV L,C 5 4 LD L,C
MOV L,D 5 4 LD L,D
MOV L,E 5 4 LD L,E
MOV L,H 5 4 LD L,H
MOV L,L 5 4 LD L,L
MOV L,M 7 7 LD L,(HL)
MOV M,A 7 7 LD (HL),A
MOV M,B 7 7 LD (HL),B
MOV M,C 7 7 LD (HL),C
MOV M,D 7 7 LD (HL),D
MOV M,E 7 7 LD (HL),E
MOV M,H 7 7 LD (HL),H
MOV M,L 7 7 LD (HL),L
MVI A,byte 7 7 LD A,byte
MVI B,byte 7 7 LD B,byte
MVI C,byte 7 7 LD C,byte
MVI D,byte 7 7 LD D,byte
MVI E,byte 7 7 LD E,byte
MVI H,byte 7 7 LD H,byte
MVI L,byte 7 7 LD L,byte
MVI M,byte 10 10 LD (HL),byte
STAX B 7 7 LD (BC),A
STAX D 7 7 LD (DE),A
STA word 13 13 LD (word),A
LXI B,word 10 10 LD BC,word
LXI D,word 10 10 LD DE,word
LXI H,word 10 10 LD HL,word
LXI SP,word 10 10 LD SP,word
LHLD word 16 16 LD HL,(word)
SHLD word 16 16 LD (word),HL
SPHL 5 6 LD SP,HL
XCHG 4 4 EX DE,HL
XTHL 18 19 EX (SP),HL
ADD A 4 4 ADD A,A
ADD B 4 4 ADD A,B
ADD C 4 4 ADD A,C
ADD D 4 4 ADD A,D
ADD E 4 4 ADD A,E
ADD H 4 4 ADD A,H
ADD L 4 4 ADD A,L
ADD M 7 7 ADD A,(HL)
ADI byte 7 7 ADD A,byte
ADC A 4 4 ADC A,A
ADC B 4 4 ADC A,B
ADC C 4 4 ADC A,C
ADC D 4 4 ADC A,D
ADC E 4 4 ADC A,E
ADC H 4 4 ADC A,H
ADC L 4 4 ADC A,L
ADC M 7 7 ADC A,(HL)
ACI byte 7 7 ADC A,byte
SUB A 4 4 SUB A
SUB B 4 4 SUB B
SUB C 4 4 SUB C
SUB D 4 4 SUB D
SUB E 4 4 SUB E
SUB H 4 4 SUB H
SUB L 4 4 SUB L
SUB M 7 7 SUB (HL)
SUI byte 7 7 SUB byte
SBB A 4 4 SBC A
SBB B 4 4 SBC B
SBB C 4 4 SBC C
SBB D 4 4 SBC D
SBB E 4 4 SBC E
SBB H 4 4 SBC H
SBB L 4 4 SBC L
SBB M 7 7 SBC (HL)
SBI byte 7 7 SBC byte
DAD B 10 11 ADD HL,BC
DAD D 10 11 ADD HL,DE
DAD H 10 11 ADD HL,HL
DAD SP 10 11 ADD HL,SP
DI 4 4 DI
EI 4 4 EI
NOP 4 4 NOP
HLT 7 4 HLT
INR A 5 4 INC A
INR B 5 4 INC B
INR C 5 4 INC C
INR D 5 4 INC D
INR E 5 4 INC E
INR H 5 4 INC H
INR L 5 4 INC L
INR M 10 11 INC (HL)
DCR A 5 4 DEC A
DCR B 5 4 DEC B
DCR C 5 4 DEC C
DCR D 5 4 DEC D
DCR E 5 4 DEC E
DCR H 5 4 DEC H
DCR L 5 4 DEC L
DCR M 10 11 DEC (HL)
INX B 5 6 INC BC
INX D 5 6 INC DE
INX H 5 6 INC HL
INX SP 5 6 INC SP
DCX B 5 6 DEC BC
DCX D 5 6 DEC DE
DCX H 5 6 DEC HL
DCX SP 5 6 DEC SP
DAA 4 4 DAA
CMA 4 4 CPL
STC 4 4 SCF
CMC 4 4 CCF
RLC 4 4 RLCA
RRC 4 4 RRCA
RAL 4 4 RLA
RAR 4 4 RRA
ANA A 4 4 AND A
ANA B 4 4 AND B
ANA C 4 4 AND C
ANA D 4 4 AND D
ANA E 4 4 AND E
ANA H 4 4 AND H
ANA L 4 4 AND L
ANA M 7 7 AND (HL)
ANI byte 7 7 AND byte
XRA A 4 4 XOR A
XRA B 4 4 XOR B
XRA C 4 4 XOR C
XRA D 4 4 XOR D
XRA E 4 4 XOR E
XRA H 4 4 XOR H
XRA L 4 4 XOR L
XRA M 7 7 XOR (HL)
XRI byte 7 7 XOR byte
ORA A 4 4 OR A
ORA B 4 4 OR B
ORA C 4 4 OR C
ORA D 4 4 OR D
ORA E 4 4 OR E
ORA H 4 4 OR H
ORA L 4 4 OR L
ORA M 7 7 OR (HL)
ORI byte 7 7 OR byte
CMP A 4 4 CP A
CMP B 4 4 CP B
CMP C 4 4 CP C
CMP D 4 4 CP D
CMP E 4 4 CP E
CMP H 4 4 CP H
CMP L 4 4 CP L
CMP M 7 7 CP (HL)
CPI byte 7 7 CP byte
JMP address 10 10 JP address
JNZ address 10 10 JP NZ,address
JZ address 10 10 JP Z,address
JNC address 10 10 JP NC,address
JC address 10 10 JP C,address
JPO address 10 10 JP PO,address
JPE address 10 10 JP PE,address
JP address 10 10 JP P,address
JM address 10 10 JP M,address
PCHL 5 4 JP (HL)
CALL address 17 17 CALL address
CNZ address 11/17 10/17 CALL NZ,address
CZ address 11/17 10/17 CALL Z,address
CNC address 11/17 10/17 CALL NC,address
CC address 11/17 10/17 CALL C,address
CPO address 11/17 10/17 CALL PO,address
CPE address 11/17 10/17 CALL PE,address
CP address 11/17 10/17 CALL P,address
CM address 11/17 10/17 CALL M,address
RET 10 10 RET
RNZ 5/11 5/11 RET NZ
RZ 5/11 5/11 RET Z
RNC 5/11 5/11 RET NC
RC 5/11 5/11 RET C
RPO 5/11 5/11 RET PO
RPE 5/11 5/11 RET PE
RP 5/11 5/11 RET P
RM 5/11 5/11 RET M
RST 0 11 11 RST 0
RST 1 11 11 RST 8
RST 2 11 11 RST 10H
RST 3 11 11 RST 18H
RST 4 11 11 RST 20H
RST 5 11 11 RST 28H
RST 6 11 11 RST 30H
RST 7 11 11 RST 38H
PUSH B 11 11 PUSH BC
PUSH D 11 11 PUSH DE
PUSH H 11 11 PUSH HL
PUSH PSW 11 11 PUSH AF
POP B 10 10 POP BC
POP D 10 10 POP DE
POP H 10 10 POP HL
POP PSW 10 10 POP AF
IN byte 10 11 IN A,(byte)
OUT byte 10 11 OUT (byte),A
по крайней мере этим пользуюсь я
А нет, так не пойдет. Не принято
- - - Добавлено - - -
Сравните bc #101 и #100, будет понятно почему не покатит.
накинуть единичку при старте...
и мы же не эмулируем ldir
он и на флаги не особо влияет в оригинале...
просто задавать уже с учетом
Не совсем.
Можно старт сделать
Тогда вроде прокатывает. -1 байтКод:dec bc
inc c
inc b
- - - Добавлено - - -
Так по тактам не все я запомнил, получается
Табличка пригодилась, спасибо, мне так удобнее запомнить, может еще кому.Код:ld r,r 5(4)
dec/inc r 5(4)
dec/inc (hl) 10(11)
dec/inc rp 5(6)
ld sp,hl 5(6)
jp (hl) 5(4)
ex (sp),hl 18(19)
add hl,rp 10(11)
call c,addr 11/17(10/17)
in a,(port) 10(11)
out (port),a 10(11)
на всякий лучше ее еще кому то сверить
тк я ее делал из другой таблички...
Вот схема видеовыхода совместимая со старым цветом. В режиме старого цвета выполняется прямое управление лучами кинескопа, а сигнал RVV выбирает - в знакоместе задаётся цвет фона или цвет символа. В режиме нового цвета, сохранены 8 цветов, причём цвет имеет одновременно и символ и фон, а бит RVV освобождён для использования в качестве оперативного коммутатора фонтов, что позволяет одновременно в одном экране иметь 256 символов. Таким образом, расходом в 2 корпуса достигается не только выигрыш в качестве цвета, но и в количестве доступных символов.Цитата:
Сообщение от Vital72
Сигнал "Video" с выхода ИР13 управляет тем, будет выдан на выход код цвета символа или код фона. Сочетания цветов любые, т.е и цвет фона и цвет символа могут быть любыми из 256 цветов. Но всего сочетаний цветов - только 8. Код этого сочетания как-раз и поступает с выходов ВГ75. Таким образом эти 3 бита не цвет, а код, задающий какими чернилами и на каком фоне рисуется символ.
В режиме совместимости сигнал "Mode" равен 1, отчего сигнал RVV проходит и схема работает как и ранее. Одновременно сигналом "Mode" формируется ноль на входе ПЗУ фонта, отчего включён базовый фонт, что и требуется для антикварных программ. Естественно, в режиме совместимости сигналы PB0...PB4 с D14, также задающие номер фонта (если фонтов больше 2-х), должны быть нулями, чтобы был включён базовый фонт. ПЗУ РЕ3 прошито так, что в режиме совместимости со старым цветом на всех весах Rx, Gx, Bx полностью повторяются сигналы на 3-х входах РЕ3 (как будто бы РЕ3 вообще нет), что и обеспечивает совместимость.
В режиме нового цвета сигналом "Mode"=0 запрещается прохождение RVV на схему инверсии на ЛП5, - вместо RVV туда подаётся 0, отчего схема инверсии не действует. В режиме нового цвета инверсный сигнал "Мode" разрешает поступление на вход А10 ПЗУ знакогенератора сигнала от атрибутного выхода RVV ВГ75. Тем самым в этом режиме бит RVV служит для оперативный смены фонта. Благодаря использованию РЕ3, в новом режиме число цветов не изменилось, причём цвета стали более удобными для программ.
В качестве сигнала Mode, который переключает режим цвета, используется сигнал с тумблера или разряд порта C ППА D14.
Путём расхода ещё двух КП11 можно получить в данной схеме 2 палитры. Тогда коммутация выходов RGB делается не за счёт совместимой прошивки РЕ3, отчего сигнал "Mode" не подаётся на РЕ3 и её один вход освобождается. КП11-е коммутируют 8 выходов РЕ3. В режиме совместимости на выходы КП11 проходят сигналы GPA0, GPA1, HGLT (как в старой схеме цвета). А в режиме нового цвета на выходы проходят сигналы с РЕ3. На освободившийся адресный вход РЕ3 подаём бит выбора палитры PA0 ППА D14.
Однако, если для кодо-преобразования применять не РЕ3, а РТ5, то и без двух КП11-х получается 16 палитр выбираемых PA0...PA3 ППА D14.
Внимание. В данной схеме есть одно важное ограничение. Которое связано с тем, что в РК86 физически отсутствует сигнал BORDER, которым можно было бы гасить RGB на время обратного хода развёрток. Этот сигнал отсутствует по причине программного формирования бордюра, за счёт заполнения части экранного ОЗУ кодами 0 или пробел. Необходимо гасить RGB во время вывода бордюра (иначе сорвётся синхронизация. После вывода печатаемых символов строки все атрибутные сигналы сброшены, т.е 0. Это соответствует коду цвета 0. Код символа тоже 0 (или пробел). Таким образом во время бордюра выводится код цвета 0 и пустой символ, т.е выводится только цвет фона. Таким образом возникает ограничение, - цвет фона для кода цвета 0 - всегда должен быть чёрным. Из-за этого код 0 нельзя сделать желтым на синем, но можно сделать зеленым на чёрном и это будет код монохрома.
;--------------------
Решена проблема регенерации SIMM большого объёма. Для этого вводится счётчик регенерации, формирующий адреса регенерации A8, A9, A10, A11. Этот счётчик переключается с периодом вывода 4-х строк в момент вывода первой линии знакоместа. 4 строки необходимы, т.к в одной строке регенерируется только 64 столбца. 256 столбцов регенерируются за 4*64*10=2.56 МСЕК. SIMM 256 кб регенерируется за 5.12 МСЕК, SIMM 1 мб регенерируется за 10.24 МСЕК, а SIMM 16 мб регенерируется за 40.96 МСЕК, что с запасом удовлетворяет паспортным данных всех микросхем.
Режим с высотой строки 8 линий, наиболее близкий к PAL/SECAM стандарту:
85*39 = (79+6)*(38+1) = 15686*50.277 Гц
Один мой современный и придирчивый к сигналу телевизор показывает этот режим стабильно, в отличии от стандартного РК-шного.
Размер фреймбуфера 79*38 = 3002 байта
Aspect ratio псевдографического пикселя и знакоместа примерно 15:22 = 1:1.466
Во вложении пример для РК,Апогея и Микроши.
По ссылке фото с экранов - посмотреть, сколько видно, сколько обрезается.
УЭИТ для сравнения. Везде композитный вход (CVBS), кроме crt2 - это RGB монитор.
Не смог понять ход твоих мыслей, как у тебя получилось 15/22?
По теории у меня вышло 13:9 = 1.44(4) - очень близко, но не 15/22
Как считал: видимая часть строки: 52 мс или 69 + 1/3 символа
Видимых скан-линий - 288 или 288/8 = 36 строк
(69 + 1/3) / 36 * 3/4 = 13/9
Причем от конкретного режима вроде бы зависеть особо не должно.
krt17, к сожалению, у тебя ЛС недоступны, спрошу здесь.
Не поделишься своей тестовой утилиткой, пусть даже не окончательной версией? Надо бы кое-что потестировать в эмуляторе, как раз пригодилась бы, а скачать, пока она была доступна, не успел...
Без проблем. Формирование видео сигнала в РК абсолютно выбило меня, я пас, вернусь к zx. Желаю всем РК-шникам успехов в их нелегком деле :)
krt17, спасибо!
Да, в некотором смысле в спектруме все проще.
Если честно, то я сомневаюсь, что изучение формирования видео в РК приведет к реальному прорыву в написании игр вроде псевдографики высокого разрешения и т.п. - очень уж сложно все учесть.
Но по крайней мере достигнем лучшего понимания работы БИС и лучшей эмуляции - уже неплохо.
C псевдографикой высокого разрешения писать программы намного сложнее, чем чисто текстовые. Не делайте прорыв в псевдографике. Сделайте прорыв в играх с аппаратными спрайтами (по принципу Денди). Псевдографика - вынужденная мера, когда фонт всего один. А если есть несколько фонтов, то красивые графические спрайты намного приятнее, чем псевдографика 128*50 (и даже, чем 192*60).Цитата:
Сообщение от Pyk
Имею вопрос по, находящимся в разработке, немерцающим программам. Они, как я понял, рассчитываются на самый базовый журнальный вариант, куда и лишний проводок припаять не разрешено. Но ведь всякий нормальный пользователь имеет модификации. В частности, с помощью расхода куска проволоки, подающего на ВТ57 клок 2.66 МГЦ вместо 1.77, быстродействие увеличивается (на 13.5%). А если подать туда клок 3.2 МГЦ (16:5=3.2), то быстродействие возрастает ещё больше (на 20%). Ну а тот, кто имеет электро паяльник и в состоянии смонтировать отдельный задающий генератор с кварцем 16 МГЦ и заменить кварц у ГФ24 на 30 МГЦ (по ж.РАДИО 01.1991), тот получает ТУРБО в 2.5 раза (на 150%).
Так вот вопрос. Если Ваша игра не мерцает на базовом тормозном РК86 с реальным тактом в 1.3 МГЦ, то это значит, что она не будет мерцать и на моём РК86 с двойным быстродействием (или даже с акселератором на базе Z80B с тактом 9 МГЦ). Я так понимаю, что на более быстром РК процедура работы с экраном привязанная к КСИ, заведомо будет успевать выполняться за 3.84 МСЕК (время гашения по кадрам: 6 строк * 10 линий * 64 МКСЕК). Т.е на любой модификации РК, где реальная скорость прогона равна или незначительно превышает скорость базового РК86, то никаких мерцаний в игре, рассчитанной на базовый РК, - не будет? Или же сдвижка быстродействия немного в плюс-минус - расстрел? Т.е игра на чуть отличающемся железе будет мерцать по страшной силе.
Некоторые пользователи РК86, не имеющие RGB-монитора с частотой строк в 15.6 КГЦ, но сделавшие простейшую доработку до цвета (ЛИ1 + ЛП5), вынуждены смотреть цветные РК-игры на старых монохромных мониторах (вместо цветов - градации яркости). Однако ещё в 2014 году Alex_LG разработал простейший вариант подключения РК86 к цветному VGA монитору. Для чего достаточно заменить кварц 16 МГЦ на 24 и подпаять 15-ти контантный VGA-разъём (одновременно такая переделка даёт ТУРБО в 1.75 раза, для НЕТУРБО оставляют и старый кварц 16 МГЦ).
Я тоже не имею цветного CGA-монитора, потому после монтажа схемы для цвета, мне придётся подключать VGA-монитор. Кстати, РК86 - это единственный комп, где возможно использование VGA, тогда как на других бытовых компьютерах - это неразрешимая проблема. Так вот. При другой частоте строк (31 МГЦ) и кадров (50-70 ГЦ), как себя поведут немерцающие программы привязанные к КСИ?
Используя обнаружение КСИ через регистр статуса ВГ75, предположительно можно:
- опираясь на частоту кадров, определить реальный такт КР580
- опираясь на известный такт КР580 (1.77 или другой), можно точно рассчитать частоту кадров и частоту строк, на основании чего определить - видео вывод идёт на CGA или VGA.
Это возможно, потому что так делал Е.Седов, написавший программу точной подстройки скорости вращения колеса в дисководе. Т.е у РК86 всё-таки есть какая-то привязка к реальному времени.
А почему до сих пор никто не обратил внимание на вход для светового пера? Сигнал на этом входе тоже можно обнаруживать программно. Например, можно завести туда 50 Гц делённые на 10? С несложной схемой можно обнаруживать не только КСИ, но и самое начало кадрового бордюра.
Вопрос не ясен. Приведена моя цитата и понятие встречный вопрос означает, что вопрос к тому, кто задавал первый вопрос. Таким образом логично предположить, что это вопрос ко мне. Но, если Вы прочитаете эту тему с начала, то Вы обнаружите, что я то как-раз считаю, что игры РК86 не мерцают и без использования апп.прерываний с частотой КСИ. Поэтому, к сожалению, не могу ответить на Ваш вопрос о том, какие игры РК86 мерцают. Это вопрос не ко мне, а к тем, что утверждает, что такие мерцающие игры существуют.Цитата:
Сообщение от zebest
А то, что имеющиеся игры РК86 мерцают, т.к не используют модификацию экрана во время гашения экрана, утверждают "залётные" синклеристы. И целью этой темы, по крайней мере, на протяжении последних 20 страниц, является выяснить, как можно делать немерцающие игры. А попутно и доказать, что все кто программировал для РК86 ранее, - были недостаточно квалифицированы. Чтобы научиться делать немерцающие игры, а также обнаружить другие полезные для игр ресурсы железа РК86, и осуществляется в этой теме разборка временнЫх свойств применённых БИС с помощью изучения документации и тестовых программ прогоняемых на реале и в эмуляторах.
Я как залетный могу лишь вспомнить что кое кто тут предлагал вырубать экран вообще для его обновления, и якобы если на 1 фрейм то будет не заметно :) Мерцания не замечал, да и чему мерцать то если вся динамика , как правило, в 10 байтах.
Как делать "немерцающие" игры я думаю понятно всем за исключением barsik'а, и, судя по тому что отлавливание IR флага обычное дело, все так всегда и делали. Мы же тут разбирались как именно работает в РК i8275 и i8257 и как это тормозит проц. Разобрались уже давно. При всем при этом код и примеры были только от нео спектрумана, ДДП и меня, а от профи с 30 опытом только несколько нерабочих, непонятно для чего предназначенных фрагментов.
ну думаю что можно взять и просто так рассчитать частоту проца
погрешность будет сильно большая
ну 1.7 от 2.5 думаю вполне отличить можно будет...
а за частоту строк...
мерцают программы только у тех кто совсем не понимает что нельзя просто так кидать в видео память фон а потом сверху дорисовывать все остальное
если использовать буфер то проблемы этой никогда не будет
а с этим у РК проблем нет
у него небольшой экран
у него куча памяти
у него возможность двигать видео память куда пожелается (правда нужно уже писать программу которая будет постоянно синхронизироваться с КСИ(тоесть полный потактовый расчет всего кода и всех ветвлений и установка задержке для выравнивания или счетчиков тактов...))
проблема в том что писатели программ на РК кодили примитивно в лоб
да и не могу я сходу вспомнить "мерцающие программы"
вот для львова это повсеместная проблема...
там криво мерцает 90% софта...
обнаружение последний строки до КСИ хватает с головой
на этот момент изображение последней строки буферизировано
и можно спокойно менять содержимое видео памяти
и перенастраивать ДМА не боясь получить кашу на экране...
- - - Добавлено - - -
щас у меня скоро появится еще немного свободного времени
и я вернусь
и запилю этот *****й pseudohires!!
(по крайней мере я на это надеюсь)
нужно еще провести несколько тестов на реальном железе...
и с осциллографом...
Почему же нельзя? Я уверен, что наоборот можно и точность будет идеальная +/- 0.01. Смотрите сами. Частота кварца и частота ВТ57 (т.е время захватов) меняется, а вот частота ВГ75 - это константа. До сих пор известно только 3 частоты - кварц 16 МГЦ стандарт, 20 МГЦ (когда знакоместо не 6*8, а 8*8 за счёт замены ИЕ4 на ИЕ5 + 2 диода) и 24 МГЦ, когда видео вывод идёт на VGA. И частота кадров всегда 50 ГЦ (точнее такая, что задана режимом ВГ75).Цитата:
Сообщение от NEO SPECTRUMAN
Так что при желании можно делать универсальные игры. Тогда при старте игра оценивает скорость КР580 и соответственно меняет константы торможения. Просто дорабатывать на универсальность игры, в которых есть уровни. Обычно уровни отличаются только тем, что в более высоком уровне константы торможения меньше.
Вы имеете ввиду, что хватает для программной замены аппаратного прерывания по КСИ.Цитата:
Сообщение от NEO SPECTRUMAN
В нормальной машине было бы лучше, т.к там сразу после последней строки начинается аппаратное гашение (строки на обратный ход луча по кадрам), т.е то что надо. А в РК86 бордюр программный, так что по IR мы определяем в РК86 только начало КСИ, т.е лишь середину периода гашения по кадрам, а не начало гашения.
Но, если Вы считаете, что этого хватает, то нет проблем.
А почему программы для ЛЬВОВА мерцают больше, чем программы СПЕЦИАЛИСТА, ВЕКТОРА и ОРИОНА на КР580 ? Во всех 4-х - процессор КР580 и нет прерываний, а во ЛЬВОВЕ, наоборот, даже экран меньше, значит перерисовка экрана происходит быстрее, отчего мерцаний меньше.Цитата:
Сообщение от NEO SPECTRUMAN
К тому же ЛЬВОВ это отечественный ответ сэру Синклеру, т.е машинка чисто для игр (с маленьким экраном), значит никаких проблем в играх там быть не может.
Я просто забыл что можно отключить экран и проц освободится...
- - - Добавлено - - -
а были бы прерывания
и одни и те же игры(нормально написанные) работали бы на любой частоте проца
хоть на 0.5 МГц
хоть на 100600 ТГц
без какого либо изменения задержек...
грусть печаль....
- - - Добавлено - - -
А если его отключить то не с чем синхронизироваться!!! (или нет(щас гляну в мануал))
и уже нельзя ничего считать!!!
нет в мануале сказано они остаются!!!
- - - Добавлено - - -
как замена никудышняя
но хоть что то
этот флаг прерывания
включается в последней строке знакомест
когда рисуется первая линия последней строки(по идеи)
и до начала КСИ там еще
и этот программный бордюр вон успешно видно на LCD-шниках по самое немогу(процентов 99 точно)...
и забейте на свое гашение
какое еще гашение???
гашение чего???
я генерировал примитивный видео сигнал без какого либо гашения (белый фон и синхроимпульсы - провалы до 0)
все прекрасно ловилось и гасилось (что телек сам не может погасить луч когда поймал синхроимпульс чтоле???(не я не уверен конечно...))
и никаких следов обратного хода луча и в помине не было
это ваше "гашение" нужно в цветных телеках чтоб находить уровень черного и там еще у них какая то фигня для цвета расположена(не помню как называется)...
просто нужно учитывать то что не на всех телеках видно весь экран
Да ну, 29 кБ - это большая ?? даже по меркам спека
device zxspectrum128 в данном случае спасет горе-программистов?
без disp #0000 - не портит. и даже вроде с disp #0004 - тоже нормально
org #4000 в начале я думаю спасет, че там сжасм делает не понятно.
Проверяем тесты на железных апогеях
подход\код несколько брутальный и вероятность того что он даст нормальный результат стремится к 0
Вложение 60207
возможно я там накосячил и оно вообще не может работать
но нормально отладить мне не на чем...
Скрытый текст
это только смещение для компилируемого кода
(оно рассчитано на компиляцию процедур которые будут потом перемещены)
lua видит память спектрума без какого либа смещения
нужно делать -/+4 в lua
мне задолбалось ловить глюки вызванные этим смещением
и я решил что проще отдать первые 4 байта
хотя можно компилировать
а потом при помощи другого исходника
в котором incbin результат работы пред компиляции
и считание контрольных сумм
все сделать в одном батнике, которым все и компилируют
может можно будет
после savebin
сразу же сделать incbin только что сохраненного по смещению 4
добавить адреса спереди и КС
ЭТО Я ОТВЕТИЛ НЕ ДОЧИТАВ О ЧЕМ РЕЧЬ...
мдаааа.....
прикольно сджасм крашится при попытке сделать lua allpassКод:01 0000 device zxspectrum48
02 0000 org #0000
03 0000 rkBegin
04 0000 00 00 db progBegin/#100,progBegin&#ff
05 0002 73 16 db (progEnd-1)/#100,(progEnd-1)&#ff
06 0004 binBegin
07 0004 disp #0000
08 0000 progBegin
09 0000 ;-------------------------------------------
10 0000 ; code here
11 0000 ; jp $
12 0000 incbin "RK-86.bin"
13 7317 ;-------------------------------------------
14 7317 progEnd
15 7317 ent
16 731B binEnd
17 731B cs = 0
18 731B lua pass3
19 731B~ mems=_c("binBegin")
20 731B~ meme=_c("binEnd")
21 731B~ cs=0
22 731B~ for i=mems,meme-2 do
23 731B~ cs=(cs+sj.get_byte(i)*257)
24 731B~ end
25 731B~ cs=(cs-cs%256+(cs+sj.get_byte(meme-1))%256)%65536
26 731B~ _pl("cs = "..cs)
27 731B cs = 11373
27 731B endlua
28 731B display cs
29 731B 0000E62C6D db 0,0,#e6,cs/#100,cs&#ff
30 7320 rkEnd
31 7320 savebin "prog.rk",rkBegin,rkEnd-rkBegin
Value Label
------ - -----------------------------------------------------------
0x0000 rkBegin
0x0000 progBegin
0x7317 progEnd
0x0004 X binBegin
0x731B X binEnd
0x2C6D cs
0x7320 rkEnd
может єто традиционные траблы со всякими include-ми?
нужно запихнуть все єто в виде defb и нлянуть
...нет bin2hex щас под рукой...[свернуть]
СКОРМИЛ СВЕЖЕМУ SJASM-У
https://github.com/mkoloberdin/sjasm...s/tag/20170311
И ВРОДЕ ВСЕ НОРМ!!!!
Тесты 1, 3 и 4 на реальном Апогее ничего не показывают.
Тест 2 выдаёт такую картинку:
Скрытый текст
При этом синхронизация периодически срывается.
Сейчас остальные попробую..
С остальными тестами то же самое - ничего нет на экране
во втором и четвертом тесте
включено 0 тактов между запросами ПДП
видимо ДМА не успевает за строку перекинуть столько памяти (почему??? я брал с запасом...)
и как и сказано ВГ75 тушит єкран при потере данных...
в принципе раз второй пример более менее работает
можно попытаться копнуть в этом направлении
непонятно где все остальное только...
оно не мигает??
на частоте 200Гц случаем о_О???
Нет, не мигает. Думаю ЖК-ТВ просто не понимает сигнал.
Чтобы удостовериться что я всё делаю правильно и Апогей рабочий, загрузил пару игр от vinxru:
http://savepic.ru/13352697m.jpg http://savepic.ru/13341433m.jpg
http://savepic.ru/13335289m.jpg http://savepic.ru/13320953m.jpg
Вложение 60208
еще вариант
- - - Добавлено - - -
не просто видео сигнал получается сильно дырявым и не по ГОСТ-у
а еще я зря туда вставил атрибуты (с первого раза да еще и захотел мультиколор :v2_dizzy_facepalm:)
сразу после ССИ они наверное еще хуже делают
телек то проглатывает дырки посреди строки
но потери целой он уже...
Скрытый текст
Мдаа....
- - - Добавлено - - -
дырка посреди картинки и текста
это кадровый синхроимпульс размером 8 линий
+ пустое место (чуть больше строки)
а только потом всякий мусор
после него должно быть 4 такие же картинки 90х64(в данном случае 30х64 с широкими пикселями)...(а их только одна(и то кусочек))
нет недопсевдохайрес мы то получили
ну его качество...
мягкоговоря...
оно вообще поймает теплый ламповый телек???
может я накосячил?
А в чём вообще идея?
Скрытый текст
Мельком посмотрел код. Сначала инициализируем контроллер дисплея на короткий экран в 6 строк, а потом отлавливаем начало вывода последней строки и не даём ему сделать вертикальный обратный ход. Подставляем контроллеру новые значения и он продолжает рисовать новый экран, который по факту оказывается продолжением старого. Так?
[свернуть]
Так.
а тут нет
мы не можем(не знаем как) выкинуть КСИ как бы нам этого не хотелось
Основная проблема что максимальное число строк 64
А в режиме 1 линия пикселей на строку
мы хоть и можем что нибудь положить в строчный буфер
но получается 240 Гц кадровая развертка
и нужно как то продлить изображение
Тут все с расчетом на то что телек не успеет понять что перед ним левый короткий КСИ
а Зацепится за более широкий КСИ (телек может игнорить дырки в сигнале(правда изображение становится волнами(похожее видно в обоих изображениях вверху)))
Для успешной работы этого подхода
нужно искать более высокую частоту строчных(уменьшать ширину экрана) которую может ловить телек
чтоб еще уменьшить время существования лишних КСИ и чтоб телек за них не цеплялся
за одно это расширит hires область на экране
(расширение в 2 раза за счет высоты строки 2 пикселя(окошко как минимум 62x128 пиксели 3х1) видимо не прокатит из за увеличения ширины левых КСИ
хотя тоже можно ткнуть одну картинку по центру и глянуть
расширение в 3 раза(окошко 94х64 пиксели 3х3) могло бы дать РК-шкам такое же разрешение(плотность пикселей на сантиметр)))) по вертикали как в апогее со вторым набором шрифтов. Да и площадь такого экранчика уже бы была ~47 знакомест по горизонтали)
можно попытаться оставить только одно окошко по центру высотой 64 пикселей
возможно такое будет лучше синхронизироваться
нужно попробовать ткнуть белую полосу сразу после КСИ
у меня есть идея как переместить это окошко в центр
но качество видео сигнала станет еще ниже...
и вообще вся надежда на не исследованный пресет счетчиков
если при помощи него можно будет погасить КСИ, ССИ
то мы сможем сами программно генерировать дополнительные КСИ, ССИ которых нам не хватает
если при пресете сразу включаются КСИ, ССИ уже будет сложнее
но можно будет все равно по извращаться
нужно еще посмотреть что делает серия беспрерывных сбросов
или сбросов без указания параметров
и разные комбинации сбросов, разрешений, запрещений
тк судя по документации КСИ и ССИ никогда не прекращаются
стоп дисплей их не тушит
что делает с ними пресет счетчиков неизвестно...
Ещё один цветовой "чит" на Апогее:
http://savepic.ru/13350630m.jpg
Империя наносит ответный удар
Вложение 60225
я только предполагаю что должно быть на экране...
как всегда эмуляция этого посредственная (2 эмуля - 2 разных картинки(и как по мне обе не те)...)
вполне возможно будет черный экран