/**[Palantr]************************************************[Issue #1]**/



                                                         
                                                         
                                                             
                                                             
                                                            
                                       
                                                     
                              
                                                 finrod            
               The DemOS Project Newsletter                       
             Released: 29/12-1995     Issue #1               
                                                     


  Your favourite editor is of course Beren of Ewox and comments are
  welcome at beren@infolink.no



/************************************************************************/

It begins right now. It's an opportunity to create the future. It's the
right way of kicking Bill Gates' butt! >:-D It's what we've all been
longing for. And all it requires is a bit of coding, a bit of co-operation
and some fancy ideas. An operating system (OS) made for running and making
Demos. Coders Rejoice! All the system resources will be at your feet!

/**[Contents]************************************************************/

  1. What is this?
  1.1 General info
  1.2 Dist sites
  1.3 Related information

  2. Background
  2.1.1 Why not DOS
  2.1.2 Why not Windows 95
  2.1.3 Why not Linux?
  2.2 The thought about a new OS
  2.3 The initiative

  3. About the OS
  3.1  Hardware requirements
  3.2  The kernel
  3.3  I/O
  3.4  Multitasking
  3.5  Video support
  3.6  Sound support
  3.7  The file system
  3.8  Shells
  3.9  Programming aids

  4. Joining the project
  4.1 Who do we need?
  4.2 How do I join?
  4.3 What privileges do I get by joining?
  4.4 *GRAPHICIAN* *NEEDED*

  5. Misc.
  5.1 Music
  5.2 Graphics

  6. Creating demos and programs for DemOS
  6.1 Is all my prior programming experience wasted?
  6.2 Programming concepts

  7. Closing words

/**[End of Contents]*****************************************************/

/**[1]******[What is this?]*************************************[Beren]**/
/**[1.1]****[General info]***********************************************/

Palantr is a newsletter which will be released on monthly basis. Its
purpose is to keep you up to date about The DemOS Project.

The DemOS will be a new Operating System which has only one main purpose:
To run demos at the best performance possible at your home computer. As
much of the computer resources as possible are laid at the coders feet.
The only limit is your computer and your imagination.

/**[1.2]****[Dist sites]************************************************/

Palantr is distributed at the following sites, groups and BBS'es:

http://www.ifi.uio.no/~dag-erli/DemOS/newsltr.htm

news://comp.sys.ibm.pc.demos

Doriath BBS (Ewox WHQ)     (+47) 22491249
Infolink BBS               (+47) 22571600 / (+47) 22571604

It will be distributed through ftp.cdrom.com within a few weeks.

/**[1.3]****[Related information]****************************************/

[subscription information will be released at later occasion]

/**[2]******[Background]*************************************************/
/**[2.1.1]****[Why not DOS]*************************************[Beren]**/

Why not DOS? The reasons are many. First of all, DOS uses BIOS calls for
whatever it needs to be done. This slows down the overall performance.
Secondly, DOS works with 16-bits programs. 16 bits? That's 286 talk!!! We
want our demos to be pure 32-bits, don't we? Most scene dudes use a 486
DX33 or better anyway. No need to stay behind! Okay, many demos nowadays
tend to use DOS Extenders, but this isn't really as good as it ought to
be. Especially when you have memory managers going in the background which
already have put the computer in some crazy mode. Thirdly, DOS uses FAT on
both floppies and harddrives. Do you realise how much space this wastes?
And FAT gives you the 8+3 filename headache! No, give me a decent
file system!

/**[2.1.2]****[Windows 95?]*************************************[Beren]**/

Why not Windows 95? First of all, Windows 95 lays on top of DOS. They had
to change DOS somewhat to make it VFAT compatible and let them take more
control of your machine, a control which Windows 95 doesn't give you back.
Think of Windows 95 as a bad kind of Bilbo and the democoder is Gollum
(the character, not the group) 'Thief, thief! We hates it!' ;-)
  Secondly, the VFAT system is a rather poor system. Ever tried to copy
VFAT files with a program that does only know FAT? There you've got a
fucked up system!
  Thirdly, as I said, Windows 95 doesn't give you back the control, WHAT
SO EVER! When you want to use a graphical routine, you'll have to go to
some DLL and ask it to be so kind and fulfil your wish. Then it goes and
checks if it's OK by the driver, the system and every other application.
If nothing sais no, it gives in and grants you your wish. But by the time
it sais OK, you've already lost three frames if you've got a rather quick
PC.

Why not Linux? Hey, I'm sick and tired of all these why nots. Finrod,
take this one. I've got some Coke to drink! :-)

/**[2.1.3]**[Why not Linux? or: My Early Childhood]************[Finrod]**/

