(Theoretical) PocketViewer OS

Table of Contents

1. PV OS

Ideas for a self-hosting operating system for the Casio PocketViewer series of PDAs ./casio pocket viewer.html

Package CollapseOS as a stock PV OS app? Would be limited to a single memory segment, which is 16 bits of address space. 216 = 210*26 = 64KiB That's exactly half of RAM. There is also 2MiB of storage, but it really does not like repeated writes and is not user replaceable, so swap is out of the question.

App memory segments on PV OS: 8K stack 20K+32K data The rest is various system managed stuff. If staying in high segment then only the 8K stack and 20K data are addressable, the 32K one is all in the low segment. Definitely can't fit an optimizing compiler in that…

What about using RAM as a cache for ROM? Okay… that might work but let's not overcomplicate it for now… Let's just wrap CollapseOS as a standard C SDK app.

Actually, there is another route: building on the existing Contiki port. Or porting RTEMS. (Thanks Wim for the suggestions!)

Storage is an interesting issue. There are various embedded flash friendly file systems we could use or base our design on. Or it could be block based like in cOS. Or it could be object based… Considerations: execute in place (XIP): this could seriously expand available RAM recovery: if a write fails it should not be catastrophic longevity: level out wear (see F2FS for hot vs cold storage) compression: possibly conflicts with XIP and recovery but makes better use of storage

There is an interesting possibility to implement virtual memory in software: instead of passing around pointers, wrap them in some kind of accessor. It results in an extra function call if evaluated naively, but if the accessor is known, it can be inlined. This has the potential of cutting down code size and allowing for some interesting unification of storage and memory. Ah but wait, what about DMA?

Some example uses: fragmented array: presents multiple arrays as a single array

Extended to maps: multi-level dictionary: words defined at the REPL live in RAM, "stock" words live in ROM writeback: commit finished words from RAM to "ROM"

A simple object system with interfaces could make for some interesting other combos, like writeback cache, etc.

Author: Csepp

Created: 2025-01-22 sze 04:15

Validate