какой именно спек собираешься эмулировать?
Собираюсь эмулировать Pentagon 128 + TR-DOS (очень упрощенно) + AY (через миди) + Kempston Joystick + Keyboard (как нибудь извращенно). Но речи о мультиколорах пока быть не может, да и бордер не собираюсь эмулировать.
По поводу AY на MIDI у меня была подобная разработка в одной из версий первого ZXMAK, еще до того как он появился в сети
Если нужно могу поискать. Код там был довольно небольшой и на удивление простые звуки проигрывались хорошо. Серьезная проблема с MIDI - огибающая, получался дрожащий звук, возможностей MIDI для нормальной имитации огибающей AY я так и не нашел
Поищи пожалуйста исходники. Я C++ пока только изучаю, но при желании разберусь, все таки уже работал с MIDI. Про сложности с огибающей я прекрасно знаю. Причем не столько сложно подобрать инструмент для огибающей, сколько сложно повторить "наложение огибающей на тон и шум".
По поводу ВГ, можешь посмотреть ZXMAK.NET... код ZXMAK.NET на C#, думаю переделать на Java можно быстро
Если не сложно, дай ссылку на исходники. В C# не соображаю, но раз ты говоришь, что есть сходство с явой, то возможно разберусь.
В коде ВГ Unreal'а есть нехорошая штука, CRC считается без учета маркеров, если маркеров будет не три, то скорее всего работать будет неправильно, детально не изучал, но отметил что этот вопрос нужно проработать.
Я собираюсь поддерживать только TRD и SCL. На сколько я знаю, там заморачиваться с CRC и всякими маркерами не нужно. просто читать сектора через сэмулированные порты. Соблюдать временные параметры и тактировку для ВГ93 тоже считаю излишним, думаю должно работать и так.
switch и 256 case-ов конечно будут тормозно работать, и никакой jit кэш их в себя не впихает, и что-то мне кажется что компилер это не сможет заоптимизить до таблицы переходов, т.е. будет тормозно по-очереди всё приверятся.
У меня в Nescube эмулится проц 6502. Там около 150 комманд. Я б не сказал, что там CASE работает медленно. К тому же, в будущем эмуле спека есть одна хитрость. например основной набор в 256 комманд разбивается на три набора в соответствии с длиной комманды в байтах (1-3 байта). Таким образом 256 комманд уже деляться на три SWITCH. Для однобайтной комманды срабатывает один SWITCH, для двухбайтной - два SWITCH и т.д.
а вот есть ли в джаве делегаты функций? в .NET есть, и можно все обработчики комманд заделегировать и сделать массив делегатов.
и тогда почти указатели получаются.
Ничего подобного я в яве не видел. Я пересмотрел очень много разных интерпретирующих эмулей (в том числе и ZX) на яве и везде используется (в той или иной форме) SWITCH...CASE.
В первых версиях ZXMAK (C++) я тоже пробовал делать дешифрацию по битам, в результате отказался от этого, т.к. после реализации недок. префиксов дешифрация стала очень-очень медленной, а код дешифрации жутко запутанным.
Скорость действительно не самая быстрая. Когда я писал это ядро, я хотел именно сократить длину одного большого SWICH'а,и думая что скорость перехода в нужную ветку зависит от количества CASE. Как оказалось, я ошибался. Скорость не зависит. А мое ядро оказалось даже медленнее, чем построенное на SWITCH...CASE и функциях ядро MobileZX. Поэтому я оставил это ядро для лучших времен. Его алгоритм можно будет применить в тех проектах, где важен размер кода и не так важно быстродействие. Но ядро именно крассивое, не какой-то там безконечный SWITCH.