Well, once when I was about half the height of this gun, my dad took me on
his lap and he said, son, one day you're gonna be a coder. And you're
gonna make demos. And son, I want you to know that Linux is not an OS to
write demos in! So promise me that you'll never, ever write a demo under
Linux. And as the obedient son that I was (but that was way back. Now I'm
not quite sure what "obedient" means, it just *looks* good if you know
what I mean.) So anyway, Dave - sorry, *Jimmy* - Letterman's top ten
reasons not to use Linux for demos:

10. Finrod's dad told him so when he was a kid.
 9. Linus forgot to greet Future Crew in the man pages.
 8. Bad run-time capabilities.
 7. Too many background processes.
 6. To strong OS, applications can't take total control.
 5. Need to individually request permission to use each I/O port you need.
 4. Don't pretend you like that Bell Labs ASM syntax: movl 12(%esp),%ecx
 3. Too well documented. Scene coders can't think properly with too much
    documentation around.
 2. cd /usr/linux ; make config

And the number one reason not to use Linux for demos:

 1. It's already written. Why should we use an OS we don't have to write
    ourselves? Get a life.

/**[2.2]****[The thought about a new OS]************************[Beren]**/

This is not at all a new idea. The Amiga used to boot from floppies. Most
games ran without OS. This was of course to use the computer best for the
games needs. In comp.sys.ibm.pc.demos, most people agreed that it was a
good idea to have an OS to run demos under, but that was it. And I was to
impatient to wait for an OS. If every single group was to make their own
OS'es, the 'f', 'd', 'i', 's' and 'k' keys on my computer would quickly
wear out. What we needed was a standard OS for The Scene, and to make
it a standard, we'd have to make people use it. But for everyone to like
the OS, we'd have to let everyone work on it... And me, as a musician with
poor system programming experience [make that poor programming experience
at all ;) -Finrod] [Hey! I know enough to survive, all right? -Beren]
[Nah, just kidding -Finrod], would have to wait endlessly for this OS to
come out, IF anybody would do anything about it, that is. OR, I could host
a co-operation myself. So I did.

/**[2.3]****[The initiative]************************************[Beren]**/

Some lousy afternoon the phone rings at Finrod's. With much effort he lets
go of the computer for long enough to answer the phone. It's that wierd
guy Beren again. Yes, he has read comp.sys.ibm.pc.demos lateley, and yes
he has read the dreams about an operating system for demos and yes no one
is taking any initiative at all. Beren had not long ago asked if anyone
was doing anything about it. One guy had actually begun working on such an
operating system. But no one had considered the thought of co-operation
with other demogroups over the net as anything but ridiculous. 'Someone's
got to take an initiative,' Beren complains to Finrod. 'How would you like
us to host such a project?'

/**[3]******[About the OS]***********************************************/
/**[3.1]****[Hardware requirements]****************************[Finrod]**/

DemOS will run on any 386 or better computer, with 1 MB RAM or more, and a
few megs of free harddisk space. However the minimum realistic
configuration for a DemOS system is a 486/33 (DX or SX does not matter as
long as no application you wish to run needs floating point) with 4 MB RAM
and enough harddisk space ("enough" simply because we have no idea yet how
big the OS will be. However, the OS itself, complete with microkernel,
kernel modules and command interpreter, should require less than 5 megs.
Such a stripped- down configuration is more than adequate if you plan to
just *watch* demos. If you want to use DemOS for "serious" work, however,
such as coding, tracking, drawing, or whatever, you'll need a lot more.)

Most of you are probably thinking "Yeah, right, 486/33/4, that's what IBM
said about OS/2, and look at the result." However we have very good
reasons to believe that these figures are realistic. Amongst other
reasons, DemOS (in its initial configuration) has no fancy GUI, nor tons
of useless utils (who needs ramdrive, fastopen, nlsfunc, dosshell,
msbackup, or qbasic anyway?). Basically, if it can run DOS at a satisfying
speed, it can run DemOS even faster.

/**[3.2]****[The kernel]***************************************[Finrod]**/

We are planning to base DemOS on a microkernel architecture with most of
the OS functionality lying in external modules. All modules will comply to
a standard API, with standard APIs for each subcategory. This simply means
that all modules will behave the same for common functions such as driver
identification, version number, etc., and that all modules in a given
category (for instance, all sound drivers, all file system drivers, etc.)
will behave in a similar fashion. Provisions will be made to allow partial
or extended functionality - for instance, AdLib drivers will be allowed
not to implement recording :) and Matrox Millenium drivers will be allowed
to add 3D functionality (or maybe we'll define an API for 3D functionality
and allow VGA drivers to ignore it)

/**[3.3]****[I/O]**********************************************[Finrod]**/

