Секреты и трюки программирования (в том числе и игр) для РК-86

[barsik]

сомневаюсь, что изучение формирования видео в РК приведет к реальному прорыву в написании игр для псевдографики высокого разрешения

C псевдографикой высокого разрешения писать программы намного сложнее, чем чисто текстовые. Не делайте прорыв в псевдографике. Сделайте прорыв в играх с аппаратными спрайтами (по принципу Денди). Псевдографика - вынужденная мера, когда фонт всего один. А если есть несколько фонтов, то красивые графические спрайты намного приятнее, чем псевдографика 128*50 (и даже, чем 192*60).

Имею вопрос по, находящимся в разработке, немерцающим программам. Они, как я понял, рассчитываются на самый базовый журнальный вариант, куда и лишний проводок припаять не разрешено. Но ведь всякий нормальный пользователь имеет модификации. В частности, с помощью расхода куска проволоки, подающего на ВТ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? С несложной схемой можно обнаруживать не только КСИ, но и самое начало кадрового бордюра.

[barsik]

Имею встречный вопрос по списку мерцающих\<мерцающих со СТРАШНОЙ силой> программ. Ну хотя бы первый десяток?

Вопрос не ясен. Приведена моя цитата и понятие встречный вопрос означает, что вопрос к тому, кто задавал первый вопрос. Таким образом логично предположить, что это вопрос ко мне. Но, если Вы прочитаете эту тему с начала, то Вы обнаружите, что я то как-раз считаю, что игры РК86 не мерцают и без использования апп.прерываний с частотой КСИ. Поэтому, к сожалению, не могу ответить на Ваш вопрос о том, какие игры РК86 мерцают. Это вопрос не ко мне, а к тем, что утверждает, что такие мерцающие игры существуют.

А то, что имеющиеся игры РК86 мерцают, т.к не используют модификацию экрана во время гашения экрана, утверждают "залётные" синклеристы. И целью этой темы, по крайней мере, на протяжении последних 20 страниц, является выяснить, как можно делать немерцающие игры. А попутно и доказать, что все кто программировал для РК86 ранее, - были недостаточно квалифицированы. Чтобы научиться делать немерцающие игры, а также обнаружить другие полезные для игр ресурсы железа РК86, и осуществляется в этой теме разборка временнЫх свойств применённых БИС с помощью изучения документации и тестовых программ прогоняемых на реале и в эмуляторах.

[krt17]

утверждают "залётные" синклеристы.

Я как залетный могу лишь вспомнить что кое кто тут предлагал вырубать экран вообще для его обновления, и якобы если на 1 фрейм то будет не заметно Мерцания не замечал, да и чему мерцать то если вся динамика , как правило, в 10 байтах.
Как делать "немерцающие" игры я думаю понятно всем за исключением barsik'а, и, судя по тому что отлавливание IR флага обычное дело, все так всегда и делали. Мы же тут разбирались как именно работает в РК i8275 и i8257 и как это тормозит проц. Разобрались уже давно. При всем при этом код и примеры были только от нео спектрумана, ДДП и меня, а от профи с 30 опытом только несколько нерабочих, непонятно для чего предназначенных фрагментов.

[NEO SPECTRUMAN]

Используя обнаружение КСИ через регистр статуса ВГ75, предположительно можно:
- опираясь на частоту кадров, определить реальный такт КР580
- опираясь на известный такт КР580 (1.77 или другой), можно точно рассчитать частоту кадров и частоту строк, на основании чего определить - видео вывод идёт на CGA или VGA.

ну думаю что можно взять и просто так рассчитать частоту проца
погрешность будет сильно большая
ну 1.7 от 2.5 думаю вполне отличить можно будет...
а за частоту строк...

Имею вопрос по, находящимся в разработке, немерцающим программам.

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

проблема в том что писатели программ на РК кодили примитивно в лоб
да и не могу я сходу вспомнить "мерцающие программы"
вот для львова это повсеместная проблема...
там криво мерцает 90% софта...

С несложной схемой можно обнаруживать не только КСИ, но и самое начало кадрового бордюра.

обнаружение последний строки до КСИ хватает с головой
на этот момент изображение последней строки буферизировано
и можно спокойно менять содержимое видео памяти
и перенастраивать ДМА не боясь получить кашу на экране...

- - - Добавлено - - -

этом код и примеры были только от

щас у меня скоро появится еще немного свободного времени
и я вернусь

и запилю этот *****й pseudohires!!
(по крайней мере я на это надеюсь)

нужно еще провести несколько тестов на реальном железе...
и с осциллографом...

[barsik]

Не думаю что можно взять и просто так рассчитать частоту проца. Погрешность будет сильно большая

Почему же нельзя? Я уверен, что наоборот можно и точность будет идеальная +/- 0.01. Смотрите сами. Частота кварца и частота ВТ57 (т.е время захватов) меняется, а вот частота ВГ75 - это константа. До сих пор известно только 3 частоты - кварц 16 МГЦ стандарт, 20 МГЦ (когда знакоместо не 6*8, а 8*8 за счёт замены ИЕ4 на ИЕ5 + 2 диода) и 24 МГЦ, когда видео вывод идёт на VGA. И частота кадров всегда 50 ГЦ (точнее такая, что задана режимом ВГ75).

