Guide to sources

LCARS 24 is compiled with DJGPP and Allegro plus libraries 
for jpeg and gif. The jpeg and gif libraries are in the lib 
folder with this source package. Newer versions of Allegro 
have a compatibility problem with this version of the gif 
library. However, since there are numerous conflicts with 
the newer versions of Allegro and newer versions of DJGPP, 
one of which causes trouble with sound (there are fixes for 
most of the other problems), release versions of LCARS 24 are 
compiled with versions of DJGPP and Allegro that predate 
these troubles. This must be done on a DOS-only machine, 
not a Windows environment.

These are the zips for the version of DJGPP used here. 

gcc303b 
txi42b 
djdev203 
bnu2112b 
mak379b 
gdb521b 

These are not the versions shown at the current DJGPP Web 
site, but some are available here: 

GARR Network's Napoli FTP-archive
http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2gnu/

Also Goodie Domain Service:
http://gd.tuwien.ac.at/pc/dos/djgpp/deleted/v2gnu/?fisel=gG


In addition: 
DJGPP v. 2.03: <http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2/v2-pre-2002-08-04/dj*203.zip> (note the wildcard) 
gcc for DJGPP v. 3.0.3: <http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2gnu/gcc303b.zip> 
gcc README v. 3.0.3: <http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2gnu/readme-gcc-3.0.3.txt> 
GNU binutils v. 2.11.2: <http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2gnu/bnu2112b.zip> 

The version of Allegro to use is 4.0.2, just to be on the 
safe side. The DJGPP part of Allegro hasn't changed for the 
better in quite some time. 

Allegro 4.0.2: <https://sourceforge.net/project/showfiles.php?group_id=5665&package_id=5714&release_id=97945> 

This older version of Allegro builds and works smoothly with 
the above-mentioned DJGPP setup. The maintainer of 
Allegro has also said, however, that Allegro should not be 
compiled for DJGPP on a Windows machine unless in 
Pure DOS mode, that it can introduce bugs. 

If you use the latest versions of DJGPP and Allegro, for 
whatever purpose, there are problems compiling Allegro. One 
is that the following line is missing from the file 
graphics.c in the subfolder allegro\source:

extern void blit_end(void);

The above line should be added above the following line in that 
file: 

/* lock_bitmap:

If you do that and just ignore all the warnings as Allegro 
is compiling, there is a reasonable chance that it will 
complile and can be installed and used. If compiled 
under Windows XP, malfunctions will crop up later.  Use 
a DOS environment, not a Windows DOS box. With the setup I 
recommend above, the situation is totally different. It 
compiles and installs smoothly with no complaints, and some 
programs will be a fraction of the size they would be with 
the newer versions and work better. In fact, sound output 
with the newer setups is unacceptable, and the maintainers 
of Allegro offer no solution. Either way, do it in a DOS 
enviroment if you are using DJGPP. 

   The makefile MAKEFILE.GCC is for compiling LCARS 24 with 
DJGPP, with no instructions included for other platforms. 
The DOS batch file MK.BAT just issues the command for that, 
which you could type in directly if you prefer:  

   make -f makefile.gcc

   I normally just type MK and let the batch file execute the above.

   If you compile LCARS 24, you can run your compiled 
version (LCARS24.EXE) in your local folder if you have LCARS 
24 version 3.1 or higher installed on the machine. This is 
required, since there are many support files in that 
package, mainly fonts and images. Startup doesn't get very 
far if there are any font files missing; you get an error 
message supported by the two bulletproof (built-in) fonts 
Mars28 and Luna. 

LCARS 24 properly compiled will run from the local folder, 
as long as LCARS 24 is properly installed and runs on the 
machine. For a ThinkPad with 800 x 600 screen, type 800 to 
run the batch file 800.bat, which starts LCARS 24 with the 
argument 800, or type LCARS 24 800. This is because such 
machines have strange (cheap!) graphics cards that don't 
have the 1024 x 768 mode. 

Other platforms

I haven't gotten into MinGW (for Windows), Linux, or other 
UNIX yet. This might compile as a native Windows version 
with MinGW (with whatever changes to the makefile that 
requires). For Linux, etc. the file GETKEY.C would have to 
be rewritten to take key input from the Allegro keyboard 
functions or NCurses. The file I/O, as well as the gif and 
jpeg libraries (and perhaps the calls to their functions), 
and the directory references would have to be changed. The 
LCARS 24 DOS box might be inappropriate for a Linux/UNIX 
version and could be disconnected or redone for UNIX 
commands. Without getting into these versions myself, I 
don't know yet what other calls need to be changed. I have 
made all the time and date functions in conformity with 
Linux style. For setting the time or date, I think the user 
has to be logged in as root on any kind of UNIX system, and 
I haven't added functions to check for that and post a 
notice where necessary. 

The source files

A general listing of what is where is given below. Each file 
has an explanation at the top. Perhaps the easiest way to 
see how to make or adapt a program so that the LCARS 24 core 
takes care of the graphics is to back up then tinker with 
the file BMI.C, which sets up the most common type of LCARS 
screen and uses fonts of several sizes. The names of the 
LCARS colors are shown at the top of that file for your 
reference. You can try a few simple modifications, compile 
it with the same makefile, then run LCARS 24 in your local 
folder and launch the BMI program to see your changes. 

LCARS 24 is rather strange in a few ways other that the 
LCARS motif. For one thing, LCARS 24 and all its apps (not 
counting the background MIDI and MP3 players), have a total 
executable size on disk of less than that of one little 
Allegro program in the EXAMPLES folder of any of the newer 
versions of Allegro, at least, and all the LCARS apps start 
up instantly, even faster than those little examples could 
if on a RAM disk, which is normally as fast as possible. You 
can see from the makefile that they are all prelinked. 
Further examination reveals that apps don't have mains but 
mode names instead. 

   They are not only linked but avoid the high overhead of 
DJGPP, Allegro, and the LCARS 24 core. The main pays that 
high cover charge, and the rest get in free, paying for only 
what they actually consume, which is very little, since the 
core does most of the work, and there is code sharing even 
among apps. Also, an LCARS app doesn't burn up time setting 
the graphics mode. It's already set, and program launching 
is really nothing more than a normal screen change. Also, 
having more than one iteration of the same app open at one 
time is not supported. That's the Mac/Windows thing, but 
it's not an LCARS thing, at least not on a single computer. 
Files 24 may look like it's open in two places on the screen 
(tantamount to having two Explorer windows open side by 
side), but it's not. It always opens with the folder tree 
open twice side by side to facilitate moving, copying, etc. 
With Windows, it's common to open two 
Explorer/floppy/recycle windows and adjust their sizes and 
positions so you can drag and drop between them. Files 24, 
opens with that already done for you, but it's not the same 
program open twice on the screen at once. 

   Even with all that, it's not possible to have that much 
functionality in one chunk that loads so quickly and has 
such a small footprint on disk, right?  Well, it's 
compressed with UPX (the Linux kernel is usually set up the 
same way, needing to decompress at startup). 

   Okay, it's just one cheap trick after another, but the 
bottom line is that, regardless how much smoke-and-mirror 
methodology is required, LCARS programs are supposed to 
start instantly, regardless of what people are used to with 
mainstream software. Touch a key, and the screen changes 
before the key is fully pressed. So it's subversive, in a 
sense, giving the user a false sense of hope that mainstream 
software can eventually do the same. It could, with CPU and 
hard-disk access speed increased a thousandfold--or if 
priority were placed on quick response by any means 
necessary. Hello? Spam comes up instantly, doesn't it? So 
what about making things the user actually wants as 
efficient as spam, regardless of what programming 
methodology that requires. 

For example, if it really were impossible for a Web browser 
to start up in less than 30 seconds after a user clicked on 
a desktop icon, yet users demanded instant display with no 
excuses, then each slow-starting program could come with a 
PNG of its opening screen, which could be blitted up by the 
program launcher in the blink of an eye. It's a cheap trick, 
but just an example to illustrate that there are other ways 
of doing things if trimming the fat out of bloatware is too 
much to ask. 

   Game programmers have to go to extremes to make some 
functions smooth enough to be acceptable. Watch the stake in 
Ferengi Blackjack increase or decrease as you increase or 
decrease the size of your bet--especially when there are 
cards lying on top of it. It may look like magic, but any 
good game programmer could make that happen. What about 
regular application software? Does it answer to a lower 
standard? 

Even without future improvements in computers, operating 
systems and programming tools in this area, LCARS 24 will 
continue on the path of instant response, using other 
tricks, if that's that it takes. Starting with version 3.1, 
LCARS 24 supports SFML (Starfleet Markup Language) to 
renders a wide variety of LCARS screens. This is similar to 
yet quite different from HTML, and already offers some user 
interaction, yet is fast and smooth. 

External DOS apps

When the user launches an external DOS app, things are 
different. There can be none of this instant-on business. 
But LCARS 24 is still different in this regard. First, it 
generates an LCARS title screen for whatever DOS app you 
have installed, then it creates a batch file and exits. The 
title screen remains displayed until the DOS program loads, 
starts up, and takes over responsibility for screen 
displays. When that program exits, the next thing executed 
by the batch file is "LCARS 24 restart in progress" 
(directly to Standby mode without the startup intro). So in 
effect, LCARS 24 releases all but a few bytes of memory when 
launching a DOS program, just in case it's needed. Some DOS 
programs need that and wouldn't be able to run on some 
machines otherwise. Launching a memory-hog game or DOS-based 
Web browser as a child process would fail if the machine had 
only 32 megabytes of RAM. With this precaution taken as a 
kindness to the user, the downside is that LCARS 24 doesn't 
bounce back as quickly as it would if it remained loaded 
(launching the DOS program as a child process). But showing 
off has to take a back seat to making sure something works. 
In future versions, there may be special consideration for 
external LCARS programs, to allow them to start and later 
close without delay. 

Touch-screen and mouse support? 

The first comment people make is about touch-screen support. 
But I suspect what they really want is mouse support, since 
touch input is implemented through a mouse driver, and few 
people have touch-enabled displays anyway. But mouse input 
is just not appropriate for LCARS, even though you see it on 
Star Trek Web sites. In that regard, on any Web pages I 
make, the only click targets are text, never LCARS buttons 
or bracket sections. 

   Also, LCARS 24 is mainly intended for laptops, and 
normally you don't poke the screen of a laptop. Touch is 
more for a wall-mounted flat screen for use as a light 
switch, control panel for a microwave oven or washing 
machine, doorbell, etc. or perhaps a TV remote control built 
into the arm of an easy chair or coffee table, or even for 
control panels on the next-generation space shuttle--
whatever, in short, units that don't move when touched. When 
it's real and relevant, I have no problem with touch-screen 
input. 

   Finally, to the die-hards who still want touch but really 
intend to use a mouse for that function, I make the point 
that before adding touch support I would have to buy at 
least one touch-screen display and test the code to make 
sure that no functions are accidentally invoked without user 
intent because of mouse movement, considering a case in 
which a user by force of habit moves the mouse and clicks, 
even though no mouse cursor is displayed. The program would 
have to be tested an verified not to misinterpret that as 
touch-screen input. Sure, I could do that just to be able to 
say that LCARS 24 supports touch, but hardly anyone would 
really buy a touch-screen panel, etc. for this. 

Proper coding? 
Nah! The priority is program performance. It started out for 
personal use, not open source or a school project. The code 
itself is undergoing constant clean-up, and I won't make any 
claims about coding elegance.  Its use of arrays adds to the 
hotrod performance, but is generally frowned upon. Structs, 
linked lists, and other niceties are few and far between. 
It's mostly just mass quantities of simple code. But at 
least it's neat and legible and makes some sense at a 
glance. 

What is where 
Some of the following might not mean much unless you've 
tried out the various functions and apps of LCARS 24. The 
scalable font that displays the time is called Mars28. It 
can be used in size 2 up to sizes too big to fit a single 
character on the screen, in units of 28 pixels in height, 
always in an LCARS color on a black background. A memory 
bitmap (solid black) is created in the size of output, the 
Mars28 string is drawn to the bitmap, then the bitmap is 
blitted to the screen. The change is visually smooth, as you 
can see with the clock numerals, and the program need not 
erase the previous display. Most of the other fonts support 
buffered output, as well, to allow use of LCARS fonts 
instead of TrueType with HTML output. The 14-point font used 
for labeling is called Luna. Others are pretty much named 
according to size. Calls to an old font called Scorpio 
appear in the code, but they are now implemented by a newer 
font of the same size. 

Core
Some defines and globals: lcars24.h
Antialiased fonts: mars24.c, headline.c, parts.c
Plain bitmapped fonts: mapfonts.c, winfont.c 
Graphic objects: cropcirc.c, brack1.c, elbows.c, parts.c
Graphics mode: grset.c 
LCARS colors: lccolor.c 
Keyboard: getkey.c
Screenshots: scrnshot.c 
Error messages: errmsg.c 
File loading, saving: textio.c
Buffered copying: copyfile.c
Doc display: lcreader.c, help.c 
Roman numerals: roman.c 
Stardate: stardate.c 
Voice and beeps: playwav.c 
Gif animation: gifview.c 

Standby mode (clock & calendar, math & DOS service, program 
launching, library, settings, all alarm modes and Glow 
mode, Image Scroll, and Image Zoom): main.c, standby.c, pickboth.c,  

File manager: files24a.c, files24b.c 
System info: sysinfo.c 
HTML & SFML support: htmload.c, htmproc.c, htmview.c, sfmview.c 
MIDI & MP3 support: binaries with the LCARS 24 package (code 
not included here)
JPEG: jpeg.h (libary also supplied) 
GIF: gif.h   (libary also supplied [plus alternate for 
versions of Allegro where there is conflict])
Math formula parser & solver: matheng.c 

Apps
Chess: chess24.c, rand.c, hash.c, book.c, eval.c, moves.c, 
       search.c, utils.c 
Card games: cards.c, borg.c, blackjak.c
Text editors: filemenu.c, text24.c, phone.c, progedit.c 
World map: mapdata.c, mapfonts.c, worldmap.c 
World time: timezone.c
BMI (a medical app): bmi.c 
Unit conversion: convert.c
Crossword: crosswrd.c 
Tic-tac-toe: warbird.c, wb3.c, wb5.c
View360: view360.c
Planet sim: planets.c
Gates: gates.c 
Starfleet: starship.c 
Periodic table: periodic.c 
HTML: htmload.c, htmproc.c, htmview.c
SFML: sfmview.c
Program editor: progedit.c
(Many others. Briefing is a Powepoint clone in LCARS style.) 

A comprehensive screenshot gallery can be viewed at lcars24.com. 

Bill Morris 
lcarsuser@yahoo.com

Comments? Bug reports? Feature requests? 
There are places for those on the LCARS 24 project page 
at SourceForge. There are public forums, and anyone may report a 
bug or make a feature request. 

June 24, 2010

