Предполагается (по крайней мере мной), что по нажатию клавиши вызова интерфейса, работающая программа будет выгружаться, а на её место будет загружаться интерфейс. При выходе из интерфейса всё будет происходить в обратном порядке.Сообщение от Vitamin
Мой эмулятор под Палм не имеет вообще никакого интерфеса. Если бы в моём распоряжении была бы такая штука, то и ситуация была бы несколько другой...
С уважением, Станислав.
Предлагаю оценить трудоемкость написания и отлаживания этого интерфейса и сравнить ее с трудоемкостью написания нативного гуя. Плюс не стоит забывать об опасностях (случайный останов процессора, включение максимальной скорости- и все, остается только перезапускать эмулятор).
В данном случае написание нативного полностью отпадает. При качественно написанном ZXGUI никаких опасностей просто быть не может. Все описанные причины никак не повлияют на его работу. (см. предыдущий от твоего пост).
Добавлено через 3 минуты
Пожалуйста, не нужно приписывать слова Windows, Win32 и т.д. Это никоим образом не касается данной проблемы.
Последний раз редактировалось DZh; 14.09.2008 в 18:43. Причина: Добавлено сообщение
Ну предположим, у нас абсолютно безбажный код (что само по себе невозможно), есть возможость отката настроек если чтото пошло не так.
Как, например, будет делаться навигация по дереву файлов?
Навигация по дереву файлов - это дело техники программирования под конкретную платформу. Если имеется в виду вопрос передачи данных в память ZX, то в ней можно либо выделить буфер по умолчанию, либо в параметрах команды указывать адрес/размер передаваемых данных. Я не вижу никаких препятствий в реализации такого типа GUI. На практике это можно реализовать как два раздельных режима: эмуляция для софта и эмуляция для GUI. Отличие будет лишь во включенном/выключенном бите в области переменных эмулятора. В этом случае отпадает необходимость в идентификаторе после EDxx. Также это исключит выполнение вредоносного кода в режиме софта, а режим GUI делаем недоступным для пользователя.
Господа, вы не думали о том, что такой интерфейс можно было-бы применить для общения реального Спектрума с РС? Может сразу заложить и эту возможность, чтоб потом не делать всё заново.
не понимаю все же.. зачем Z80-API управления фичами эмулятора, ясно. а зачем рисовать эмульский GUI средствами эмулируемого спека -- нет. у такого варианта есть какие-то плюсы? вроде, сплошные минусы кругом
это ж проще можно устроить, через COM-порт например.
4-байтовый идентификатор придется повторять много раз -- для каждой команды. плюс по 3 байта на CALL (см ниже)
прога-то не обвалится, но писать ее станет неудобно. каждый раз при необходимости подачи команды делать RET.. сталбыть перед этим делать туда CALL, и опять-таки для каждой команды, брр...
Последний раз редактировалось boo_boo; 15.09.2008 в 02:53.
Как раз именно по этой причине и возникла эта идея! Посняю, что мой, что эмулятор Дмитрия написаны на чистом ассемблере. Лично для меня оказалось не подъёмным писать интерфейс эмулятора под PalmOS на ассемблере, хотя я пытался. Для меня было бы гораздо проще создать такой интерфейс именно в коде Z80. Так что вопрос трудоёмкости весьма относительный...
С уважением, Станислав.
Физический интерфейс может быть разным - СОМ, LPT, ISA - эт вопрос уже драйвера, вопрос в том чтоб была такая возможность прицепить соответствующий драйвер и юзать хоть в эмуле, хоть на реале один и тот же универсальный программный интерфейс.
Последний раз редактировалось Black_Cat; 15.09.2008 в 03:06.
Не вижу минусов. Интерфейс как интерфейс, только слегка необычный. Плюс - каждый может написать свой интерфейс на свой вкус, если реализовать загрузку GUI-файла в эмуль также как и ROM-файлов.
Идентификатор не нужно повторять много раз. Он будет находиться в одном месте. Да и вызовов не требуется слишком много - при грамотной реализации алгоритма всё должно выглядеть компактно. Но разве у нас на счету каждый байт? Ведь в распоряжении GUIшки может быть вся память ZX, включая даже область ПЗУ!
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием