Закон о защите прав потребителей допускает как «дефолтный гарантийный срок», если товар приобретался без дополнительных условий, так и возможность его изменения по договору между продавцом и покупателем.
ну мы (не для игр) ставим флешку на 4 мегабайта, циклическая перезапись — итого можно записать 400 гигабайт.
если писать по несколько килобайт на игру (а что там больше писать?) — хватит и на сотню миллионов игр.
Если не брать в расчет совсем уж игрушечный Palm Zire
эээ… я про модели ДО palmos5.
мы под свои проекты брали sony sj20, цена была порядка сотни долларов. даже на сотне устройств разница в бюджете была более, чем ощутимая.
а что пошло дальше с palmos5 — я уже писал своё мнение, извращение. но совместимость, совместимость, совместимость.
Банальный текст, в случае обычного файла с последовательным доступом, вы просто добавляете в конец файла. Здесь вы должны считать запись, проверить, что «запись + новый текст < 64K» если меньше, то сохранить запись. Если не меньше, то добить до 64К, а остаток записать в новую запись.
Программирование, когда оно на 10% состоит из решения поставленной задачи, и на 90% из борьбы с ограничениями платформы, это отстой.
когда потребовались логи — сел и написал, пара десятков строк кода, наверное. ну чуть больше обвязки, чем на обычном open/write/close, но я бы не сказал, что на это ушло 90% времени, которое я кодил проект.
да и вообще, на кодинг ушло не так много времени, основные трудозатраты — проектирование UI (не реализация, а обдумывание «как оно может выглядеть», «как минимизировать число тапов при типичных действиях» и т.п.)
P.S. вот прямо сейчас занимаюсь хранением логов в nor flash. страницы по 4кб, erase/битовая запись, обработка ситуаций «а вдруг у нас внезапно отключили питание».
по сравнению с этим задача «сохранить текст в pdb» кажется вовсе смешной.
да, 32-битная платформа (при желании и 64-битная — обычные raspberry), тот же linux, что и на десктопе — а возиться с низкоуровневыми вещами приходится.
можно, конечно, плюнуть и хранить данные на sd-карте или usb-флешке, но опыт показывает, что ненадёжно. подключать внешние hdd/ssd? я уж лучше приделаю хранение данных в копеечной микрушке, оно и надёжнее, и удобнее.
Хотите хранить что-то больше 64К или просто данные переменной длины, или работать с текстом — ухищряйтесь, боритесь с системой, мучайтесь :)
а в чём проблема хранить данные переменной длины? или текст?
одно ограничение — запись не может быть больше 64кб.
б) PocketPC, существовавшие в это же время, вам могли предложить, опять же таки, и файловую систему, и embedded СУБД SQL Server Compact, которая вообще была полноценным SQL-движком со всеми плюшками.
только:
a. цена была несколько другая;
b. автономность тоже была несколько другая.
вы сравниваете железки разных классов. если мне не изменяет память, то palm продавало свои железки как «organizer», а pocketpc позиционировался как носимый компьютер.
«Полноценный эмулятор» был у всех — но поведение на реальном устройстве всегда отличалось. Помню веселые времена, когда printf("%i"); (или что-то подобное) спокойно работал в эмуляторе PocketPC, но падал безо всяких сообщений на реальном устройстве.
вам не кажется, что вы сами себе противоречите?
вот именно, что винды ЕМНИП была альтернативная реализация платформы, отличающаяся от реального устройства.
а у palmos честный эмулятор, который полностью эмулировал конкретное устройство, вплоть до того, что (как я уже писал) эмулятор использовал «родную» прошивку с устройства.
просто сообщаю что на фоне основного конкурента это была ужасная для программиста платформа — то, что делалось на PocketPC щелчком пальцев, на палме приходилось героически преодолевать.
всё-таки не могу с вами согласиться. это не «ужасная для программиста платформа», а вы выбрали железо, не подходящее для задачи (грубо говоря, сели писать многопоточный web-сервер для arduino).
а мне нравилось писать под palmos, как раз во времена m68k, обделённым я себя не чувствовал.
тулчейн есть? да, стандартный gcc.
API описано? очень качественно, плюс потом исходники заметной части OS появились, заглядывал в них — всё просто.
ограничения памяти — так проц-то 16-разрядный, что вы хотите. с другой стороны, это карманная записная книжка, зачем там мегабайты? идея состояла в том, чтобы сделать недорогое устройство с хорошей автономностью — это вполне удалось.
да, файлов нет — вместо них несколько другая абстракция (не набор байт, а набор записей). всё хранится в памяти, если программист специально не извращался, то приложения запускались моментально.
дебаг прямо на устройстве — это божественно после полноценного эмулятора от palmos?!? (полная виртуализая, даже ROM с реальной железки, ЕМНИП, плюс плюшки для разработчиков, связанные с отладкой — от возможности подцепиться gdb, до «гремлинов», которые тестировали UI, совершая беспорядочные действия).
а вот с palmos5 у них не вышел каменный цветок.
эмуляция m68k на arm, эмуляция старого API доступа к DB поверх NVFS (ох, сколько времени у меня ушло на вылавливание и обход глюков), попытка к старому API приделать web, мультимедию и т.п.
похоже, это был временный/переходной вариант, но пока разрабатывали идеологически верный (наверное) palmos6 поезд ушёл…
на каком основании? не думаю, что отказ в гарантии пройдёт проверку судом.
зато стоят копейки, linux обычно ставится без проблем, куча ethernet, часто есть usb-host.
если писать по несколько килобайт на игру (а что там больше писать?) — хватит и на сотню миллионов игр.
Palm OS 4.0 Limited Sources
вроде бы были выложены куски и более старых версий, но не нашлось сходу, увы.
эээ… я про модели ДО palmos5.
мы под свои проекты брали sony sj20, цена была порядка сотни долларов. даже на сотне устройств разница в бюджете была более, чем ощутимая.
а что пошло дальше с palmos5 — я уже писал своё мнение, извращение. но совместимость, совместимость, совместимость.
когда потребовались логи — сел и написал, пара десятков строк кода, наверное. ну чуть больше обвязки, чем на обычном open/write/close, но я бы не сказал, что на это ушло 90% времени, которое я кодил проект.
да и вообще, на кодинг ушло не так много времени, основные трудозатраты — проектирование UI (не реализация, а обдумывание «как оно может выглядеть», «как минимизировать число тапов при типичных действиях» и т.п.)
P.S. вот прямо сейчас занимаюсь хранением логов в nor flash. страницы по 4кб, erase/битовая запись, обработка ситуаций «а вдруг у нас внезапно отключили питание».
по сравнению с этим задача «сохранить текст в pdb» кажется вовсе смешной.
да, 32-битная платформа (при желании и 64-битная — обычные raspberry), тот же linux, что и на десктопе — а возиться с низкоуровневыми вещами приходится.
можно, конечно, плюнуть и хранить данные на sd-карте или usb-флешке, но опыт показывает, что ненадёжно. подключать внешние hdd/ssd? я уж лучше приделаю хранение данных в копеечной микрушке, оно и надёжнее, и удобнее.
а в чём проблема хранить данные переменной длины? или текст?
одно ограничение — запись не может быть больше 64кб.
только:
a. цена была несколько другая;
b. автономность тоже была несколько другая.
вы сравниваете железки разных классов. если мне не изменяет память, то palm продавало свои железки как «organizer», а pocketpc позиционировался как носимый компьютер.
вам не кажется, что вы сами себе противоречите?
вот именно, что винды ЕМНИП была альтернативная реализация платформы, отличающаяся от реального устройства.
а у palmos честный эмулятор, который полностью эмулировал конкретное устройство, вплоть до того, что (как я уже писал) эмулятор использовал «родную» прошивку с устройства.
всё-таки не могу с вами согласиться. это не «ужасная для программиста платформа», а вы выбрали железо, не подходящее для задачи (грубо говоря, сели писать многопоточный web-сервер для arduino).
тулчейн есть? да, стандартный gcc.
API описано? очень качественно, плюс потом исходники заметной части OS появились, заглядывал в них — всё просто.
ограничения памяти — так проц-то 16-разрядный, что вы хотите. с другой стороны, это карманная записная книжка, зачем там мегабайты? идея состояла в том, чтобы сделать недорогое устройство с хорошей автономностью — это вполне удалось.
да, файлов нет — вместо них несколько другая абстракция (не набор байт, а набор записей). всё хранится в памяти, если программист специально не извращался, то приложения запускались моментально.
дебаг прямо на устройстве — это божественно после полноценного эмулятора от palmos?!? (полная виртуализая, даже ROM с реальной железки, ЕМНИП, плюс плюшки для разработчиков, связанные с отладкой — от возможности подцепиться gdb, до «гремлинов», которые тестировали UI, совершая беспорядочные действия).
а вот с palmos5 у них не вышел каменный цветок.
эмуляция m68k на arm, эмуляция старого API доступа к DB поверх NVFS (ох, сколько времени у меня ушло на вылавливание и обход глюков), попытка к старому API приделать web, мультимедию и т.п.
похоже, это был временный/переходной вариант, но пока разрабатывали идеологически верный (наверное) palmos6 поезд ушёл…