> I'm not familiar with the SA1110 architecture nor the Bitsy
> code, and I have a few questions about it.
The Bitsy is an SA1100, if I'm not mistaken. There's not a great
deal of difference between ARM processors. The bitsy has no
floating point, but there is a floating poiunt emulator in Plan 9.
> The SIMpad has an MQ200 video thing. There are a couple of
> drivers for it (in Linux and in NetBSD), but I'm not really sure
> what they need to replace. My question is: is screen.c the only
> part of bitsy that does graphics stuff?
Yes, screen.c is where we do the graphics on the bitsy.
xgscreen is the data structure representing the physical screen.
You paint a pixel by writing the video memory.
> If so, what would be the best way to handle the addition of the
> SIMpad code? Since it's based on the same architecture, it seems
> silly to make an entirely new directory with half the same files
> (if that can even be done).
You can start in the bitsy directory (renaming it `arm', perhaps).
There's a file called `bitsy' in that directory that describes what makes
a bitsy kernel. You should copy it into `simpad' and then modify
simpad as necessary, also copying and modifying other source
files. I'd first keep two versions of all files that are different and,
once everything works, see what can be done to reintegrate things
that are the same.
> The SIMpad has a UCB1300 controller for the touchscreen, sound
> and keyboard. As far as I know, there is no keyboard that you
> can get to put on the SIMpad. Might anybody have a clue where
> the code for this would go (and what the opensimpad people are
> referring to by keyboard)?
You can use the keyboard application on the bitsy to have a touchscreen
keyboard. /dev/kbdin gives you an interface to move characters
typed from user space back into the kernel.
> Speaking of keyboards, it should theoretically be possible to
> write a driver for a self-powered KB connecting via serial, no?
> I have a DB9 serial dongle for this thing, and I would REALLY
> like to not have to use the on-screen thing as it's a huge PITA.
> If anybody has suggestions on projects that have implemented
> this out of a regular PS/2, SUN, old Apple (from a Performa 630)
> or AT keyboard, I'd appreciate that as well :).
If there's a serial line, that's what you use for a keyboard initially.
You'll also use it for diagnostic output initially.
Good luck.
Sape