I/O ports will not be privileged in DemOS. To do so would be pointless as
it would significantly slow down anything that uses them, i.e. most - if
not all - demos, intros and games. However it is possible that we provide
a mechanism to lock specific I/O ports - for instance the disk subsystem
might lock the SCSI adapter's I/O ports to prevent accidental data loss.
However only privileged processes (i.e. OS modules) will be allowed to
lock I/O ports. Thus we simply set the IOPL to 0 and give everybody the
same I/O permission bitmap, and avoid the hassle of setting one up for
each task.

/**[3.4]****[Multitasking]*************************************[Finrod]**/

We do not plan to implement multitasking from the beginning. However we
mean to design the OS and especially the API in such a way that multi-
tasking can later be added with no programmatic differences (i.e. old
programs will run just as well with multitasking).

/**[3.5]****[Video support]************************************[Finrod]**/

A standard API for video cards will be defined, and DemOS will ship will
drivers for VGA and probably a few accelerators. Forget VESA, it's far too
slow. I don't know how the coder (or coders) in charge of the video
subsystem will handle this, but quite possibly they will define a list of
standard mode numbers. Minimal SVGA support should be easy to achieve for
most adapters; the only really critical functions that need to be
implemented for each card are identification, mode initialisation and
status report.

Needless to say DemOS will make provisions for linear addressing. The idea
so far is to map the linear video buffer at a fixed position in each
application's address space, and provide an OS call which will return the
offset to that location. With some work it is possible, through paging, to
simulate linear addressing even on cards that do not support it.

/**[3.6]****[Sound support]*************************************[Beren]**/

DemOS will ship with a set of sound support modules. These drivers are
meant for coders who don't want to devote all their time and effort to
implementing support for whichever sound board they feel like but rather
to the demo (or intro or whatever) itself. Note that the use of these
drivers will NOT be compulsory. Coders are free to write their own sound
routines rather than use the DemOS sound API - or if they wish, to write
and distribute their own drivers.

/**[3.7]****[The file system]**********************************[Finrod]**/

DemOS will use a dual file system. The microkernel contains code for a
proprietary file system loaded at boot time; this is the only file system
allowed on the boot partition because of the kernel's need to easily
locate and load dynamic link OS modules. Additional file system drivers
may be used by DemOS to mount other partitions, such as FAT12, FAT16,
VFAT, EXT2FS or HPFS partitions. Apart from FAT16, and most probably
FAT12, it is not yet clear which file systems will be supported at release
time.

The additional file systems will be implemented as external modules which
can easily be exchanged. Specs for the file system API will be released to
allow programmers to design and/or implement their own file systems.

/**[3.8]****[Shells]*******************************************[Finrod]**/

Whichever you want - even write your own if you like. The shell is just a
program like any other (contrary to DOS). You can even specify your
favourite word processor (anyone want to port WordPerfect to DemOS?) as a
shell if you like.

/**[3.9]****[Programming aids]**********************************[Beren]**/

When the kernel is ready, we will start working on a linker and probably
port GCC/GPP to DemOS. The advantage of a GNU C/C++ compiler is that the
code can easily be ported from system to system and grants us access to a
huge collection of for instance Linux programs which will help us much
while the number of programs running under DemOS is still very limited.
For instance, porting an editor and an assembler could greatly accelerate
development.

/**[4]******[Joining the project]****************************************/
/**[4.1]****[Who do we need?]**********************************[Finrod]**/

Primarily, we need people with expertise in graphics (low-level VGA
programming), sound (sound drivers) and disk drives (file system), but all
in all any coder who wants to join and feels he has something to bring to
the project is welcome to apply. If you feel you don't have the time or
the energy to participate in the coding effort, you can join as an alpha
tester. In my opinion it is an advantage for alpha testers to participate,
even passively, in the development so they have a good knowledge of the
system and know what to do and where to look for bugs.

Finally we need beta testers and anyone willing to write programs for
DemOS, both to test the OS and to ease our work.

/**[4.2]****[How do I join]*************************************[Beren]**/

To join The DemOS Project, write to me, beren@infolink.no, and tell me
what you want to work with and I'll send you everything you'll need of
information and tell you who you'll be working with.

/**[4.3]****[What privileges do I get by joining?]**************[Beren]**/

First of all, you get to know a whole bunch of people.

Secondly, you'll be on the list of people who made this thing come true.
(You'll be writing Scene-history, I hope! :-) )

Thirdly, you'll receive no payment because we all do this for free, and
this will give you a clearer conscience. :-)

Next, you'll have access to the newest alpha and beta releases and most of
the sourcecode at all times.

And of course, you get a chance to make the DemOS be the OS of your dreams
as long as you tell us what you want from the OS.

But the thing which will make you feel REAL good is that this is the best
way to tell Bill Gates to go to hell! >:-D

