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

[zebest]

ну да, скрипт на lua - это же так просто.

[NEO SPECTRUMAN]

ну да, скрипт на lua - это же так просто.

просто

но отлаживать его если оно не будет с ходу работать
рассматривать эти долбанные print-ы
которые в командной строке не бесконечно хранятся...

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

+списка доступных команд в sjasm-е нету (во всех мануалах по lua их побольше да и написание местами не совпадает...)
все методом научного тыка...

[barsik]

Имею конкретный вопрос по работе ВГ75, определяющий можно ли без введения хитроумного узла регенерации, ставить в РК86 большие SIMM.

Ранее, исходя из того, что в реале ВГ75 тормозит на 25%, тогда как по расчёту на основе имеющихся данных должна тормозить лишь на 7%, я предполал, что ВГ75 читает память в каждой линии растра, а не один раз за строку, т.е за 10 линий растра (отчего авторы ВГ75 попадают в категорию идиотов).

27% получаются из расчета: одно считывание 78-ми байт за всю строку, т.е за время вывода всех 10-ти линий растра, один байт передаётся за 4 такта и ВГ75 использует единожды считанное содержимое строки для вывода всех 10-ти линий растра. Вот расчёт:

100 * (78:1.77)*4 : ( 64*10)= 27.6%

Даже, если откорректировать расчёт с учётом, якобы обнаруженных в этой теме потерь 4-х тактов при пересылке каждой посылки из 8-ми байт, то получается дополнительная потеря 9*4=36 тактов 1.77 МГЦ (ПДП у нас на такте 1.77). Девять - это число посылок за которые пересылается строка в 78 байтов. Тогда получается вот такой расчёт:

100 * ((4*78+9*4) : 1.77) : ( 64*10)= 10%

Но никак не 25%. Таким образом, после прочтения этой темы, дело запуталось ещё больше. Теперь уже никто не знает, считывает ли ВГ75 требуемые 78 байтов один раз за строку из 10 линий, или делает это многократно, считывая какие-то куски строки для каких-то линий повторно. Тогда интересно, по какому алгоритму? Хотелось бы знать какие считанные байты и в каких строках используются повторно, а какие считываются всякий раз заново?

После расчёта, с учётом новых данных, я пришёл к выводу, что считывать байты для каждой линии растра ВГ75 не может. Т.к (78+9*4):1.77=64.4 МКСЕК, что даже больше строчного периода в 64 МКСЕК, т.е если бы ВГ75 читал для каждой линии растра, то прогон программы происходил бы только во время одной строки обратного хода по кадрам и быстродействие КР580 упало бы в 31 раз и составило бы 1.77:31= 57 КГЦ, а РК реально даёт не менее 1.3 МГЦ.

И объяснение, что тут предлагают, а именно - то что для одних линий считанные байты строки используются повторно, а для других считываются заново, - мне кажется полной ерундой. Логично только или одно считывание на всю строку или считывание для каждой линии растра, что как доказал расчёт невозможно. Отбросив невозможное, остаётся истина. Вывод: ВГ75 считывает строку только один раз и использует эти данные для вывода всех 10-ти линий растра строки (отчего авторы ВГ75 перестают быть идиотами).

Куда же ПДП тратит время. Тогда логично предположить, что ВТ57 тратит на пересылку байта из ОЗУ в ВГ75 не один такт, а два. Если ВТ57 тратит 2 такта на байт и никаких потерь по 4 байта на посылку нет, тогда:

100 * ((78*2) : 1.77) : ( 64*10)= 24%

А вот это уже близко к реальным 25%. Ещё 2 процента набежит из-за несинхронности ВГ75 и ВТ57, но КР580 немного отыграет за время вывода единственной строки за время обратного хода по кадрам, когда РК86 работает на полной скорости 1.77 МГЦ, без захватов шины.

Кстати, вот сколько РК86 отыгрывает на единственной строке гашения по кадрам.

(76*30 + 100*1) : 76*31= 1.0102

