я потом попробую написать тест для проверки...Цитата:
Сообщение от SegaBoy
...еще нужно придумать как сделать выравнивание на 1такт...
я потом попробую написать тест для проверки...Цитата:
Сообщение от SegaBoy
...еще нужно придумать как сделать выравнивание на 1такт...
Поправил в эмуляторе подсчет тактов. Сейчас такты ПДП считаются точно (по крайней мере в том тесте):
Скрытый текст
http://emu80.org/temp/5ae1.png[свернуть]
На днях выложу обновленную версию.
Цитата:
Сообщение от NEO SPECTRUMAN
Да нет эти параметры сами по себе не дадаут выравниваниеЦитата:
Сообщение от NEO SPECTRUMAN
они просто сделают так что все фреймы будут идти одинаковыми
а вот какой будет из 3-х вариантов фрейма...
нужна будет еще процедура которая определит в каком мы сейчас фрейме (думаю простой счетчик насчитает разное число в каждом из них...)
и сбросит вг75 так чтобы все устаканилось так как нам нужно
- - - Добавлено - - -
а в Апогее INTE не заведен на бипер???
- - - Добавлено - - -
А кто нибудь может подкинуть сохранялку в RK для sjasm-а??
дето она проплывала тут по моему...
Да, в Апогее INTE меняет набор шрифтов. И ещё он выведен наружу, на разъём расширения.Цитата:
Сообщение от NEO SPECTRUMAN
По поводу работу ПДП в РК.
Пересылка байт из ОЗУ в ВГ75 происходит следующим образом. После торможения процессора, контроллер ПДП выставляет адрес на шину адреса и формирует сигнал чтения для ОЗУ через выход /MEMW. Появившиеся данные на шине данных ПДП проталкивает в ВГ75 сигналом /IORD. То есть по факту ВТ57 в себя не загружает эти данные, они просто находятся на шине данных.
Подробнее можно прочитать в книжке "Домашний компьютер" от авторов РК, на стр. 45.
SegaBoy, ПДП не только в РК так делает, он это делает @design. Смысл в том, что ПДП при приходе DRQ (будем считать, что канал настроен и прочее) запрашивает шину у ЦП, и как только ЦП подтвердит, что шина свободна, ПДП формирует полный адрес памяти для доступа и активирует шины управления памятью MEMRD/MEMWR а так же подтверждает доступ устройству DACK. Устройство изначально настроено так, чтобы при приходе DACK сразу выдавать данные на шину либо принимать их с нее, в зависимости от направления передачи. У устройства могут быть несколько DACK и, соответственно, несколько DRQ, которые могут быть настроены на разные режимы. К примеру популярная SB16 использует 2 DMA канала, одна для 8ми битной передачи и вторая для 16ти битной. Либо сразу для дуплексного режима (одновременно воспроизведение и запись).
Таким образом да, ПДП выступает в качестве арбитра, который связывает приемник и передатчик на шине, минуя процессор. Более сложный ПДП умеет копирование памяти, для этого он имеет регистр хранения данных и формирует он 2 операции (одну запись и одно чтение).
Но особенность работы ПДП 8257 именно в РК заключается в особом подключении выводов MEMRD/MEMWR и IORD/IOWR самого контроллера. Поэтому операция при программировании выглядит не логичной.
http://savepic.ru/13272249.png
Но это все только из-за упрощения схемы самого РК, логику работы самого ПДП оно не нарушает.
HardWareMan, спасибо!
Ну да, я это и имел в виду. Полезно иногда проговаривать в слух очевидные для одних вещи, не очевидные для других. На форуме полно тем, где многие нюансы раскрыты не до конца и максимум предлагается пойти и почитать. По-любому интерес к ВГ75 и ВТ57 возникнет не один раз, а читать книжки не всегда получается с пониманием. Даташиты и мануалы же везде разложены, но язык там такой непривычный, что люди постоянно переспрашивают - как это работает = ))
Не понял, что имеется в виду по "кривым" заголовком? Если отсутствие в конце файла контрольной суммы, то просто добавьте в конец что-то типа:Цитата:
Сообщение от zebest
db 00h, 0e6h, 00h, 00h
И файл будет грузиться в любом эмуляторе. Пусть даже выдавая ошибку КС.
А что касается Emu80, я так понял, что желательно убрать проверку наличия КС при загрузке из командной строки?
ладно тогда напишу сам и потом выложу...
Подсчет контрольной суммы я уже выкладывал в составе исходника позавчера, честно говоря не думал что для кого то это может быть проблемой.
Раз такое дело положу темплейт полностьюКод:cs = 0
lua pass3
mems=_c("binBegin")
meme=_c("binEnd")
cs=0
for i=mems,meme-2 do
cs=(cs+sj.get_byte(i)*257)
end
cs=(cs-cs%256+(cs+sj.get_byte(meme-1))%256)%65536
_pl("cs = "..cs)
endlua
display cs
db 0,0,#e6,cs/#100,cs&#ff
Скрытый текст
Код:device zxspectrum48
org #0000
rkBegin
db progBegin/#100,progBegin&#ff
db (progEnd-1)/#100,(progEnd-1)&#ff
binBegin
disp #0000
progBegin
;-------------------------------------------
; code here
jp $
;-------------------------------------------
progEnd
ent
binEnd
cs = 0
lua pass3
mems=_c("binBegin")
meme=_c("binEnd")
cs=0
for i=mems,meme-2 do
cs=(cs+sj.get_byte(i)*257)
end
cs=(cs-cs%256+(cs+sj.get_byte(meme-1))%256)%65536
_pl("cs = "..cs)
endlua
display cs
db 0,0,#e6,cs/#100,cs&#ff
rkEnd
savebin "prog.rk",rkBegin,rkEnd-rkBegin
[свернуть]
ну да, скрипт на lua - это же так просто.
простоЦитата:
Сообщение от zebest
но отлаживать его если оно не будет с ходу работать
рассматривать эти долбанные print-ы
которые в командной строке не бесконечно хранятся...
а еще нету никакого подобия goto
и возможности преждевременно завершить цикл...
+списка доступных команд в sjasm-е нету (во всех мануалах по lua их побольше да и написание местами не совпадает...)
все методом научного тыка...
Имею конкретный вопрос по работе ВГ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? От правильного ответа на этот вопрос зависит и работа программ, для которые считают такты...
Посмотрите картинки к посту 143Цитата:
Сообщение от barsik
На втором и третьем изображении видно, что в стандартном видеорежиме (78+8 * 30+1) загрузка одной строки знакомест (78 шт.) занимает почти четыре строки вывода на экран (если судить по количеству импульсов HRTC). Следующие шесть строк вывода, ВГ75 не требует загрузки и ВТ57 простаивает (подозреваю что и регенерацией не занимается).
Загрузка одной строки знакомест происходит один раз. Если она длится меньше времени вывода всех линий предыдущей строки, то происходит ожидание окончания вывода предыдущей строки, после чего ВГ75 запрашивает новую строку символов.
Я понял, что имелось ввиду, что загрузка занимает время вывода четырёх линий растра.Цитата:
Сообщение от SegaBoy
Это не даёт информации сколько тактов на байт тратит ВТ57, чтобы заслать байт в ВГ75. Но уверен, что два. На первом такте он читает из памяти, на втором засылает в какой-то порт. А какой конкретно порт, из-за схемотехники РК неважно.
Так много времени занимает пересылка 9-ти посылок по 8 байт, видимо потому, что установлен слишком большой интервал между запросами ПДП. А это сделано, вероятно, чтобы КР580 между захватами шины мог выполнить существенную работу. Например, обработать апп.прерывание. Т.е это надо для сокращения времени реакции на апп.прерывание. Если сделать паузу между пересылками не в 55 тактов, а очень маленькую, то КР580 в обработчике прерываний не успеет "заткнуть" ВТ57 и потеряет еще 2*8 + 4 тактов на следующем захвате шины.
Естественно, если ПДП не считывает, то и не регенерирует.Цитата:
Сообщение от SegaBoy
В общем, прощай установка в РК86 больших SIMM, да и РУ7-мые в схеме РК без специальных мер для регенерации будут работать с периодом регенерации более 4 МСЕК, т.е с нарушением паспортных данных. Т.о, чтобы достичь хотя бы 1 мб, придётся паять 16 банок РУ5-тых...
Однако, не всё так трагично. Просто регенерация SIMM будет сложнее, не за счёт проводов, а за счёт лишних микросхем, т.к теперь адреса регенерации придётся получать иначе. В простейшем варианте по сигналу LC3 (что меняется лишь раз за строку в 9-й линии) будет инкрементироваться счётчик регенерации. Однако при установке высоты знакоместа менее 9, сигнал LC3 пропадёт и SIMM потеряют старшие адреса регенерации и из 16-ти мегабайт будут регенерироваться только первые 64К.
Можно бы поставить последовательно 2 счётчика. Первый будет делить ССИ на 8, а второй давать адреса регенерации. Но это тоже не пойдёт, потому что надо, чтобы адреса регенерации менялись каждую строку, а не каждые 8 линий (а число линий в знакоместе переменное). Нужен сигнал меняющийся раз за строку, а такого сигнала я не вижу. Пока в голову приходит только отлавливать 4 ССИ подряд, в которых нет HLDA, т.е отлавливать большую паузу в работе ПДП, что бывает раз за время вывода строки.
Кто-нибудь из аппаратчиков может предложить какое-нибудь максимально простое решение по регенерации больших SIMM, стоящих параллельно банке с экраном или даже вместо неё? (Если вместо неё, то это конечно потребует использовать режим CAS раньше RAS).
Да, не даёт. Я не успел этот момент зафиксировать, но собирался. Чуть позже сделаю.Цитата:
Сообщение от barsik
Из мануала по ВГ75: Команда "Начало воспроизведения" - 001SSSBB, где SSS - интервал между пакетами ПДП, BB - число запросов в пакете.
Инициализация ВГ75 в РК завершается командой 0x27 (001_001_11). Получается интервал между пакетами 7 тактов CCLK и число запросов в пакете 8.Код: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
А если увеличить паузу между посылками с 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% и музыкальность звуков.
Добавил сигналы ВГ75 LC0-3, теперь наглядно видно какая линия из строки выводится.
Добавил сигналы ВТ57 /MEMWR, /IORD и /IOWR. Первый выставляет адрес в ОЗУ, второй дёргает /WR ВГ75. Что делает третий не знаю, он заведён на сигнал /RAS ОЗУ. Может это и есть регенерация?
Скрытый текст
- - - Добавлено - - -
Да, сейчас найду этот момент и выложу скрин. Так же выложу весь файл анализа для самостоятельного просмотра.Цитата:
Сообщение от barsik
файл здесь
дла каждого видео режима своя эффективная скорость РКЦитата:
Сообщение от barsik
в каждом варианте фрейма она своя
её нельзя взять и расчитать
+все задержки сразу уплывают в зависимости от исполняемого кода!!!
это тяжело просто так расчитать
тут нужно только писать нормальный эмулятор
тут все возможно
скорость рк 1.77777777777777777777 до бесконечности МГц
в строке свободной от ДМА-ления в строке порядка 115 тактов
в тех строках(пикселей) в которых происходит ДМА-ление
тактов под код в строке порядка 24-35 (27% от реальной скорости)
то есть чем выше высота символов и меньше их на экране
тем быстрее работает РК ))))))))))
чуть позже напишу тестов
обмозговав результат которых можно будет начать писать более менее полноценный эмулятор РК
и кодить более интересные вещи
я еще не переварил все выше написанное(в пред постах)...
Значит так. ПДП не беспокоит процессор пока ВГ75 выводит линии с 3 по 8. Включается на последней строке 9 и продолжается с 0 по 2. Это актуально для оригинального режима. При сокращении линий в строке с 10 до 8, свободные от ПДП линии будут с 3 по 6 и запрос к ПДП начнётся с линии 7. Если менять режимы работы контроллеров то и эти цифры могут измениться.
Скрытый текст
П.С. файл анализатора для самостоятельного изучения выложил в прошлом посте.
П.П.С. Поправочка. Ввёл всех в заблуждение, так как не учёл в 4-м параметре инициализации ВГ75 значение M. По умолчанию в РК (и Апогее) оно равно 1. Значит на выходах LC формируется значение на один больше.
Цифры выше надо понимать так - с 4 по 9 отображаемую строку нет ПДП и с 0 по 3 оно есть.
А еще мне интересно
какого хрена гф24 делит частоту на такое не естественное число как 9?? о_О
и создает нам этим неимоверную кучу проблем...
почему нельзя было делить по людски на 8!!!
- - - Добавлено - - -
не я вкурсе что там
ВСЕ РАВНО БЕСИТКод:JJJJJJJJJ
ПП_______
__ППППП__
123456789
- - - Добавлено - - -
это нелзя просто взять и предказатьЦитата:
Сообщение от SegaBoy
была бы у 8080 40 тактовая команда
и проц бы пока не выполнил бы её всю
не подтверждал бы hlda
и переброска даже не начиналась бы....
всё напрямую зависит от исполняемого кода...
это вам не 6,5,4,3,2,1,0,0 на спектруме...
У меня есть только предположение. Тактирование процессора двухфазное, и для получения правильных временнЫх интервалов требовалось такое деление. Предположение основано на картинке в какой-то книжке, где расписывалось, как нужно тактировать процессор 8080, так вот там период был поделен на 9 частей.Цитата:
Сообщение от NEO SPECTRUMAN
Да, предсказать точно нельзя. Пока вижу ~20 тактов процессора после окончания всей серии пакетов ПДП и началом вывода ВГ75 новой линии строки. Пакетов всего 10, даже если каждый задержится на несколько тактов, то максимум наедем на начало следующей линии и то на чуток.Цитата:
Сообщение от NEO SPECTRUMAN
да в принципе абсолютно не важноЦитата:
Сообщение от barsik
если в эти 7 тактов успеет начатся команда побольше
например 5 + 16
то и эти 7 тактов расширятся
...
мультиколоры все равно ненакодить
единственное это может быть полезно для звука
для чтения с магнитофона
можно будет грузить картинку на экран и видеть ее)))
- - - Добавлено - - -
ну я же вроде и "нарисовал" этоЦитата:
Сообщение от Vital72
(только вчера этот период видел)
все равно делать такое...
ну железятники и программисты живут в разных вселенных...
- - - Добавлено - - -
напомню что чутокЦитата:
Сообщение от SegaBoy
1 такт процессора это 4.5 экранных пикселя
что совсем не чуть чуть...
- - - Добавлено - - -
напомню что чутокЦитата:
Сообщение от SegaBoy
1 такт процессора это 4.5 экранных пикселя
что совсем не чуть чуть...
без видения исполняемого кода...Цитата:
Сообщение от SegaBoy
- - - Добавлено - - -
И еще как сделать доходчивое описание всего этого????? о_О
тут надо прилагать кучу осциллограмм...
все расписывать...
...у всего по 100500 режимов работы...
...кошмар...
- - - Добавлено - - -
А что такое ???
во время сбросаЦитата:
0 Нормальные символы
1 Недоступные (закрытые) символы
1-й байт параметра
в буржуйском мануале это называется spaced rows
и там есть для этого картинка
в которой после каждой строки
строка пробелов
видимо можно дать еще больше времени процу
используя этот режим (нужно вообще потестить на реале...)
- - - Добавлено - - -
и еще предложение
чтоб не путать строки символов и пикселей
давайте для строк пикселей будем использовать термин
Цитата:
Число горизонтальных линий в строке
Тут всё просто. Если этот параметр равен 1, то экран становится через-строчным. Сначала выводятся все горизонтальные линии первой строки. Затем столько же выводится пустых (чёрных) линий. Потом начинается отображение всех горизонтальных линий второй строки, а за ней снова столько же пустых линий. И так до конца экрана. Соответственно сам экран в памяти занимает в два раза меньше места (и ПДП так же происходит в два раза реже).Цитата:
Сообщение от NEO SPECTRUMAN
Например можно сделать текстовый режим 64х16, читать в таком режиме будет намного удобнее.
Добавил под спойлер, как это выглядит на реальном Апогее.
Скрытый текст
П.С. Похоже что последняя строка знакомест выводится без последующих spaced row. За ней сразу идёт кадровый синхроимпульс.
не ну чтоб назвать это недоступные закрытые символы это надо быть...
- - - Добавлено - - -
а что в апогее по дефолту 4 байт конфига _F.. ....
записывается D3
field attribute mode 1 (не прозрачные атрибуты)
непрозрачные атрибуты это когда управляющие коды (которые будут выставлять цвет в апогее?) будут в виде пробела перед используемым символом?
и зачем это включать тогда по дефолту??????
Если на Апогее случайно поместить управляющий код в экранную память, то он отобразиться как пробел, а за этим пробелом будет напечатан следующий символ. И всё, ничего страшного не случится. Если так сделать на РК, то он не отобразиться, а следующий символ будет напечатан вплотную к предыдущему. Но так как управляющий код это загруженный через ПДП байт, то ВГ75 попросит ещё один символ взамен неотображаемого. ВТ57 выдаст ему дополнительный символ, только это будет уже начало новой строки, так как случайно кинув атрибутом в экран мы не пересчитали размер блока для ПДП и не переинициализировали ВТ57. Выглядит на РК это как бегущий экран - чем больше накидать управляющих символов, тем сильнее он бежит.Цитата:
Сообщение от NEO SPECTRUMAN
Проще говоря, если этот бит установлен, то размер блока ПДП равен размеру экрана (78*30 байт по умолчанию). И не важно что в этом экране, нули, символы или управляющие коды. Если этот бит опущен, то размер блока ПДП надо всегда пересчитывать. Он будет равен размеру экрана, плюс количество атрибутов в этом экране. Если их расставить заранее и все посчитать, а потом не трогать (или трогать аккуратно) то экран не разрушится. Если их количество менять по ходу программы, то надо всегда их пересчитывать и инициализировать ПДП или экран убежит.
NEO SPECTRUMAN, для простоты - чтобы не приходилось перепрограммировать ПДП при каждом добавлении управляющего кода.
Меняем пробелы между словами, например, на управляющие коды - и слово уже выделено другим цветом, и не нужно думать о программировании ВГ75 и ВТ57...
А если надо выделить букву не с начала слова? Пример распространенный (управление в меню по ключевым кнопкам).Цитата:
Сообщение от Pyk
Вообще интересно, ну вот когда вы разберетесь с времянками, что дальше? Что за сакральное знание, времянки? Какие-то нештатные вещи с ВГ75 использовать?
Странно. Я использовал только RVV, и т.к это было почти 30 лет назад, то подробностей не помню. Но о необходимости перепрограммировать ПДП и сдвиге, и соответственно, сложности расчёта начал всех последующих строк, слышу первый раз. Зачем тогда нужен упр.код "конец строки"?Цитата:
Сообщение от SegaBoy
Не понял, что за размер блока для ПДП. Если речь о размере ПДП-посылки, то вроде 8 - это уже и так максимум. И непонятно, что дало бы увеличение размера ПДП-посылки, если бы это даже было возможно.Цитата:
Сообщение от SegaBoy
Кто-нибудь из пользующихся цветом на РК86 и клонах может рассказать, как использовать цветовые атрибуты и какие возникают при этом проблемы?
Интересует проблема сдвижки начал последующих строк, если вставить атрибут? Никогда о такой проблеме не знал. Я считал, что 7 символов для правого бордюра как раз достаточны для того, чтобы вставить пару атрибутов и никакой сдвижки последующих строк не помню.
Атрибуты отображаемые пробелом, крайне неудобны. Как сделать тогда "балку подсветки" в НОРТОНЕ? И интересно, - сам символ пробел выводится с атрибутным сигналом уже активным или он станет таким только для следующего символа.
И что происходит тогда при выключающем цвет атрибуте? В одном из двух вариантов ответа, Вы никак не получите "балку подсветки", где один пробел в цвете балки до цветного текста и один цветной пробел после. А вот с невидимыми атрибутами проблем нет. По сути режим с отображаемыми пробелом атрибутами вообще никогда не нужен.
Да и вообще атрибуты для целей цвета или инверсии - полное дерьмо. Попробуйте сделайте ими такую картинку, что вообще, абсолютно без труда, делаю я, используя для инверсии фонт. Для цвета, кстати, будет то же самое - программирование на порядок проще и результат намного выше.
Вот почему я сразу же забраковал RVV и использовал инверсию альтернативным фонтом, что к тому же ещё даёт и рамки и инверсные окна. И легко в программировании. Атрибуты удобны только для оперативного переключения фонтов, чтобы, например, в одном экране видеть КОИ-8, т.е и мелкие + заглавные латинские и мелкие + заглавные русские буквы.
При цвете, что описан в журнале "Радиолюбитель" 04.1992, задают только цвет INK (PAPER всегда черный). Поэтому я всегда считал, что надо не напрямую управлять RGB-лучами кинескопа, а через кодо-преобразователь (РЕ3, РТ5). Тогда из тех же 3-х битов получаем 8 сочетаний цветов, т.е имеем цвет как для символа, так и для фона. А 8-ми сочетаний как раз хватает для всех системных программ.
;----------------------------
Судя по одному сообщению, что я где-то на сайте читал, атрибуты не могут идти подряд друг за другом. Никогда так не делал (да и цвета никогда не имел, только экспериментировал с RVV для инверсии знакомест). Соответствует ли это утверждение истине?
Вопрос: как тогда на цветных машинах устанавливают НЕОСНОВНЫЕ цвета (у которых несколько атрибутных сигналов активны). Если каждый из 3-х атрибутных выходов управляет одной цветовой пушкой телевизора, т.е R, G или B. А если надо включить белый цвет (для которого нужны все три луча), сразу после чёрного, то надо выводить подряд все 3 цветовых атрибута. Тогда если "перемежать" атрибуты пробелами, то тратятся не 6 байтов, а 12, а свободных имеется только 6. Тогда чтобы иметь белый цвет приходится строку укорачивать на 6 символов. А если на строке есть и другие фигурки в другом цвете? То строку укоротим ещё больше? Таким образом, цвета на базе атрибутов обходятся слишком большой "кровью" (программиста) и дают намного худший результат, чем цвет из МЦПГ.
В общем, тут требуется консультация знатока. Того кто разбирался с использованием цвета на РК и клонах. Это Pyk и b2m, а также владельцы цветных "Партнёров" и "Апогеев-010/Ц". Хотелось бы, чтобы они не скрывали свои знания от народа, т.к цветные игры выглядят намного лучше.
- - - Добавлено - - -
Сакральные знания якобы позволят заимствовать опыт спектрумистов для создания немерцающих игр для РК86. В качестве выходного результата этой темы ожидается разработка "движка" для РК-игр, обладающих свойством "немерцаемости" и кучей других свойств, а также получение 30-ти игр для РК86 уровня первых лет ZX-Spectrum.Цитата:
Сообщение от error404
Всё это можно проверить на реальном компьютере РК. Если не ошибаюсь, чёрно-белый Апогей так же себя вёл (давно это было, аж в 90 году). Похоже что в цветном константу изменили.
К смещению экрана цвет не имеет никакого отношения.
Только что проверил в эмуляторе EMU - выбрал Радио-86РК, ввёл директиву Монитора М7А00. В первую строку поставил 33 и нажал ВК. На экране появилась цифра 3. В следующей строке ввёл 89 и нажал ВК - экран плавно поехал влево. Можете проверить самостоятельно.
Уплыл он, потому что размер экранной памяти, заданный в третьем и четвёртом параметре инициализации ВТ57 указан 0x0923 (2340 - 1 байт). Экран так же составляет 78*30=2340 байт. Но для ВГ75 имеет большое значение что там. И вот без этого флага, обсуждаемого выше, он не учитывает атрибут как символ. В показанном мной примере в строке стало 77 символов и один атрибут. Поэтому ВГ75 инициировал продолжение ПДП, а ВТ57 не в курсе что такое атрибуты. Он выдаёт байты когда попросят, вот и выдал. Только это уже было начало другой строки. Поэтому экран плавно едет влево и постепенно смещается вверх. Так и должно быть при одном атрибуте в экране. Киньте ещё пяток-другой и экран пулей начнёт носиться.
Атрибут надо выключать в конце строки. Нельзя оставлять атрибут активным, не будет синхронизации !
SegaBoy, вставьте атрибут включения в первую строку, через сколько-то символов вставьте атрибут выключения, а затем вставьте коды F0 или F1 в 78-й позиции строки, т.е в ячейку 77C2+4E-1= 780F. Тогда ВГ75 не будет запрашивать лишнюю посылку и ВТ57 не собъётся.
вот на*****кодил тест для АПОГЕЯЦитата:
Сообщение от Error404
(я хотел написать что нить по лучше\по эффектней... но что то время затраты я не рассчитал(без нормальных средств отладки...))
в итоге получилось как всегда...
сравните то что на реале (я сильно надеюсь что там именно то что я представляю)
и то что в эмуляторе (кстате b2m эмуль приятно удивил! похоже но не совсем то)
Emu80 v.4 ничего вообще не выдает...
Вложение 60134
хочу видео!!!! (не если оно такое же как в b2m то не надо)
ида извиняюсь за большой размер...
...и я чот не уверен что оно точно будет держать синхронизацию без наличия какого либо бордюра
именно даЦитата:
Сообщение от Error404
для повышения качества картинки и не только...
и не только вг75
там много интересных микросхем...
Так мне то это зачем, я же это всё прекрасно понимаю и пару постов назад описал, что есть вариант берез переинициализации и без сдвига экрана. Может я там не совсем корректно выразился - нужно будет манипулировать экранными байтами, чтобы экран не двигался.Цитата:
Сообщение от barsik
- - - Добавлено - - -
Оно?Цитата:
Сообщение от NEO SPECTRUMAN
видео (30 метров)
Или вот, захват с ТВ-выхода:
https://yadi.sk/i/L2MwStgE3G2ZpG
(700 Мб)
Когда думал, нужно ли поддерживать такое в эмуляторе, отмел эту идею как бредовую - не думал, что кто-то будет так извращаться ;)
Могу, конечно, и сделать, если уж очень нужно будет...
ДА ИМЕННО ОНО!!!!!
Кстати, атрибут подчёркивания легко сделать работающим. Для этого нужен диод. Это даст подчёркивание текста и символ E0, позволяющий рисовать сплошную по горизонтали линию. Этот атрибут не имеет соответствующего выхода, а реализуется внешней логикой.
Чтобы не мучиться с атрибутом RVV для получения инверсии, я первоначально планировал на выходе ВГ75 поставить аппаратные ловушки на коды 0E, 0F. Эти коды в древних терминалах для этого и используются (точнее там они коммутируют фонт). Расход деталей 3 корпуса логики на ловушки и триггер, что взводится и сбрасывается, как только начинается вывод на экран этих кодов. Тогда код 0E включает инверсию и сам отображается инверсным пробелом, а код 0F выключает инверсию и отображается неинверсным пробелом.
Псевдографические символы 0E и 0F при этом теряются для отображения на экране. Но если этими кодами переключать фонт на альтернативный, то основной фонт остаётся тем же, что и сохраняет псевдографику кодов 0E и 0F.
Т.к инверсия за счёт второго фонта в 1 кб из той же РФ2, обходится всего в кусок проволоки, то этот вариант был отброшен. Но можно это использовать, чтобы прямо в экране переключать режим отображения, в частности - старый режим моно и цветной с сокращённым вдвое разрешением в знакоместе, что даёт на одном экране и текст и цветные спрайты (и не тратить на это атрибуты).
Сразу видно не спектрумист :v2_tong2:Цитата:
Сообщение от Pyk
Вот как сделан цвет на Апогее. Код атрибута 10UIGBFR - где U подчёркивание, I инверсия, G зелёный, B синий, F мигание, R красный. Для установки любого цвета или варианта цвета с подчёркиванием, инверсией и/или миганием сразу, требуется всего один атрибут. То есть никаких нескольких цветовых атрибутов не надо для переключения на какой-то цвет.Цитата:
Сообщение от barsik
Цитата:
Сообщение от krt17
плясал плясал с бубном...
пытался я эту сумму вычислить всем чем только можно
и копипастил уже готовое
и видоизменял на случай очепяток
и пробовал другой вариант (тут попался)
в конечном итоге глянул что РК-шная сумма для
defb 1,2,3
0606
и сделал
простое прогоняние всех байтов через
csum = (csum + (sj.get_byte(cnt) * 257))
и контрольная сума подходит!!!:v2_dizzy_aaaaa:
пробовал разные файлы...
по крайней мере нету знака вопроса (я не знаю как должен выглядеть tape loading error)))))
и всего 3 строки
как в других нормальных файлах
короче считаю что это был ЗАГАВАР :v2_dizzy_bomb:
не иначе!!! :v2_tong2:
3Ы на всякий случай надо добавить
csum = (csum + (sj.get_byte(cnt) * 257)) % 65536
чтоб не вступить в плавающие запятые...