|
you ask: > Do you favor a specific structure of hardware, OS code, and user scripts, or whatever ends up offering the best use of power and long-term device durability? well, i think it's critical for the zorzpad to be able to rebuild its own operating system code, because otherwise it's dependent on external computers to modify its own operating system, and the external computers might have become incompatible or untrustworthy at some point. this poses tricky problems of recovery from bad operating-system updates; probably having multiple redundant microcontrollers in the device is the best option, so that on bricking one of them, i can restore its old configuration using the other ideally, though, the core code capable of bricking it would be a small tcb, not everything that runs on the system the way it is in ms-dos or templeos. that kind of isolation is usually implemented with an mmu, but the apollo3 doesn't have an mmu, just an mpu. so currently my plan is to implement it with a low-level virtual machine instead; initially an interpreter (my prototype seems to have about 10× interpretive overhead, but probably providing a small number of extra primitives will be adequate to eliminate the worst hotspots from things like updating the display and digital signal processing) but maybe later a simple jit compiler. like most microcontrollers, the apollo3's memory/throughput quotient comes to about a millisecond, rather than the second or so that has been typical for human-interactive computation for the last 60 years, so i suspect i'll be leaning pretty hard to the side of sacrificing speed to reduce memory usage in addition to providing the protection needed to write experimental code without risk of bricking the machine, the virtual machine can also provide services like virtual memory (including compressed ram), transactional concurrency, and transparent persistence the nand flash chips i'm using (s34ms01g2) are supposed to consume 27 milliwatts when running, but their power budget at the nominal 1-milliwatt full power is only 300 microwatts. at full speed they're capable of 133 megabytes per second, so at 300 microwatts they might be capable of 1.5 megabytes per second. i can't write to them nearly that fast without wearing them out early, but i can load data from them that fast. in particular that means that the 24 kilobytes of a full screen can be loaded from flash every 16 milliseconds, so you can do 60fps video from flash. reloading all 384k of ram, for example to switch to a completely different workspace, would take a quarter of a second. i feel like this is enough of a quantitative difference from the speed of floppy disks on a commodore 64 or a macintosh 128 that it becomes a qualitative difference, and for applications like the spell corrector example i gave in the other comment, it might be possible to use the flash almost as if it were ram, using the ram as a cache of what's in the flash but maybe when i gain more experience with the hardware, all that stuff will turn out to have been the wrong approach, and i'll have to go with something else |