Просмотр полной версии : Вектор-06Ц: Эмуляция
Страницы :
1
2
3
4
[
5]
6
7
Есть поддержка популярных устройств, таких как - внешнее ПЗУ, R-Sound, Covox, Джойстики. Настраивается все через меню.
а подключить что нибудь не стандартное?
а подключить что нибудь не стандартное?
нет ))
Есть поддержка популярных устройств, таких как - внешнее ПЗУ, R-Sound, Covox, Джойстики. Настраивается все через меню.
Ramiros, если ты когда-нибудь всё же решишься на поддержку Sound Tracker и R-Sound одновременно, это будет просто замечательно!
Я уже вроде-бы спрашивал, не помню, спрошу ещё раз.
Эмуль VV - очень тормозит, в нижнем левом углу (видимо FPS) показывает 18/50 в оконном режиме, в полноэкранном 12/50.
Когда запущен МикроДос, набрать команду (имя файла) практически не возможно, клавиши или не срабатывают или срабатывают сразу несколько раз.
Комп IP4 2.2Ггц, ось - ХР.
Комп слишком слабый для эмуля, или конфликтует с чем-то?
KTSerg, IP4 известен своей низкой производительностью на такт, для VV уже достаточно IP4 3ГГц, при условии что видео карта не Intel GMA950 или того хуже...
для VV уже достаточно IP4 3ГГц
Какие-то страхи пишете. Запускаю VV на core2 duo 2,8 ГГц, показывает загрузку процессора около 10%, а скорость процессора ВМ80 100%.
Если запускать на ноуте со встроенной видюхой (Intel HD Graphics 3000), то картинка мерцает почему-то.
Какие-то страхи пишете. Запускаю VV на core2 duo 2,8 ГГц, показывает загрузку процессора около 10%, а скорость процессора ВМ80 100%.
Я не выдумываю, я пробовал запускать VV на Pentium4 2,4GHz, тормозило, а после разгона бедного P4 до 3.6GHz тормозить перестало, и загрузка CPU была на уровне 70% ))
Что вы сравниваете разные поколения процов, одно ядро равночастотного core2duo быстрей pentium4 в три раза, а ядер в core2duo еще и два, в то время как pentium4 только прикидывается двухядерным, а на самом деле одноядерник.
Чтобы не быть голословным хотел проверить на Р4, но под рукой оказался Celeron 430 1,8 GHz, 1 ядро. Ничего не тормозит, скорость ВМ80 100%, загрузка селерона около 75%.
После скачивания эмулятора включил только ковокс. Может, у вас что-то дополнительно было включено?
http://ixbt.photo/?id=photo:1142771
Чтобы не быть голословным хотел проверить на Р4, но под рукой оказался Celeron 430 1,8 GHz, 1 ядро. Ничего не тормозит, скорость ВМ80 100%, загрузка селерона около 75%.
После скачивания эмулятора включил только ковокс. Может, у вас что-то дополнительно было включено?
http://ixbt.photo/?id=photo:1142771
Celeron 430 это ядро Conroe-L, это архитектура Core или по сути обрезанный Core2duo. http://www.cpu-upgrade.com/CPUs/Intel/Celeron/430.html Не удивительно что на нем не тормозит ))
А Pentium4 или Celeron D это более старая архитектура NetBurst, которую Intel свернул из за ее провальной тормознутости.
Запустите именно на Pentium4 или Celeron D и убедитесь в моих словах ))
Ramiros, вы меня заинтересовали. Попробую поискать пень4 или селерон д.
Пока у меня есть некоторые данные тестов скорости памяти пентиум 4
Intel Pentium 4, 2.66 GHz, 480 MB PC2100, int SiS M650_651_650_740, 32 MB, WinXP HE SP2 32bit:
Чтение из кэша 9760 МБ/с, чтение из оперативки 1184 МБ/с, запись в оперативку обычная 480 МБ/с, запись в оперативку без кеширования 1536 МБ/с.
и этот селерон
Intel Celeron 430, 1.8GHz, 760 MB RAM (512 MB Dual channel), Intel 82945G Express (Int), WinXP SP3:
Чтение из кэша 6776 МБ/с, чтение из оперативки 3128 МБ/с, запись в оперативку обычная 1136 МБ/с, запись в оперативку без кеширования 3256 МБ/с.
Т.е., пентиум 4 может отставать из-за работы с памятью DDR против DDR2 у Celeron 430. В общем, нужно смотреть конкретную конфигурацию.
Я согласен, что "пень" пень у меня тормозной, да ещё видюха Радеон9200 (на которой современные программы даже не запускаются)...
Пробовал отключать/включать разные настройки звука/экрана ... в эмуле VV...
При настройках экрана "оригинальный размер" - ФПС начал доставать до 50/50 и загрузка проца снизилась до 80..90%%
Но при этом ничего не возможно разобрать на экране в МикроДосе.
Такое ощущение, что пропускает колонки пикселей.
При настройках экрана "оригинальный размер" - ФПС начал доставать до 50/50 и загрузка проца снизилась до 80..90%%
Но при этом ничего не возможно разобрать на экране в МикроДосе.
Такое ощущение, что пропускает колонки пикселей.
Оригинальный размер предполагает, что на векторе включено разрешение 256х256, но микродос использует разрешение 512х256, поэтому для читаемости надо выбирать хотябы следующее (Average size).
Оригинальный размер предполагает, что на векторе включено разрешение 256х256, но микродос использует разрешение 512х256, поэтому для читаемости надо выбирать хотябы следующее (Average size).
Ясно, спасибо.
На "Average size", загрузка проца уже слишком большая, пришлось указать "Skip Frames" 4 или 8 - разгружают проц и клава начинает вполне адекватно реагировать в МикроДосе.
Что означают проценты загрузки ВМ80 ? Обычно указано 100%, но иногда падают до 17%.
Что означают проценты загрузки ВМ80 ? Обычно указано 100%, но иногда падают до 17%.
показывает соотношение работы и простоя процессора после команды HLT.
можно попробовать выкраить быстродействие отключив опции:
File-Tape-Support CAS File;
Screen-Rendering-High Quality;
И включить опцию Screen-Rendering-Pixeling.
показывает соотношение работы и простоя процессора после команды HLT.
Ясно.
можно попробовать выкраить быстродействие отключив опции:
File-Tape-Support CAS File;
Screen-Rendering-High Quality;
И включить опцию Screen-Rendering-Pixeling.
"High Quality" - было уже выключено, остальное возможно даёт эффект, но он особо не заметен.
Больший эффект получается при включении пропуска кадров, при значениях 2-4 - граница загрузки проца, при меньших значениях начинает значительно тормозить, при больших вполне приемлимо (для "Average size").
Ramiros, последния версия эмулятора была 6.88 за май 2016.
ещё обновления были, будут ?
Ramiros, последния версия эмулятора была 6.88 за май 2016.
ещё обновления были, будут ?
Да это крайняя версия, обновления будут только по багам, если найдутся.
Вопрос к Ramiros по эмулятору VV: что делает пункт меню Display Frequency? Всегда почему-то думал, что он просто даёт выбрать частоту кадровых прерываний (сделать её больше или меньше стандартной 50 Гц), а на частоту процессора не влияет. Потом, видя, что изменение этого пункта влияет и на частоту звука через ВИ53, решил, что он регулирует и тактовую частоту ВИ53. Но выяснилось, что при этом и частота процессора тоже меняется. Вопрос: как конкретно работает Display Frequency – изменяет пропорционально заданной частоте кадров как бы частоту кварца «Вектора» (т.е. и частоту процессора, и частоту таймера, и кадровую – всё вместе)? А можно ли сделать так, чтобы менялась только частота прерываний от кадровой развёртки (а частоту процессора при необходимости менять в соотв. пункте меню)?
И ещё на ту же тему: каково точное действие пункта Skip Frames?
Вопрос к Ramiros по эмулятору VV: что делает пункт меню Display Frequency? Всегда почему-то думал, что он просто даёт выбрать частоту кадровых прерываний (сделать её больше или меньше стандартной 50 Гц), а на частоту процессора не влияет. Потом, видя, что изменение этого пункта влияет и на частоту звука через ВИ53, решил, что он регулирует и тактовую частоту ВИ53. Но выяснилось, что при этом и частота процессора тоже меняется. Вопрос: как конкретно работает Display Frequency – изменяет пропорционально заданной частоте кадров как бы частоту кварца «Вектора» (т.е. и частоту процессора, и частоту таймера, и кадровую – всё вместе)? А можно ли сделать так, чтобы менялась только частота прерываний от кадровой развёртки (а частоту процессора при необходимости менять в соотв. пункте меню)?
И ещё на ту же тему: каково точное действие пункта Skip Frames?
Частота процессора и всего остального привязана к частоте кадров. На CPU Speed Normal (3МГц) между кадрами всегда 59904 процессорных такта, если это соотношение нарушить, съедет вся синхронность и мультиколорные фичи перестанут работать. Если выбрать пункт CPU speed other, то можно задавать свою тактовую частоту для CPU, но тут тоже надо учитывать что кадровая частота подразумевается 50 Гц, если другая то надо учитывать коэффициент на который она отличается от 50.
На векторе есть еще одна тонкость - реальная частота кадров равна 3000000/59904=50.08 Гц. если выбрать пункт CPU speed other и задать 3 МГц, то там по формуле задасться 60000 тактов и частота кадров будет ровно 30000000/60000=50 Гц.вроде бы мелочь, но для точной эмуляции это критично и все мультиколорные фичи будут не точно отрисовываться )).
Skip Frames задает эмулятору сколько кадров подряд не отрисовывать на экране (например Frames 8 означает что 1 кадр нарисуем и 8 пропустим и т.д.) т.е. задумывалось для облегчения нагрузки для слабых машин. в наше время практически не актуально т.к. на современных машинах рендеринг отъедает примерно 1-5% всего процессорного времени. если только не пытаться запустить эмуль на пентиуме 3. пункт влияет только на конечную картинку и никак не сказывается для программ вектора и его виртуального железа.
Ramiros, а можно как-то настроить VV так, чтобы в полноэкранном режиме сохранялись заданные пропорции экрана? У меня все мониторы широкие и фуллскрин в VV смотрится из-за этого не фонтан.
Ramiros, а можно как-то настроить VV так, чтобы в полноэкранном режиме сохранялись заданные пропорции экрана? У меня все мониторы широкие и фуллскрин в VV смотрится из-за этого не фонтан.
Можно попробовать сделать черные поля по бокам, тут проблем в общем то нет, по другому наверное не получится т.к. в VV картинка формируется наложением двух текстур - бордюра и самой картинки 256х256 (512х256) точек. нельзя растянуть текстуру бордюра а текстуру с картинкой не растягивать. вернее можно но получатся дыры между бордюром и самой картинкой.
Можно попробовать сделать черные поля по бокам
По-моему именно так и надо делать (не забывая при этом, что бывают еще мониторы вертикальные). Растягивать бордюр было бы неправильно, потому что все привязано к тактам.
Приложенная программка зависает через некоторое время бенчмарка (старт бенча по УС, СС или РУС/ЛАТ) - от 30 сек до примерно 2 с половиной минут. Пробовал 6.89, 6.87 (ВМ80 и z80) и 6.76. Т.к. все виснет и в дебаггер попасть не могу, затрудняюсь назвать точное место. Возможно дело в конкретном конфиге, другой комп смогу попробовать только во вторник.
В emu все нормально.
ivagor, многократно проверил на intel и amd, все норм. не виснет
Запустил VV от имени администратора (на той же системе) - все доработало до конца.
Обновился VV (http://sensi.org/~svo/virtualvector/). Cделано масштабирование 4:3 для FullScreen
У меня есть такой вопрос... надеюсь, не сильно оффтопный. Насколько код VV завязан на Windows? Будет ли реалистично сделать порт под Linux и Raspberry Pi?
Да, навскидку я понимаю, что придётся полностью переделать вывод звука, и здесь надежда только на то, что PulseAudio оперирует примерно теми же понятиями, что и DirectSound
С графикой - насколько помню, в VV была поддержка OpenGL - может быть даже проще...
GUI переписать на Qt или GTK тоже не должно быть большой проблемой
Но блин как было бы круто воткнуть "малинку" в видеовход телевизора и увидеть там тёплый ламповый загрузочный экран "Вектора"... :v2_dizzy_keyboard:
P.S. Про наличие JavaScript эмулятора я в курсе, и даже посмотрел бегло его код на гитхабе. Но что-то есть смутные сомнения, что будет работать с приемлемой скоростью на "малинке", а так, конечно, проще всего было бы завернуть в Electron приложение и не мучаться с портированием
x-code, я знаю, что в MAME есть какая-то рудиментарная поддержка Вектора-06ц (http://www.progettoemma.net/mess/system.php?machine=vector06). Вот последний коммит в него (https://github.com/mamedev/mame/commit/409427c7cca5add9bbfc60d07e5b1505af40a49d).
Может быть попробовать туда копнуть? Попробовать сначала собрать на какой-то вменяемой машине наверное, если получится, пересобрать для рпи. Можно даже доделать.
Про Electron я почему-то не думал. Быстро у меня это не получится. На скорую руку попробовал запустить chromium с vector06js на RPi3, результат никуда не годится. При этом на телефоне вполне убедительно все крутится. В raspi уж очень много прослоек и все кривые, я плохо в них ориентируюсь. Может быть и можно подобрать какую-то волшебную формулу, с которой все компоненты rpi3 вдруг заработают вместе эффективно, но по-моему скорее получится доделать драйвер Вектора из MAME.
Но я бы все равно предпочел отдельностоящий кроссплатформенный эмулятор Вектора.
недавно читал википедию https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6
и наткнулся там на такое
"Кроме того, был разработан ROM-диск объёмом 65 КБ или больше, на котором обычно размещались часто используемые программы, например: Бейсик, монитор-отладчик, текстовый редактор. Была создана схема подключения жёсткого диска с возможностью разбиения диска на логические области и операционная система с поддержкой НЖМД"
а в vv есть эмуляция жёсткого диска ?
ОС для НЖМД есть, но ей, мягко говоря, не очень удобно пользоваться. И для эмулятора поддержка НЖМД теряет смысл, т.к. по сути, при работе в ОС для НЖМД пользователь получает логический набор дискет (НГМД), между которыми нужно переключаться, переходя с диска на диск обычным способом (C:, D:, E:...). С таким же успехом можно просто менять дискеты (это про эмулятор), эффект аналогичный, в эмуляторе с обычной ОСью это (менять дискеты) даже нагляднее и понятнее.
Хотя под ОС для НЖМД вроде-бы есть игрушка... но я её или не смог запустить, или не смог поиграть... в памяти не отложилась...
У меня есть такой вопрос... надеюсь, не сильно оффтопный. Насколько код VV завязан на Windows? Будет ли реалистично сделать порт под Linux и Raspberry Pi?
Да, навскидку я понимаю, что придётся полностью переделать вывод звука, и здесь надежда только на то, что PulseAudio оперирует примерно теми же понятиями, что и DirectSound
С графикой - насколько помню, в VV была поддержка OpenGL - может быть даже проще...
GUI переписать на Qt или GTK тоже не должно быть большой проблемой
Но блин как было бы круто воткнуть "малинку" в видеовход телевизора и увидеть там тёплый ламповый загрузочный экран "Вектора"... :v2_dizzy_keyboard:
Код VV очень сильно завязан на x86, еще конечно есть завязки на direct sound. на х86 завязан потому, что VV зарождался еще в далеком 1998 году. и первые версии были под DOS, и там была борьба за быстродействие, поэтому эмуляция процессора и многое другое писалось ассемблерными вставками. Многое из это наследия и сейчас присутствует в исходниках VV. Перенести VV на линукс прямо в лоб, врят ли получится, но думаю это проще чем писать с нуля. но даже если это сделать, все равно на Rpi и т.п. ARM машинах запустить не получится т.к. надо переписывать x86 специфический код.
- - - Добавлено - - -
а в vv есть эмуляция жёсткого диска ?
нет ))
Тест сброса 8052 в 0 при установке режима: http://sensi.org/~svo/b/brdtestx.rom
Сорец для прекрасма https://pastebin.com/Nhv6zffD
VV и vector06js:
http://sensi.org/~svo/b/brdtest-vv.png
b2m:
http://sensi.org/~svo/b/brdtest-b2m.png
В свете недавних событий с отладкой Рива Рейда и благодаря перекрестному анализу разных текстов и сорцов я почти уверен в результате. Между тем я поправил vector06js, добавил себе автотест и карточку в картотеку (http://sensi.org/scalar/ware/898/).
По идее так же надо проверить и другие проверябельные порты, например должен сбрасываться tape out.
- - - Добавлено - - -
x-code, я собрал mess на rpi3. Выглядит это вот так (лучше не смотреть): https://youtu.be/-55Bx3fNK_I
Никакого теплого лампового Вектора, сплошная мертвящая цифра. На самом деле даже мой vector06js в chromium-е выглядит лучше: фреймрейт примерно такой же, но хотя бы реальное время соблюдается корректно. Тут на самом деле загадка: в чем дело? В лице Retropie есть убедительное доказательство того, что рпя3 способна эмулить системы значительно более продвинутые, чем Вектор. Может быть какие-то особенности сборки, может быть libretro запатчен с головы до ног, а я этих патчей не брал.. Хорошо бы разобраться.
На реалах 06Ц и 06Ц.02 картинка как на b2m - с ребристым бордюром (если речь о нём).
По крайней мере на ч/б мониторе...
Или вот еще такой тестик (только красоты в нем совсем нет).
Слева результат emu, справа - VV
Или вот еще такой тестик (только красоты в нем совсем нет).
Слева результат emu, справа - VV
Если разница в бордюре, то на "реале" бордюра не вижу.
Может зациклить тест с принудительным миганием бордюра, что-бы нагляднее было...
Правда у меня ч/б некоторые сочетания цвета могу и не видеть...
Да разница в цвете бордюра. Значит правильность работы emu по данному вопросу еще раз подтверждена.
Насчет мигания - думаю это излишне.
Там всего два цвета, как раз ч/б.
Просто неожиданно, что в VV ВВ55 в сторону проца работает нормально (вроде доработки этой части были связаны с колобихой), а в сторону бордюра - только через порт 2 (по крайней мере так можно заключить из теста).
ivagor, полезный тест. А можешь его расширить для портов A и C?
- - - Добавлено - - -
Ну и заодно посмотреть на результат IN 0.
Расширенный тест.
Слева - emu, cправа - VV (не ожидал таких результатов)
Расширенный тест.
Слева - emu, cправа - VV (не ожидал таких результатов)
06Ц.02
Test 1: 0-33; 1-11; 2-22; 3-33
Test 2: 0-FF; 1-EB; 2-FF; 3-7B
Test 3: 0-00; 1-00; 2-00; 3-00
Test 4: 0-FF; 1-FB; 2-FF; 3-FC
Во нашел шнурок от фотика...
По поводу РУС: была информация, что оттуда читается последнее записанное в любой из портов А,В,С значение. Тест подтверждает это, но однако показывает, что если порты настроены на ввод, то оттуда читается FF. Можно поправить в эмуляторе для аутентичности (у меня пока возвращается ноль). Что возвращать, когда порт настроен на ввод, а схемно он предназначен на вывод - непонятно.
когда порт настроен на ввод, а схемно он предназначен на вывод - непонятно
Кроме как затычкой специфичной для схемы никак. Вывод как правило подтянут либо к нулю, либо к единице (чаще к единице). Значит, если такой вывод настроить на ввод, он прочитает то, к чему подтянута шина.
А как объяснить результаты этого теста?
По поводу РУС: была информация, что оттуда читается последнее записанное в любой из портов А,В,С значение.
Если так, то почему Тест 2 показывает FF?
но однако показывает, что если порты настроены на ввод, то оттуда читается FF
Недоперечитал?
- - - Добавлено - - -
Интересно, что прочитается из РУС если не все порты настроены на ввод.
А как объяснить результаты этого теста?
Уточни, какие именно =) Я вижу много непонятных мне цифр. Пока думаю что понимаю, что вижу, только в строках 1 и 3. Но думаю, что ты про строки 2 и 4.
- - - Добавлено - - -
Недоперечитал?
Феноменология. Это то, что мы видим, но можем ли мы доверять нашим органам чувств? Хотелось бы понять, как такое случается. Ведь портов три, а слово состояния одно.
Test 1: всё предельно ясно, порты на вывод, последним выводилось 33
Test 2: из РУС считалось FF, старшая часть порта 1 и порт 2 - данные с клавиатуры, зависят от порта 3, но он тоже на ввод (непонятно E в порту 1, клавиша нажата что-ли)
Test 3: тут тоже всё понятно, настроили порты на вывод, всё по нулям
Test 4: то же как и во втором тесте, но непонятно, почему порт 2 имеет уже другое значение (паразитные ёмкости?)
- - - Добавлено - - -
Хотелось бы понять, как такое случается. Ведь портов три, а слово состояния одно.
Я сначала думал, что возвращается содержимое двунаправленного буферного регистра шины данных ВВ55. Но если так, то почему во втором тесте читается FF, а не 33? Видимо нет никакого буферного регистра, а читается один из трёх регистров, ответственных за состояние портов А,В,С, а из какого именно - помнит мультиплексор, к какому последний раз обращались, значение того и вернёт. Если порт настроен на ввод, то в регистр не пишется, возможно при настройке на ввод регистр устанавливается в FF (чтобы меньше кушать по питанию, или использовать монтажное И, или ещё для чего). Ну или выходы регистра настроенного на ввод в третьем состоянии находятся (что более вероятно).
- - - Добавлено - - -
непонятно E в порту 1, клавиша нажата что-ли
Блин, просмотрел, это же бит ввода с магнитофона. Всё равно непонятно, почему то 0, то 1.
А на порту 3 что мы видим в тестах 2 и 4?
это же бит ввода с магнитофона. Всё равно непонятно, почему то 0, то 1.
Если KTSerg загружал wav с PC, и оставил шнурок подключенным, то компаратор мог среагировать на звуки с PC.
Но если загружал через "ЛВС" - тогда не знаю.
Торчащий провод подключенный к компаратору, в окружении плохо разведенной платы без даже земляного слоя и 70 микросхем.. Не, не может быть помехой.
А на порту 3 что мы видим в тестах 2 и 4?
Кто-ж его знает, что читается со входов ЛЕ1...
ЛЕ1 это где? Я вижу шину 4, которая идет на столбцы клавиатуры (XT1) и на страницу 2 на загрузку счетчиков D25-D24. Правда что так что эдак, я не вижу очевидных подтяжек нигде. Интересно, это работает как случайный процесс, или имеет склонность к самопогружению в стабильное состояние.
Добавил в тест вторую серию с "классическими векторовскими" 8Ah и 88h
Мне еще конечно хотелось бы узнать что в 0, когда не все порты настроены одинаково. Это правда совсем уже изврат и слишком много возможных состояний, так что не знаю, стоит ли это любопытство такой заморочки. Особенно при том, что даташит не просто говорит, что читать нельзя, я говорит, что читать нельзя.
Возвращаясь к Скайнету и проч. Удивительно, что никто не использовал это в своем коде, ведь это такой очевидный и удобный способ получить константу $FF, например.
И еще вариант.
Тесты 1-8: системная ВВ55 (т.е. аналог v3)
Тесты 9-С: ВВ55, которая подключена к ПУ. Если к ПУ что-то подключено, то перед тестом желательно отключить.
Возвращаясь к Скайнету и проч. Удивительно, что никто не использовал это в своем коде
Да, ещё один способ различить реал, мой эмуль и VV. Не хочется нарываться на гонку за подлинностью эмуляции, но я уверен, ivagor с лёгкостью напишет прогу, которая в зависимости от того, где она выполняется, выведет на экран "Реальный компьютер", "Virtual Vector" или "EMU 1.01". И будет трудно избежать искушения, обмануть эту программу. :)
Если бы с ухмылкой бы ладно, но ведь с серьезным лицом это сделает.
Не не не.
Раньше у меня была (нездоровая) радость от каждого найденного различия.
Теперь скорее раздражение или что-то в этом духе (типа ну вот опять...)
:D
По поводу значений в порту 3 я спокоен, а вот порт 0 и его FF мне все-таки покоя не дает.
По поводу отличия EB - FB, да пардон, грузил через магнитофонный вход, и оказалось, что плеер зациклен на воспроизведение. Т.е. тест выполнялся при изменяющихся на входе данных.
При отключенном "магнитофонном" проводе, стабильно считывается FB.
Вот фотки тестов V3, V4. (к ПУ ни чего не подключено).
И это еще режимы 1 и 2 не трогали. Наверно лучше и не трогать.
И это еще режимы 1 и 2 не трогали. Наверно лучше и не трогать.
Там открываются бескрайние возможности для злоупотребления, но осмысленно их использовать по-моему нельзя. Они требуют соответствующей схемоты вокруг ВВ55. Так, завалить беззащитный эмулятор, это конечно.
ivagor, я понимаю, что тесты и результаты может проанализировать каждый, но, как говорится, назвался груздем - полезай в кузов. Где аналитика? Что хотел и что прояснилось?
Ну вы тут раскопали ящик пандоры )) С бордюром разобрался. сейчас в VV тесты 1-8 проходят аналогично реалу за исключением РУС в тестах 5-8. почему в реале из РУС читается FF еще как то можно объяснить, а вот F3 и F0 ? у меня нет идей.
Когда порт 3 на ввод, я думаю читается рандомное значение. я в VV просто сделал рандом.
я в VV просто сделал рандом.
Криптографически стойкий, или обычный? ivagor быстро на чистую воду выведет =)
Мне кажется что если порт 3 стоял в режиме выхода и выдавал какое то число, а потом его переключить на вход и сразу считать, то в течении каких то миллисекунд будет читаться то, что было на выходе, потом заряды в затворах транзисторов микросхем конечно утекут и уже будет читаться помеха т.е. случайное число.
Раньше сядешь - раньше выйдешь. Пока большинство в переходном процессе после, я уже готов.
b2m, насчет аналитики - ты, svofski и Ramiros уже все понятные моменты озвучили.
По двум не вполне понятным моментам:
1. Тест 4, порт 3 - было бы здорово использовать в качестве аппаратного ГСЧ, но в 2х тестах из трех там FC, и в одном B8 - для ГСЧ, мягко говоря, слабовато. Разве что в качестве начального SEEDa брать, но, конечно, не для криптографии (ха-ха).
2. Тесты 6, 8, младшая половина порта 0. У меня только очень спорная идея - порты на вывод "продавили" в младшую половину последнее записанное в (1-3) значение, т.к. их "больше", чем на ввод.
Пункты 1 и 2 можно поковырять, но надо ли? Если бы у меня на столе стоял рабочий вектор, я бы не удержался, но его у меня нет, а обладателям реалов и авторам эмуляторов это думаю интересно примерно как режимы 1 и 2.
Удивляюсь (вслед за svofski), как авторы дем и защит не использовали такую тему. На мой взгляд ВВ55 даже хуже ВИ53 в плане всякой гадости, которую можно выцепить.
- - - Добавлено - - -
Забыл еще
3. Тест A, порт 1, старшая половина - 0 портит стройную картину.
Тест A, порт 1, старшая половина - 0 портит стройную картину.
Что-то кажется мне, если ввести задержки между записью и чтением портов, то результаты в данном случае другие будут (проверять не обязательно).
Обновил VV (http://sensi.org/~svo/virtualvector/VV_691.7z)
Ramiros, спасибо за доработку, но вопросы есть.
Порт 3 в тестах 2 и 4, как я понял, случайный - ну и бог с ним, там непонятно, для точности нужно дополнительно копать.
А вот что с портом 2 в тестах A и С? Да и в целом с тестом A?
Ramiros
А вот что с портом 2 в тестах A и С? Да и в целом с тестом A?
С портом 2 в моем случае все просто, там подключен внешний ROM диск, поэтому читается FF, возможность отключения я не предусматривал )).
Тест А вообще это нечто непонятное на первый взгляд. на самом деле просто напряжениям на висящем в воздухе порту ПУ стекать особо некуда, поэтому стекают они достаточно медленно. и если перед чтением сделать достаточно большую задержку то в реале прочитаются скорее всего тоже нули. ну а в эмуляторе эмулировать стекание зарядов на висящих в воздухе портах - это уже слишком )).
У меня появилось предчувствие, что не дотяну до преклонных лет. Авторы эмуляторов, единолично или вместе, как-нибудь встретят и прикопают в лесу.
Но emu желательно поправить.
А из этих портов тоже что-то предсказуемое должно читаться? У меня так заглушка $FF на все.
А разве не там где-то "аппаратные" Джойстики были посажены в 02-ом?
Это конечно провокация была...
Если склероз не изменяет на 02-ом Векторе на портах 0E и 0F исдят Джойстики, только не помню как их называли, что-то типа "УС"... не помню...
на 02-ом Векторе на портах 0E и 0F исдят Джойстики
Джойстики-С. Но если ничего не нажимать, то и из них должен читаться FF, разве нет? А если вдруг не FF, то это можно использовать для детекта 02.
А в эмуляторах, насколько я помню, никакие джойстики не поддерживаются.
Но emu желательно поправить.
У меня пока сомнения относительно алгоритма. Если скажешь (точно) как надо - поправлю. Короче - сколько вешать в граммах (https://www.youtube.com/watch?v=R5L5GUDAT5M)? :)
b2m, я ожидал из любых неиспользуемых (на чтение) портов FF.
Джойстики-С. Но если ничего не нажимать, то и из них должен читаться FF, разве нет? А если вдруг не FF, то это можно использовать для детекта 02.
А в эмуляторах, насколько я помню, никакие джойстики не поддерживаются.
в VV поддерживается на цифровой клавиатуре с включенным numlock (или если реальный джойстик подцепить).
Джойстики-С. Но если ничего не нажимать, то и из них должен читаться FF, разве нет? А если вдруг не FF, то это можно использовать для детекта 02.
А в эмуляторах, насколько я помню, никакие джойстики не поддерживаются.
02-ой Вектор по всем портам от 0С до 0F стабильно читает FF. Хотя по схеме входные биты 4 и 5 регистров джойстиков висят в воздухе (может в реале подтянуты к питанию)...
А вот простой Вектор по этим портам (от 0С до 0F) стабильно читает... барабанная дробь... 42.
А вот простой Вектор по этим портам (от 0С до 0F) стабильно читает... барабанная дробь... 42.
Вот это да...
Опять я такого не ожидал
- - - Добавлено - - -
Дуглас Адамс что-то знал
- - - Добавлено - - -
Если серьезно, то ведь так не должно быть, почему 42?
Вот это да...
Опять я такого не ожидал
...
Если серьезно, то ведь так не должно быть, почему 42?
Да ужжж.
Вектор такая штука, и спустя 30 лет может сюрприз подкинуть...
Если серьезно, то ведь так не должно быть, почему 42?
Слово состояния процессора?
Повесил на порты D-E CPU.state - действительно 42.
Слово состояния процессора?
Намекаешь, что у меня в тесте ошибка? Ткни пальцем, где?
Намекаешь, что у меня в тесте ошибка?
Нет, намекаю, что если шина не подтянута к еденице и все устройства в третьем состоянии, то читается то, что выдавалось в первом такте. В Микроше, например, в области памяти, где ничего нет, читается 82.
Еще раз проверил, что читается из порта, то и показывается.
- - - Добавлено - - -
Нет, намекаю, что если шина не подтянута к еденице и все устройства в третьем состоянии, то читается то, что выдавалось в первом такте. В Микроше, например, в области памяти, где ничего нет, читается 82.
А, вот как.
Еще раз проверил, что читается из порта, то и показывается.
Ну правильно, цикл чтения из порта, в такте Т1 выдаётся 42, оно же потом и читается из порта (точнее из ниоткуда).
Сравнил части схем 06Ц и 06Ц.02 - с проца на ВА86, другая сторона которого (или которой) подтянута через резисторы к +5В. В 06Ц резисторы 680 Ом, в .02 - 10 кОм. В этом дело (я про FF у .02)?
Думаю, всё намного проще.
Просто в 02-ом переделали схему выборки регистра в котором хранится слово состояния, и он перестал ложно спамить на шину...
А номинал резисторов связан скорее всего с переходом с 155-ой серии на 1533...
В 06Ц вижу, что биты слова состояния пишутся в 155ТМ8, в .02 - в 1533ТМ9. Т.е. в 06Ц возможно читает со входа триггера?
- - - Добавлено - - -
Я про то, что "штатной" выборки (с выходной стороны) на шину проца хоть из ТМ8 в 06Ц, хоть из ТМ9 в 02 не предусмотрено.
Если серьезно, то ведь так не должно быть, почему 42?
Кодовое название проекта было Deep Thought.
Нет, думаю из ТМ8 или ТМ9 не читается. Там ведь не все биты, а из 0C-0F читается полное слово состояния 42h. Т.е. в 06Ц оно как-то висит на шине, а в 02 - нет.
- - - Добавлено - - -
Просто для полноты - в 06Ц один из битов слова состояния (не влезший в ТМ8) запоминается в ТМ2.
- - - Добавлено - - -
И еще один - в другой ТМ2.
странно, у меня из PSW читается 56, а если выбрать Z80 то 42... или там не все биты участвуют?
Ramiros, речь про слово состояния, которое выдает на шину данных 8080 в первом такте машинного цикла в сопровождении SYNC.
Большое спасибо Дмитрию2012, он проверил на Векторе-2014 - тоже 42, как и ожидалось, т.к. это реплика 06Ц.
- - - Добавлено - - -
В теме про river raid еще раз поднимался вопрос программирования палитры. Дмитрий2012 проверил мой fastpalprog.rom на своем 2014 - все работает нормально, т.е. при тщательном выборе моментов программирования палитры хватает и одного out/цвет (проверено на двух векторах - бывшем моем 06Ц и 2014 Дмитрия).
странно, у меня из PSW читается 56, а если выбрать Z80 то 42... или там не все биты участвуют?
А ну да, я тупанул, подумал было что CPU выдает на шину состояние флагов ))
Нет, думаю из ТМ8 или ТМ9 не читается. Там ведь не все биты, а из 0C-0F читается полное слово состояния 42h. Т.е. в 06Ц оно как-то висит на шине, а в 02 - нет.
Просто для полноты - в 06Ц один из битов слова состояния (не влезший в ТМ8) запоминается в ТМ2.
И еще один - в другой ТМ2.
Самое прикольное, что судя по схеме, проц по командам IN от 0C до 0F - читает сам себя.
Т.к. D19 ВА86 на момент чтения этих портов отключена (на ОЕ "1"). А по схеме к шине данных проца подключены только ВА86, два порта и таймер (все отключены)... и даже подтяжки шины к питанию нет...
Осталось сделать временную подтяжку шины и проверить идею...
KTSerg, я дошел до предположения, что разница в логике формирования OE для ВА86, но в самой этой логике даже не начал разбираться.
KTSerg, я дошел до предположения, что разница в логике формирования OE для ВА86, но в самой этой логике даже не начал разбираться.
Проверил подтяжку шины проца...
Читает другое число. При подтяжке ноги 3 проца к +5 через 10К, стал читать 52. А 4 ноги 62.
Но если я правильно понимаю, в принципе есть и другой путь - изменение логики формирования OE для ВА86. С "другой стороны" ВА86 подтяжка к питанию есть.
Правда толку в этих изменениях и доработках нет, и так все работает. Зато теперь известен простой способ программного детекта 06Ц и .02.
... Зато теперь известен простой способ программного детекта 06Ц и .02.
Ну или возможно процов разных производителей в 06Ц. :)
Точный ответ на это вопрос может дать разбор формирования OE для ВА86. Но можно относится как к вопросу веры - я не верю, что это зависит от производителя ВМ80.
Интересно, что выдал бы z80, и это еще может зависеть от конкретного варианта установки.
Точный ответ на это вопрос может дать разбор формирования OE для ВА86. Но можно относится как к вопросу веры - я не верю, что это зависит от производителя ВМ80.
Интересно, что выдал бы z80, и это еще может зависеть от конкретного варианта установки.
Не, формирование ОЕ для ВА86 тут ни при чём. У 06Ц логика отключения ВА86 очень проста, всего два условия. Первое Чтение из порта ЧТВВ. Второе выборка адреса (порта) на шине адреса от 00 до 0F.
Соответственно, при чтении из портов с адресом ниже 10h ВА86 отрубает шину данных от проца, и на ней остаются только D27, D29, D30, причём без подтяжки шины к питанию. А т.к. в интервале адресов портов от 0C до 0F ничего на шине нет, то там сплошное Z-состояние. Вот проц сам себя и читает.
Скорее всего эти прочитанные 42 зависят от схемного решения входного/выходного каскада шины данных процессора. И если в этот каскад производителями вносились хоть какие-то изменения, то и проц будет считывать другие значения...
Но это моё ИМХО соответственно.
Пока не вижу противоречия, надо еще с условиями отключения ВА86 от проца в .02 разобраться.
- - - Добавлено - - -
Скорее всего эти прочитанные 42 зависят от схемного решения входного/выходного каскада шины данных процессора.
Как указал b2m, это четко слово состояния для цикла INPUT:
D0 (INTA) - 0
D1 (/WO) - 1
D2 (STACK) - 0
D3 (HLTA) - 0
D4 (OUT) - 0
D5 (M1) - 0
D6 (INP) - 1
D7 (MEMR) - 0
01000010b=42h
А вот интересно, с ВМ1 на борту, результат будет таким-же?
А с 10h и далее что будет читаться, FF ?
Сделал вчера такую проверялку, но не стал выкладывать.
А с 10h и далее что будет читаться, FF ?
Да, оба показывают предсказуемую картинку, источников инфы нет, у 06Ц подтяжка по питанию подключена (через ВА86).
x-code, заводи cmake ;)
https://github.com/svofski/vector06sdl
Пока только необходимый минимум для полноценной игры в River Raid на RPi3. На полных парах кушает меньше 40% одного ядра.
Опенсорсный эмулятор на c++, неужели я дожил до этого. svofski - респект! А под win его можно собрать?
Ну и хочу завершить тему с 42 и FF. Мое предположение, что FF в .02 связан с изменением логики формирования OE у ВА86 похоже было неверным. Внимательно посмотрел Вектор-USER 4 с прототипом джойстика-с. И бегло посмотрел этот фрагмент в .02. FF при чтении портов 0C-0F в .02 идет от джойстиков (только непонятно, откуда единицы и в битах D4-D5, висящих в воздухе, о чем упоминал KTSerg). Если в 06Ц реализовать схему из ВU4 (только там вроде биты контактов перепутаны), то из 0С-0F тоже пойдет FF. И, насколько я понял, при выборке джойстиков по схеме в вектор-user (и в .02) 0C=0E и 0D=0F.
... Если в 06Ц реализовать схему из ВU4 (только там вроде биты контактов перепутаны), то из 0С-0F тоже пойдет FF. И, насколько я понял, при выборке джойстиков по схеме в вектор-user (и в .02) 0C=0E и 0D=0F.
Вот в BU4 схема более правильная, там все входы ИР23 подтянуты к питанию, а в схеме Вектора 06ц.02 по два входа "в воздухе", детальки на плате 02-го посмотрел, увидел две группы резисторов по 6шт. (значит как в схеме, по два на группу - не хватает).
По поводу чтения портов, на 02-ом, так и есть 0С=0Е и 0D=0F, соответственно это J1 и J2 (по обозначениям разъёмов на корпусе).
И да, на схеме в BU4 контакты перепутаны. На 02-ом, контакт 2 разъёма - это GND...
А под win его можно собрать?
Можно конечно. Попозже попробую.
Попробовал: https://www.dropbox.com/s/y5cyrhgle98ddm0/v06x.zip?dl=0
Под виндой трудно ручаться за то, что не будет нужна какая-нибудь dll, но вроде должны быть в зависимостях только стандартные. Запуск
v06x --rom incurzion.rom. Выход - pause/break.
Правда это 64-битный exe. 32-битный собирать честно говоря будет многовато мороки. Могу показать, как собирать.
Могу показать, как собирать.
Научи, сенсей!
Работает, меня правда удивил размер exeшника. Это с чем связано?
svofski, присоединяюсь к ivagorу. OpenSource Вектор на плюсях - это круто: респекты, бесты и регарды! ИМХО, заслуживает как минимум отдельного топика в форуме.
Посмотрел чуть код: ядро от Alexander Demin, я его закачал несколько лет назад, но руки так и не дошли :). Забавноe названиe указатель that (sound.h).
Ещё всего один шаг с выносом SDL - dependent байды типа SDL_AddTimer в отдельный abstraction layer, и у нас будет portable сырок-заготовка для мультиплатформенного переноса под вообще что угодно.
ядро от Alexander Demin, я его закачал несколько лет назад
Кто ж его не качал :)
Немного экспериментировал с ним, но ничего серьезного
Аналогично, не дальше экспериментов. А тут - праздник у нас :).
Да я просто "this." заменил на "this->" в vector06js :) Нового кода тут вообще почти нет. Деминский I8080 удобен, правда я немного его допилил под Вектор, так что не получилось сделать внешний субмодуль с его оригинальной репой.
Размер exe-шника такой из-за SDL2 и boost-а, они статически слинкованы (зачем тут boost это другой вопрос, но потом он все равно пригодится). Кроме того 64-битные бинарники вообще жырны. Может быть можно потом будет попробовать настроить линкер, чтобы он как-то поскромнее линковал, хотя я не очень понимаю зачем. Чисто кода там котенок наплакал, на распе бинарник динамически слинкованный без дебаг инфы занимает 122К.
PPC, А зачем SDL вынимать, если SDL как раз и есть такая штука, которая перенесена уже вообще куда угодно?
М, было бы интересно наверное сделать его под libretro для интеграбельности с разными запускаторами, чтобы шейдеры общие со всеми и вообще.
Кстати, можно будет emscripten-ом обратно в js скомпилировать. А то че.
ivagor, я сейчас пытаюсь билд скрипт сделать универсальным. Как сделаю, напишу как собрать.
svofski, а на какой-нибудь stm32f7 discovery SDL порт есть? Я просто не в курсе.
PS. Порылся, есть вот такая либа http://api.ugfx.io/index.html
Ставится вот на чего: https://community.ugfx.io/index.php?/files/
В общем рецепт примерно такой:
1. Обрести полный MinGW вот этого разлива: https://nuwen.net/mingw.html (в нем в комплекте Boost, SDL2 и git, суперская вещь для вдыхания жизни в винду)
2. Обрести CMake: https://cmake.org/download/
3. Запустить окруженьице MinGW батником
C:\MinGW\open_distro_window.bat (альтернативно можно просто выставить все пути в стандартном окружении, если не лень)
4. Перейти туда, где живут всякие такие вещи, например
cd %HOME%\projects
5.
git clone https://github.com/svofski/vector06sdl (или скачать zip)
6.
cd vector06sdl
7.
mkdir build && cd build
(мы сейчас в %HOME%\projects\vector06sdl\build)
8.
cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ..
9.
make
По идее MinGW может быть и любой другой, но в любом другом придется не знаю каким образом строить самому libboost и SDL2 со всеми его зависимостями, чего под виндой я никому не пожелаю.
- - - Добавлено - - -
PPC, на такую шелезяку по-любому придется что-то мудрить. Вот соберется кто-нибудь портировать, там и будет видно. Можно будет хоть взять используемое (ничтожно маленькое) подмножество SDL и реализовать его поверх того же uGFX.
Спасибо! Ты все настолько разжевал, что для неудачи надо было постараться, а я поленился и просто откомпилировал exe (на полмега меньше, чем твой вариант выше, ну полмега туда, полмега сюда, подумаешь), romы запускаются.
- - - Добавлено - - -
на полмега меньше, чем твой вариант выше
Возможно из за того, что не подцепился sdl2_image
- - - Добавлено - - -
У меня скачанный исходник скомпилировался в exe дающий картинку на весь экран (16:9)
Заменил
SDL_RenderSetLogicalSize(this->renderer, 4, 3);
на
SDL_RenderSetLogicalSize(this->renderer, 1, 1);
и соотношение сторон стало как в твоем exe. Ты компилировал с 4,3 или 1,1?
Ты компилировал с 4,3 или 1,1?
С (4,3), но там по другому создавалось окно. Для этой части в tv.h надо еще будет найти волшебную формулу, которая работает на всех платформах. Вот изменения (https://github.com/svofski/vector06sdl/commit/4d890d6c198bef294f4af4edaf663a56603de56a#diff-fafd1dfe80ee70402ec3c9bafec372f9L28).
SDL2_image вчера еще не было. Я даже не поленился сделать его опциональным, потому что он корявый и почему-то никак не может являться частью самого SDL2 и поставить его морока. Он нужен только для тестов чтобы записывать экраны в png. Твой exe меньше может быть потому что ты собрал Release, а не RelWithDebInfo, как я скорее всего (сейчас не помню). В любом случае офигенно, что у тебя получилось независимо собрать.
- - - Добавлено - - -
P.S. на скорую руку запустил последний вариант, потому что вчера я легко мог не заметить пропорций, засыпая, но у меня все хорошо с соотношением сторон. На мониторе 16:9 картинка 4:3.
Поэкспериментировал с соотношением сторон.
Твой вчерашний вариант (5.5 Мб) корректно отталкивается от соотношения сторон монитора.
А последний вариант похоже берет за точку отсчета текущее разрешение рабочего стола, при котором его запустили. А у меня оно нестандартное 1440x1080. Сменил на 1920x1080 и последний вариант стал выдавать соотношение как заказано. Повторюсь - вчерашний работает одинаково независимо от разрешения, при котором его запустили. Но это практически никто не заметит, т.к. доля людей, не использующих большую часть экрана 'крайне мала'.
Понятно. Вчерашний вариант совсем не работал на макосе и еще не проверял на десктопном линуксе (изначально это для расбери-пи без иксов).
molodcov_alex
05.01.2018, 20:57
на десктопном линуксе
На десктопном вроде бы работает, правда пришлось поиграться с ключами objcopy в переменной BFDNAME. У мну вышло "-O elf64-x86-64 -B i386:x86-64" для CMAKE_SYSTEM_PROCESSOR == x86_64.
molodcov_alex, у меня не срослось с таким bfdname на Debian stretch. Линкер не ругается, но неправильно цепляются символы из объектника. На macOS еще дурнее, потому что там вообще нету стандартного objcopy. В результате для Darwin-а и десктопного Линукса объектник загрузчика генерится через xxd.
Обратил внимание на звук с хрипотцой. Оказалось, что сделать чего-то приличное кроссплатформенное так наивно вообще не получается: таймер и аудио драйвер могут иметь очень разное представление о своем периоде и, сколько я ни подкручивал, буфера разбегаются где-то быстрее, где-то медленнее. Зато я придумал посчитать размер аудио буфера для нужной частоты кадров и использовать аудио колбек вместо таймера. И вот это работает хорошо везде. Так и оставил. Если запущено с --nosound, должен работать таймер как раньше.
По поводу программирования палитры.
Посмотрел схему 06Ц. И понял, что доработка Tim0xи (http://zx-pk.ru/threads/8739-vektor-06ts-videovykhod-podklyuchenie-k-tv.html?p=162372&viewfull=1#post162372) влияет и на "зоны непрограммируемости" палитры. Т.е. palprog.xls, который я составлял, и по которому Ramiros делал эмуляцию этого эффекта, полностью справедлив только при реализации доработки синхры.
ivagor, посмотри плз, как у тебя текущая версия будет вести себя с пропорциями.
Новинки:
--window для запуска в оконном режиме. Alt+Enter как обычно должна переключать туда-сюда (грр на SDL, фу).
--fdd подключает образ дискеты (можно 4 штуки)
--autostart
Такое дело, до основного компа (с монитором 16:9) я доберусь только к среде. И среда для сборки там. Но как только доберусь - сразу попробую.
Записки на полях:
Raspberry Pi 3 умеет выдавать традиционную для компьютеров и консолей псевдо-прогрессивную развертку на своем композитном выходе. Режим включается добавлением 16 к параметру sdtv_mode в /boot/config.txt. Например, чтобы получить 50 Гц PAL 288p, нужно прописать
sdtv_mode=18.
Это почти работает, но распя продолжает считать, что у нее разрешение 720х576 и это выглядит нечитабельно. В консоли ее можно убедить в том, что строк 288 командой
fbset -yres 288 После чего картинка на мониторе становится пиксель к пикселю и по принципу формирования примерно соответствующей компьютерам 80-х.
У меня, увы, не получается убедить SDL в том, что разрешение экрана выставленное таким образом надо уважать. Он упорно продолжает сообщать, что экран 720х576. При этом реальное разрешение с которым он работает оказывается даже не 288 по вертикали, а 270. Если создавать текстуру 288 строк, как, казалось бы, предписано, получается совершенно непригодное масштабирование. Я не очень понимаю, как именно решить этот вопрос цивилизованным путем, пока просто захачено в бранче vsync.
Но зато полученная с этими хаками картинка на подключенном к распе ЭЛТ мониторе (хотелось бы попробовать еще ЭЛТ телевизор, но у меня нету) получается совершенно настоящая. Нету мельтешни, как и на реале, все идеально плавно, мост в Рива Рейде накатывает гладко. На LCD мониторе — увы. У меня есть один монитор, который имеет композитный вход и в принципе приемлемо цепляет 50 Гц сигнал, но он почему-то не в состоянии показывать его стабильно. То все плавно как на ЭЛТ, то вдруг начинается дерганье, то вообще как будто кадровую срывает.
Но как только доберусь - сразу попробую.
Попробовал. Собирается, окно работает, fdd и AY работают (немного skynet, до конца не дотерпел). Спасибо, круто!
- - - Добавлено - - -
Пропорции в полноэкранном режиме теперь не зависят от разрешения рабочего стола, что тоже здорово.
Редкий векторист дотерпит до середины Скайнета.
Обновил VV (http://sensi.org/~svo/virtualvector/)
Попробовал. Собирается, окно работает, fdd и AY работают (немного skynet, до конца не дотерпел). Спасибо, круто!
Присоединяюсь к благодарностям!
Подскажите, пожалуйста, эмулятор лучше собирать на самой "малинке", или стоит возиться с кросс-компиляцией?
x-code, удачно настроенный кросс-тулчейн наверное будет немного шустрее, чем сама малина, но затачивать его, если уже нету готового, морока по-моему не оправданная. На самой же малине все собирается предельно просто, никаких принципиальных отличий от десктопного линукса нет. Не уверен, что смогу перечислить требуемые зависимости. Их можно будет найти на ощупь. libboost1.62-dev, cmake, libsdl2-dev. libsdl2-image-dev нужен только для тестов, без него можно обойтись.
Может быть тонкость с SDL2. По-моему тот, что в репозиторях Raspbian, собран для wayland composer, для оконной системы. Как это работает, я просто не знаю, может быть хорошо. Свой SDL2 я собирал из сорцов примерно так (не ручаюсь за детали):
../configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl
Это получается консольный полноэкранный такой SDL2.
NB: последние фиксы, особенно для RPi3 подключенной к 50Гц монитору в sdtv_mode=18, в бранче vsync (vsync на не-50Гц мониторах пока не будет работать правильно). Если ivagor выгадает как-нибудь минутку и проверит его на своей конфигурации мониторов и скажет, что ок, я его смержу в мастер.
Попробовал, с vsync лучше, и даже если частоту кадров PC не менять на 50 Гц (оставить 60 или у кого сколько) - все равно лучше. По крайней мере скроллы не дергаются.
ivagor, минутку выгадал, vsync слился с мастером. Осталось сделать правильный vsync для не-50Гц мониторов и он станет опцией по умолчанию.
Посмотрел чуть код: ядро от Alexander Demin,
У него там ошибка была где-то в количестве тактов, я ему писал, но он так и не исправил.
Найду где именно - надо будет pull request сделать... У себя в эмуляторе я исправлял...
Чего Деминскому 8080 не хватает для универсальности, так это растактовки по циклам и прерываний. Растактовку немудрено доделать, собственно я два раза уже это делал в своих эмуляторах. А прерываний у него нету вообще как явления. Чтобы красиво сделать прерывания надо интерфейс менять. У меня просто захачено (https://github.com/svofski/vector06sdl/commit/32add18f6714f7d73d0849aa16b9f88cbc915c73) все вокруг этой темы. Основано на реальных событиях, но не очень-то красиво. Это тонкости архитектуры, о которых бедные эмуляторщики без ivagor-а даже не догадываются. Спасибо его тестам таймингов (http://sensi.org/scalar/ware/787/), особенно Ei, MovR и MovM.
Научил VV6.93 (https://cloud.mail.ru/public/DyDZ/zQn5sspLY) понимать 16 битные WAVы ))
svofski, только сейчас обратил внимание, что у тебя на сайте http://sensi.org/~svo/virtualvector/ последняя версия 6.92.
а ведь была уже 6.93.
ZEman, cпасибо за напоминание! Обновил.
Обновления в vector06sdl: https://github.com/svofski/vector06sdl/releases/tag/v0.1 (в зипе сборка для win64).
Основные новшества:
* рендеринг и эмулятор работают в разных потоках. Под Windows теперь окно таскается и уходит в фон без пропадания звука
* рациональная передискретизация полифазным фильтром звука с ВИ53 и бипера. Советую послушать эксперименты ivagorа с ШИМом на таймере и пищалке
* (опционально) рендеринг через OpenGL с поддержкой шейдеров. Можно писать свои.
* дебаггер в виде gdb-z80 (https://github.com/legumbre/gdb-z80) (exe в комплекте, target remote localhost:4000) Не самый красивый дебаггер, но мощный ;)
Огромное спасибо ivagor-у за тестирование и консультации в области ЦОС.
Обновил VV6.94 (https://cloud.mail.ru/public/9r7c/tnQqUbuSd) Исправлен баг с чтением регистров AY/YM, появился в версии 6.92 когда мы делали "аутентичное" чтение портов ВВ, но т.к. сравнивали с голым Вектором, естественно про порты AY забыли ))
- - - Добавлено - - -
svofski, Обнови VV у себя.
svofski, Обнови VV у себя.
Обновил.
Обычно из FARа (командной строкой), открываю rom-ы в эмуляторе "emu".
Вопрос, у эмулятора VV есть командная строка или опции для запуска?
Ещё заметил странное поведение эмулятора ve27. Если положить rom в его папку, то командной строкой он запускается. А если открывать rom (из сторонней папки), указав путь к ve27 (c:\ve27\ve27a.exe test.rom), то эмулятор зависает с чёрным экраном, выйти из него штатно не получается.
Вопрос, у эмулятора VV есть командная строка или опции для запуска?
в VV файлы запускаются с командной строки, можно запустить VV в режиме администратора и выполнить команду File->file associations->register, после чего можно будет ромы (и другие файлы кроме *.com) запускать как экзешники прям из Far или из проводника. можно просто перетаскивать ромы мышой на окно VV.
в VV файлы запускаются с командной строки, ... можно просто перетаскивать ромы мышой на окно VV.
Точно, если находишься в директории эмулятора, то можно из командной строки загрузить rom.
Правда если находишься в другой директории, то стандартная FAR-овская "C:\VV_694\VVector.exe !.!" не срабатывает...
Упс. Всё. Заработало. Добавил в FARе указание пути к rom-у "C:\VV_694\VVector.exe !\!.!"
Новый релиз v06x + сборка для винды (https://github.com/svofski/vector06sdl/releases/tag/chainik):
* добавлена возможность скриптования
Новые аргументы командной строки:
--script src1.chai --script src2.chai ... -- внутри просто все склеивается в одну большую строку
--scriptargs arg1 --scriptargs arg2 ... -- аргументы для скриптов, например имена файлов
Язык скриптов - https://chaiscript.com - отдаленно похож на ECMAScript и более-менее интуитивно понятен. Писать на нем нетрудно, вот шпора (https://github.com/ChaiScript/ChaiScript/blob/develop/cheatsheet.md).
В качестве примера сделал поддержку загрузки файлов rk и автоматический проигрыватель музонов из великой биперной музыкальной системы. Это обсуждается в параллельной теме тут (https://zx-pk.ru/threads/28132-bipernaya-muzyka-na-vektore-06ts.html?p=999466&viewfull=1#post999466).
Описание доступного API: https://github.com/svofski/vector06sdl/blob/master/README.md#available-api
- - - Добавлено - - -
Из темы про биперы:
Пока я не готов, думаю (пытаюсь думать) о другом.
Может быть, если ты в общих чертах обрисуешь как вообще ты себе все представляешь, я мог бы чего-то набросать. Без конкретного юзкейса я не знаю, что именно было бы удобно.
Может быть, если ты в общих чертах обрисуешь как вообще ты себе все представляешь, я мог бы чего-то набросать. Без конкретного юзкейса я не знаю, что именно было бы удобно.
Стартуем в командной строке батник с указанием бейсиковского файла (с расширением cas) для запуска.
В эмуляторе
1. Робот грузит бейсик 2.5. И лучше не стандартный, с заставкой, т.к. он долго стартует, а, например, из пзу 32Кб Tim0xи.
2. Робот набирает cload"" и жмет ВК
3. Перехват процедуры загрузки, адрес можно подсмотреть в соответствующих файлах emu или VV.
4. Дальше можно оставить пользователя с загруженным файлом или даже набрать run и запустить, но это наверно даже лишнее.
ivagor, у меня не нашлось избытка .cas файлов, зато .bas-ов в архиве Tim0xи полно. Мне показалось, что BAS неплохо тоже, сделал такое:
http://sensi.org/~svo/b/tas-basic.zip
Но оказалось, что не все басы правильно грузятся. Вложил один условно хороший, DIAMOND.BAS, и один условно плохой, FLOMAST.BAS. Может ты знаешь, в чем дело?
Кажется, разобрался. Бейсик определяет конец файла по трем нулям, а в некоторых файлах почему-то какие-то дописки в конце. Что делать с дописками я не понял, но bas файлы стали загружаться нормально. Обновил архив по ссылке.
- - - Добавлено - - -
Я раньше никак не мог разобраться, как без излишнего напряга загружать берестяные грамоты бейсиковские программы. А тут вдруг стало просто, и для меня открылся новый культурный слой. Особенно поражают воображение заставки минут на 5. Видно, что загрузка программы было делом торжественным.
Значительная часть BAS файлов дошли до нас с образов fdd, а там они добиты до кратности 128 байтам всяким мусором. Все, что после трех нулей в BAS файлах, как ты уже написал, можно игнорировать.
ivagor, я так и сделал. Будет время, можешь погонять. Пока еще нет поддержки BLOAD. Как сделаю, по аналогии с Музыкальной системой можно будет сделать сиквенсер загрузки мультипульти-программ типа BUSINESS.
Особенно поражают воображение заставки минут на 5.
Некоторые были красивые. Сама игрушка часто очень слабая, а вот заставка хорошая (и рисуется долго).
- - - Добавлено - - -
Попробовал запуск бейсиковских файлов в v06x - работает. svofski, здорово, что добавил эту фичу. Вспомнил (и посмотрел) заставку игрушки The House (house.bas), довольно красивая.
Где бы найти какую-нибудь подборку софта (игр) на бейсике для Вектора?
На vector06c.narod.ru были раньше 4 диска, сейчас же на скорую руку не нашел :(
Может быть, в картотеку их? Хотя бы прямо образами...
Pyk, вот все, что у меня есть: http://sensi.org/~svo/b/BASIC.zip
Теперь, когда я могу их запускать, есть шансы их забюрократить в картотеку. Но это работы непочатый край. А картотечный эмулятор пока загружать бейсик не умеет, это еще одна морока.
Заценил HOUSE.BAS. Очень красиво и даже игра почти играбельна, но заставка все затмевает собой. Могла бы занять почетное место на procedural graphics где-нибудь.
Еще ведь и музычку (пусть и коротенькую) в фоне пустили, у таймера для музыки есть плюсы перед бипером.
Вот если б не такие шедевры и не подумал бы бейсик в картотеку добавлять. А придется.
Вопрос на засыпку...
Есть ли в эмуляторах Вектора возможность взаимодействия со "сторонними" модулями/программами/библиотеками ?
Например: в конфиге эмулятора прописывается, что при работе с конкретным портом ввода-вывода (запись и/или чтение), нужно отправить байт или прочитать байт работая с неким приложением/модулем...
Это позволило-бы например (написав "внешнюю программу") "эмулировать" работу не стандартного внешнего оборудования (контроллера) для Вектора, без внесения изменения в сам эмулятор...
KTSerg, в v06x можно наскриптовать все, что угодно. Перехвата портов ввода-вывода нет, потому что я делал минимально то, что было нужно для загрузки .rk и .bas. Но для этого на самом деле все готово, просто надо сделать. Сам скриптовый язык достаточно мощный, чтобы на нем написать эмулятор Вектора ;)
Чтобы получить общее представление, можешь заглянуть в то, как сделана загрузка бейсиковских файлов, например. Для зацепки есть два колбека: frame и breakpoint. С кадром все понятно. breakpoint это та же точка останова из отладчика, только оператором отладчика становится скрипт. Все доступные вызовы расписаны в README (https://github.com/svofski/vector06sdl/blob/master/README.md).
Взаимодействие с внешними программами это чуть сложнее. Есть какой-нибудь конкретный пример, что бы ты хотел сделать?
Я всё "колдую" над контроллером ЛВС, который подключен к "ПУ".
Сейчас к нему подключена SD-карта. С неё при старте в Вектор грузится программка типа "эмулятор монитора". Далее используя тот-же протокол ЛВС, контроллер общается с Вектором. По сути Вектор используется как консоль, коды нажатых клавиш передаются в контроллер ЛВС, а с него в Вектор передаются команды вывода символов на экран.
В результате на экране Вектора получаем доступ с файлам SD-карты. После выбора файла, он грузится в Вектор.
Основная идея была грузить на КвазиДиск образ из файла EDD, и иметь возможность потом сбросить (измененный) образ КвазиДиска в файл на SD-карту.
Но это аппаратный контроллер, который периодически приходится модифицировать, что-то подпаивать/перепаивать.
А если-бы эмулятор Вектора имел возможность при работе с портами ввода-вывода работать с внешними ресурсами, то можно было-бы значительно упростить процесс отладки контроллера и софта.
Да и просто помечтав, например слепить виртуальный "контроллер Ethernet" посаженный на "ПУ" (или другие порты), грузить программы в эмулятор непосредственно из каталога http://www.sensi.org/scalar/categories/all/ ;)
Ну или с помощью внешней программы адаптировать к эмулятору не стандартный Джойстик, виртуально подключив его к портам "ПУ" как "стандартный" для Вектора.
Или реализовать программную эмуляцию других контроллеров, для возможности их использования в "Эмуляторе"...
Загрузить файл с диска сейчас уже можно. Фактически, чтобы сделать эмуляцию твоей железки, тебе не хватает возможности зацепиться за ввод-вывод в порты ПУ. Я правильно понял?
Загрузить файл с диска сейчас уже можно.
Это понятно, что в эмулятор можно файл загрузить. Но это частный случай, и применим только к эмулятору.
А при разработке реальной "железки", которая в перспективе должна работать с реальным Вектором, была-бы полезна возможность отладки в эмуляторе. И в таком случае просто загрузки файла уже маловато...
Да и "подключение" контроллера к эмулятору Вектора не ограничивается задачей загрузки файла.
Фактически, чтобы сделать эмуляцию твоей железки, тебе не хватает возможности зацепиться за ввод-вывод в порты ПУ. Я правильно понял?
Да работы эмулятора с внешним "ПУ" уже на многое хватит.
Правда на сколько я понимаю, есть много разных способов общения двух программ (в нашем случае эмулятора Вектора и эмулятора контроллера). А в этом я не спец :( Один раз, 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 в современных компах нет.
...
Сейчас перехват портов не сделан, но если это востребовано, я могу прикрутить.
Не сомневаюсь, что скрипт - это круть...
Но я пока не готов к такой крутизне. Делфа и Кейл пока привычнее.
А "проброс" портов из Эмулятора Вектора во "внешний мир", это пока только тема для размышлений.
Возможно когда появятся идеи для реального использования такой фишки, можно будет подумать и о реальной реализации... пока только как идея...
Не уверен, что я правильно все понял, но возможно KTSerg пишет про доступ к реальным интерфейсам ПК изнутри эмулятора. Правда физических LPT в современных компах нет.
Если это так, то с современным ПК это в первую очередь задача подключения к нему этой железки и написание драйверов. Только это ой и по-моему в случае с Вектором задачу усложняет экспоненциально.. Да и вообще не понятно, какую задачу это решает?
Я это понял немного иначе. Что прототип железки сначала делается в эмуляторе, на этой связке пишется софт и обкатываются возникающие проблемы. Потом проще делать реальную железку с уже наверняка работающим софтом. И отлаживать ее проще, сверяя с эмуляцией.
...
Я это понял немного иначе. Что прототип железки сначала делается в эмуляторе, на этой связке пишется софт и обкатываются возникающие проблемы. Потом проще делать реальную железку с уже наверняка работающим софтом. И отлаживать ее проще, сверяя с эмуляцией.
Да это буквально одно из применений.
Прямой задачи доступа к реальным ресурсам ПК, я конечно не ставил.
Второе применение это реализация программной эмуляции неких реальных или гипотетических контроллеров, для их использования с эмулятором при отсутствии реального Вектора, без внесения изменений (реализующих контроллер) в эмулятор Вектора.
Чтобы упростить решение проблемы курицы и яйца, дописал скриптование устройств ввода-вывода: Ссылка (https://github.com/svofski/vector06sdl/releases/tag/iohooks). Примитивный пример в scripts/iohook.chai (https://github.com/svofski/vector06sdl/blob/master/scripts/iohook.chai) реализует инвертер на порту 0x33.
Интересно, тестировали ли когда-нибудь переключение "на лету" режима 512/256 символов?
В демке dizrek_.rom во всех эмуляторах картинка заставки (на втором экране и дальше) иногда "подмаргивает" - неточная эмуляция или на реале так же?
Pyk, на моем реале не подмаргивает (или может быть только когда я моргаю ;) ) -- https://youtu.be/pZkqfxt4DYw (зря он что ли на подоконнике место занимает?)
На всякий случай оговорюсь, что это Вектор-06Ц с доработкой синхры и по-моему нету 100% консенсуса насчет влияния доработки на подобные эффекты.
Я бы не связывал возможные мигания в dizrek_ с переключением режима 256/512. Имхо там единственная возможная причина мигания - если в какой-то момент плеер выходит за отведенный интервал и синхронизация временно рушится.
Интересно, тестировали ли когда-нибудь переключение "на лету" режима 512/256 символов?
В демке dizrek_.rom во всех эмуляторах картинка заставки (на втором экране и дальше) иногда "подмаргивает" - неточная эмуляция или на реале так же?
На реале переключение режима 256/512 не должно приводить ни к каким "подмаргиваниям", так схема формирования изображения сделана, что переключение происходит "на ходу". Скорее всего должны быть демки в которых разные части экрана работают в разных режимах одновременно.
В эмуляторах если "подмаргивание" действительно связано переключением режима, то возможно это связано с переключением "разрешения" экранной области, хотя я в этом и не уверен, т.к. не имею представления как в эмуляторах происходит "вывод на экран".
Я бы не связывал возможные мигания в dizrek_ с переключением режима 256/512. Имхо там единственная возможная причина мигания - если в какой-то момент плеер выходит за отведенный интервал и синхронизация временно рушится.
Дело конечно же в синхронизации, но заметно на переключении режима. Это может быть момент начала прерывания, а может быть момент, когда именно появившийся в порту битик начинает оказывать влияние на схему генерации видеосигнала.
Вот как это проявляется у меня в эмуляторе. Сделал 512x256 инверсным, чтобы это было хорошо видно
https://www.youtube.com/watch?v=bv8njWtlvG0
- - - Добавлено - - -
KTSerg, все может мигать и на реале если переключать не синхронно, или не одинаково каждый кадр. В дизреке@ прямоугольная врезка из 256x256 в нижней части экрана. И плеер AY. Похоже, что на некоторых кадрах, плеер не успевает полностью отработать вовремя и что-то там залезает на прерывание, отчего все сбивается на тютельку. Надо сказать, что размер тютельки судя по тому, что я сейчас вижу, довольно крупный.
На реале смыргивание тоже происходит, не могу поверить, что это не так. Но вся зона смещена влево, поэтому этого эффекта просто не видно. У меня есть специальная задержка между out и реальной записью в порт, она нужна была для разных других бордюрно-палитровых прелестей. Если я делаю быструю установку режима 512, без этого буфера, то мырганье пропадает. Хмм..
Для пробы версия DIZREK_ без музыки, возможно она не будет сдвигоморгать. Кроме самого конца, когда ожидание прерывания сделано не очень хорошо.
В самом конце оригинала dizrek@, то есть на последней сцене, в моем эмуляторе сдвигомыргает даже с хакой.
В версии ivagor-а врезка стоит монолитом так прочно, что слышится Реквием Лигети и хочется подбросить вверх чего-нибудь.
на последней сцене, в моем эмуляторе сдвигомыргает даже с хакой.
Так и должно быть, я это упомянул. Там ожидание прерывания не по HLT.
Для надежности набросал тестик. В трех эмуляторах результат одинаковый (± 1 пиксель), отличается только в VV.
Неплохо бы проверить на реале.
Спасибо ivagor за использованные в качестве шаблона исходники предыдущих тестов, и svofski за pretty assembler :)
Для надежности набросал тестик. В трех эмуляторах результат одинаковый (± 1 пиксель), отличается только в VV.
Неплохо бы проверить на реале.
Спасибо ivagor за использованные в качестве шаблона исходники предыдущих тестов, и svofski за pretty assembler :)
Была бы полезна сплошная линия под цифрами, для точного определения переходов.
Цепляю фото с 02-го.
Была бы полезна сплошная линия под цифрами, для точного определения переходов.
В идеале да, но тут повезло, что момент окончания четко виден, а момент начала за 40 LoRes (или 80 HiRes) точек до этого.
KTSerg, есть возможность проверить и на 06Ц? Разница вряд ли будет, но вдруг.
- - - Добавлено - - -
На всякий случай хака со сплошной линией
...
KTSerg, есть возможность проверить и на 06Ц? Разница вряд ли будет, но вдруг.
...
Самое прикольное, что похоже смещение на 0.5 пикселя. Даже не на целый 1/512 а на 1/1024.68378
68379
Если учесть, что изображение 02-го смещено влево на 1/256, то получим, что у обычного Вектора переключение режимов отстаёт.
Это видимо можно попробовать объяснить схемой Вектора. У 02-го бит 4 порта ВВ55 прямиком подключен к логике переключающей режимы. А у простого Вектора, между ними есть D34 (шинный формирователь), он видимо и задерживает переключение.
Я так думаю...
Я у себя поправил VV_6.97 (https://cloud.mail.ru/public/Fyu9/3aRSL6QRU)
Ramiros, стало очень похоже, но если приглядеться, то в "6" надо бы еще чуть правее продлить.
Ramiros, стало очень похоже, но если приглядеться, то в "6" надо бы еще чуть правее продлить. Я это заметил, но там уже доли такта (видимо связаны с задержкой распространения сигнала в логике) которые я не могу учесть в нынешней реализации. Но ошибка на один такт была поправлена )).
А я бы так сделал
- - - Добавлено - - -
Это, конечно, дело вкуса. Для точной имитации очевидно надо раза в два повысить разрешение, что для такой ерунды вряд ли оправдано. Хотя 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-kvazidisk-dorabotka-barkarya.html
там даже тесты делали для проверки работоспособности этой доработки.
crackintosh
15.03.2019, 20:14
А кто-нить прикручивал 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 (http://sensi.org/scalar/ware/469/)
Монитор супер-монстр - это слегка доработанный стандартный монитор-отладчик, руководство которого здесь (http://sensi.org/scalar/ware/774/), про отличия здесь (http://sensi.org/scalar/ware/690/).
Насколько помню, vec это как rom, только расширение другое (предложил автор одного из древних эмуляторов).
Магнитофонный перехват нужен как минимум в бейсике 2.5, мониторе-отладчике и эмуляторе рк-микроши.
Попробовал игрушки z80, почти все работают, кроме knight lore, на мой взгляд проблема в опросе клавиатуры при маске BF.
И в целом звук AY как-то слегка заикается.
ivagor, а при каких обстоятельствах проявляется заикание звука на AY?
Проблема специфична для Z80, Вектора в целом или для определенных программ?
Пока слушал только вектор. Похоже проблема была в vsync, отключил его в настройках эмулятора и стало практически нормально. Хорошо было видно в рекламе диззи, особенно той, где бегущая строка. Звук заикался и строка тормозила. Рекламу диззи смотрел в конфиге вектора с ВМ80.
очень даже хорошо получается эмуляция вектора в emu80.
запускал различные игрушки - вылетов не обнаружил.
только вот звук как-то не то.
дема skynet сразу определяет что это эмулятор и звук там просто ужасен в некоторых сценах.
ZEman, skynet запускался в обычной конфигурации или с Z80? В варианте с Z80 я тоже слышу проблемы, но не изучал пока, причина в эмуляторе либо в самой деме.
Если проблемы со звуком были в обычном "Векторе", подскажи, на каких именно сценах - внимательно послушаю еще раз.
в обычной, без Z80.
смотрите например сцену с летящей кометой в том-же vv звук намного лучше и чище получается.
В процессе работы над эмулятором понял, что один аспект эмуляции экрана Вектора остался неисследованным - позиция отображения собственно графики.
Набросал еще один тест, во всех эмуляторах результаты разные, неплохо бы проверить на реале.
В эмуляторах результаты следующие:
v06x - 1-3
vv - f-1
ve27 - 2-4
emu - нет
emu80 - пока ерунда какая-то, буду смотреть ;)
...Набросал еще один тест, во всех эмуляторах результаты разные, неплохо бы проверить на реале.
...
На 02-ом
68478
Получается, что правильно пока только на древнем VE 2.7 Романа Пантелеева ;)
Сохранилась у кого-нибудь 2.8, кстати? А то я на днях оживил старенький ноут под DOS/Win98... :)
Вроде это последняя версия. Тут не полный комплект, только отличающиеся файлы.
Попробовал игрушки z80, почти все работают, кроме knight lore, на мой взгляд проблема в опросе клавиатуры при маске BF.
Сегодня добрался до этой игрушки. Действительно, проблема была при опросе клавиатуры, причем ошибка обнаружилась в заимствованном коде - реализации Z80 из проекта YAZE by Frank D. Cringle, конкретно ошибка была в инструкции INI.
Поправил, все текущие изменения на guthub, но тестовую сборку не делал. Надеюсь до конца месяца подготовить уже релиз.
Добрался до перехватов магнитофона в эмуляторе и понял, что мне не хватает опыта работы с Вектором и в частности с его бейсиком.
Как я понял из сообщений ivagor на форуме, общепринятое расширение для ленточных файлов бейсика 2.5 - cas, несмотря на то, что фактически это формат rk?
Я не нашел ни одного cas-файла для примера, все basic-программы, ссылку на которые недавно выкладывал svofski, имеют формат bas.
Насколько вообще распространены cas-файлы? Если их нет, зачем нужны перехваты в кассетном бейсике? Раз в других эмуляторах перехваты реализованы, эти файлы все-таки существовали?
Есть ли какие-то конвертеры из cas в bas и обратно (для Вектора или PC)? Можно ли как-то запустить дисковый бейсик после кассетного или наоборот, сохранив программу в памяти?
И еще вопрос: есть ли эмуляторный аналог формата, в котором читает с ленты загрузчик (кроме wav/csw)? Нужно ли его поддерживать, существуют ли файлы в этом формате? Есть ли какие-то утилиты для сохранения в нем?
bas2cas, cas2bas (https://zx-pk.ru/threads/9997-kak-zapisat-na-kassetu-basikovskie-programmy.html?p=182292&viewfull=1#post182292)
bas2cas2 (https://zx-pk.ru/threads/8634-vektor-06ts-emulyatsiya.html?p=233853&viewfull=1#post233853)
ivagor, спасибо, походил по ссылкам, многое прояснилось :)
Не смог скачать архив с утилитами saverom, saveasm, savebas, savemon отсюда:
https://code.google.com/archive/p/vector06cc/downloads?page=2
Получаю AccessDenied, на github же у svofski не нашел...
Upd:
Нашел здесь:
http://sensi.org/scalar/ware/693/
Pyk, Вот ссылка на мою коллекцию ленточных файлов: https://cloud.mail.ru/public/EF9n/YdKLaE3Db
Ramiros, спасибо за коллекцию!
Подскажи, пожалуйста, для какого бейсика, например, файл MySoft (BAS)\carts.cas ?
При попытке загрузки в Basic 2.5 выдает ошибку "Мало памяти".
перед загрузкой надо выполнить:
screen 2,7
himem 40959
т.е. расширить память за счет видео ОЗУ
Сделал новый релиз Emu80.
https://zx-pk.ru/threads/27488-emu80-v-4.html?p=1006126&viewfull=1#post1006126
Что сделано по части "Вектора" по сравнению с предыдущей сборкой:
- вроде бы точная эмуляция экрана, все тесты пока проходят ;)
- исправлена ошибка в эмуляции AY, звучание сейчас должно соответствовать оригиналу
- исправлены все длительности команд Z80, в том числе они должны быть правильными и на "Векторе"
- сделана загрузка файлов Бейсика (bas и cas) с помощью встроенного загрузчика (Файл->Загрузить и выполнить, Alt-F3), так же, как это уже сделано для ПК8000
- перехваты для Бейсика, Монитора и эмулятора РК/Микроши
- кнопка на тулбаре и горячая клавиша для загрузка RAM-диска
- поддержка мыши в отладчике
- сброс счетчика тактов процессора по точке останова в отладчике
- устранены вылеты
Развитие Emu80 радует, но в отладчике есть шероховатости.
1. Не смог поставить бряк по F9.
2. Хотелось бы, чтобы счетчик тактов перезапускался по F4/F7/F8 и по бряку (последнее я не пробовал из-за пункта 1).
ivagor, ну, я же писал, что мог что-нибудь сломать ;)
Сделаю чуть позже новую сборку, а пока можно поставить точку останова двойным щелчком слева от адреса.
Поясни, по каким событиям стоит перезапускать счетчик тактов.
Если сделать так, как ты предлагаешь:
F4 - Here,
F7 - Step,
F8 - Over
и по бряку,
то уже и не останется действий, по которым счетчик не будет перезапускаться ;)
По моим ощущениям, по шагам F7 и F8 перезапускать не нужно, по бряку - обязательно, насчет F4 - не уверен...
Голосую обязательно за бряк и F4, без F7 и F8 для данной задачи в принципе можно обойтись.
Багфикс-релиз 4.0.334 (https://zx-pk.ru/threads/27488-emu80-v-4.html?p=1006257&viewfull=1#post1006257)
Вернул работоспособность F9 в отладчике
F4 (Here) в отладчике сейчас сбрасывает счетчик тактов процессора
Еще не закончилось время года, когда внезапно можно оказаться в электричке, или в зоне плохого мобильного интернета без Бейсика 2.61. Чтобы не пришлось любоваться природой, или радоваться человеческому общению, я хоть и немного наспех, но подготовился к такой ситуации:
v06x для Андроида, в виде apk, очень сырой, дается as-is, пока без особых видов на улучшение:
http://sensi.org/~svo/b/v06x/v06x.apk
Предполагаемый способ применения:
https://i.imgur.com/0ovNQuo.png (https://imgur.com/a/FfvykuE)
https://i.imgur.com/3mqvW3J.png
В комплекте value added software: Бейсик 2.61 от ivagor-а, который поддерживает восьмеричную нотацию констант.
crackintosh
15.08.2019, 10:29
надо убрать "проверку на сертификацию".
KTSerg, эта версия не будет работать на Андроиде младше 5.0.
KTSerg, эта версия не будет работать на Андроиде младше 5.0.
А исходники этой версии где-то доступны?
Сюда (https://github.com/svofski/vector06sdl), конечно же, смотрел, но ветки для Андроид не нашёл...
У меня планшет с Андроидом 4.3; эмулятор Спектрума Spectacol там вполне работоспособен, ощущения от игры в R-Type с джойстиком прям как в старые добрые времена :)
Вот и подумалось - а чем "Вектор" хуже? Если сам движок эмуляции не требует чего-то специфического, доступного только в пятом "андрюше", то, может быть, есть вариант запилить полноценную Android версию? Производительности PowerVR SGX 544MP и Intel® Atom™ Z2560 Dual-Core, 1.6 GHz должно бы хватить.
Как вариант, можно подумать о том, чтобы переложить часть работы по формированию картинки на GPU - например, каждая экранная плоскость копируется в текстуру, а пиксельный шейдер уже формирует итоговые цвета пикселей, получая на вход палитру цветов как один из параметров.
x-code, есть сорцы, просто они чуток разъехались с десктопной версией и, как я сказал, пока не нахожу сил их свести обратно в одно. Для этого требуется определенный peace of mind. Формирование картинки не такое уж требовательное, arm хорошо жонглирует битами. У меня наибольший тормоз это аудиофильтр, но он с неоном тоже справляется.
В общем спасибо за напоминание, я постараюсь может быть сорцы выложить отдельной веткой. Ну разъехались немного и пусть.
Мощный релиз, мощь которого в основном в том, что ничего не должно было измениться.
кроме фикса баги (https://github.com/svofski/vector06sdl/issues/5), которую нашел ivagor
тотальный морж андроидной версии, теперь все версии собираются из одних сорцов
скрипты для запуска бейсика итд упакованы вместе с дистрибутивами и даже есть батнички и скриптики
бонус - бинарные сборки для всех поддерживаемых платформ
v06x version 3-theydo (https://github.com/svofski/vector06sdl/releases/tag/3theydo)
Мощный релиз, ...
v06x version 3-theydo (https://github.com/svofski/vector06sdl/releases/tag/3theydo)
Я что-то не совсем понял минимальные требования к системам.
Винда только 10 ?
А какой минимальный Андрюха ?
Винда только 10 ?
В семерке работает.
Я что-то не совсем понял минимальные требования к системам.
Винда только 10 ?
А какой минимальный Андрюха ?
Я не знаю, какая минимальная винда, но это 32-битная сборка с минимумом зависимостей. Я думаю, она даже на XP может запуститься (моя виртуальная XP застряла в activation loop-е, а только ради такой проверки устраивать битву с ней не хочется).
Минимальный Android 5.0, ничего не изменилось (надеюсь).
Нашел Windows XP, запускается. Надо бы переименовать дистрибутив в win32, я машинально его назвал win64.
После обсуждения в операционных системах сделал тестик (исходник прилагается) ВВ55 перед и после рестарта. По схеме вижу, что ВВ55 не ресетится, но у авторов эмуляторов мнения разделились. Переход по "стадиям" по нажатию БЛК+СБР или F12 в эмуляторах. Полная стадия - 8 строк цифр и Pass complete. Потом можно еще рестартовать и пойдет по новой.
В эмуляторе emu есть возможность вызвать режим "Debug" с помощью горячей клавиши, или опцией (из командной строки) сразу перейти в режим отладки без запуска загруженной программы?
Ваял программку, накосячил по мелочи, но не мог понять где, после запуска программы, через 1-2 сек, программа глючила с уничтожением своего кода.
При запуске в эмуляторе не успевал выбрать в меню режим отладки, что-бы посмотреть, что там творится... :(
Improver
05.08.2020, 09:09
В эмуляторе emu есть возможность вызвать режим "Debug" с помощью горячей клавиши, или опцией (из командной строки) сразу перейти в режим отладки без запуска загруженной программы?Есть, по нажатию клавиши "Pause/Break" сразу переходит в режим отладки. Либо ещё можно поставить брекпоинт на какой-нибудь адрес программы...
Есть, по нажатию клавиши "Pause/Break" сразу переходит в режим отладки. Либо ещё можно поставить брекпоинт на какой-нибудь адрес программы...
Поставить брекпоинт, ДО начала работы программы?
Можно ли поставить брекпоинт в командной строке (или настройках), чтобы программа запустилась уже с настроенным брекпоином?
опцией (из командной строки) сразу перейти в режим отладки без запуска загруженной программы?
Из командной строки - опция /d
по нажатию клавиши "Pause/Break" сразу переходит в режим отладки
Если отладчик не был запущен, то будет пауза, но в этот момент тоже можно вызвать отладчик.
Поставить брекпоинт, ДО начала работы программы?
Тоже можно - опция /brk XXXX (16-ричный адрес)
Вот несколько примеров:
emu.exe /d
emu.exe /c "Orion-128" /d
emu.exe /c "Orion-128" /brk F842
emu.exe /c "Orion-128" /brk @my.brk
1. Вызов отладчика, без выбора конфигурации
2. Более полезный вариант, с автоматическим выбором конфигурации
3. Ещё более удобный вариант, с указанием точки останова
4. Вариант с сохранением точек останова в файле
crackintosh
10.11.2020, 08:18
Подскажите, как в VV (7.02) загрузить файл с кассеты в реальном времени с реального магнитофона?
Нужно оцифровать несколько кассет.
Скажите, насколько точна работа Вектора в MiSTer?
https://github.com/MiSTer-devel/Vector-06C_MiSTer
То есть даже вопрос скорее - а если проверить игрушку под Мистером, можно ли считать что и под настоящим Вектором она тоже будет точно так же работать?
Желательно поправить в VV такты для семейства команд jr в конфиге z80. Когда переход есть, то они должны занимать на векторе 16 тактов (не 12), т.к. там по циклам (из даташита): 4+3+5, т.е. на векторе будет 4+4+8=16.
DJNZ не проверял, но на всякий случай обращу внимание. При наличии перехода (B<>0): 5+3+5, на векторе - 8+4+8=20 тактов. Без перехода (B=0): 5+3, на векторе - 8+4=12 тактов.
Еще в отладчике VV, по крайней мере в конфиге z80, после изменения значения PC жму Next и выполнение программы продолжается не с нового адреса, а как будто изменения PC не было.
Написал и задумался - третий цикл в jr и djnz без обращения к памяти, там торможения не будет. И точно, растактовки amstrad cpc (https://wiki.octoate.de/lib/exe/fetch.php/amstradcpc:z80_cpc_timings_cheat_sheet.20131019.pd f) говорят, что:
1. jr - 12 тактов; условный jr при невыполнении условия - 8 тактов.
2. djnz b<>0 - 16 тактов; djnz b=0 - 12 тактов.
Получается в VV jr правильный (djnz так и не проверил), а вот emu80 надо поправить.
- - - Добавлено - - -
Допроверил djnz, в итоге вот что получилось.
1. VV
1.1. Надо поправить djnz при b=0 (когда нет перехода), должно быть 12 тактов вместо 8.
1.2. У меня остался вопрос по отладчику, почему изменение PC не влияет на следующий адрес выборки команды.
2. Emu80
2.1. jr и условные jr при наличии перехода должны быть по 12 тактов вместо 16.
2.2. djnz при b<>0 (когда есть переход) должно быть 16 тактов вместо 20.
Допроверил djnz, в итоге вот что получилось.
1. VV
1.1. Надо поправить djnz при b=0 (когда нет перехода), должно быть 12 тактов вместо 8.
1.2. У меня остался вопрос по отладчику, почему изменение PC не влияет на следующий адрес выборки команды.
Исправил. VV_7.03 (https://cloud.mail.ru/public/qLUs/XBkFS7snE)
Ramiros, так VV всё ещё развивается?
Вообще это отличный эмулятор.
Но мне лично очень нехватает возможности передать ROM-файл для загрузки через командную строку. В других эмуляторах Вектора эта возможность уже есть.
Ramiros, спасибо за исправления, возник еще вопрос по отладчику. Иногда перестает реагировать на кнопку Next в отладчике, жму и ничего не происходит.
Ramiros, Но мне лично очень нехватает возможности передать ROM-файл для загрузки через командную строку.
Есть возможность зарегистрировать типы файлов, тогда все ромы запускаются просто как exe-шники (File->Fileassociations->Register). Такой вариант запуска не пойдет?
Есть возможность зарегистрировать типы файлов, тогда все ромы запускаются просто как exe-шники (File->Fileassociations->Register). Такой вариант запуска не пойдет?
Нет, для меня типично - итерация кодирования, скомпилил командным файлом, и запустил командный файл запускающий эмулятор.
Нет, для меня типично - итерация кодирования, скомпилил командным файлом, и запустил командный файл запускающий эмулятор.
Тогда тебе скорее v06x подойдет. С ним даже можно сделать автоматизированный тестовый стенд.
Ramiros, так VV всё ещё развивается?
Вообще это отличный эмулятор.
Но мне лично очень нехватает возможности передать ROM-файл для загрузки через командную строку. В других эмуляторах Вектора эта возможность уже есть.
Так оно же и в VV работает! И всегда (по крайней мере давно) работало...
2. Emu80
2.1. jr и условные jr при наличии перехода должны быть по 12 тактов вместо 16.
2.2. djnz при b<>0 (когда есть переход) должно быть 16 тактов вместо 20.
Пробежался по всем командам и нашел кроме этого и еще несколько команд Z80 с неправильным временем исполнения на Векторе (и одну - на всех ПК).
Исправил, но изменения пока только в репозитории. Не помню, были ли для Вектора какие-то тесты, зависящие от таймингов Z80 (например, с привязкой к растру)?
были ли для Вектора какие-то тесты, зависящие от таймингов Z80 (например, с привязкой к растру)?
К сожалению таких не знаю.
Игрушка ROBBO-AT (http://www.sensi.org/scalar/ware/916/) подсветила баг в VV (пробовал 7.02 и 7.03). Если SP=0001, то PUSH не меняет байт по адресу 0000. Точно касается кваза, основную память не проверял.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot