Эмуляция ZX на J2ME

[Sinus]

Вопросы именно по архитектуре спека, какие порты есть, какие биты в них за что отвечают и т.д. и т.п.

какой именно спек собираешься эмулировать?
есть обычный 128kb, то вроде и так всё ясно
out: #7FFD, #FD
in: #xxFD
+AY, +TRDOS

[Advertiser]

[Sinus]

писал (и пока пишу) на яве. Там нет указателей, поэтому таблица процедур не возможна.

я вот думаю...
switch и 256 case-ов конечно будут тормозно работать, и никакой jit кэш их в себя не впихает, и что-то мне кажется что компилер это не сможет заоптимизить до таблицы переходов, т.е. будет тормозно по-очереди всё приверятся.

а вот есть ли в джаве делегаты функций? в .NET есть, и можно все обработчики комманд заделегировать и сделать массив делегатов.
и тогда почти указатели получаются.

статья в тему -> http://www.onjava.com/pub/a/onjava/2...delegates.html

не окажется ли это быстрее твоего метода?

[Dr.Lion/RSM]

какой именно спек собираешься эмулировать?

Собираюсь эмулировать 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.

[Sinus]

Ничего подобного я в яве не видел. Я пересмотрел очень много разных интерпретирующих эмулей (в том числе и ZX) на яве и везде используется (в той или иной форме) SWITCH...CASE.

тут http://www.onjava.com/pub/a/onjava/2...delegates.html написано про делегаты на яве

[psndcj]

у моего бро key-jee новая аська - правда он ее редко читает =( стукнись ко мне в аську - я тебе скажу номер (у меня не получается стукнуться в твою из-за нового движка форума). ну и при встрече ему скажу о твоем проекте...

[проф]

и чёто тема заглохла а хоцца на своём сонерике к 750 хороший эмуль иметь

[Dr.Lion/RSM]

Сейчас дописываю ядро эмуляции Z80. Как показывает жизненный опыт, завести такое достаточно объемное и сложное ядро с первого раза врятли получится, где-то все равно будут ошибки. В связи с этим, хочу спросить "бывалых" эмуляторщиков как и на чем лучше всего отлаживать ядро Z80, чем можно проверить правильность исполнения инструкций процессора? Я слышал о такой вещи, как zexall, но понятия не имею, где его взять и как им тестить ядро. Подскажите кто что знает!

P.S. По первым моим поверхностным прикидам имею смелость заявить, что будущий эмуль ZX (текущее название PocketZX) будет работать не медленнее моего эмуля денди, т.е. расчитываю получить скорость в 30-50 FPS (железо у ZX, не смотря на Z80, проще чем у денди, а сложность Z80 заключается, в основном, в его большем количестве комманд, которое, однако, практически никак не влияет на скорость эмуляции).

[Dr.Lion/RSM]

Да, похоже здесь я помощи не дождусь! Очень жаль, что все такие безразличные!

P.S. Собрал простейшую версию эмуля, видео работает, проц на каких-то коммандах вылетает в нирвану, zexall на белом экране ничего не показывает.

[проф]

обратись в личку к кому нибудь, например к Кладову

[Error404]

Некоторые эмуляторы умеют сохранять дамп выполненных Z80 команд (и регистров). IMHO простейшим способом отладки был бы режим аналогичного дампа в Вашем эмуляторе и просто сравнение по содержимому (например, в ТоталКомандер) двух текстовых простыней: полученных при выполнении zexall (или другого кода) на Вашем и на эталонном эмуляторах.