Вот если б не такие шедевры и не подумал бы бейсик в картотеку добавлять. А придется.
Вид для печати
Вот если б не такие шедевры и не подумал бы бейсик в картотеку добавлять. А придется.
Вопрос на засыпку...
Есть ли в эмуляторах Вектора возможность взаимодействия со "сторонними" модулями/программами/библиотеками ?
Например: в конфиге эмулятора прописывается, что при работе с конкретным портом ввода-вывода (запись и/или чтение), нужно отправить байт или прочитать байт работая с неким приложением/модулем...
Это позволило-бы например (написав "внешнюю программу") "эмулировать" работу не стандартного внешнего оборудования (контроллера) для Вектора, без внесения изменения в сам эмулятор...
KTSerg, в v06x можно наскриптовать все, что угодно. Перехвата портов ввода-вывода нет, потому что я делал минимально то, что было нужно для загрузки .rk и .bas. Но для этого на самом деле все готово, просто надо сделать. Сам скриптовый язык достаточно мощный, чтобы на нем написать эмулятор Вектора ;)
Чтобы получить общее представление, можешь заглянуть в то, как сделана загрузка бейсиковских файлов, например. Для зацепки есть два колбека: frame и breakpoint. С кадром все понятно. breakpoint это та же точка останова из отладчика, только оператором отладчика становится скрипт. Все доступные вызовы расписаны в README.
Взаимодействие с внешними программами это чуть сложнее. Есть какой-нибудь конкретный пример, что бы ты хотел сделать?
Я всё "колдую" над контроллером ЛВС, который подключен к "ПУ".
Сейчас к нему подключена SD-карта. С неё при старте в Вектор грузится программка типа "эмулятор монитора". Далее используя тот-же протокол ЛВС, контроллер общается с Вектором. По сути Вектор используется как консоль, коды нажатых клавиш передаются в контроллер ЛВС, а с него в Вектор передаются команды вывода символов на экран.
В результате на экране Вектора получаем доступ с файлам SD-карты. После выбора файла, он грузится в Вектор.
Основная идея была грузить на КвазиДиск образ из файла EDD, и иметь возможность потом сбросить (измененный) образ КвазиДиска в файл на SD-карту.
Но это аппаратный контроллер, который периодически приходится модифицировать, что-то подпаивать/перепаивать.
А если-бы эмулятор Вектора имел возможность при работе с портами ввода-вывода работать с внешними ресурсами, то можно было-бы значительно упростить процесс отладки контроллера и софта.
Да и просто помечтав, например слепить виртуальный "контроллер Ethernet" посаженный на "ПУ" (или другие порты), грузить программы в эмулятор непосредственно из каталога http://www.sensi.org/scalar/categories/all/ ;)
Ну или с помощью внешней программы адаптировать к эмулятору не стандартный Джойстик, виртуально подключив его к портам "ПУ" как "стандартный" для Вектора.
Или реализовать программную эмуляцию других контроллеров, для возможности их использования в "Эмуляторе"...
Загрузить файл с диска сейчас уже можно. Фактически, чтобы сделать эмуляцию твоей железки, тебе не хватает возможности зацепиться за ввод-вывод в порты ПУ. Я правильно понял?
Это понятно, что в эмулятор можно файл загрузить. Но это частный случай, и применим только к эмулятору.Цитата:
Сообщение от svofski
А при разработке реальной "железки", которая в перспективе должна работать с реальным Вектором, была-бы полезна возможность отладки в эмуляторе. И в таком случае просто загрузки файла уже маловато...
Да и "подключение" контроллера к эмулятору Вектора не ограничивается задачей загрузки файла.
Да работы эмулятора с внешним "ПУ" уже на многое хватит.Цитата:
Фактически, чтобы сделать эмуляцию твоей железки, тебе не хватает возможности зацепиться за ввод-вывод в порты ПУ. Я правильно понял?
Правда на сколько я понимаю, есть много разных способов общения двух программ (в нашем случае эмулятора Вектора и эмулятора контроллера). А в этом я не спец :( Один раз, 15 лет назад, во время лабораторных работ, кидали сообщения между программками... вот и весь мой опыт.
Для выбора наиболее удобного для реализации и использования нужны знания и практический опыт, которыми я не обладаю.
Хотя "работа" с портами ввода-вывода это по 1-му байту за раз...
KTSerg, если у тебя нету какой-то отдельной программы, эмулирующей железку, то проще эмулятор железки написать в самом скрипте. Я может быть плохо выразился, но под загрузить файл я имею ввиду не загрузку rom в эмулируемый Вектор, а загрузку произвольного файла в массив из скрипта. Этот массив можно интерпретировать как что угодно, может быть это образ SD-карты, может быть один файл.
Например, давай распишем игрушечную железку-расширялку, почему-то на порту 0x33-34:
1. в порт 0x33 записывается 0x01 "MYFILE.ROM", 0x00 - это команда загрузить файл.
2. Вектор как бы крутится, читает порт 0x34 обратно и там пока 0
3. железяка загрузила файл в и выставила в порт 0x34 "1"
4. дальше на все запросы ввода из порта 0x33 железяка возвращает сначала длину файла, потом его содержимое байт за байтом
То же самое скрипт-эмулятор:
Перехватываются порты 0x33, 0x34:
Когда появилась команда мы ее исполняем -- то есть в нашем примере загружаем в массив содержимое запрашиваемого файла
Когда Вектор из порта читает статус и данные, подсовываем ему их из скрипта
Вот и все. Понятно, что реальная железяка сложнее, это просто такой хелло вролд.. Сейчас перехват портов не сделан, но если это востребовано, я могу прикрутить.
Не уверен, что я правильно все понял, но возможно KTSerg пишет про доступ к реальным интерфейсам ПК изнутри эмулятора. Правда физических LPT в современных компах нет.
Не сомневаюсь, что скрипт - это круть...Цитата:
Сообщение от svofski
Но я пока не готов к такой крутизне. Делфа и Кейл пока привычнее.
А "проброс" портов из Эмулятора Вектора во "внешний мир", это пока только тема для размышлений.
Возможно когда появятся идеи для реального использования такой фишки, можно будет подумать и о реальной реализации... пока только как идея...
Если это так, то с современным ПК это в первую очередь задача подключения к нему этой железки и написание драйверов. Только это ой и по-моему в случае с Вектором задачу усложняет экспоненциально.. Да и вообще не понятно, какую задачу это решает?Цитата:
Сообщение от ivagor
Я это понял немного иначе. Что прототип железки сначала делается в эмуляторе, на этой связке пишется софт и обкатываются возникающие проблемы. Потом проще делать реальную железку с уже наверняка работающим софтом. И отлаживать ее проще, сверяя с эмуляцией.
Да это буквально одно из применений.Цитата:
Сообщение от svofski
Прямой задачи доступа к реальным ресурсам ПК, я конечно не ставил.
Второе применение это реализация программной эмуляции неких реальных или гипотетических контроллеров, для их использования с эмулятором при отсутствии реального Вектора, без внесения изменений (реализующих контроллер) в эмулятор Вектора.
Чтобы упростить решение проблемы курицы и яйца, дописал скриптование устройств ввода-вывода: Ссылка. Примитивный пример в scripts/iohook.chai реализует инвертер на порту 0x33.
Интересно, тестировали ли когда-нибудь переключение "на лету" режима 512/256 символов?
В демке dizrek_.rom во всех эмуляторах картинка заставки (на втором экране и дальше) иногда "подмаргивает" - неточная эмуляция или на реале так же?
Pyk, на моем реале не подмаргивает (или может быть только когда я моргаю ;) ) -- https://youtu.be/pZkqfxt4DYw (зря он что ли на подоконнике место занимает?)
На всякий случай оговорюсь, что это Вектор-06Ц с доработкой синхры и по-моему нету 100% консенсуса насчет влияния доработки на подобные эффекты.
Я бы не связывал возможные мигания в dizrek_ с переключением режима 256/512. Имхо там единственная возможная причина мигания - если в какой-то момент плеер выходит за отведенный интервал и синхронизация временно рушится.
На реале переключение режима 256/512 не должно приводить ни к каким "подмаргиваниям", так схема формирования изображения сделана, что переключение происходит "на ходу". Скорее всего должны быть демки в которых разные части экрана работают в разных режимах одновременно.Цитата:
Сообщение от Pyk
В эмуляторах если "подмаргивание" действительно связано переключением режима, то возможно это связано с переключением "разрешения" экранной области, хотя я в этом и не уверен, т.к. не имею представления как в эмуляторах происходит "вывод на экран".
Дело конечно же в синхронизации, но заметно на переключении режима. Это может быть момент начала прерывания, а может быть момент, когда именно появившийся в порту битик начинает оказывать влияние на схему генерации видеосигнала.Цитата:
Сообщение от ivagor
Вот как это проявляется у меня в эмуляторе. Сделал 512x256 инверсным, чтобы это было хорошо видно
https://www.youtube.com/watch?v=bv8njWtlvG0
- - - Добавлено - - -
KTSerg, все может мигать и на реале если переключать не синхронно, или не одинаково каждый кадр. В дизреке@ прямоугольная врезка из 256x256 в нижней части экрана. И плеер AY. Похоже, что на некоторых кадрах, плеер не успевает полностью отработать вовремя и что-то там залезает на прерывание, отчего все сбивается на тютельку. Надо сказать, что размер тютельки судя по тому, что я сейчас вижу, довольно крупный.
На реале смыргивание тоже происходит, не могу поверить, что это не так. Но вся зона смещена влево, поэтому этого эффекта просто не видно. У меня есть специальная задержка между out и реальной записью в порт, она нужна была для разных других бордюрно-палитровых прелестей. Если я делаю быструю установку режима 512, без этого буфера, то мырганье пропадает. Хмм..
Для пробы версия DIZREK_ без музыки, возможно она не будет сдвигоморгать. Кроме самого конца, когда ожидание прерывания сделано не очень хорошо.
В самом конце оригинала dizrek@, то есть на последней сцене, в моем эмуляторе сдвигомыргает даже с хакой.
В версии ivagor-а врезка стоит монолитом так прочно, что слышится Реквием Лигети и хочется подбросить вверх чего-нибудь.
Так и должно быть, я это упомянул. Там ожидание прерывания не по HLT.Цитата:
Сообщение от svofski
Для надежности набросал тестик. В трех эмуляторах результат одинаковый (± 1 пиксель), отличается только в VV.
Неплохо бы проверить на реале.
Спасибо ivagor за использованные в качестве шаблона исходники предыдущих тестов, и svofski за pretty assembler :)
Была бы полезна сплошная линия под цифрами, для точного определения переходов.Цитата:
Сообщение от Pyk
Цепляю фото с 02-го.
В идеале да, но тут повезло, что момент окончания четко виден, а момент начала за 40 LoRes (или 80 HiRes) точек до этого.Цитата:
Сообщение от KTSerg
KTSerg, есть возможность проверить и на 06Ц? Разница вряд ли будет, но вдруг.
- - - Добавлено - - -
На всякий случай хака со сплошной линией
Сюрприз, однако :)
Самое прикольное, что похоже смещение на 0.5 пикселя. Даже не на целый 1/512 а на 1/1024.Вложение 68378Цитата:
Сообщение от ivagor
Вложение 68379
Если учесть, что изображение 02-го смещено влево на 1/256, то получим, что у обычного Вектора переключение режимов отстаёт.
Это видимо можно попробовать объяснить схемой Вектора. У 02-го бит 4 порта ВВ55 прямиком подключен к логике переключающей режимы. А у простого Вектора, между ними есть D34 (шинный формирователь), он видимо и задерживает переключение.
Я так думаю...
Я у себя поправил VV_6.97
Ramiros, стало очень похоже, но если приглядеться, то в "6" надо бы еще чуть правее продлить.
Я это заметил, но там уже доли такта (видимо связаны с задержкой распространения сигнала в логике) которые я не могу учесть в нынешней реализации. Но ошибка на один такт была поправлена )).Цитата:
Сообщение от ivagor
А я бы так сделал
- - - Добавлено - - -
Это, конечно, дело вкуса. Для точной имитации очевидно надо раза в два повысить разрешение, что для такой ерунды вряд ли оправдано. Хотя 1024 точки в активной области нужны и для точной эмуляции кристы-2.
Я пока не готов выложить окончательный фикс, но я прикинул локально и любопытно, что у меня получается точь в точь, как у Ramiros-а -- то есть два штришка у "6" сверху, а не три, как в эскизе ivagor-а.
svofski, я не спорю с тем, что если делать с точностью до точки 512 и специально не хакать, то получится как у Ramirosа. Просто мне больше бы понравился вариант как на "эскизе". Но я признаю, что "мой" вариант тоже не точный, и, как уже написал, это дело вкуса. Новые вершины точности эмуляции покорятся эмуляторам будущего, рендерящим 1024 точки в активной области, как-то так.
Увы, новую сборку emu80 показать пока не готов, но сделал пока так:Вложение 68395
Вроде бы как раз получилось нечто среднее между обычным "Вектором" и 02.
Но здесь 40 lo-res пикселей, в то же время у меня складывается ощущение, что на реале 41...
"dizrek_", кстати, моргает намного реже (кроме последнего экрана).
На мой взгляд такой вариант больше соответствует 06Ц.02.
В процессе прикручивания Z80 к Вектору в Emu80 попробовал запустить Jet Set Willy, которая запустилась в черно-белом режиме.
Прочитал, что она требует модифицированный квазидиск. Где бы найти информацию об этой модификации?
Если речь о "доработке Баркаря", то https://zx-pk.ru/threads/29377-kvazi...-barkarya.htmlЦитата:
Сообщение от Pyk
там даже тесты делали для проверки работоспособности этой доработки.
А кто-нить прикручивал Z80 к своему вектору на уровне железа? Все программы для с ВМ80 пашут на Z80 без проблем?
Вот ситуация, о которой я не так давно поднимал вопрос...
Возможность эмуляторов работать с внешней (для себя) программой, которая позволяет программно эмулировать некое устройство, подключенное к портам Вектора.
Всплыл мдос2хт... можно ли его запустить в каком нибудь эмуляторе? Нет, т.к. этот дос пользуется внешней ХТ-клавой...
Можно конечно взять и во всех эмуляторах внести "заплатки" на данный конкретный случай... но это не выход и не оправдывает затраты. Т.к. если вдруг "всплывёт" ещё что-то интересное. снова всем нужно делать "заплатку"...
А при наличии возможности о которой я говорю, достаточно написать внешний модуль/программу (не привязанную к конкретному эмулятору) которая позволит эмулируемому "Вектору" "получить доступ" к "внешнему оборудованию"...
Конечно svofski (спасибо ему ещё раз) уже сделал это на скриптах... думаю сделать эмуляцию ХТ-клавы на скриптах - плёвое дело... но для меня это пока "тёмный лес" :( :( :(
KTSerg, когда засядешь писать, не стесняйся спрашивать, если чего-то не понятно, или может быть не хватает. Я подключусь к процессу тогда.
Получилось 2-3 дня довольно плотно поработать над эмулятором, выкладываю сборку для тестирования.
http://emu80.org/v4beta/Emu80qt_40327_test.7z
Распаковать поверх 4.0.323 (http://emu80.org/v4beta/Emu80qt_40323.zip) с заменой файлов.
Все наработки по "Вектору" также влил в master и запушил на github.
Что сделано и пока не сделано (по части "Вектора"):
+ довольно точная (недеюсь) эмуляция экрана
+ квазидиск 256К с модификацией Баркаря
+ НГМД, AY
+ информация в отладчике о тактах процессора, ходе луча и состоянии контроллера НГМД
+ обновление в отладчике в реальном времени экрана "Вектора"
+ Z80. Длительность команд, имеющихся в 8080, вроде бы должна быть точной;
специфичных для Z80 - кратна 4 тактам, но не факт, что везде правильная
- пока нет HDD, RTC, ROM-диска, Covox
- таймером пока не занимался, с ним пока все не очень хорошо; звук в режимах 0 и 3 выводится,
но не уверен, что даже в этих режимах считываются правильные значения счетчиков
- иногда вылетает с исключением при закрытии
Я не очень ориентируюсь в софте для "Вектора", неплохо бы потестировать его на программах,
эксплуатирующих различные особенности его реализации (пока кроме таймера).
Я вообще много чего еще о Векторе пока не знаю. Например, какой бейсик для него можно считать стандартным,
перехваты работы с магнитофоном для каких программ стоит сделать, могут ли в файлах VEC присутствовать
какие-нибудь особенности, отличающие их от rom, где найти описание встроенного в 32К-загрузчик Монитора
"Супер-монстр"? В общем, принимаются советы, что еще в эмуляторе нужно сделать в плане "Вектора".
Pyk, спасибо, движение в очень хорошем направлении!
Стандартный бейсик - 2.5
Монитор супер-монстр - это слегка доработанный стандартный монитор-отладчик, руководство которого здесь, про отличия здесь.
Насколько помню, vec это как rom, только расширение другое (предложил автор одного из древних эмуляторов).
Магнитофонный перехват нужен как минимум в бейсике 2.5, мониторе-отладчике и эмуляторе рк-микроши.
Попробовал игрушки z80, почти все работают, кроме knight lore, на мой взгляд проблема в опросе клавиатуры при маске BF.
И в целом звук AY как-то слегка заикается.