Raw source and immediate archive at
http://www.icculus.org/~phaethon/plan/Entries are currently sorted in: Newest First
Syntax (time and date in UTC, my local timezone is PST/PDT):
[YEAR].[MONTH].[DAY] <space> ~[APPROX. HOUR] <space> <space> [SUMMARY]
<empty line>
[CONTENT]
<empty line>
<empty line>
2003.06.19 ~10 Palm OS 5 and Linux
The Palm OS 5 Simulator is the primary tool supplied by PalmSource,
Inc., for debugging and testing Palm OS apps for Palm OS 5.
Most Palm OS 5 devices use a variant of the ARM CPU, a little-endian
CPU. Pre-OS5 devices primarily used a derivative of the Motorola 68xxx
family of CPUs, which are big-endian CPUs. To retain compatibility with
older apps, Palm OS 5 has a m68k sort-of-kind-of-emulator layer called
PACE (Palm Application Compatibility Environment). As I understand it,
PACE is more of a translation layer than emulation, but in any case, the
point of PACE is so that m68k-compiled PalmOS apps can run on the
ARM-based devices.
In any case, the Palm OS 5 Simulator isn't an emulator in the same sense
of the Palm OS Emulator (POSE). The Simulator, currently available only
only for MS-Windows, uses host-native code, instead of code targeting
for a particular Palm device. I'm not sure what the exact mechanics
are, but I'm assuming there's some sort of Palm OS 5 library targeted
for win32-x86 involved somewhere. I haven't bothered looking at, much
less downloading, the Simulator because of its current bigotry.
The end result is that I can't test nor debug ZBoxZ under Palm OS 5,
unless I get a Windows machine, which is not likely to happen. Another
option is trying to run WINE, but I munged up my WINE setup badly.
Lastly, plex86 or vmware, but those involve a Microsoft tax. An
expensive option is to cough up the cash for an actual Palm OS 5 device,
such as a Zire 71, one of the Tungstens, or a Sony CLIE with a camera.
Anyway, my primary bitch-and-whine is that I can't test for Palm OS 5
using a linux-based machine.
2003.05.18 ~06 Subtlety in TV ad for Microsoft Windows Server 2003
There's a TV ad for Windows Server 2003. The ad presents a party going
on at some office company, presumably because they saved money (as
hinted later). The ad focuses on a "manager type" asking a "techie
type" what's going on; the latter says something about moving over to
Windows Server 2003, reducing domains from hundreds to just four, this
and that, etc. In response to a blank look, the "technie type" reduces
the explanation to "we're saving over 2 million dollars".
One thing I didn't understand about the ad is how a company buried under
a Microsoft lock-in can possibly spend 2 million dollars less, much less
a single buck. I take it for granted that once a company dedicates to
using Microsoft products, they're stuck in an endless loop of buy-more-
Microsoft-stuff (in the form of upgrades and "services", such as tech
support). The claim of saving money in the ad made even less sense to
me, since Microsoft, as a for-profit corporation, wouldn't want their
customers to spend less on their "products" and "services". Then I
received a flash of insight when I paid more attention to the term
"ActiveDirectory" mentioned in the commercial. But, of course... LDAP
wasn't MSIE-style-integrated into prior versions of Windows, so
third-party providers of LDAP flourished.
Then the ad started making sense. Microsoft wasn't promoting cutting
off a stream of revenues to themselves... they're promoting customers to
shunt the cash flow entirely over to Microsoft that otherwise would have
gone to Microsoft's partners and competitors. That's how the office
company portrayed in the ad would save $2M by going down to Windows
Server 2003. They cut off the n million dollars going to Microsoft's
partners and competitors, and give a portion of that cash to Microsoft
(boosting MS's own revenue at the expense of others). The expenditure
in the company's books would show a $2M reduction, Microsoft's books
would show a cash boost of some amount, and the books of Microsoft's
partners and competitors would show reduced revenues.
Devilishly clever. The wording in the ad, I mean.
2003.05.09 ~11 Patents, a moment of zen
US Patents System -- a non-market government instrumentation designed to
promote free-market competition by forbidding free-market competition.
2003.04.03 ~01 USB solid-state storage devices
Is it just me, or do those little USB solid-state storage mechanisms (those
small enough to hang on a keychain) eerily hint at Star Trek-style isolinear
chips?
On a related random thought, these things are small enough that, if they were
to be cheap enough, could be used as, say, business cards, the way shaped
mini-CDs can be used to hold business-card data. Or as a means of distributing
resumes. Flash the info to a solid-state device of a couple MB that's about
the size of a stick of gum, distribute. Recycle. etc.
2003.03.19 ~07 BAFO BF-120 IrDA<->USB dongle
So, I went to Fry's Electronics (in Manhattan Beach, the one with the
Hawaii theme -- coincidentally, also the smallest of the Fry's stores)
to get a new fuse to replace the one I blew in my multimeter (a cheap-o
one that only measures up to 250mA; I tested the current through two
full batteries in series (400mA) for a split second). This led to that,
and for the next few hours I kind roamed around the store floor looking
at this and that.
As I started to wind down on whatever hell this phenomenom is called (I
think it's the same one that induces women to wander for hours through
clothing stores without buying a single article), I finally stumbled
across the only IrDA-over-USB doohickey in the entire store. A BAFO
BF-120 IrDA dongle. It's a IrDA dongle that connects via USB, instead
of connectors on the mainboard that directly wire to IrDA controllers.
I basically bought the thing on impulse, with intent to use the existing
TV/VCR/cable/etc. remote controls we have at home to control my PC.
Should that fail, plan B is to use the IrDA for Palm syncing.
The BF-120 comes in three variants, apparently each with a different
IrDA chipset, if the packaged manual is any hint. The dongle has a
label on the flatter surface, towards the USB plug, that indicates the
particular Windows driver to install (so I assume the three different
labels indicate three different chipsets). A synthesis of information
from /proc and the web revealed that (a) if the label reads "V6102F",
it's a SigmaTel Ir4200 (STIr4200) chip, (b) there is no existing driver
in linux for the STIr4200 chip, (c) the full technical specs for the
STIr4200 (down to the physical packaging!) are available with little
fuss. These docs should suffice for writing a driver.
My options at this point were (A) return the doohickey and hunt for
another IrDA dongle, (B) wait for someone else to write the missing
drivers, (C) write the damned thing myself.
I was about to go with A when our dear local Mr. chunky mentioned he has
the same device. Bought at the same store. But at different times. I
switched over to option C, partly as a challenge. I printed out the
docs, and have been mulling over the 22 pages of it for 3 hours, at the
time of this writing.
If only I knew how to program Linux drivers...
It's learnin' time.
2003.03.18 ~10 OES UI
The last three (four?) days I worked on overhauling the ui system for
Orbital Eunuchs Sniper (
http://www.icculus.org/oes/). For one thing, I
was annoyed at the existing menus not working. Secondly, I wanted a
platform to prototype a ui for my q3 mod (the one done in Scheme).
Mainly because of the Scheme slant, I used S-expressions for storage
format. For quite a while, I knew of the existence of sfsexp
(
http://sexpr.sourceforge.net/), but didn't have much practice actually
using it. To cut my teeth on sexpr, I started on something smaller, the
preferences file in OES. The original preference format was binary, a
memory dump of a C struct. I'm a strong believer in the unixian way of
plain-text configuration files. As an added bonus, the preference file
only held four settings, so the preferences could be simplified into a
four-member association list. Reading would involve a simple one-level
traversal of the list, and then picking the pairs out of each member of
the list. This little exercise gave me a sufficiently half-clued idea
of how to use the sexpr data structs.
Afterwards, I took on the menus system. The initial idea was to
parallel the menu system in Q3TA, involving text files that describe the
initial state of the gui, then letting the system rip loose with a C
core. The first goal was to have the buttons react to the mouse, focus
and clicking. The first incarnation checked the mouse location every
time the screen was redrawn, checking if a button was in focus or not.
The ui system walked down the widgets heirarchy to propagate click
events, checking each widget's clickability, mouse location, and name to
react to mouse clicks. This method was really nasty, since button
actions were hard-coded according to their name, embedded in the ui
functions (broken encapsulation).
I think I went through four rewrites of the data structures for the
widgets. What I wanted in the data structure was a simplified
query/modify interface to widget properties. Initially, I wanted to
directly modify the sexp structs describing the widgets, in the form of
alists, but I couldn't quite figure out how to modify the structs
decently, either to add a key/value pair or to modify one. The data
structures I finally settled on involves a singly-linked list of structs
holding a key/value pair, which I found to be more easily modified than
the sexp structs. A couple of support functions translates the sexp
structs into the linked list.
After the buttons started reacting to clicks properly (starting game,
quitting, etc.), I worked on purifying the encapsulation of the ui
system. Namely, to separate the OES-specific data and actions from
ui.cpp. The goal was to make the ui system capable of being a drop-in
component into another project.
One interesting progress I notice in retrospect is my gravitation
towards a signals system as used in gtk+ and SWING, away from the
"cascading events" style. Initially I couldn't comprehend the signals
system, and partially as a result had a general distaste for it at
first. For one thing, I didn't like, and couldn't handle very well, the
notion of multiple paths to a widget (one via parenting heirarchy, and
one via signals, etc.). OTOH, what I found out is that using a signals
system greatly expanded the capabilty of the ui system. I don't know if
it's something intrinsic within the signals system or if it's a
"perspective" thing, like taking a different slice of The Whole General
Mishmash of widgets.
As a hack, the extent of signal-handling within the ui system itself is
emitting yet another signal. There is C instruction to handle signals
not understood by the widgets in the ui system. So, for example,
handling of the Escape key (which was added fairly late in development)
to backtrack through menus was done by connecting the toplevel (menu)
widget to the "esc" signal; the "esc" signal is generated by pressing
the Escape key (from the ui input handler); the toplevel widget re-emits
the signal "go-main" upon receiving "esc"; no widgets understand
"go-main", so this signal is handed off to the C handler, which does a
series a string checks to figure out what the signal is, then rearranges
menus accordingly (in the case of "go-main", bringing the menu named
"main" to the foreground).
This signals system is still better than recursively stepping through
child widgets and repeating events to all of them. For one thing,
signalling doesn't need to worry that some widget that doesn't
want/like/know an event won't stop the entire event-propagation loop.
For another, CPU cycles aren't wasted on widgets that don't care about a
particular signal.
The advantages of a signals system are probably common knowledge to
developers of ui systems, but I'm scribbling all this down for my own
future reference.
2003.03.13 ~04 Triseism - standalone Q3VM interpreter
http://www.icculus.org/triseism/Standalone Q3VM interpreter. Most of the workings of a stack-based
machine became clearer when I brushed up on Forth. And Forth didn't
make much sense until after I learned Lisp. After learning lisp, the
idiosyncrancies of python became understandable.
Q3VM sets aside 64KB total for stack. Forth uses two stacks. If Q3VM's
stack is split in two (which I'm not absolutely certain on, but makes
sense), to mirror the two Forth stacks, this gives a limit of 32KB for a
stack frame. This limit is enforced by q3lcc at compile time, and I've
always wondered why 32KB in particular. Looks like the run-time stack
is involved.
Some of the emulation techniques I borrowed from my experience on PHFC,
the CUSP emulator. And from hacking on q3asm, the opcodes were fairly
transparent. I created and compiled many very simple programs to see
the translations of C source into Q3VM asm.
The Q3VM syscalls are a bit of a zinger. For one, I can't possibly
implement ALL the syscalls -- this would basically lead to rewriting Q3.
The other problem is that Q3 has three sets of syscalls, one each for
game (server-side), cgame (client-side), and ui (client-side menus).
I'm thinking of using a dlopen() system to optionally load one set of
syscalls over another. Splitting off the syscalls package would also be
helpful in utilizing triseism as a general-purpose sandboxed VM.
The other problem I'm having is the mysterious two words allocated on
the (return) stack upon entering a procedure. Local storage starts
after these two words, so the two words are likely involved with the
return process.
I'm thinking of distilling triseism into a library. One of my
motivations for finishing this was an acquaintance's desire for being
able to load a .qvm in another app, as one would open a dll.
In other possibilities, since the opcodes of the Q3VM are now very
clear, it should be possible to compile Lisp directly to qvm bytecode,
bypassing any C translations or C compilation, i.e. foo.l -> foo.qvm.
Also, I'm certain gcc and the gnu toolchains to can be hacked to compile
directly to .qvm.
Implementing a dll system within Q3VM is doable, but would probably need
changes to the .qvm format. The current .qvm format discards the symbol
table, precluding any dynamic symbol resolution.
Since triseism is developed independently of Q3 proper, triseism isn't
bug-for-bug compatible with idsoftware's Q3VM. This means triseism may
not mimick every tiny detail of Q3VM down to the fiddling of bits.
Triseism may help in tracing an execution path through a Q3 mod, but
without debugging symbols, there isn't a simple way to link an
instruction location with its matching line of C source.
Life: No Life found.
Project:
1. Project FI, Quake 3 mod (
http://www.icculus.org/fi/)
a. provide an extensible environment for a Q3 mod. The intended notion is that of "mutators" in Unreal Tournament.
b. FI:WFC, a more faithful reproduction of Q2WF for Q3 than WFA.
2. QuakeScheme
* Extensible language for Project FI.
* Builds on TinySCHEME (
http://tinyscheme.sourceforge.net/)
* Deal with idiosyncrasies of Q3VM not handled by most other Scheme impls.
3. Q3VM libc
* Implementation of Standard C Library for Q3VM bytecode.
* Implementation of a subset of Single Unix Specification v2 (SUS v2).
* Help import third-party library into Q3VM.
4. QS GUI/widget set
a. Need to research advanced OO and GUI of Scheme derivatives and Common Lisp.
b. Replication/extension of boxy widgets in Q3TA (Q3 PR 1.27+).
c. Pie menus -- just to annoy theoddone33.
5. Q3 compilation toolchain
[X] q3lcc sources (official version out with Q3A SDK 1.32)
[X] q3asm - get static to work, dammit.
[ ] q3as - assemble-only (.asm to .o).
[ ] q3ld - link-only (.o/.a to .qvm).
5. PalmOS stuff
a. PiNGer (gfx viewer)
* generalize interface to a "any-gfx" viewer (libpnm?)
b. ZBoxZ (file manager)
* beef up its appness: menus, dialogs, pen actions
6. Blender development (
http://www.blender.org)