Можно и набор плоскостей и палитру сделать опциональными в заголовке. Рому на 45кБ будет не до этого, зато на тех, что поменьше, можно будет оторваться.
Вид для печати
Можно и набор плоскостей и палитру сделать опциональными в заголовке. Рому на 45кБ будет не до этого, зато на тех, что поменьше, можно будет оторваться.
В разнобой это слишком много изменений протокола, хотя и круто бы выглядело, если речь о загрузке картинки в перемешку с данными. Думаю, для начала достаточно одного первого блока 256 байт, для одного спрайта, а далее уже существующий протокол без изменений.Цитата:
Сообщение от ivagor
Просто мысль вслух - при достигнутых скоростях возможно нечто вроде медленного видео. Если размер кадра 64x64, то примерно 3 кадра в секунду. Или если 128x128, то 0.7-0.8 кадра/сек.
Крутизна.Цитата:
Сообщение от ivagor
Вот прикинул, по ЛВС, меньше чем в два раза быстрее получается (2.5КБ/сек), а там можно сказать в Вектор инфа в параллельном виде поступает.
ЛВС можно как-то ускорить?
Конечно можно.Цитата:
Сообщение от ivagor
Там протокол жутко "не оптимален", и скорость СОМ-порта я использую 57600, хотя можно и выше, изменив гальваническую развязку.
А можно ещё и одновременно данные передавать с РС на контроллер ЛВС, и с контроллера в Вектор. Только процессор контроллера должен иметь достаточно встроенной памяти. Сейчас сначала пакет (32 Байта данных + служебные) передаётся с РС в контроллер, потом весь пакет перегружается в Вектор. Если пакет принят корректно, запрашивается у РС следующий пакет...
Оптимизировал загрузчик fm9 и теперь получается считать контрольную сумму на ходу. Это более чем на треть сокращает интервал от завершения загрузки до старта программы.
Пара слов про скоростные возможности ROM-формата. На примере файла размером 33.25 Кб. Использовался модифицированный ROM2WAV Ramirosa. Две модификации: устранение избыточности по результатам Tim0xи и изменение задержки между байтами (1/2).
Сначала самый неинтересный вариант - рекорд скорости при загрузке в VV с использованием хакнутого загрузчика kish3 - 1:07.
Дальше подобрал вариант, который грузится и в VV и в emu при использовании kish2/UNBOOT2K (загрузчики Tim0xи ведут себя аналогично) - 1:57.
Еще попробовал 512 байтный загрузчик FirstBoot. В него рекорд загрузки в районе двух с половиной минут.
Самый привередливый загрузчик в 6128. В него получилось загрузить примерно за 3 минуты, но возможно резервы еще есть.
Хотел поднять интересную тему (если она ещё не поднималась). прочитал недавно в одном из векторовских журналов, что были нестандартные загрузчики, которые были "а-ля Спектрум". Полосы на бордере, картинка при загрузке, да и сам физический формат был не фазовый, а ЧМ (чистый спектрум по сути). Кому-нибудь подобные кассеты встречались?
У меня в детстве была "Планета птиц" со своим загрузчиком. Сначала грузился загрузчик. А в него дальше - уже игра. В середине было написано "Планета птиц". При загрузке шел таймер оставшегося времени, а по бокам были полосы как при загрузке на Спектруме. По окончании загрузки - игра сама запускалась. БЛК+СБР нажимать не нужно было. Я пробовал как-то загрузить игру - минуя загрузчик - она грузилась, но не запускалась.
Сталкивался с "отголоском" такой штуки. Это была хакнутая версия планеты птиц, вероятно при хаке рудименты загрузчика остались и если в процессе загрузки (не дожидаясь окончания) стартануть, то по бордюру шли цветные полосы. С рисованием картинки во время загрузки на векторе не сталкивался.Цитата:
Сообщение от BYTEMAN
Еще были "проприетарные" загрузчики попроще, без полос и без рисования.
- - - Добавлено - - -
Оп, я не успел, и тоже планета птиц :)
- - - Добавлено - - -
Кстати, если вспоминать волгоградские игрушки, в фатаксе вроде подгрузка уровней (в оригинальной, не хакнутой версии) сопровождалась цветными полосами на бордюре, надеюсь я не спутал.
Вроде у Кристы там картинка при загрузке прорисовывается, но это совсем другое дело было вроде как...
Блин, было бы круто, если бы у кого такие "своеобразные" записи сохранились бы...
Насчет рисования помню оригинальую версию BASIC-M. Сразу после загрузки она рисовала на весь экран, как бы от руки курсивом название (Basic M или что-то в этом духе). В хакнутой версии такого нет.
- - - Добавлено - - -
И, кстати, у Basic-M исходно был свой загрузчик.
Да, круто бы было. Вдруг еще сохранились у кого-то.Цитата:
Сообщение от BYTEMAN
Я бы это, скорее, списывал на переход на обработчик прерывания RST 7 при прямом ходе луча, в результате чего мы наблюдаем на бордюре процесс записи физических цветов палитры :)Цитата:
Сообщение от ivagor
- - - Добавлено - - -
Ну я в подростковом возрасте и сам подобный эффект делал, там же ничего сложного. Другое дело, что для меня действительно новость, что на "Векторе" вообще существовали "кассетные" игры с подгрузкой уровней.Цитата:
Сообщение от ivagor
При этом менялись бы цвета не только на бордюре, а везде.Цитата:
Сообщение от x-code
В наших пенатах не встречались. Сам в начале 90х носился с идеей сделать такое, но потом забил, т.к. Вектор это вам не Спектрум, ждать загрузки 32 кб картинки мало кто захочет (ну пусть даже в RLE она сожмётся в 20 кб - это, по времени, всё равно больше чем загрузка, скажем, Бейсика).Цитата:
Сообщение от BYTEMAN
Ну и, в довесок, я осознавал, что загрузчик родного ROM формата, точнее, его автоподстройку под константу чтения, я не осилю - а форматы что монитора-отладчика, что спекрумовский ЧМ будут сильно проигрывать в надёжности.
- - - Добавлено - - -
Вполне возможно, мог перепутать за давностью лет. С детства в памяти отложилось, что некоторые игры после перегрева Вектора начинали сбоить и нажатый со злости Блк-Сбр иногда приводил к "радуге" именно на бордюре. ХЗ, вероятно, просто ложные воспоминания.Цитата:
Сообщение от ivagor
С другой стороны... вроде бы порт 02 отвечал за цвет только бордюра, а цвет фона задавался нулевым математическим цветом? А в обработчике прерывания в цикле в порт 02 писались именно математические цвета от 0 до 15, или я гоню?
Если на запись, то это бордюр/номер цвета палитры плюс режим экрана 256/512.Цитата:
Сообщение от x-code
Да, но если вызывать процедуру программирования палитры не в невидимой области, то в качестве номера палитры будут использоваться не только значения из порта 2, но и цвета активной области изображения, если моменты программирования палитры попадут (а они иногда точно попадут) на активную область.Цитата:
Сообщение от x-code
Точно, вспомнил, были и такие артефакты в виде цветных полос на всю ширину экрана.Цитата:
Сообщение от ivagor
Так а как это выглядело в загрузчике Планеты Птиц? Именно целенаправленная анимация цветов бордюра, как в игре "Клад"?
Анимацию цветов бордюра в игре клад не помню.Цитата:
Сообщение от x-code
Могу сравнить с монитором-1200, в котором есть попытка изобразить нечто на бордюре во время загрузки. В планете птиц было намного лучше, полосы не 2х, а может даже 8 цветов (насчет 8 точно не уверен, но цветов было не менее 3х), плюс полосы сравнительно широкие, не просто как штришки. Выглядело хорошо. Пожалуй было похоже на спековский bomb jack.
А вот интересно, "Планету птиц" с таким загрузчиком, продавали у разных "распространителей". Значит была специальная программа, генерирующая запись на магнитофон загрузчика и самой игры. Если бы это был просто универсальный "копировщик", то с таким эффектом писали бы на кассеты все игры. Неужели не сохранились архивы если не разработчиков, то хотя-бы "распространителей"...Цитата:
Сообщение от lafromm31
Со своим загрузчиком распространял разве что центр Компьютер (Кишинев) и, возможно, сам автор. Подавляющее большинство пиратов продавали обычный файл в формате загрузчика.
Вот, например, фатакс с подгружаемыми уровнями (если не путаю, реально там подгружались не уровни, а типа сигнатуры) распространяла разве что волгоградская контора (забыл название), у остальных был обычный (хакнутый) rom. Неудобно же переписывать левый формат, и делать свой генератор для записи тоже особого смысла не было. Да и пользователям удобнее. Защиты нужны были только авторам и "официальным" распространителям.
- - - Добавлено - - -
Кстати, иногда и пираты изобретали свои уникальные форматы. Например отец покупал в какай-то кишиневской конторе пару кассет и там оказалось нечто со своим загрузчиком. И я их потом ломал и переделывал в обычные ромы.
Центр Компьютер (Кишинев), с какого-то момента, продавал практически всё с загрузчиком. Только он был без наворотов, просто загружал основной файл в своём формате.
ivagor, а есть описание формата вывода loadfm9? Т.е. какие там заголовки, синхробайты, в каком порядке надо "пищать байтами файла" и т.п. Что-то я впечатлился им по этому видео, хочу попробовать добавить в свой "магнитофон на ардуино"...Цитата:
Сообщение от ivagor
Так вот же буквально здесь, все задокументировано в самой твердой форме, кодом:Цитата:
Сообщение от Improver
https://github.com/svofski/bin2wav/b...r/tape.js#L370
data[dofs++] .. -- байт за байтом собирается формат, потом кодируется функцией encode(). encode() кодирует каждый байт функцией fmbyte(). Служебная информация кодируется медленно, по 3/6 отсчетов, основная полезная нагрузка быстро по 2/5 отсчетов.
Improver, вся задокументрованность благодаря svofski, он ссылку привел. И еще он картинку рисовал, там написано fm6, но идея сохранилась до fm9, только уменьшалось число отсчетов/бит.
Мои познания JS не настолько велики, но попробую разобраться. Без учёта кодировки функцией fmbyte() получается так:
Не совсем понятно, как работает этот флип, полагаю это нечто для лучшего утрамбовывания данных. А дальше, при кодировании, вообще происходит какая-то магия... И единственное, что я понял из рисунка, это то, что единица передаётся за полтора цикла несущей частоты, а ноль -- за половину цикла.Код:1. Заголовок:
- 256 байт 0FFh
- синхробайт 0E6h
- 4 байта, 'FM9'5 (046h 04Dh 039h 005h)
- 11 байт -- имя файла (8 байт, дополняется пробелами)+(3 байта расширение)
- 1 байт -- номер начального блока
- 1 байт -- количество блоков
- 256 байт 0FFh
2. Блоки данных:
- 1 байт 0FFh
- 1 байт 0E6h
- 256 байт из файла поXORенные с неким флипом???, с подсчётом контрольной суммы
3. Завершение:
- 1 байт -- контрольная сумма данных
- 1 байт -- флип??? (полагаю, для раскодировки данных)
В общем, по-быстрому добавить FM9 не получится, надо углублённо изучить инфу, но уже этих сведений достаточно, чтобы прикинуть, что в ардуине не хватит места сразу для всех форматов, надо будет чем-то жертвовать.
JS это такой цирковой Си для клоунов. Там все как бы просто, но можно сложить 2 и 3 и получить строку, например.
Флип для лучшего утрамбовывания, но он не работает в текущей версии, потому что на момент флипанья ПЗУ не отключено, а флипанье на лету невозможно потому, что признак записывается в конце потока. Я его как раз только что запретил. Можно считать, что он всегда 0, то есть его как бы нет.
С форматом -- вроде все правильно.
Дальнейшую информацию можно игнорировать, она больше для исторической полноты. Если использовать rom2fm, то там вместо 5 может быть и 4, этот байт соответствует скорости передачи (5 для 11700; 4 для 13500). Т.к. в железный вектор 13500 грузится нестабильно, то можно считать, что скорость всегда 11700. 13500 из железок грузится в de1, но разница небольшая. Теоретически можно попробовать дожать и 13500 для реала, но тут уже для отладки нужен реал, т.к. эмулятор стабильно грузит 13500 (как и de1), а реал - нестабильно.Цитата:
Сообщение от Improver
Не помню где я слышал, но засело в памяти, что дескать у Вектора такой крутой формат, что блоки можно в любом порядке и сколько хочешь раз. Я вроде знаю, что это не совсем так и в этой теме это уже не раз обсуждалось. Но я все же проверил еще раз сам и пришел к тем же выводам, что и предыдущие исследователи. Два важных принципа стандартных загрузчиков: 1) номера последовательных блоков обязаны быть равны (повтор) или уменьшаться на один (нумерация идет от максимального до 1) и 2) перейти к очередному блоку невозможно, если текущий не был загружен полностью. Понятно, что альтернативные загрузчики могут грузить более расслабленно, но если делать какой-то трюк для стандартного Вектора, рассчитывать на это нельзя.
Ограничение, причем двойное (ах ты номер увеличил, а данные пропустил, ну так вот тебе пункт 2), мне кажется совершенно бессмысленным. Как-то вот просто чтобы было "тупо зло". Зачем мне это я не знаю, видимо просто внутреннее неприятие зла :)
Ограничения есть, но все же формат сравнительно гибкий, видео Tim0xИ, которое теперь недоступно, меня в свое время впечатлило.
Это другое, подблоки можно грузить в произвольном порядке и грузить данные поверх экрана можно, если при этом не забывать включать в эти данные то, что загрузчик распознает, как "блок загружен". Но вот целые блоки переставить местами, или например загрузить блок по адресу 0, а другой по адресу $8000 -- никак, ни за что. Опять же, в этом не много практического смысла было бы в любом случае, но чему служит такое напряженное отношение к последовательности блоков я тоже понять не могу.
Тут можно поспекулировать, что если мы сопротивляемся дефектам на пленке, например, повторять блоки друг за другом, то есть вероятно в одной области повреждения, может быть менее надежно, чем повторять запись целиком, когда повторные копии физически отстоят друг от друга на большом расстоянии. Хотя психологически это не воспринимается так эффектно, конечно. Это же тогда просто вторая копия.
У меня есть версия, что может быть фрагменты кода как-то повторно использовались в возможных экспериментах с ЛВС и они может быть боялись, что допустим будут принимать пакеты не тому адресату, но почему бы тогда не включить в формат пакета собственно адресата. В общем это левая идея.
Есть еще загадочный фрагмент кода по крайней мере в одной из версий загрузчиков (который называется newrom v(2.0)), который делает так:
тут вперемешку фарш из комментариев из архива с моими. Понятно, что так ничего не понятно: это процедура окончательного копирования прочитанного подблока с уже верифицированной контрольной суммой из буфера $DED0 (многозначительно, исп. el dedo = палец) в память. Казалось бы, можно ли тут изобрести что-то новое? Но вот чему могли бы служить инструкции ldax b \ xra m \ mov m, a, кроме как быть частью какого-то мрачного ритуала ? Комментарий "уст.ошибку в буфф." наводит мысли на то, что предыдущий исследователь тоже уже слишком долго вглядывался в бездну.Код:; пересылка 32 байт (с очисткой источника?)
; h = &src[0]
; b = &dst[0]
; в процессе производятся странные ритуалы - может быть это связано с кодом в ПЗУ? не понятно
PUSH D ; push: d = число блоков e = cs0
PUSH B ; push: b = org_hi
INX H ; HL=нач.данных (ABUFF + 2, 32 байта, остаеется еще checksum_data)
LXI D,207EH ; из буфф. в озу d = 32 байта, e = $7e = битмап столбика в карте загрузки
LOA14: MOV A,M ; a = *src - взять из буфф.
STAX B ; *dst = a - поместить в озу
LDAX B ; a = *dst - взять из озу -- ну зачем это все ?..
XRA M ; a ^= *src - чего это все ради? может быть потому что ПЗУ?
MOV M,A ; *src = a -- что? -- уст.ошибку в буфф.
LOA15: INX H ; src++
INR C ; dst++ (только младший байт, мы внутри блока B)
DCR D ; счет байт
JNZ LOA14 ; D<>0
POP B ; восст.(BC)
MOV L,C ; (BC)=(HL)
MOV H,B ; --//--
Я бы поставил на то, что авторы хотели побыстрее написать загрузчик влезающий в 512 байт и упростили себе задачу.Цитата:
Сообщение от svofski
Если все без ошибок (чтение из памяти и запись в память), то в итоге область источника будет обнулена.Цитата:
Сообщение от svofski
Хорошо, тогда у меня такие вопросы:Цитата:
Сообщение от ivagor
- обнулена область будет при отключенном ПЗУ или адресах, куда ПЗУ не отображается. При включенном ПЗУ в младших адресах мы считываем назад не то, что записали. Значит загрузка в младшие адреса -- это "ошибка" ?
- что если все же с ошибками? Разве это тест ОЗУ? Может быть я не нашел, но вроде бы область буфера на нули нигде не проверяется.
Но в общем я согласен, что время было ограниченно, а средства разработки неприступны. Скорее всего замариновали ту версию, которая наконец заработала.
Последовательность загрузки все же по-моему задачу не упрощает. Это больше похоже на ложную цель, не знаю есть ли у этого какое-то классическое название. Когда ты при выполнении задачи зацикливаешься на достижении чего-то, что почему-то запало как нечто архиважное, но на самом деле не имеющего к делу никакого отношения.
А я не смотрел newrom v(2.0), возможно это предполагаемое обнуление (или необнуление в случае пересылки в область пзу) никак и не проверяется дальше. Вещь в себе. Может бездумно скопипастили с другого компа фрагмент.Цитата:
Сообщение от svofski
Ага. Мне просто он попался под руку. Не нашел с ходу записи с прошлого разбора загрузчиков, когда делал автостарт для loadfm. Заглянул и удивился.
А мне кажется, что это "защита" загружаемой информации.
Штатный загрузчик принимает данные с ленты и помещает их в буфер на экране. Это потенциальная уязвимость. Поскольку данные можно переписать с экрана, и восстановить их даже если они защищены от копирования.
Собственно так вскрывались начальные загрузчики программ, записанных на ленту в собственном формате... их загрузчик переписывался из экранного буфера на листочек, набирался, модифицировался, и игрушка копировалась.
А тут, экранный буфер практически сразу после заполнения модифицируется (при его копировании на положенное место), и данные "переписать" значительно сложнее.
Я так думаю.
Если их загрузчик по любому грузился стандартным загрузчиком, не было проще загрузить этот промежуточный загрузчик своим измененным не-стандартным загрузчиком и спокойно разобрать его устройство? Идея взламывать чего-то перерисовывая с экрана битмапы, со скоростью 50 кадров в секунду мне кажется достойным комментария на хабре.Цитата:
Сообщение от KTSerg
Ну и кроме того, неиспорченные данные ведь уже успели промелькнуть к этому моменту на экране по любому, значит их можно было успеть перерисовать.
На заре, даже кваза ещё не было. Выкручивались как могли. До получения исходников начального загрузчика или хотя-бы самого кода загрузчика было ещё ой как далеко.Цитата:
Сообщение от svofski
А написать амому загрузчик с лены, это не тривиальная задача, даже имея описание формата ром-а в Вектор-Юзере.
Когда данные не уничтожаются, то есть достаточно времени нажать БЛК+ВВОД, что-бы "поймать" кадр с нужным битмапом, перед тем как он будет переписан новыми данными, а вот когда он сразу после получения уничтожается (при копировании), поймать будет значительно сложнее.Цитата:
Ну и кроме того, неиспорченные данные ведь уже успели промелькнуть к этому моменту на экране по любому, значит их можно было успеть перерисовать.
Для современных технологий, знаний, и опыта, такой "финт" конечно выглядит не понятно, или наивно. Но если-бы такое было изначально в штатном загрузчике...
Я только не понял, причём тут 50 кадров в секунду?