Т.е благодаря отсутствию захватов шины во время единственной строки гашения по кадрам выигрывается 1 процент быстродействия. Таким образом, одна погашенная строка добавляет к быстродействию 0.0102*1.77 МГЦ = 18.1 килогерц. А вот целых 4 погашенных строки ускоряют прогов в:

(76*27 + 100*4) : 76*31=1.0407 раза.

Четыре погашенные строки добавляют к быстродействию 4 процента, что соответствует приросту реального такта в 0.0407*1.77 МГЦ = 72.1 килогерца. А абсолютный выигрыш относительно стандартного режима составит 72.1-18.1= 54 КГЦ.

Кстати установка кода F1 в конце строки в позиции 8+64=72, только экономит 5 байтов, но не даёт ускорения, т.к последняя посылка все-равно читает 8 байтов. Вот если поставить F1 в позиции 8*8-1=63, то девятая посылка ВОЗМОЖНО не будет читаться. Хотя, скорее всего, всё-равно будет читаться, т.к оценку содержимого строки делает вероятно схема вывода, а не схема загрузки буфера.

Кто-нибудь может проверить в реале или по документации, сколько тактов на байт тратит при пересылках ВТ57? Ясно, что два, иначе времена не сходятся.

Моя идея регенерации SIMM была основана на том, что ВГ75 читает строку для каждой линии растра, таким образом за строку ОЗУ в одних и тех же ячейках регенерируется 10 раз. Идея заключалась в использовании того, что т.к сигналы LC0, LC1, LC2, подаваемые на ПЗУ фонта, меняются при каждой линии растра, то используя эти сигналы как A8, A9, A10 для мультиплексора регенерации, можно будет без потерь регенерировать параллельный экрану SIMM. Тогда при чтении ВГ75 первой линии регенерируется один столбец, на следующей линии другой и т.д. Но если ВГ75 читает за строку каждый символ строки только 1 раз, то идея вообще не работает, - прощайте большие SIMM в РК86, - тогда, увы, остаётся наращивать ОЗУ за счёт моря параллельных банок РУ5-тых... Как видите для аппаратных модернизаций РК86 нужны точные знания как работает его железо.

Итак, может кто-нибудь "пролить свет" на число считываний на строке, привести более правдоподобный расчёт реальной скорости РК86? От правильного ответа на этот вопрос зависит и работа программ, для которые считают такты...

[SegaBoy]

Итак, может кто-нибудь "пролить свет" на число считываний на строке...

Посмотрите картинки к посту 143
На втором и третьем изображении видно, что в стандартном видеорежиме (78+8 * 30+1) загрузка одной строки знакомест (78 шт.) занимает почти четыре строки вывода на экран (если судить по количеству импульсов HRTC). Следующие шесть строк вывода, ВГ75 не требует загрузки и ВТ57 простаивает (подозреваю что и регенерацией не занимается).

Загрузка одной строки знакомест происходит один раз. Если она длится меньше времени вывода всех линий предыдущей строки, то происходит ожидание окончания вывода предыдущей строки, после чего ВГ75 запрашивает новую строку символов.

[barsik]

загрузка одной строки знакомест (78 шт.) занимает почти четыре строки вывода на экран (если судить по количеству импульсов HRTC).

Я понял, что имелось ввиду, что загрузка занимает время вывода четырёх линий растра.

Это не даёт информации сколько тактов на байт тратит ВТ57, чтобы заслать байт в ВГ75. Но уверен, что два. На первом такте он читает из памяти, на втором засылает в какой-то порт. А какой конкретно порт, из-за схемотехники РК неважно.

Так много времени занимает пересылка 9-ти посылок по 8 байт, видимо потому, что установлен слишком большой интервал между запросами ПДП. А это сделано, вероятно, чтобы КР580 между захватами шины мог выполнить существенную работу. Например, обработать апп.прерывание. Т.е это надо для сокращения времени реакции на апп.прерывание. Если сделать паузу между пересылками не в 55 тактов, а очень маленькую, то КР580 в обработчике прерываний не успеет "заткнуть" ВТ57 и потеряет еще 2*8 + 4 тактов на следующем захвате шины.

