PDA

Просмотр полной версии : Эмулятор ZX-Spectrum на Java



Dizzy
09.10.2004, 19:19
Вот пришла в голову идея попытаться сделать эмулятор ZX-Spectrum для телефона Х100.
ZX Spectrum представляет одну из лучших реализаций 8-битных платформ. В базовой конфигурации он имеет 3,5 МГц процессор Z-80, 64 кб памяти, из которых 16 кб занимает ПЗУ и 6912 байт экран. Благодаря усилиям отечественных Кулибиных добавилась память, появился звук, работа с FDD, HDD, а также новые режимы экрана, кэш и прочее.
Основная прелесть проекта в том что с 1982 по 2004 год для платформы ZX Spectrum было разработано просто _огромное_ количество программного обеспечения и в том числе игр. Отдельного внимания заслуживает музыка но об этом позднее.
На сегодняшний день платформа практически умерла, но остались ещё люди в основном из СНГ которые ей верны до последнего ;)
Ознакомившись со спецификациями MIDP 1.0 и Samsung OEM API можно прийти к выводу что реализовать задуманное вполне возможно (хотя на первый взгляд невозможно).
На сегодняшний день существует целый ряд нерешённых, но постоянно обдумываемых мною задач.
Принцип работы транслятора будет основываться на золотом правиле оптимайзера: «Выигрываем в скорости – проигрываем в размере памяти». Ориентировочной скорости работы транслятора должно хватить на корректную эмуляцию логики, но практически не остаётся машинного времени для прорисовки экрана и обработки звука (звук я хочу обсудить позднее).
Итак экран.
Экран ZX – Spectrum занимает 6912 байт из которых: 6144 байта занимает чёрно-белое изображение (256x192) в режиме 8 точек на байт, причём он ещё адресуется по хитрому, а оставшиеся 768 байт (32x24) цвета в режиме 1 байт на квадрат 8x8 точек линейно.
Экран X100 128x128x65536 нас вполне устраивает по цветности, но совсем не устраивает по разрешающей способности. Не беда - придётся рисовать с использованием фильтров.
Это всё тонкости реализации, но проблема с экраном не в них, а в том чтобы как-то адресовать экранное пространство телефона или область изображения класса Image, что нам MIDP 1.0 не позволяет. Может есть какие-то дополнительные наборы классов которые это умеют? Может это можно как-то сделать и без них?
У меня есть варианты со стандартными классами только очень медленные (отсортировано предположительно по скорости):
1. Например для чёрно-белого рендеринга создаётся 256! Imag-ей а для цветного 256x128=32768! (Интересно Java такое выдержит?) Imag-ей размером 4x1 пикселей. Дальше для каждого байта изображения с ZX рисуем соответствующий Image и так 6144 раза.
2. Создаём свой шрифт 256 символов который в принципе делает то же что и 256 Imag-ей, задаём цвет тона, цвет фона, печатаем.
3. Рисуем экран с помощью линий Canvas-а но по точкам, предварительно установив нужный цвет.
4. Кодируем на лету экран ZX-Spectrum в PNG файл (считаем CRC и сжимаем ZIP - это по скорости нереально просто) далее создаём из него Image.

Давайте подробнее остановимся на способах прорисовки с помощью MIDP 1.0 как можно что-либо нарисовать кроме стандартных линий прямоугольников и дуг, загрузки Imag-ей из PNG и печати текста?

Dizzy
09.10.2004, 19:21
Подскажите где взять спецификации по организации памяти в х100, системе команд, регистрам, картам API-функций и т.д.
И ещё интересует как можно с вызвать из Java мидлета какую-нибудь функцию если точно известен её адрес и аргументы в прошивке?

Tualin
09.10.2004, 20:26
а ты уверен, что производительности телефона хватит?
я понимаю, если это был бы se k700 и компания, но самсунг x100... архитрудная задача.

Dizzy
09.10.2004, 21:00
Забыл сказать, что проект не коммерческий, а хобби. Очень хочется освоить новую для себя платформу.
На уровне асма думаю скорости хватит, но на уровне Java не уверен. Думаю, если это возможно, смешивать.
Например экран прорисовывать рисовать асмовской функцией предварительно прошитой в верхнюю часть памяти телефона или поверх неиспользуемых языков или картинок. Есть же в самсунге картинка "домик на траве", но её посмотреть можно только “ковыряя” прошивку. 8)
Сейчас пишу SCR вьювер на Java. Хочу проверить скорость прорисовки. Эх, если б как-то можно было бы адресовать или область экрана или область данных Imag-а…
Даже если и будет тормозить, то начатое будет не сложно перенести на другой, более мощный телефон.
Достал исходники классов для MIDP, но в них совсем нет javax.microedition.lcdui. Интересуют исходники класса Image.

Dizzy
10.10.2004, 20:34
"Авторы языка Java сконструировали _интерпретатор_ языка (JavaVM) таким образом, что в Java-программу можно включать фрагменты, написанные на других языках и выполняемые в объектном коде (native code) соответствующей платформы."
Теперь, после слова интерпретатор, у меня большие сомнения насчёт скорости. 8)
Расскажите пожалуйста подробнее про native code.

Dizzy
10.10.2004, 21:18
"The library containing the native code implementation is loaded by a call to System.loadLibrary()."
В спецификации MIDP 1.0 у класса System оказывается нет метода loadLibrary("nativelib"). Значит ли это что использовать native код в Java 2ME не представляется возможным?

