Development Tools

The Cybiko computer

Computer magazines present information about computers in a predictable fashion. Chances are, there is a table with processor, ROM, RAM, mass storage columns, then some other columns, then, of course, price. Presented that way, Cybiko's specifications will probably make you think were a throwback to the old days of Personal Computers. Indeed, Cybiko computer has 512k of RAM, 512k of flash memory, a 11-MHz processor, and a 4-color LCD display with 160x100 pixel resolution. You have to understand that Cybiko is not like other computers. Cybiko is a pocket-size, handheld, wireless computer. Two-way wireless communication is built into the design. The aim of this manual is to reveal the programming details to get you started writing applications for Cybiko computer so you can harness its unique features. This manual will explain what it takes to write your first "Hello, World!" program, what it takes to get the most out of the 11-Mhz processor, and what it takes to stuff your 1-megabyte masterpiece into our modest 512k.

Hardware specifications

Main Processor:	32 bit, 11 MHz Hitachi H8S/2246
Coprocessor:	Atmel AT90S2313, 4 MHz
RAM:	512 KB
Flash disk:	512 KB, extendible up to 1 MB
LCD display:	160x100 dots, 59x40 mm, 4 level grayscale
RF transceiver:	RF2915
Expansion cartridge slot:	68-pin
PC connection socket:	RS232 serial port
Size:	5.7" x 2.8" x 0.86"
Weight:	4.3 oz

Features and figures

If you've programmed a wide range of computers (that is, not just PCs) then you probably can point out a counterpart of almost each and every feature of Cybiko^TM computers (with the exception of the wireless connection and the very way computers communicate). But Cybiko, and programming for Cybiko, is unique. Highlights include:

Simple and reliable wireless communication between computers. E.g., what does it take to send a data buffer from within some application to an (probably different) application on a different computer. It is as simple as calling one API function. Usually, there is no need to "initialize" some API, or to even "poll" or "enumerate" available computers; there is an easily and instantly accessible application called Finder which monitors available Cybiko computers in the vicinity, collects all necessary information (such as gender, habits, etc.) about them, and even sorts them out in the order set by the Cybiko computer owner. The reason behind this is simple: when a programmer requests the ID of the first computer in the Finder's list, he/she gets the ID of the computer most attractive to the owner of the local Cybiko computer! When sending a message, you do not need to reserve a special field for the sender ID, or invent your own way of guaranteed message delivery - all these goodies are already there!

The Cybiko operating system, CyOS, uses preemptive multitasking. Applications are, however, message-driven (much like in MS Windows), and CyOS keeps track of the time an application spends processing each message, and may even kill hung applications. It's important to keep in mind that there are other processes running concurrently with yours, and they consume system resources too. CyOS supports two types of modules: applications and dynamic libraries (compressed archives containing these modules have .app and .dl extensions, respectively). Both applications and dynamic libraries can export and import data and functions, and support both early and late binding. Module resources are also accessible to other modules via the part of the CyOS API that handles compressed archives.

Currently, Cybiko is built around the 11-MHz Hitachi H8S processor. It's a 32-bit processor and is, in many respects, more like the Motorola 68k than the Intel 80386. Importantly, it works in BE (Big-Endian) byte order mode and its register and instruction sets also bear some resemblance to those of the 68k. Although addressing is essentially 32-bit, actual address space is 24-bit, like in early 68k models. Since development is being done on PCs (and this is where most data files are being prepared also), you do have to take BE endianness into account. Moreover, this is not the only challenge - the H8S is physically unable to address a word located at an odd address.

As for processor performance, I would say you have more power than a 11-MHz 80386. Perhaps much more power. The key is instruction timing. While tinkering with an application, we were trying (really hard) to rework a little piece of code that used division (the infamous CPU time consumer). We did not succeed and, before giving up, looked at the H8S manual to see what would be the price of our failure good heavens, only 12 cycles! We could not believe it since that was the timing we were accustomed to with the 8-bit bus (more on this a bit later). The Hitachi's instruction timing is excellent: almost all arithmetic instructions take 1 cycle, multiplication 3 or 4, and division 12 or 20 cycles. Note that almost all instructions take 1 cycle longer if operating upon signed operands. Accessing data stored in RAM implies an overhead (more on this below).

On the other hand, there is no such thing as 32-bit multiplication or division; the constraints are the same as with Intel 8086 and 80286 processors, i.e. you can have a 32-bit product (but not multiplier), or use a 32-bit dividend (but not divisor). Of course, in C/C++ code, you may do whatever you want, but the compiler could then unroll some particularly optimistic operators into sequences of 16-bit multiplications or divisions. The H8S has eight 32-bit General Registers, also accessible as either 16 16-bit, or 16 8-bit registers. 32-bit registers can be used as either data or address registers.

Finally, the heart of the SDK is its C compiler, capable of producing very tight, and quite effective, code. The unique feature of the underlying virtual machine is its ability to operate upon registers (vs. "top of stack" for virtually any other vm, including that of Java^TM); this adds significant gain to overall performance. You may learn more about the Cybiko bytecode interpreter, as well as about the C compiler (that produces respectable code), in other sections of the manual.

Conclusion

The above described features could be summarized as follows:

We never experienced real problems with computer performance. Some tasks required clever programming, or reworking the algorithm (at most), but nothing was dropped due to performance issues. Cylandia runs its countless algorithms as methods compiled into bytecode (that is, it is made with this same SDK!) and it never hits its performance limit - we were even able to boost computation speed 10x when we were emulating "accelerated" gameplay.

We did experience problems with memory - but only in Cylandia, with its countless bitmaps, animations and cut scenes. "Normal" applications should not suffer like that.

Different endianness and alignment rules are either things which you ignore or the things that cause potential headaches - you decide.

Development Tools

Table of contents