Так что при желании можно делать универсальные игры. Тогда при старте игра оценивает скорость КР580 и соответственно меняет константы торможения. Просто дорабатывать на универсальность игры, в которых есть уровни. Обычно уровни отличаются только тем, что в более высоком уровне константы торможения меньше.

обнаружения последней строки хватает с головой

Вы имеете ввиду, что хватает для программной замены аппаратного прерывания по КСИ.

В нормальной машине было бы лучше, т.к там сразу после последней строки начинается аппаратное гашение (строки на обратный ход луча по кадрам), т.е то что надо. А в РК86 бордюр программный, так что по IR мы определяем в РК86 только начало КСИ, т.е лишь середину периода гашения по кадрам, а не начало гашения.

Но, если Вы считаете, что этого хватает, то нет проблем.

вот для ЛЬВОВА это повсеместная проблема...
там криво мерцает 90% софта...

А почему программы для ЛЬВОВА мерцают больше, чем программы СПЕЦИАЛИСТА, ВЕКТОРА и ОРИОНА на КР580 ? Во всех 4-х - процессор КР580 и нет прерываний, а во ЛЬВОВЕ, наоборот, даже экран меньше, значит перерисовка экрана происходит быстрее, отчего мерцаний меньше.

К тому же ЛЬВОВ это отечественный ответ сэру Синклеру, т.е машинка чисто для игр (с маленьким экраном), значит никаких проблем в играх там быть не может.

[NEO SPECTRUMAN]

Я просто забыл что можно отключить экран и проц освободится...

- - - Добавлено - - -

Так что при желании можно делать универсальные игры. Тогда при старте игра оценивает скорость КР580 и соответственно меняет константы торможения. Просто дорабатывать на универсальность игры, в которых есть уровни. Обычно уровни отличаются только тем, что в более высоком уровне константы торможения меньше.

а были бы прерывания
и одни и те же игры(нормально написанные) работали бы на любой частоте проца

хоть на 0.5 МГц
хоть на 100600 ТГц

без какого либо изменения задержек...

грусть печаль....

- - - Добавлено - - -

А если его отключить то не с чем синхронизироваться!!! (или нет(щас гляну в мануал))
и уже нельзя ничего считать!!!
нет в мануале сказано они остаются!!!

- - - Добавлено - - -

Вы имеете ввиду, что хватает для программной замены аппаратного прерывания по КСИ.

как замена никудышняя
но хоть что то

В нормальной машине было бы лучше, т.к там сразу после последней строки начинается аппаратное гашение (строки на обратный ход луча по кадрам), т.е то что надо. А в РК86 бордюр программный, так что по IR мы определяем в РК86 только начало КСИ, т.е лишь середину периода гашения по кадрам, а не начало бордюра.

этот флаг прерывания
включается в последней строке знакомест
когда рисуется первая линия последней строки(по идеи)
и до начала КСИ там еще

и этот программный бордюр вон успешно видно на LCD-шниках по самое немогу(процентов 99 точно)...

и забейте на свое гашение
какое еще гашение???
гашение чего???
я генерировал примитивный видео сигнал без какого либо гашения (белый фон и синхроимпульсы - провалы до 0)
все прекрасно ловилось и гасилось (что телек сам не может погасить луч когда поймал синхроимпульс чтоле???(не я не уверен конечно...))
и никаких следов обратного хода луча и в помине не было

это ваше "гашение" нужно в цветных телеках чтоб находить уровень черного и там еще у них какая то фигня для цвета расположена(не помню как называется)...

просто нужно учитывать то что не на всех телеках видно весь экран

[krt17]

Косяк в Ужасм-е или снова у меня? или?

Ужасм портит, device zxspectrum48 виноват большую слишком прогу вы сделали

[zebest]

Да ну, 29 кБ - это большая ?? даже по меркам спека
device zxspectrum128 в данном случае спасет горе-программистов?
без disp #0000 - не портит. и даже вроде с disp #0004 - тоже нормально

[krt17]

org #4000 в начале я думаю спасет, че там сжасм делает не понятно.

[NEO SPECTRUMAN]

Проверяем тесты на железных апогеях
подход\код несколько брутальный и вероятность того что он даст нормальный результат стремится к 0
tzts.zip
возможно я там накосячил и оно вообще не может работать
но нормально отладить мне не на чем...

я так думаю это из за disp #0000

Скрытый текст

это только смещение для компилируемого кода
(оно рассчитано на компиляцию процедур которые будут потом перемещены)
lua видит память спектрума без какого либа смещения
нужно делать -/+4 в lua

мне задолбалось ловить глюки вызванные этим смещением
и я решил что проще отдать первые 4 байта

хотя можно компилировать

а потом при помощи другого исходника
в котором incbin результат работы пред компиляции
и считание контрольных сумм

все сделать в одном батнике, которым все и компилируют

может можно будет
после savebin
сразу же сделать incbin только что сохраненного по смещению 4
добавить адреса спереди и КС

ЭТО Я ОТВЕТИЛ НЕ ДОЧИТАВ О ЧЕМ РЕЧЬ...

мдаааа.....

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

прикольно сджасм крашится при попытке сделать lua allpass

может єто традиционные траблы со всякими include-ми?
нужно запихнуть все єто в виде defb и нлянуть
...нет bin2hex щас под рукой...

[свернуть]

СКОРМИЛ СВЕЖЕМУ SJASM-У
https://github.com/mkoloberdin/sjasm...s/tag/20170311
И ВРОДЕ ВСЕ НОРМ!!!!