F21 in a Mouse

Tiny GUI Demo

I took an old computer mouse and removed the circuit board that used a common garden variety 68HC05 microcontroller. I replaced the microcontroller with a small F21d test board. I made a small cable to connect to the mouse wheel encoder and buttons and connected it to the F21 parallel port. I programmed the video coprocessor to generate 768x482 RGB images and I wrote a short test program to read the encoder and display the data while I moved it. Then wrote a driver to read the mouse hardware on the parallel port and control a tiny GUI. I setup a desktop with an icon of a osciloscope and made it launch a simulated osciloscope demo program. A number of times it has been mistaken for PC running Windows (tm) until I point out that there is no PC, just a mouse and a computer monitor or TV.

Below is an animated gif that uses and early version of the images displayed by the F21 in a mouse. The images are 768x482x16 RGB images. An arrow sprite is controled by a program that reads the mouse encoders on the F21 parallel port. On the real program on the desktop one can launch a demo of a simulated virtual lab instrument. The current demo has three active controls in the application. One starts an animation of the device display and the other closes the program and returns to the desktop. The total code on F21 to do this is a few hundred words.

This demo uses a minimal GUI consisting of a zero button mouse controling a window pointer. The code consists of an arrow sprite, graphics bit block transfer, and a simple event handler. Event list entries contain two words which designate corners of a region of a window in which events will be processed. Event list entries also contain a word to designate event type and word containg the execution vector with the code associated with events of a given type in a given region. There is also a small amount of boot code and code to initialize coprocessors. The graphics images are not compressed so are quite large but there is about 600 words of total code in the system and so with a million words of memory it could hold a lot more applications on the desktop.

The addition of code to support a variety of logical bit block transfer primitives, rich text support with a bold, italic, underlined, color, different fonts, reverse text, transparent text, window open and close, window position and size, line, fill, and pixel functions with a multitasking interface also is about 1K of object code. So a complete GUI need only a couple of K of code. Perhaps it could be made smaller if that were important. For higher performance many of the GUI routines can have their inner loops unrolled and inlined to eliminate inner loop instruction overhead and the whole GUI is still only a couple of K of code. For highest performance the GUI CPU must manipulate the video coprocesor code to make it perform windowing functions.

At some time I would like to do an extensive set of comparitive tests of window funtions including window scroll, window repaint, window relayer, window minimize, window maximize, etc. These are functions that can be easily offloaded to the video coprocessor on F21 so that they become extremely fast and are very simple to do from the point of view of the CPU.

I did do a comparison of one of the GUI functions, a scroll window function test in a 640x480 pixel window. I ran tests on a 120Mhz Pentium PC running Forths for DOS and Windows and on the F21d prototype chips. I include the numbers that the simulator gives for performance for an F21 prototype chip with the current memory interface but with the thermal fix allowing fully packed code to run and for a proposed F21e prototype with an SDRAM interface.

If I use a Forth for Windows as the relative index of 1.0 (bigger numbers mean faster than a 120MHz Pentium running Forth for Windows 95) the results are pretty much what was expected. On the PC Forths that use a DOS/BIOS interface can scroll a 640x480 pixel display 5 times faster than the Forths that use the Windows API so get an index of 5. By using a more direct hardware interface to the screen interface rather than using BIOS the index for FPC goes up to 7.

The F21d running DRAM only and with the video coprocessor programmed to generate a simple bit mapped video display where the CPU does all the windowing functions in software the numbers were pretty low. This is partly because when generting high resolution video out of DRAM with no SRAM on the card the memory bandwidth is very limited. It is also because the thermal bug on F21d requires that a lot of the instructions be no-ops, no operation instructions. The relative index was only 0.4. That is only four tenths as fast as the 120MHz Pentium running Windows 95, about like a 50MHz Pentium.

The projection for an F21 chip with the current memory interface but with the thermal bug fix in place has an index of 2, and the projection for an F21 chip with an SDRAM interface is 9. However what is interesting are the measured numbers and projections seen when using the video coprocessor to perform the windows function. Rather than moving large arrays of pixels the functions now require a few modifications to the video coprocessors instructions. The F21d (with thermal bug) was measured as an index of 20. When using the video coprocessor this way F21d performed like a 2.4Giga hertz Pentium running Windows. The projection for a chip with the the thermal fix is about 100, and the projection for an SDRAM version is 450, that's 450 times faster than my 120Mhz Pentium Windows 95 performance.

3/8/2000
Jeff Fox