dykzei eleeot
11.10.2004, 12:01
привет, интересные у тебя идеи, но многое не реализуемо так сразу мне кажется...вот что я думаю:

1. Исходники Image ничего тебе не дадут, т.к. все "нужные нам" функции лишь описаны как native, а реализации нет, что наводит на мысль: разработчик реализовал их сам как захотел, а есть лишь стандарт обращения к ним.

2. Сктолько image'ей сколько ты написан создать удастся очень врядли... сколько памяти в x100? а в geneic j2me устройстве? ведь для создания экземпляра класса нужно еще и память под все методы и т.п. я лично написал PAINTE - графический редактор,и как раз в процессе этого столкнулся с ужасной ограниченностью MIDP1 по части графики и всего остального

3. это факт, что ты не сможешь вызвать никаких функций по их адресам в прошивках, нельзя копировать содержимое Graphics! есть лишь бредовая идея под конкретную модель (например тот же х100) взломать в прошивке виртуальную машину java и добавить ссылок, а вместо чего-нибудь в прошивку на ASM написать свои native функции и работать с ними, но нужно будет еще переписать некоторые компоненты J2ME API с учетом добавленых функций... но имхо нет такого человека, который бы это всё смог сделать, это нереально на практике...

4. чтобы как-то адресовать область с которой я работаю я создал массив int[][] размером с экран и все операции с экраном дублировал собственным алгоритмом на этот массив, таким образом имел доступ к тому, что нарисовал... это самый безобидный вариант, а то, что ты насчет Image сказал бессмысленно, т.к. ты все равно не сможешь получить доступ к тому, что на них...прийдется для каждой создавать что-то типа дублирующей переменной

Dizzy
11.10.2004, 19:02
Спасибо за ответ. Мои вопросы или размышления: 8)
1. А реализации этих native функций лежат в прошивке или они неявно подключаются виртуальной машиной как некая native.dll? Откуда интерпретатор Java вообще знает про native функции телефона или они hard coded?
2. В х100 памяти под Java где-то 479кб, максимальный размер мидлета 150кб. При создании нескольких екземпляров класса память выделяется только под properties а под методы она выделяется только 1 раз при описании класса. Если Image - 4х1 пиксела, то занимать он будет немного. Идея тут создать кучу статических Imag-ей и рисовать ими Canvas. Таки есть вероятность что не хватит памяти или будет тормозить.
3. Да, это всё ужасно 8). Оставим на потом как самый самый последний вариант чистый ASM. Буду Java “мучить” до последнего. 8)

Dizzy
11.10.2004, 19:03
В FAQ по переделке игр на Samsung с других телефонов (forum.samsung-mobile.ru) говорится, что для переделки игры например с Nokia достаточно в файл jar добавить папочку с файлами com\nokia\… У меня в голове не укладывается как можно добавить на Samsung native классы от Nokia. Таким же образом переделываются игры от сименс и сони-ериксон. Как такое потом может работать? Почему?

dykzei eleeot
12.10.2004, 13:04
нет не все так...
native реализация действительно лежит в прошивке, однако там нет файловой системы и никаких dll, просто интрепритаторы у всех разные, и возможно native код содержится в самом интерпритаторе, возможно где-то еще в прошивке или же в стороннем описаном классе (как ты и писал com\nokia.. например) - поэтому далеко не все переделанные игры таким способом идут на других моделях.

Dizzy
15.10.2004, 00:41
Платформа Java2ME оказалась непригодной для решения подобного рода задач, т.к. скорость работы мягко сказать неудовлетворительна. Написал программу, которая рендерит образ экрана zx-спектрума на экран телефона. Все вычисления кроме побитовых логических операций и сдвигов делаются по таблицам. Результат - 0.05 fps, а норма zx-спектрума 50 fps. Оптимизировать алгоритм прорисовки по скорости в 1000 раз не представляется возможным, следовательно на сегодняшний день задача имеет место быть нерешаемой средствами Java.

P.S. Очень странно, что 16-ти битная платформа с процессором > 100 Мгц (не могу найти точную цифру по х100) не может эмулировать простенький 3,5 МГц 8-ми битный процессор. Для себя отмечу приятным и надеюсь в дальнейшем полезным моментом знакомство с Java 2 ME. 8)

dykzei eleeot
15.10.2004, 13:31
во первых: http://forum.siemens-club.ru/viewtopic.php?TopicID=41496
во вторых: http://mobilezx.sourceforge.net/ (используется MIDP 2.0)
в третих... на х100, как я помню, одна из самых медленных JAVA машин...

Tualin
15.10.2004, 14:09
Dizzy, чего-то вы путаете насчёт процессора в x100... 100 мегагерц в смартфоны ставят.

я думаю, что в разы меньше, эдак в 10 раз...

gobliin
22.10.2004, 18:28
фигасе ты чо-то подзагнул. в M55 стоит процессор на ~50 mHz?, а M55 это далеко не смартфон, и не думаю что на процессоре с 10 mHz ява будет бысто работать, если на M55 она не особо быстрая то что будет на 10 mHz ?

Tualin
26.10.2004, 23:58
gobliin
ява основана на интерпретаторе... скорость, во многом, зафисит именно от него, ну потом уже от процессора.

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