Да и мой будет циклиться. На входе же вечный 0, сигнала нет.
Вид для печати
Да и мой будет циклиться. На входе же вечный 0, сигнала нет.
А у меня эмулятор EMU от b2m нормально читает оба типа RKS-файлов и по директиве I и по директиве R. Естественно также нормально читает и WAV-формат. Вот только не пишет в WAV-формате.
Может быть дело в версии EMU, у меня вообще старая версия 1.01 из 2011 года. Привожу скриншот экрана с эмулятором B2M с указанным конфигом и на дампе видно, что монитор непатченный. И как видите и введённая программа работает.
А нельзя ли сделать версию эмулятора, чтобы звуки выводил на PC Speaker, а магнитофонный ввод/вывод делал через LPT-порт ?
barsik, А не мог бы высокоуважаемый (джин) :v2_dizzy_indy: опубликовать схему турбо для Специалиста?
на 2.5 мгц которая, на одной ТМ2
Нет, там вроде не надо было так извращаться. Посмотрел конфиги, нашел такое как минимум в ПК8000. Может ещё где-то было.Цитата:
Сообщение от Pyk
- - - Добавлено - - -
Я, конечно, не настаиваю, но пользоваться настолько старой версией не рекомендую. Как минимум из тех соображений, что у большинства пользователей (вероятно) гораздо более поздние версии и сравнивать работу эмулятора было бы не корректно. Возможно в той версии и был косяк с записью в wav, но я что-то не припомню.Цитата:
Сообщение от barsik
Под Windows это вряд ли возможно. А вообще 2-я DOS-версия эмулятора может выводить звук на PC Speaker.Цитата:
Сообщение от barsik
Конечно, возможности этой версии сильно ограничены, но исходники доступны на GitHub, и при желании несложно реализовать обмен с магнитофоном через LPT.
Очередная версия 4.0.277 от 30.12.2017:
Windows-сборка:
http://emu80.org/v4beta/Emu80_40277.zip
Исходники:
https://github.com/vpyk/emu80v4
Изменения в версии 4.0.277:
Легенда:
+ Нововведение
* Изменение / улучшение
- Исправлен баг
! Известная проблема
+ Конфигурация для ПК "Лик"
+ Загрузка rks-файлов в формате с именем по Alt-F3 и Alt-L
+ Новая команда U в отдадчике: пропуск текущей команды без выполнения
+ Параметр громкости "emulation.volume" добавлен в конфигурационный файл
+ Два новых параметра "cpu.debugOnHalt = yes" no и "cpu.debugOnIllegalCmd = yes" для выхода в отладчик по команде HALT
и по недопустимому коду команды (для i8080) соотвтетственно (можно добавить при необходимости в конец conf-файла)
* Модифицирован Монитор РК-86 для запуска РК-ДОС по директиве U
* Вместо клавиши Alt в комбинациях клавиш может быть использована клавиша Win (Meta). Может быть полезно в Linux.
* В знакогенераторе РК знак "$" заменен на знак денежной единицы "¤"
* Изменено поведение эмулятора при отказе от выбора файла при обмене с магнитофоном: временная отмена перехвата
+ Ограниченная поддержка записи wav-файлов
+ Чтение либо запись wav при выборе его вместо rk
+ Новый параметр конфигурации "Ускоерние при воспроизведении WAV", позволяющий задать коэффициент ускорения работы
эмулятора при загрузке wav-файлов. В глобальном ini-файле ему соответствует параметр "wavReader.speedUpFactor".
- Исправлена ошибка, возникавшая при выходе из эмулятора с установленными точками останова
- Исправлена работа управляющих клавиш УС, СС и РУС на Микро-80 и ЮТ-88
- Исправлена запись rks-файлов на Специалисте
- Исправлена загрузка некоторых wav-файлов, выдававших ошибку при открытии
- Пропатченый Монитор Специалиста заменен на оригинальный
- Внутренние изменения
Небольшое пояснение по работе с wav-файлами: загрузить wav-файл можно либо, как раньше, через Alt-W, либо выбрав wav-файл в
ответ на запрос имени файла, выдаваемый по директивве ввода с магнитофона. Аналогично, при запросе имени файла, запрашиваемого
по директиве вывода на магнитофон, можно задать имя файла с расширением wav: в таком случае вместо rk* будет записан wav-файл. В
wav-файл попадает только сигнал вывода на магнитофон, другие звуки не записываются.
- - - Добавлено - - -
zx_, для включения периодических прерываний в "Специалисте" добавьте в конец конфигурационного файла следующие строки:
Здесь 7 - это номер вектора прерывания (rst 7), а 50 - частота прерыванийКод:PeriodicInt8080 periodicInt = &cpu, 7, 50
periodicInt.active = yes
Естественно сразу поставил своё ПЗУ. С орловским ПЗУ вообще ничего невозможно вводить в WAV, т.к при WAV ввод долгий и нет никакой индикации, - неясно идёт ввод или завис. Использовал своё ПЗУ с байтом C9 по адресу CEDF.
Есть улучшения по реакции на СБРОС, хотя логика страдает. Эмулятор сам должен понимать, что когда я выбрал файл с расширением WAV, то и вводить надо звуки, а когда с расширением RKS, то готовые коды.
А при вводе по директиве I стало чуть ли не хуже. Обьясните как вводить по I WAV-звуками.
Вот смотрите. Если я нажимаю I, затем <ВК> и на запрос "Имя файла:" снова нажимаю <ВК>, то открывается окно, где я могу выбрать только файл RKS. Если же я на запрос имени файла перед нажатием <ВК> нажму АЛЬТ-W и выберу WAV-файл, то это снова не поможет. Т.к во-первых, я могу просто не успеть нажать на <ВК>, а во-вторых, это не срабатывает, - по нажатию <ВК> второй раз открывается окно на запрос имени файла и не ясно ждёт он RKS или WAV. Надо чтобы после АЛЬТ-W уже никакие окна не открывались и нужна индикация о том, что идёт ввод с WAV-файла (например, хотя-бы значок магнитофона из 2-х кружков на балке, а лучше индикатор "градусник" показываюший ход процесса).
В общем, помыкался по разному, но WAV-файл предназначенный для ввода по I так ввести и не смог. А у меня все МГ-записи в нормальном формате, т.е в формате с именем. В формате без имени файлы никто не хранил на кассетах, т.к это очень неудобно.
И по-прежнему остаются WAV-файлы на которые эмулятор пишет, что у них неправильный формат.
Многоблочные программы уже можно вводить, как в формате RKS (естественно без имени, т.к только формат без имени грузится по сбросу), так и в формате WAV. Вскоре сделаю многоблочную программу RKS, хотя необходимость всё делать через LDBYTE и блоки только с синхробайтом E6, сильно ограничивает.
Проблема в том, что в хитрых подпрограммах ввода во время ввода байта процессор делает полезную работу. Например, имитирует ввод в экран как на Синклере. А в эмуляторе это невозможно, т.к реальной процедуры ввода нет. Потому, что-то делать во время МГ-ввода в эмуляторе процессор может только в паузе между блоками, а не во время самого ввода. Что-то существенное во время пауз не сделать и это тормозит. Потому формат в кодах для многоблочных программ для эмулятора бесполезен. Т.е многоблочные программы могут быть только WAV, что резко снижает ценность, т.к WAV слишком большие по объёму, чтобы их хранить.
Заметил, что создаётся копия Emu80, занимающая ~4 мб памяти, если происходит неудачный старт эмулятора. Например, если удалить каталог какого-либо компьютера, а затем запустить его. Тогда что-то грузит, но не стартует, а в диспетчере процессов остаётся процесс Emu80. Т.е в случае неудачи старта Emu80 себя не удаляет из памяти. Это часто происходит, когда редактируешь конфиги или когда все каталоги ненужных компов поудалять из папки EMU80.
Причём если этот недо-удалённый процесс Emu80 "убить" в диспетчере процессов при второй работающей копии Emu80, то происходит сброс компьютера. Если удалить, когда другая копия Emu80 не работает, то сброса не будет. Наличие недо-убитых копий в памяти вдвое тормозит реакцию на клавиши. На Специалисте это ещё не заметно (точнее надо 2-3 недоубитых Emu80, чтобы так же тормознуть), а вот при РК86 просто пропадают нажатия на клавиши уже при одном недоубитом процессе.
Мне это не особо важно, но для адаптаторов ZX-игр это знать надо.Цитата:
Сообщение от Pyk
По какому сигналу (фронту) срабатывают прерывания: по КСИ, по началу кадрового гашения или "от балды"? В моём эмуляторе для MSDOS это было сделано "от балды", т.е момент прихода импульса запроса прерывания определялся не по реальному времени, а по прогону определённого числа команд (7800 команд). Время прогона 7800 команд при среднем числе тактов в командах это примерно 20 МСЕК, что и даёт 50 ГЦ,
Понятно, что если это 7800 команд NOP (4 такта), то это короткий период между прерываниями, а если это (гипотетически) 7800 команд EX (SP),HL (19 тактов) или тем более LDIR, то период между запросами прерываний будет в тысячи раз больше. Но т.к программы из 7800 команд LDIR стоящих подряд не встречаются, то и проблем не было. Игры с прерываниями прекрасно работали.
- - - Добавлено - - -
И по-прежнему нельзя изменять флаги процессора. Это свойство любого отладчика. Директива X должна сразу переходить на редакцию флагов. Жалко, что шагание только по F7, я привык к T (так во всех отладчиках в мире, зачем нарушать традицию?).
Специально для фанатов мнемоники КР580 (временно, потом удалю) выкладываю отладчик DDT для CP/M работающий с Z80, но в мнемонике INTEL. Это та же мнемоника что выдаёт DISASM, если указать, что есть Z80 команды (и ассемблеры такие есть). По директиве L посмотрите какой-нибудь код для Z80 и увидите какие уродские мнемоники получаются для Z80, если использовать мнемоники Intel.
Если у Вас Win XP, то можно запускать прямо из Win XP под TSR эмулятором 22NICE. Если же Ваша Windows неспособна к программам MSDOS, то придётся пользоваться DOSBOX. Кстати, 22NICE и другие TSR эмуляторы CP/M не всегда помогают. Например, компилятор PLMX приходится использовать только в эмуляторе ОРИОНА, т.к под TSR-эмулятором MSDOS он не работает. Это происходит с программами, которые лезут в Allocation Table CP/M или напрямую работают с байтами FCB.
barsik, спасибо за оперативный отзыв.
Во-первых, должен сказать, что я все тестировал с орловским Монитором. Увы, с петербургским, в том числе и патченым, не все работает, и я пока, честно говоря, толком не разбирался почему. Будет время - посмотрю.
Для этого я и сделал ускорение при загрузке wav. К сожалению, на медленных компьютерах ускорение может упереться в быстродействие процессора. А индикация пока в планах.Цитата:
Сообщение от barsik
RKS по умолчанию. Нужно из выпадающего списка фильтров выбрать "Wav Files (*.wav)" или "Все файлы" и выбрать wav.Цитата:
Сообщение от barsik
Логично, поправлю.Цитата:
Сообщение от barsik
Все возможно, хотелось бы образец.Цитата:
Сообщение от barsik
Где-то в одной из соседних тем уже начинали обсуждение возможности использования формата, альтернативного wav - в формате 1 бит на сэмпл и со сжатием. Можно развить эту тему либо использовать один из вариантов спектрумовского формата tap.Цитата:
Сообщение от barsik
Исправлял уже такое поведение, но видимо что-то опять сломалось в одной из версий. Разберусь.Цитата:
Сообщение от barsik
- - - Добавлено - - -
Именно так оно сейчас и работает - анализируется именно расширение (wav или WAV), хотя логичнее было бы смотреть заголовок файла. Почему возник такой вопрос?Цитата:
Сообщение от barsik
С орловским монитором новая версия EMU80 читает и пишет и по I/O, и по R/W, причем как в кодах (т.е в формате RKS), так и в звуках (т.е в формате WAV). С ленинградским монитором 2.7 и 3.3 (в обоих заглушены кодом C9 входы CEDF) читает и пишет только в кодах (т.е в формате RKS). Со звуками работать отказывается. Эмулятор EMU от b2m с тем же, причем оригинальным монитором читал в формате WAV.
Вообще-то это странно, потому что этот монитор делался так, чтобы совместить все входные точки, что было очень непросто, т.к они раскиданы по всему загрузчику, а не сгруппированы в начале кода. С большим трудом удалось совместить все точки и даже недокумментированные. Совмещать выходные точки из подпрограмм, естественно было незачем.
Почему же если точки выхода из подпрограмм не важны, не работает чтение/запись WAV-файла. При этом же вообще не используется никаких точек перехвата. Как тогда программа может влиять на результат. Насколько я понимаю, при этом контролируется сам разряд PB0 ППА, а код программы делающей доступ туда не важен. А может быть Вы контроллируете не тот порт, например F800, а не FF00 ? Также на мысль о "химии" при вводе WAV наводит невозможность загрузить файлы в MSX-кодировке внешним драйвером. Это вопрос ещё нуждается в прояснении. Могу попробовать читать/писать и в кодировке ZX-Spectrum, т.к она тоже есть в мониторе. Но пока это бесполезно, если даже обычная двухфазная кодировка не вводится.
Строки
cpu.debugOnHalt = yes
cpu.debugOnIllegalCmd = yes
надо помещать не в файл EMU80.CONF, а в в конец конфиг файла конкретного компьютера.
Подскажите каким редактором можно отредактировать руские тексты в Ваших конфигах. Обычно конфиг-файлы это чисто текстовые файлы в кодировке MSDOS или Windows, чтобы можно было редактировать самым простым редактором. Обидно, что используется неизвестная кодировка для русских букв. Из-за это не смог изменить титр, т.е заголовок эмулятора при работе. Какая-то левая китайская кодировка и непонятно каким редактором это можно редактировать.
Слышал, что уже изобретён однобитовый формат для МГ-записей 8-ми разрядок. Называется BAV и используется в одной конструкции самодельного цифрового магнитофона. Вроде бы это формат отличается от WAV только тем, что число разрядов не 8, а 1, отчего в несколько раз сокращается объём файла.Цитата:
Сообщение от Pyk
Для записи двухфазной кодировки годится частота дисретизации не ниже 22 КГЦ. Ведь при двухфазной кодировке скорость передачи 1200 бит/сек. Бит кодируется перепадом 0>1 или 1>0. Потому частота с которой следуют фронты равна 2400 ГЦ. Это значит, что между фронтами происходит 9 отсчётов и колебания фронтов равны +-11%. При этом размер файла будет в 18 раз больше объёма кода.
Впрочем для СПЕЦИАЛИСТА это не очень актуально, т.к почти все старые программы есть в виде кодов. И вводить программы с заставками как в Синклере интересно только из спортивного интереса (сделать так, чтобы никто не сумел кракнуть) или с целью распространения новых программ в некопируемом виде.
Помню, сделаю, не все сразу. А пока, если очень нужно, можно изменить редактированием половинки "регистра" AF.Цитата:
Сообщение от barsik
Зачем же так категорично? Может быть, так в большинстве отладчиков командной строки, но в визуальных отладчиках все-таки чаще что-то из серии F7, F8, F10, F11... Хотя мне не сложно продублировать команду на клавишу "T". Есть еще пожелания, какие буквы назначить в дополнение к F4, F8, F9?Цитата:
Сообщение от barsik
Что касается меня, то я предпочитаю родные мнемоники для каждого процессора: Intel - для 8080 и Zylog - для Z80, так что такое мне тоже не очень нравится. Но не навязываю никому свое мнение - дело вкуса и привычки.Цитата:
Сообщение от barsik
Да, знаю, есть проблема. Причину пока не знаю. Никакой "химии" там вроде бы нет, возможно просто баг. Разобраться пока не пытался, если поможете найти, буду благодарен.Цитата:
Сообщение от barsik
Обычная кодировка UTF-8. Открыть можно очень много чем, да хотя бы блокнотом, только в диалоге открытия файла выбрать из выпадающего списка эту кодировку. Есть и более продвинутые редакторы вроде Notepad++, а сам я предпочитаю консольный нортоноподобный файловый менеджер Far и его встроенный редактор.Цитата:
Сообщение от barsik
Ну а сейчас уже пора бы о встрече нового года подумать :) Всех с наступающим!
- - - Добавлено - - -
Похоже, что блокнот - не самый удачный вариант. При сохранении он добавляет байты BOM в начало файла (EF BB BF), из-за чего его перестает понимать эмулятор. Можно, конечно, потом эти три байта убрать, но проще взять более адекватный редактор.Цитата:
Сообщение от Pyk
- - - Добавлено - - -
Да, кстати, может быть поддержку CSW добавить?Цитата:
Сообщение от Pyk
Pyk, попробовал собрать под macos, лог во вложении. Я пока довольно неопытный под маком, до конца не дошёл, сорри.
Сначала не нашло SDL, но он есть собранный, скачать и один файл перетащить.
А вот wxWidgets похоже нужно собирать из исходников, это я пока отложу.
Посмотрите лог -- собрались файлы зависимые только от SDL, может варнинги будут вам полезны, их там много.
Особенно подозрительно выглядят выражения вида ((symbol && 0xC0) != 0xC0) -- по-моему, тут просто ошибка, должно быть побитовое & вместо логического &&.
nzeemin,
Но запустить я все равно не смог, выкидывает адский эксепшн при старте:Код:brew install wxmac --devel
Скрытый текст
Код:2018-01-10 03:31:45.148 Emu80[55913:802511] -[SDLApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x7fdead704090
2018-01-10 03:31:45.149 Emu80[55913:802511] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[SDLApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x7fdead704090'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff31f0a53b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fff58919942 objc_exception_throw + 48
2 CoreFoundation 0x00007fff31fa1824 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132
3 CoreFoundation 0x00007fff31e81f13 ___forwarding___ + 1443
4 CoreFoundation 0x00007fff31e818e8 _CF_forwarding_prep_0 + 120
5 libwx_osx_cocoau_core-3.1.dylib 0x00000001075a906c _ZN5wxApp9DoInitGuiEv + 262
6 libwx_osx_cocoau_core-3.1.dylib 0x00000001075e71e4 _ZN5wxApp10InitializeERiPPw + 184
7 libwx_baseu-3.1.dylib 0x0000000107b19717 _Z12wxEntryStartRiPPw + 233
8 libwx_baseu-3.1.dylib 0x0000000107b19ca9 _Z12wxEntryStartRiPPc + 30
9 Emu80 0x000000010710831f _Z9palWxInitiPPc + 31
10 Emu80 0x00000001070c4ce1 _Z7palInitiPPc + 49
11 Emu80 0x00000001070bd232 main + 34
12 libdyld.dylib 0x00007fff59506145 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6
[свернуть]
Пока не разобрался в чем дело.
nzeemin, спасибо, предупреждения насчет битовых операций - действительно ошибки (возможно, как раз с этим связаны известные проблемы с эмуляцией ВГ75), остальное подробнее посмотрю вечером. Не совсем понял только, почему у меня эти предупреждения с этим же Makefile не выдаются, может дело в ключах sdl2 либо в версии gcc, либо просто в особенности его поведения на macos? Можно узнать версию gcc и что выдает sdl2-config --cflags?
nzeemin, svofski, можно попробовать собрать только lite-версию, не требующую wx. Потребуется наверное только немного подредактировать Makefile, чтобы не пытался собирать зависимые от wx файлы (хотел сделать CMakeLists.txt для cmake для упрощения сборки, но руки пока не дошли).
Вообще, не очень мне нравится одновременное использование SDL и WX. Особенности реализации этих библиотек под Windows и Linux разные, приходилось экспериментировать, чтобы заставить их более-менее нормально работать вместе. Для windows и linux подружить их удалось, а вот для macos я этим пока не занимался. Может быть скоро основной вообще станет qt-версия: собственно эмуляция уже работает, осталась некоторая рутинная работа по реализации пользовательского интерфейса и т.п.
Pyk, в Qt-версии как выводите экран?
У меня экран это класс от QWidget, имеющий внутри QImage.
В paintEvent() эмулятор рисует экран в QImage, затем выводит его на реальный экран через QPainter::drawImage().
https://github.com/nzeemin/ukncbtl-q...ster/qscreen.h
https://github.com/nzeemin/ukncbtl-q...er/qscreen.cpp
Ну и со звуком тоже интересно как вы поступили. У меня так:
https://github.com/nzeemin/ukncbtl-q...er/qsoundout.h
https://github.com/nzeemin/ukncbtl-q.../qsoundout.cpp
nzeemin, вывожу на экран практически так же. Единственное - QImage готовится не в paintEvent, а заранее, в момент эмуляции обратного хода луча, асинхронно с отрисовкой его в paintEvent.
А звук мне пришлось хитрее делать, я создавал собственное устройство - потомок от QIODevice.
Исходники Qt-версии все еще еще слишком сырые, опубликую на github чуть позже. Можно обсудить детали реализации по эл. почте, здесь наверное это будет не совсем уместно.
Я сделал такой Makefile.lite (отдельный, чтобы не возиться с разными CFLAGS и LDFLAGS - это правда уже легче будет CMake разруливать)Цитата:
Сообщение от Pyk
Скрытый текст
Код:#!/usr/bin/make -f
SRCDIR = src
INSTALLDIR= ~/emu80
CC = c++
CFLAGS = -c -Wall -std=c++11 `sdl2-config --cflags` -DPAL_SDL -DPAL_LITE
LDFLAGS = `sdl2-config --libs`
SRC = $(SRCDIR)/*.cpp
SRCSDL = $(SRCDIR)/sdl/*.cpp
SRCLITE = $(SRCDIR)/lite/*.cpp
SOURCES_LITE = $(shell echo $(SRC)) $(shell echo $(SRCSDL)) $(shell echo $(SRCLITE))
OBJECTS_LITE = $(SOURCES_LITE:.cpp=.o)
all: Emu80lite
Emu80lite: $(OBJECTS_LITE)
$(CC) $(LDFLAGS) $(OBJECTS_LITE) -o $@
.cpp.o:
$(CC) $(CFLAGS) $< -o $@
clean:
rm -f $(OBJECTS)
rm -f $(OBJECTS_LITE)
rm -f Emu80
rm -f Emu80lite
install: Emu80 Emu80lite
mkdir -p $(INSTALLDIR)
cp Emu80 $(INSTALLDIR)
cp Emu80lite $(INSTALLDIR)
cp -r dist/* $(INSTALLDIR)
cp COPYING.txt $(INSTALLDIR)
cp whatsnew.txt $(INSTALLDIR)
cp doc/* $(INSTALLDIR)
[свернуть]
make -f Makefile.lite
Все собирается, но Emu80lite сразу после старта выходит, ничегошеньки не говоря вообще. Видно, что успевает моргнуть его меню, что-то он начинает делать, но решает, что не стоит задерживаться. Может быть надо какие-то параметры в командной строке указать?
- - - Добавлено - - -
Цитата:
Сообщение от Pyk
Это не совсем gcc ;) Кланг бывает гораздо более строг в варнингами.Код:Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
svofski, скорее всего эмулятор не знает, какую платформу эмулировать. Полная версия при первом запуске показывает форму выбора типа эмулируемого ПК а lite-версия этого не умеет. Нужно либо файл emu80.run скопировать с другой системы, либо явно указать тип ПК в командной строке ("Emu80 -a" и т. д. - варианты можно подсмотреть в emu80.conf: последний параметр в config.addPlatform (при наличии)).
- - - Добавлено - - -
У nzeemin именно gcc, судя по логам...Цитата:
Сообщение от svofski
Очень навряд ли. На маке clang собой заменяет g++, так что запускать-то его можно как g++ и он виду не подает.Цитата:
Сообщение от Pyk
- - - Добавлено - - -
По поводу конфига, я с этим эмулятором к сожалению совершенно пока не знаком и мне было бы удобно, если б он печатал, чего именно ему не хватает при старте.
svofski, насчет подмены g++ не знал, буду иметь в виду.
Lite-версия, к сожалению, ничего не печатает, да и вообще использовать ее имеет смысл разве что из командной строки. Некий такой урезанный вариант, зато не требующий wxWidgets... Смысла большого в ее существовании нет, зато можно попробовать собрать хоть что-то в отсутствии wxWidgets ;)
Ну как же, вот очень даже смысл. Интерфейс полезная характеристика, но все же не основная.
Я только не вижу, где делается Emulation::setProperty("commandline"...), и в дебаггере я туда не попадаю (отошел от компа, пишу по памяти). И без этого он правда не может найти платформу и закачивает сам себе SDL_QUIT.
svofski, так указание типа ПК в командной строке или копирование emu80.run не помогает?
Остальная вся структура папок сохранена? Установка (копирование файлов в ~/emu80) прошла без ошибок?
Я не учел, что надо обязательно сделать make install. Теперь получилось запустить, с -a запустился Апогей.
Makefile.lite поправленный для make install
Скрытый текст
Код:#!/usr/bin/make -f
SRCDIR = src
INSTALLDIR= ~/emu80
CC = c++
CFLAGS = -g -O0 -c -Wall -std=c++11 `sdl2-config --cflags` -DPAL_SDL -DPAL_LITE
LDFLAGS = `sdl2-config --libs`
SRC = $(SRCDIR)/*.cpp
SRCSDL = $(SRCDIR)/sdl/*.cpp
SRCLITE = $(SRCDIR)/lite/*.cpp
SOURCES_LITE = $(shell echo $(SRC)) $(shell echo $(SRCSDL)) $(shell echo $(SRCLITE))
OBJECTS_LITE = $(SOURCES_LITE:.cpp=.o)
all: Emu80lite
Emu80lite: $(OBJECTS_LITE)
$(CC) $(LDFLAGS) $(OBJECTS_LITE) -o $@
.cpp.o:
$(CC) $(CFLAGS) $< -o $@
clean:
rm -f $(OBJECTS)
rm -f $(OBJECTS_LITE)
rm -f Emu80
rm -f Emu80lite
install: Emu80lite
mkdir -p $(INSTALLDIR)
cp Emu80lite $(INSTALLDIR)
cp -r dist/* $(INSTALLDIR)
cp COPYING.txt $(INSTALLDIR)
cp whatsnew.txt $(INSTALLDIR)
cp doc/* $(INSTALLDIR)
[свернуть]
Ну что ж, радует, что lite-версия запустилась и работает :)
Значит, дело все-таки в wxWidgets или его совместной работе с SDL...
Как работает, кстати? Проблем с картинкой, звуком нет? (На Апогее можно сделать R,C <ВК>, G <ВК> и позапускать что-нибудь с ROM-диска).
С музыкой на первый вслух все отлично.
Гигаскрин ожидаемо: фуллскрин очень хорошо, если нет эпилепсии и учитывая обстоятельства, смыргивает изредка, но в целом отлично. В окне ой. Наверное есть параметр не использовать vsync, когда в окне?
Когда камера настроена на 25 fps, выглядит вообще как будто много цветов:
https://youtu.be/MGtcHpClMFs
Но на самом деле все мерцает. И когда в видео видно смыргивание, на экране смыргивает совсем сильно. В общем я думаю это точно так же, как и на 100% лцд мониторов на 60Гц на любой системе.
Пойду-ка соберу на расбери-пи, она у меня к ЭЛТ 50 Гц подключена, правда чб.
Ну да, это из-за небольшого несовпадения 60 Гц в Апогее и 60 Гц на мониторе.Цитата:
Сообщение от svofski
Есть параметр emulation.frameRate в emu80.conf, там можно выставить принудительно частоту обновления экрана вместо привязки к vsync. Но параметр общий, будет работать как в оконном, так и в полноэкранном режимах. Под Windows и под Linux проблем в окне нет, vsync работает точно так же - видимо, есть какие-то нюансы с SDL под macos? Либо это специфика самой macos?Цитата:
Сообщение от svofski
Для того же эффекта можно еще window.fieldsMixing = mix в apogey.conf раскомментировать. Будет так же, как в эмуляторе uart.Цитата:
Сообщение от svofski
Подозреваю, что быстродействия может не хватить :( Но попробовать можно :)Цитата:
Сообщение от svofski
- - - Добавлено - - -
На 50 Гц хуже будет - в этих режимах Апогей на частоту 60 Гц программируется...Цитата:
Сообщение от svofski
- - - Добавлено - - -
А видео в предыдущем сообщении сделано в 30 fps...
Видимо это специфика макоса или SDL под нее. По крайней мере у меня получается все то же самое.Цитата:
Сообщение от Pyk
Для Raspberry Pi 3:Цитата:
Сообщение от Pyk
Где-то на грани. Мельтешение то частое, то быстрое, звук то еще как-то, то совсем хрипит. Видно, что ему _очень_ тяжело. При этом загрузка всего 100% одного ядра и температура 58 градусов.Код:CFLAGS += -mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard
Понятно, что под рпи3 надо оптимизировать. Есть Neon, есть 4 ядра.
- - - Добавлено - - -
25, но ютуба знает лучше, как нам надо.Цитата:
Сообщение от Pyk
УФ!
Pyk, вот! https://github.com/vpyk/emu80v4/pull/1
Для распи главное, чтобы 64-битных делений было поменьше. Одно вот это изменение и теперь все влезает в 50% одного ядра.
Пойду попробую запущу ЭЛТ на 60 Гц, раз так.
- - - Добавлено - - -
Да, на 60 Гц Гигаскрин хорошо, хотя не могу сказать, что это как-то принципиально лучше, чем на LCD. И все равно он смыргивает где-то раз в секунду.
Хорошо бы это изменение по ускорению EMU80 внести и в базовую версию EMU80 для IBM PC.Цитата:
Сообщение от svofski[/b
Потому, что, уж извините за правду, эмулятор EMU80 тормозит на одноядерном PC с тактом 2.4 ГГЦ (загрузка CPU 100%). Тормозит не по экрану, с этим всё нормально. А имеет неприятный дефект, - пропускает нажатия на клавиши. Если при эмуляции ОРИОНА и СПЕЦИАЛИСТА это ещё терпимо (хотя при быстром вводе символы пропускаются, чего никогда не бывает на реале), то при эмуляции РК86 вводить с клавиатуры просто неудобно, надо нажать и удерживать клавишу нажатой примерно пол секунды. Пользоваться таким эмулятором РК86 неудобно, хотя и приходится, если надо прогнать ПО для дисковода. В играх отсутствие реакции на короткие нажатия клавиш, тоже вероятно ухудшит качество игры.
Нельзя ли сделать упрощённую версию именно для РК86, где не будут эмулироваться всякие ненужные для большинства программ свойства ВГ75. Скорее всего, что именно эмуляция этих свойств тормозит, ведь в РК86 текстовый экран, т.е заведомо более быстрый, чем экран у СПЕЦИАЛИСТА и ОРИОНА. Вообще бы не было проблем, если бы из Windows, как и в MSDOS можно было бы установить текстовый режим VGA (загрузив фонт как в РК86), что ускорило бы визуализацию в 50 раз.
Заметим, что все даже самые современные иностранные эмуляторы прекрасно работают даже на самых первых ПЕНТИУМ-ах, что имеют в 50 раз меньшее быстродействие. Для сравнения эмулятор EMU от b2m загружает процессор всего на ~10% и ввод с клавиатуры там беp потерь.
Недавно пока делал CP/M для СПЕЦИАЛИСТА, чтобы сберечь нервы, приходилось использовать EMU, эмулируя дисковод в RAM-диске, и только для проверки работы дисковода требовался именно EMU80, т.к в EMU нужный контроллер дисковода не эмулируется.
Вылет в отладчик по встрече Z80 команды при эмуляции КР580 - полезная вещь. Это позволило за 15 минут очистить от Z80-команд программу, в то время как при трассировке вручную эта работа заняла бы несколько недель.Цитата:
Сообщение от Pyk
Сброс по АЛЬТ+F11 должен работать и в окне отладчика. Иначе трассируя программу и останавливаясь в точках контроля, где для останова поставлена команда HALT, никак не выйти из отладчика, чтобы сделать сброс в основном окне программы. Закрываешь окно отладчика, и снова вылетаешь в отладчик по очередному HALT в программе, т.е никак не вернуться в окно программы, чтобы нажать там АЛЬТ-F11.
nzeemin, предупреждения clang отработаю. К счастью, среди них не оказалось ничего критического, даже ошибка с битовой операцией, вероятно, не проявляется ни в одной реальной программе.
svofski, спасибо, pull request посмотрю вечером. Насчет гигаскрин-режима: можно посмотреть режим, на который программируется там ВГ-75. Если получится подстроить его на частоту, более близкую к 60 Гц, то "смыргивать" будет реже (кстати, гигаскрин-режим есть еще в заставке к игре lines).
barsik, не факт, что этот патч поможет на процессорах x86. Эмулятор, конечно, не самый быстрый, простор для оптимизации есть, но все-таки он обычно нормально работает и на процессорах с меньшей тактовой частотой, чем 2,4 ГГц. В очередной раз прошу информацию о вашем ПК, чтобы попробовать понять причину тормозов.
А для сброса пока можно переключиться из отладчика в основное окно, нажать Alt-F11 и опять вернуться в окно отладчика. Информация в окне отладчика обновится при следующем шаге.
Это симптом загрузки 100%.Цитата:
Сообщение от barsik
Я построил было Emu80lite для винды со своим патчем. Но в последний момент вспомнил, что у вас XP. Просите Pyk-a сделать тестовый 32-битный билд.
- - - Добавлено - - -
Pyk, профайлер еще намекает на то, что еще есть 64-битные деления и что Crt8275Renderer::primaryRenderFrame() можно было бы улучшить. Типа там можно const Symbol & вместо копирования Symbol, инкременты умножить заранее итд. Но на фоне ВИ53 я не смог даже разглядеть непосредственных эффектов от этих изменений, и не факт, что локальная копия объекта не работает быстрее из-за кеша итд, поэтому я не стал копать в ту сторону.
сделали? под какой контроллер?Цитата:
Сообщение от barsik
barsik, я нашел у себя XP.
Попробуйте вот эту сборку:
http://sensi.org/~svo/b/emu80v4-patched.zip
Это версия lite без интерфейса. Надо распаковать себе в userhome, то есть например c:\Documents and Settings\barsik\emu80
Там из командной строки запустить em80v4-svofski -a (Апогей) или -r (РК)
У меня в затюканной виртуализованной в VirtualBox-е XP на лаптопе 8 летней давности эмулятор съедает около 20% своего виртуального проца:
https://www.dropbox.com/s/5uvsrq9q3b...18.54.png?dl=0
Версия из официальной сборки редко переваливает 30%.
Попробовал, не работает. Ничего не происходит при запуске, видимо для иной Windows. Пробовал в разных каталогах в т.числе и в каталоге \Documents and Settings\, хотя у меня системный диск D:, а не C:. Кстати "лайт" и полная версия жрут, кажется, одинаковый ресурс.Цитата:
Сообщение от svofski
Зато по Вашей картинке понял, где смотреть загрузку процессора. На русскоязычной Win XP этот столбец вместо CPU называется ЦП. Я не знал, что это загрузка процессора конкретным процессом и смотрел общую загрузку "Загрузка ЦП" в вкладке "Быстродействие". У меня при эмуляции СПЕЦИАЛИСТА загрузка 30...35%, а при эмуляции РК86 почти вдвое выше. А если загружены и другие ресурсо-жрущие программы, то и получается 100% загрузка и торможение. Кстати загрузка EMU от b2m тоже не 5%, а 9...12%, но зато она одинаковая при эмуляции СПЕЦИАЛИСТА и РК86.
Вообще-то, если не использовать одновременно другие программы и запустить EMU80 и никогда не выходить из него, то быстродействия более-менее хватает. Но если выходить и затем снова перезагружать EMU80, то быстродействие падает. Сейчас в этом разобрался. К тому же поднял быстродействие за счёт оверклока. Когда снимал радиатор с CPU, удалил теплопроводящую пасту, т.к она высохла. Из-за этого процессор перегревался и понижал себе частоту. Хотя радиатор не был горячим. Решил смазать вентилятор и одновременно нанёс новую теплопроводную пасту. Оказалось паста очень полезна. Температура процессора упала и процессор без перегрева работает даже на оверклоке.
barsik, шутки шутками, но похоже, что вы можете получить ощутимый прирост в общей производительности, проапгрейдив свой компьютер на Raspberry Pi 3.
Если у вас есть установленный Emu80 и вы умеете запускать в нем Emu80lite, положите мой туда же, где лежит Emu80lite.exe: вот и ответ на вопрос куда именно его класть. И наверное SDL2.dll тоже положите рядом. Я не разобрался сходу как в Code::Blocks прописать статическую линковку для SDL, поэтому dll должен лежать рядом.
Но если вообще получается, что загрузка 70%, то не должны пропускаться клавиши в эмуляции и хрюканья тоже быть не должно. От моего патча, может быть, получится сбросить еще процентов на 10,*но такое трудно прогнозировать.
- - - Добавлено - - -
P.S. уговорил Code::Blocks на статическую линковку, exe: http://sensi.org/~svo/b/emu80v4-svofski-static.exe
При копировании в каталог с EMU80 файл стал запускаться. Но всё-равно отдельные нажатия при быстром наборе пропадают, а загрузка процессора осталась той же самой. Тут дело в принципе работы эмулятора и это не исправить ускорением отдельной подпрограммы. Пропадание нажатий на клавиши происходит потому, что использован неудачный алгоритм выравнивания скорости эмуляции.
Есть три алгоритма эмуляции. Полноценная покомандная эмуляция и покадровая визуализация. Во-времена медленных ЭВМ использовалась покомандная эмуляция. Но она сложна и поэтому сейчас, когда скорости ЭВМ стали это позволять, используется визуализация, т.к это на порядок проще.
Для экранной визуализации также имеется два алгоритма. В грамотных эмуляторах это делается добавление паузы после КАЖДОЙ (!) команды. Это даёт возможность не только подогнать длительность исполнения каждой команды к числу её маш.тактов в реале. Важнее то, что эмулируемая программа прогоняется с той же равномерностью как в реале.
Визуализация делается как раз в эти паузы между командами и никак не тормозит прогон. Даже на медленной машине не возникает торможения, т.к в каждой паузе визуализируется лишь маленькая часть экрана. Достаточно скоростей 486-той. В эмуляторах сделанных на таком принципе реакция на клавиши абсолютно полностью соответствует оригиналу.
А в данном эмуляторе используется покадровая визуализация и применён следующий алгоритм выравнивания скорости. Весь прогон разбивается на фрагменты дискретизации. В 20...50 мсек. Известно сколько маш.тактов выполнит реальный процессор за это время. Эмуляция команд эмулируемого CPU производится на максимальной скорости PC. При этом эмулируемая программа прогоняется на эмулируемом такте 200 МГЦ, и нужное число машинных тактов прогонит всего за 1 МСЕК. Чтобы уровнять скорость прогона, надо остановить эмуляцию на оставшиеся 49 МСЕК. И как раз в это время и делается визулизация - копирование экрана 8-ми разрядки в реальный экран SVGA. Если быстродействия не хватает, чтобы процедурой написанной на ЯВУ вывести весь кадр за 49 МСЕК, то FPS падает (хотя это визуально не вредит), а время вывода кадра подпрограммой написанной на ЯВУ может увеличиться до долей секунды.
Ясно, что в такой концепции прогон происходит рывками, т.е прогнали фрагмент, остановились, затем после паузы - следующий фрагмент. И вот как раз в эту паузу программа не чувствует клавиатуру. Если коротко нажать как раз в момент такой паузы (длиной в доли секунды), то нажатие пропадает.
Исправить такой алгоритм можно 2-мя способами. Во-первых, не допускать потери нажатий клавиш. Т.е фиксировать нажатия. А не только проверять клавиатуру тогда, когда к ней обращается программа. Надо искусственно удлинять нажатия на период больший чем время паузы, чтобы программа 8-ми разрядки могла это обнаружить.
Когда нажатие случается и заканчивается во время, когда происходит визуализация, то оно пропадает для прогоняемой программы. Если эмулятор отнял у программы 8-ми разрядки время, то он должен брать на себя функции обслуживания клавиатуры. Т.е по окончании визуализации, он должен проверить было ли или нет нажатие на клавиши во время визуализации и если оно было, то надо сэмулировать нажатие той же или лучше большей длительности на время когда прогоняется программа 8-ми разрядки. Вот тогда никаких пропаданий нажатий не будет.
Второй способ избавиться от потери нажатий - это сократить период дискретизации. Похоже сейчас пауза равна времени копирования всего экрана 8-ми разрядки в экран SVGA, написанной на ЯВУ. А чтобы сократить период дискретизации лучше в каждой паузе выводить не весь экран, а лишь его часть, например четверть экрана, что в 4 раза сократит время пауз в прогоне и требования к скорости PC.
Если визуализацию сделать на ассемблере, то период дискретизации получится маленьким. Тогда программа также прогоняется фрагментами с паузами между ними, но эти паузы малы и не приводят к плохой реакции на клавиши. Но увы, в данном случае всё сделано не на ассемблере, а на очень тормозном ЯВУ и у автора нет желания менять алгоритм.
Вывод простой. Надо писать критичные процедуры на ассемблере, а не на ЯВУ. Так было для 8-ми разрядки и так это осталось и для PC со скоростями в тысячи раз выше.
svofski, сегодня, к сожалению, был занят, успел только потестировать готовые сборки с патчем.
На Intel, похоже, деление 64-разрядных чисел не дает мало-мальски заметного прироста производительности. Пробовал запускать в XP на Core2Duo 6420 2,13 ГГц 10-летней давности. Загрузка процессора на gigascreen demo колеблется в районе35-41%10-16% как с патчем, так и без. Возможно, с патчем процента на 2 меньше - понять сложно. Завтра могу попробовать еще на Atom'е 1,6 ГГц.
barsik же от патча эффект тем более не почувствует, поскольку он работает в конфигурации "Специалиста", в которой не используется ВИ53.
А код я еще посмотрю в плане производительности. Меня пока несколько удивляет, почему именно эта процедура вызывается так часто, что затмевает все другие места, где встречается 64-битное деление. Возможно, просто специфика апогеевской программы, которая очень часто читает значения счетчиков (на какой программе проверялось, кстати?)
barsik, после прочтения последних ваших сообщений возникла одна идея. Не запущены ли у вас случайно параллельно с эмулятором какие-то DOS-программы (они запросто могут отбирать 100% процессорного времени)? Или про какие ресурсо-жрущие программы вы говорите? Просто загрузка порядка 30% на Специалисте - это довольно большой запас производительности...
Pyk, да мы никуда не опаздываем. Я проверял все на Апогее. Не знаю, почему, просто наугад. И первая попавшаяся там демка с гигаскрином меня заинтересовала тем, как она будет выглядеть на ЭЛТ.
Между вызовами updateState() по-моему 17500 циклов времени, а делитель 945. Это важный момент, потому что одно на другое не делится и, если неправильно считать количество тиков, выходит свист. В вычислении тиков до моего вмешательства уже прослеживаются какие-то следы борьбы ;) Вызывается я думаю он в обычных количествах, это же таймер. Еще подумал, что даже сохраняя 64-битное время, незачем там вычислять количество тиков в каждом счетчике. Достаточно сделать это в головном модуле один раз за троих.
Я сначала разбирал gperftools, но они не показывали причину вызовов __udivmoddi4(). Тогда я прибег к дедовскому способу: ctrl+c в отладчике, это всегда работает. Вообще я и сам удивлен, что на rpi3 это такая тяжкая операция, возможно я недожал какие-то архитектурно-специфические опции. Но, глядя правде в глаза, незачем там 64 бита иметь. При вот этих значениях, 17500/945, хватило бы на самом деле и 16.
svofski, смутила меня все-таки относительно высокая загрузка процессора, попробовал сейчас еще раз на том же Core2Duo - неизменно получаются уже другие цифры: 13-16% без патча и 10-13% с патчем на том же гигаскрине. Откуда я взял лишние 30% при тестировании час назад, не понял :confused:
Не знаю ;) На rpi3 Специалист съедает ~25%.Цитата:
Сообщение от Pyk
Вопрос к авторам эмуляторов с поддержкой КНГМД на ВГ93. Формат DD (Double Density), т.е 720 или 800 кб на диск поддерживается, а формат с одинарной плотностью, т.е SD (Single Density) 360 или 400 кб на диск поддерживается?
Предполагаю, что эмулятору, в котором эмуляция ВГ93 сделана не в реальном времени, а на отлове CPU-команд записывающих в регистры ВГ93, совершенно до лампочки низкоуровневый формат - частота импульсов записи и сам низкоуровневый формат (FM или MFM), т.к эмулятор просто отлавливает команду (например, читать сектор) и выдаёт соответствующие данные при чтении из регистра данных.
Если низкоуровневый формат до лампочки, то должна работать самая первая примитивная дискетная защита от копирования дискет ОРИОНА из начала 90-тых, которая была основана на том, что защищающие треки писались в формате SD (MFM), тогда как остальные треки были в обычном формате DD (FM). Программами копирования ОРИОНА эти дискеты не копировались, но к сожалению, специальными программами на IBM PC это копировалось. Потому пришлось усложнять защиту и все мои последующие дискеты нельзя было скопировать.
Проблема только как перенести такие дискеты в формат ODI. В формате ODI все сектора одного размера по 1 кб и идут впритык, без межсекторной информации. На дорожке отформатированной в DD 5 секторов по 1 кб, а на дорожке отформатированной в SD 5 секторов с размером всего по 512 байт.
Если считать дорожки и записать в файл ODI, то вся адресация секторов после дорожки записанной в SD сдвинется. Нужен такой формат, в котором у каждого сектора есть информация о номере дорожки, номере сектора на этой дорожке и размер этого сектора. Порядок секторов не обязан быть такой же как на реальной дискете, т.к всё-равно нет всей межсекторной информации и команда чтение дорожки не сработает.
Но это хотя бы позволит использовать дискеты ОРИОНА защищённые от копирования программой CERBERUS.COM от С.Коровкина из Ижевска. Там защита основана на том, что на дорожку пишется дополнительный 6-той ключевой сектор с размером всего в 256 байт. Такие дискеты тоже не могут копировать программы ОРИОНА для посекторного копирования дискет, но специальные программы IBM PC и это копируют.
Чтобы работали более грамотные защиты дискет ОРИОНА, что я применял начиная с 1993, надо хранить в образе диска полные копии дорожек со всей межсекторной информацией. Это увеличит объём образа диска от 800 кб до 1.5 мб.
Вопрос по эмуляции РК86. В реальном РК86, если повысить такт ВТ57 с 1.77 МГЦ до 2.66 МГЦ или даже до 3.2 МГЦ (16:5=3.2), то увеличивается быстродействие РК86 (короче становятся периоды захвата шины). В эмуляторе это так или влияние ПДП вообще не учитывается?
Как изменить такт в РК-КНГМД в эмуляторе?
Сейчас в эмуляторе в РК-КНГМД как бы применён такт 8 МГЦ (16 МГЦ на входе), что и даёт 5 секторов по 512 байт на трек. Но если поставить кварц 10.5 МГЦ, то на ту же DD-дискету на каждый трек влезает уже 7 секторов по 512 байт, что даёт емкость дискеты в 560 кб (574 кб при 82 треках). РК86 для такого формата д.быть немного турбированным. Т.е или иметь повышенный такт ВТ57 или же такт самого КР580 должен быть чуть повыше.
Для турбирования РК86 меняют кварц у ГФ24 на кварц 20...27 МГЦ. Это повышает такт у ВТ57 и у КР580. А чтобы видео-сигнал остался в норме, надо откуда-то брать такт 16 МГЦ для ВГ75. Для этого ставится отдельный генератор на 531ЛН1 с кварцем 16 МГЦ. При кварце 27 МГЦ для ГФ24 реальное быстродействие увеличивается вдвое против ~1.3 МГЦ эффективного такта базового РК86.
Можно ли в эмуляторе, чтобы не макетировать в реале, подставлять свои частоты для КР580 и для ВТ57 и замерять получившееся быстродействие РК86 ?