Следующие шесть строк вывода, ВГ75 не требует загрузки и ВТ57 простаивает (подозреваю что и регенерацией не занимается).

Естественно, если ПДП не считывает, то и не регенерирует.

В общем, прощай установка в РК86 больших SIMM, да и РУ7-мые в схеме РК без специальных мер для регенерации будут работать с периодом регенерации более 4 МСЕК, т.е с нарушением паспортных данных. Т.о, чтобы достичь хотя бы 1 мб, придётся паять 16 банок РУ5-тых...

Однако, не всё так трагично. Просто регенерация SIMM будет сложнее, не за счёт проводов, а за счёт лишних микросхем, т.к теперь адреса регенерации придётся получать иначе. В простейшем варианте по сигналу LC3 (что меняется лишь раз за строку в 9-й линии) будет инкрементироваться счётчик регенерации. Однако при установке высоты знакоместа менее 9, сигнал LC3 пропадёт и SIMM потеряют старшие адреса регенерации и из 16-ти мегабайт будут регенерироваться только первые 64К.

Можно бы поставить последовательно 2 счётчика. Первый будет делить ССИ на 8, а второй давать адреса регенерации. Но это тоже не пойдёт, потому что надо, чтобы адреса регенерации менялись каждую строку, а не каждые 8 линий (а число линий в знакоместе переменное). Нужен сигнал меняющийся раз за строку, а такого сигнала я не вижу. Пока в голову приходит только отлавливать 4 ССИ подряд, в которых нет HLDA, т.е отлавливать большую паузу в работе ПДП, что бывает раз за время вывода строки.

Кто-нибудь из аппаратчиков может предложить какое-нибудь максимально простое решение по регенерации больших SIMM, стоящих параллельно банке с экраном или даже вместо неё? (Если вместо неё, то это конечно потребует использовать режим CAS раньше RAS).

[SegaBoy]

Это не даёт информации сколько тактов на байт тратит ВТ57, чтобы заслать байт в ВГ75. Но уверен, что два. На первом такте он читает из памяти, на втором засылает в какой-то порт. А какой конретно порт, из-за схемотехники РК неважно.

Так много времени занимает пересылка 9-ти посылок по 8 байт, видимо потому, что установлен слишком большой интервал между запросами ПДП (кое-кто утверждает, что это тоже регулируется программно).

Да, не даёт. Я не успел этот момент зафиксировать, но собирался. Чуть позже сделаю.

Из мануала по ВГ75: Команда "Начало воспроизведения" - 001SSSBB, где SSS - интервал между пакетами ПДП, BB - число запросов в пакете.

SSS:
000 = 0
001 = 7
010 = 15
011 = 23
100 = 31
101 = 39
110 = 47
111 = 55

BB:
00 = 1
01 = 2
10 = 4
11 = 8

Инициализация ВГ75 в РК завершается командой 0x27 (001_001_11). Получается интервал между пакетами 7 тактов CCLK и число запросов в пакете 8.

[barsik]

А если увеличить паузу между посылками с 7 до 15-ти, то процессор сможет сделать в паузу вдвое больше полезной работы (что за полезную работу можно сделать за 7 машинных тактов?). Но главное, - улучшится качество звука. Если сделать паузы между посылками ПДП совсем равномерными по всему периоду кадра, то в спектре вместо двух низкочастоных гармоник будет только одна.

А что будет, если установить длину паузы между посылками в 31. Тогда последние символы в строке не считаются, и не будут выводиться? А нам и не надо, т.к там программный бордюр справа.

Чтобы получить чистый тон, на выход INTE можно включить вентиль (ЛА3 или ЛЕ1) и разрешать прохождение звука на динамик сигналом VRTC, т.е только во время обратного хода кадровой развёртки. Звук будет выдаваться без хрипов.Тогда сигнал будет чистым, но тихим, с частотой вибрато 50 ГЦ глубиной в 100% (обычно в тембре муз.инструментов вибрато имеет глубину до 30% и частоту 6-8 ГЦ).

Если точно знать, что во время вывода каких-то линий растра (например 5...10), HLDA точно не возникает, то подав сигнал LC2 с ВГ75 на разрешение прохождения звука на динамик, мы получим чистый звук меньшей скважности, т.е громче.

SegaBoy, раз уж у Вас есть аппаратура, не можете ли Вы выяснить, есть ли такие линии растра в знакоместе, при которых захвата шины никогда не бывает? Это бы существенно улучшило музыкальные возможности РК86.

Кстати, DI/EI в плане качества звука выгоднее, чем LD (port),A. Т.к длятся всего 4 такта вместо 13-ти.

Есть ещё одна победительная идея.

Использовать для ВТ57 и ВГ75 своё ОЗУ, а для КР580 - своё. Оба ОЗУ включены параллельно. КР580 пишет сразу в оба ОЗУ одновременно, а читает только из одного (своего) ОЗУ. Тогда когда ПДП и ВГ75 читают экранный буфер из своего ОЗУ, это нисколько не мешает процессору. И только если КР580 будет делать запись в экран при сигнале HLDA (который уже будет не из КР580, а из триггера, что взводится по запросу шины HRQ), то КР580 придётся остановить до конца цикла ПДП с помощью тактов WAIT, чтобы не потерять записываемые в экран данные. Но это нереализуемая идея, т.к требуется полная переделка платы и расход в три КП11, АП6, 6264 в качестве ОЗУ экрана и пара корпусов логики. А выигрыш - всего лишь ускорение на 25% и музыкальность звуков.

[SegaBoy]

Добавил сигналы ВГ75 LC0-3, теперь наглядно видно какая линия из строки выводится.
Добавил сигналы ВТ57 /MEMWR, /IORD и /IOWR. Первый выставляет адрес в ОЗУ, второй дёргает /WR ВГ75. Что делает третий не знаю, он заведён на сигнал /RAS ОЗУ. Может это и есть регенерация?

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

[свернуть]

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

SegaBoy, раз уж у Вас есть аппаратура, не можете ли Вы выяснить, есть ли такие линии растра в знакоместе, при которых захвата шины никогда не бывает? Это бы существенно улучшило музыкальные возможности РК86.

Да, сейчас найду этот момент и выложу скрин. Так же выложу весь файл анализа для самостоятельного просмотра.

файл здесь

[NEO SPECTRUMAN]

Итак, может кто-нибудь "пролить свет" на число считываний на строке, привести более правдоподобный расчёт реальной скорости РК86?

дла каждого видео режима своя эффективная скорость РК
в каждом варианте фрейма она своя
её нельзя взять и расчитать
+все задержки сразу уплывают в зависимости от исполняемого кода!!!
это тяжело просто так расчитать
тут нужно только писать нормальный эмулятор
тут все возможно

скорость рк 1.77777777777777777777 до бесконечности МГц

в строке свободной от ДМА-ления в строке порядка 115 тактов

в тех строках(пикселей) в которых происходит ДМА-ление
тактов под код в строке порядка 24-35 (27% от реальной скорости)

то есть чем выше высота символов и меньше их на экране
тем быстрее работает РК ))))))))))



чуть позже напишу тестов
обмозговав результат которых можно будет начать писать более менее полноценный эмулятор РК
и кодить более интересные вещи


я еще не переварил все выше написанное(в пред постах)...

[SegaBoy]

Значит так. ПДП не беспокоит процессор пока ВГ75 выводит линии с 3 по 8. Включается на последней строке 9 и продолжается с 0 по 2. Это актуально для оригинального режима. При сокращении линий в строке с 10 до 8, свободные от ПДП линии будут с 3 по 6 и запрос к ПДП начнётся с линии 7. Если менять режимы работы контроллеров то и эти цифры могут измениться.

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

[свернуть]

П.С. файл анализатора для самостоятельного изучения выложил в прошлом посте.

П.П.С. Поправочка. Ввёл всех в заблуждение, так как не учёл в 4-м параметре инициализации ВГ75 значение M. По умолчанию в РК (и Апогее) оно равно 1. Значит на выходах LC формируется значение на один больше.
Цифры выше надо понимать так - с 4 по 9 отображаемую строку нет ПДП и с 0 по 3 оно есть.