/**[4.4]****[Graphician Needed]*********************************[Beren]**/

For this issue of Palantr, I got WhiteWater of Inferiors to make the
ASCII-logo and ending. However, a small problem arose when he suddenly
went off to The Party and I couldn't get him. Well, anyway, for the next
issues of Palantr, I would need to work with a graphician. You should
know how to make ASCII-, ANSI- and normal bitmap-pictures (320x200x256).
Please write to beren@infolink.no. I need you real bad!

[PS: We might also need you to make pictures for the OS itself - Finrod]

/**[5]******[Misc.]*********************************************[Beren]**/
/**[5.1]****[Music]******************************************************/

DemOS' drivers will support module-formats and be players as well. By
making own drivers for module-formats, new module formats can be added
into your favourite module player or tracker just by adding a driver. And
by making module players as drivers, we can provide a music system which
is as easy as Midas to use for demopurposes. DemOS will as default support
4- & 8-channel MODs, S3Ms, XMs, MIDs and EarthTracker files.

/**[5.2]****[Graphics]***************************************************/

Just like music formats, we will support drivers for graphic format. We
will as default support the JPEG and PiNG format.

/**[6]******[Creating demos and programs for DemOS]**********************/
/**[6.1]****[Is all my programming experience wasted?]**********[Beren]**/

You'd like that, wouldn't ya? Well... No. It's still the x86 architecture,
so you ASM-freaks are saved from that trouble. When we have finished the
kernel, we'll have to make a linker and a GNU C/C++ compiler. If we don't
get enough people who're interested in making a Pascal compiler, it won't
be made until somebody else does it. So, if your favourite programming
language is Pascal, you'd be safer studying C or ASM, and if you don't
care anything about ANSI or GNU compatibility when you're programming C,
you've got a bit to learn. But hey, if the OS becomes a breakthrough,
these things might come slowly.

/**[6.2]****[Programming concepts]******************************[Beren]**/

Coding under DemOS shouldn't be to hard if you already know how to code
for the x86 processors in 32-bits mode. While you have to use a DOS
Extender in DOS, you can skip that bit of the work with this system. You
don't need to bother about memory limits no more, but I would strongly
recommend not to exceed 8 MB because not everybody has 16+ MB RAM.

/**[7]******[Closing words]*************************************[Beren]**/


  Thnx to Finrod for his contribution [contribution? Hah! I *wrote* the
    damn thing! -Finrod] [(1) You wrote 9 and I 15 sections and (2) You
    just wrote what I told ya to! I had to do all the boring stuff, like
    correct your spellingmistakes! -Beren] to this first edition.

  Thnx to Token, Jester, Hook and Erise for supporting this project
    already before the idea was launched officially.

  Thnx to Trixter for laying cdrom.com at our feet.

  Thnx to WhiteWater for the ASCII art which never made it in time.
    [Hey, I've never claimed to be an ASCII-artist, but deadlines are
    deadlines, even for Scene-mags which are quite often late, right?
    So... next issue, WhiteWater. Then TP95 is over and everything!]
    and to Henrik Bakken for the logo on our web pages.
    [You guys seen the title logo? Neat, huh? I made it in TheDraw in
    15 minutes after it became clear that we had no logo, and it was
    release night... and a coder at that! - Finrod]

  Thnx to all you guys who joined / will join this project. We desperately
    need you! Without you, this project is nothing!

  Hi to Monique, all three Elins, Walker, Kjetil, Laurelin, Kaja, Edge,
    Obi Wan and all ye other guys! :)


/***********************************************************************/

                 ______      ___   ____         ____     _____
                /  ___/ /  /  /  / __ \       /    \   /  __/
               /  /    /  /  /  / / / /      / /\  /  /  /
              /  /_   /  /  /  / / / /      / / / /  /  /_
             /  __/  /   /  /  / / / /      / / / /  /  __/
            /  /    /      /  / / / /      / / / /  /  /
           /  /_   / /   /  / /_/ /      /  \/ /  /  /
          /____/  /_/ __/  /_____/       \____/  /__/
                                                               ____
                                                              /___/
       __               ___                   ___  ________  ___   ___
      /  \    /       /  /     /       /  /  / /__   __/ /  /  /   \
     / /\   /       /  /     /       /  /  /    /  /   /  /  / // 
    / //  / / O     /  /     / O     /  /  /    /  /   /  /  / // /
   /  __/  / _     /  /     / _     /   /  /    /  /   /  /  /     \
  /  /    / / \   /  /___  / / \   / /   /    /  /   /  /  /  /  
 /__/    /_/   \ /______/ /_/   \ /_/ __/    /__/   /__/  /__/ __/


/**[End of Palantr]*****************************************[Issue #1]**/


