>Paul, another thing I noticed somewhere: Wasn't there a preliminary
>unfinished support for 16/24/32 bpp graphics in NewtOS 2.1?
Not sure. The 32bpp functions I'm thinking of immediatly pack the
result to a smaller size. But this isn't really the issue. Bitmaps
are designed for up to 256 levels.
>Another thing that I think could cause headaches is the endianess problem,
>if a big endian emulator needs to be written. I thought that all newer
>StrongARM CPUs still feature support for both big and little endian
>operation mode. Wouldn't this make the endianess wrapper obsolete?
>Another point would be: How to implement the drivers? Using a minimal
>embedded Linux Kernel as low-level OS to wrap system calls coming from the
>PlatformDriver interface to the devices using some sort of "glue-code"? I
>think this would add additional overhead not really needed and would
>possibly sacrifice performance and memory usage. Porting existing drivers
>from Linux/NetBSD et al. to this new structure would make more sense to keep
>memory usage as low as possible, though this will also add additional amount
>of time.
Another issue is that NewtonOS needs the MMU and interruptions. But
so does MacOS and it runs in MacOnLinux.
I think that indeed an underlying big-endian unix (preferrably a BSD
as far as I'm concerned) is the way to go. And we could then shortcut
some NewtonOS functions and plug them to the unix equivalent.
The interest here is that the structure could evolve and we'd get
support for things such as xpdf. Plus PDAs today are so powerful that
the memory or processor overhead will not be noticeable as long as
code is executed natively.
Writing drivers from scratch (or porting them) is more work as you
say. Testing them will be a complete headache.
Paul
-- NPDS: http://newton.kallisys.net:8080/ Apache: http://www.kallisys.com/-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries List FAQ/Etiquette/Terms: http://www.newtontalk.net/faq.html Official Newton FAQ: http://www.chuma.org/newton/faq/
This archive was generated by hypermail 2.1.2 : Wed Jan 01 2003 - 10:01:50 EST