V2_OS System Architecture

Chapter 01 Introduction
Chapter 02 The Bootsequence
        - The BIOS
        - The BootSector (Boot.asm)
        - System16 Initialization(System16.asm)
        - System32 Initialization(System32.asm)
Chapter 03 Modules
        - Overview
        - Loading Modules
        - The ModList
        - The Mod_Load Routine
        - The Mod_Service Routine
        - The Mod_UnLoad Routine
Chapter 04 Servers
        - Overview
        - How to use Servers
Chapter 05 DiskAccess
        - Overview
        - Supporting new devices
Chapter 06 Output Devices
        - Overview
Comming Up: The Stack
The 'RealMode' Portal
The PiXeL System
System16 InfoTable
ServerSpecifications for:
   -VideoCard Server
   -PiXeL Server
   -PCX Server
2 Much 2 Mention :)



Chapter 01
Chapter 01 : Introduction
Thes 'System-Architecture' pages are ment to give a 'global' introduction to the most important parts of the system, and will help you to understand how the system works, how to write applications, modules and servers for the system, and understand the 'System32 Services'.

Chapter 02
Chapter 02 : The Bootsequence - The BIOS
To explain the System-Architecture of the V2_OS, it's useful to first look at the Bootsequence in a bit more detail... When a PC boots, the BIOS first runs the POST(Power On Self Test), searches for IDE, PCI and EISA devices, checks the memory and some other things...

When it has done all that, the BIOS checks (in the order specified in the BIOS Setup) the available bootdevices. If for example the first IDE disk is set as the first bootdevice, the BIOS loads the first sector of this disk into memory. This sector is called the MBR(Master Boot Record). If this sector has the 'AA55' signature in the last two bytes (Offset 1F4H), then the BIOS will make a far jump to this code. What happens after that depends of the code located in this first sector(the MBR). If the signature was not found, the BIOS will try the same to all the MBR's of all other bootdevices (Second IDE disk, floppy stations, CD-ROM drives, zipdrives etc..) If no bootable MBR was found, the BIOS loads the ROM-Basic... And since the ROM-Basic is no longer implemented for ages, the long forgotten message 'No ROM-Basic installed' appears and the system locks-up.

Chapter 02 : The Bootsequence - The BootSector
But if all goes well, this doesn't happen, and the BIOS finds the V2_OS bootsector (The source file is called Boot.asm). Note that this is the very first piece of code that gets control after the bios. Since it is loaded from only one sector, it has 512 bytes of 80x86 instructions to find more code. To see how this is done, take a look at the bootsector-structure in the V2_FS pages. At offset 28h, a byte is located describing the amount of sectors 'System16' uses, after reading that, the bootsector code positions it's drive heads at the sector after the bootsector, and starts loading the 'System16' code, sector per sector(that are the dot's seen at bootup) to the absolute address 500h(0050:0000h in segment:offset notation). If it fails, a message appears saying 'Failed.SysLock.', if it succeeded, the bootsectorcode loads dl with the drive number booted from, dh with the head, cl with the cylinder, and ch with the sector number of the bootsector. It then jumps to 600h(yes, skipping 100h bytes). After this, this chunk of code will never be used again. Since it never knew where it was anyway, it will be overwritten by other code later...

Chapter 02 : The Bootsequence - System16
For a more detailed look at what 'System16' is, and what it does, see the 'System16' chapter on the 'Developer Pages'.
System16's role at bootup is not that big, it mainly loads System32 to memory, enters protected mode and passes control to System32:

To make V2_OS look a bit fancier, System16 first set's the 80x50 textmode(1112h) and set's the colors(preserving the original text on the screen). It then reports that System16 is in control.

At this point the code collects data on the bootdisk used later to load the System32 code. When the info is gathered, the 'DiskList' Structure is created. Also some general information on the machine is gathered and stored in the 'System16Data Structure'.

Now it's time to load the System32 code... First the memory location gets calculated by adding (512*the amount of sectors of System16) to 600h. Now System32 gets loaded into memory sector-per-sector (indicated by dots on the screen)

The CMOS area is copied to the CMOS-DataBlock.
The CPU is thoroughly checked to see if it's capable of handling all modes of the V2_OS
The A20 enables

The system is now ready to leave real-mode, and enter protected-mode. Because System32 is responsible for building the GDT, a temporary GDT is created to make the switch. This GDT has the following Descriptors:
  00 Null Descriptor
  08 System16 Code
  10 System16 Data
  18 The 4Gig Descriptor
  20 System32 Code
  28 System32 Data
When these descriptors are created, the LGDT instruction is prepared and executed. The system is now ready to make the jump out of the RealMode. The system first enters protected mode in 16Bit, and from there on it jumps to System32, and the system is now in full 32Bit Protected Mode.

Chapter 02 : The Bootsequence - System32
For a more detailed look at what 'System32' is, and what it does, see the 'System32' chapter on the 'Developer Pages'.
When System32 gets control, the system has nothing, all irq's are disabled, there are no service routines, etc.etc. So System32's first task is too make this system a bit usable.

First, the 'MemoryMap' is being initialized, a place is found to create an IDT, the 'Shared Stack Space', the keyboard area, the GDT,  the ModList and the ServerList
Now there is a place for an IDT, a smart self-writing code routine is executed that builds 256 callable functions that put the IRQ number in EAX and jump to the exception handler. This code is found nowhere in the source code and is entirely build up at run-time IN the code-segment of System32.
Except for IRQ 0(redirected to the PIT handler), and IRQ 1 (Redirected to the keyboard handler)
Interrupt 20h is hooked to the 'famous' System32Service handler.
Now that the IDT is valid, the LIDT instruction is prepared and executed.

The code is still on that 'cheap' GDT declared in System16. It's time to create a 'real' GDT. The 6 entries from the other GDT are copied to the new GDT, and the GDT switch is made...

The Keyboardsystem is initialized, and ready to use.

The system is now stable enough to execute the 'STI' command. (SetInterrupt flag, enables hardware IRQ's)

The system32 Initialization is done, and the system now goes into 'CommandPrompt'-mode.

Chapter 03
Chapter 03 : Modules - Overview
Modules are applications that provide 'Services' to other applications. They remain loaded in memory, doing nothing, using no processing power, until an application 'Requests' a service. The type of services these Modules provide can be anything, like 'foreign filesystem access' or 'Special Video Effects', etc, etc. Modules are 'normal' files that can be 'read', 'copied', 'deleted', etc. and they carry the extension '*.v2m'(Standing for 'V2_Module')

Chapter 03 : Modules - Loading Modules
Modules can be loaded at any time, by using the 'loadmod'-command, like 'loadmod hda1://Example.v2m'. At this point System32 checks if the file exists, and verifies if the file starts with the magic-characters 'V2M.' System32 reads the ModID of the file and checks if it is not already loaded. It then verifies if the V2_OS Version required by this Module matches the current V2_OS Version.

If all these checks are successful, System32 finds a location for the Module in High-Memory, and loads it there. It then adds the module to the 'ModuleList', and finally the Mod_Load routine is being executed.

Chapter 03 : Modules - The ModList
The ModList is the structure in memory that holds information on all the currently loaded modules. It knows the ModID, the location in memory, the size, the Code and Data descriptors. This list is used for several reasons. Firstly, it prevents that the same Module gets loaded twice, this would cause the system to get confused and become unstable. Secondly, applications can check this list, eather by themselves, or by some provided System32 Functions, and see how to access these Modules and their services. For a more technical description of the ModList and the format of the structure, check the 'Modules' chapter on the 'Developer Pages'.

Chapter 03 : Modules - The Mod_Load Routine

In the header of a Module, a pointer is included to the 'Mod_Load' routine. This routine is called after a module is loaded into memory, and it's environment is completely set up. This gives the module the abilty to, for example, allocate some memory space, or load some lookuptables from the disk, or initialize some internal structures, hook an interrupt or IRQ, initialize a hardware device, etc, etc...

Chapter 03 : Modules - The Mod_Service Routines
Modules become usefull when they can provide so called 'Services'. This way any other application or even other Modules can say 'Execute Service 27h of module 'v2_xmple'.
The first 10h service routines are reserved and should not be used. For an example of how to implement a Service and the ServiceTable in your module click here.

Chapter 03 : Modules - The Mod_UnLoad Routine
By using the 'modunload' command modules can be 'unloaded' at any time. This means that firstly the 'mod_unload' routine in a module is being executed so that the module can free memory it has allocated during it's life-time and return IRQ handlers, and tell other modules it is about to 'die'. Then System32 blanks the code and datasegments of this module, frees them and removes the modname from the modlist. Note > This function is build in the system, but it is not yet supported.

Chapter 04
Chapter 04 : Servers - Overview
Servers are actually just 'Modules'. They have the same Mod_Load, Mod_Service and Mod_UnLoad mechanism. The Difference is that in the Mod_Load Routine the use the System32 Service called 'Announce Server'. This way thay can say 'Hey look ! I'm a VideoCard Server !'. At this point an entry is made in the 'ServerList' that says 'VideoCard Server > Ask Module 'v2_xmple'. Servers have to support all functions defined for that type of 'Server'. For VideoCard servers for example, they HAVE to support the 'SetVideo Mode' Service, and the 'HardWare Scroll' Service and so on. These Server-Specifications are documented here. This mechanism is very usefull to implement 'Drivers' for hardware, or 'FileFormat' interpreters, 'Video Codecs', 'Memory Managers' (Yes, even virtual memory handlers if you like), and the 'Disk' Interfaces.

Chapter 04 : Servers - How to use Servers.
When a Server is loaded and metioned in the 'Server-List', applications and other modules and servers can execute the System32 Fuctions 'Query Servers' and 'Get Server Info'. The 'Query Servers' Command tells the requestor how many servers of a specific type are loaded. An application can for example need access to the videocard. It can then call this service with 'VideoCard' as it's parameter, and it is told -IF- any servers of that type are loaded, and even -How Much-. This means that several Servers of the same type can be loaded ! So you could make a videocard server optimized for 3D-work, onother one for vectorwork and yet anotherone for motion-video.

Chapter 05
Chapter 05 : DiskAccess - Overview
An application can always rely on the System32 Services 'Read Sector(s)' and 'Write Sector(s)'. They'll always work, But > Not always optimal. This means, not at their maximum speed, or not all devices in your system may be 'recognized'. When the System is booted, use the 'disklist' command. This will list all devices that are currently recognized, and how they are threated. If you have a floppydrive, you'll find a 'fd0' entry in this list which is being threated as a 'BIOS' device. Also if you have a harddisk, you'll find a 'hda' or 'hdb' etc entry. These harddisks will also be of the 'BIOS' type. As long as a device is of the type 'BIOS', expect it to be very slow. Here the modules come in handy again. Load for example the 'Ide.v2m' module. It will at load, scan your IDE controllers for IDE compatible devices. 99.9 % chance that it will find the harddisks. It then tells System32 that if it ever receives a request for that specific device, it will be redirected to this module. You can see it if you run the 'disklist' command again. The same 'hda' that was of the type 'BIOS' is now of type 'IDE' and being handled by 'v2_ide00'. This module is optimized for IDE devices, and will speed up access to this device to the maximum available. Note that -every- action that involves this disk will speed up too, the 'files' command, the 'file-info' services etc.etc. It is therefore important that the correct modules for the devices are always loaded.

Chapter 05 : DiskAccess - Supporting new devices
When the System boots, it will not list any CD-Rom drives you may have in your system, it will also not find a IoMega Zip-Drive, or any other devices that are not recognized by the BIOS. The DiskModule-mechanism makes it possible to support these devices. They will detect their own type of hardware and insert it in the 'DiskList'. The 'Cdrom.v2m' for example will insert a 'cda', or 'cdb' entry in the disklist, and from thereon all applications, modules and servers can access this device without adding special support for it. This makes it also possible to create RamDisks or later even assign disknames to FTP-Sesions or create network diskshares !

Chapter 06
Chapter 06 : Output Devices-Overview
When an application wants to output text/information to the user, it should use the System32 Services 'Output Text' and 'Output Number'. Currently the only output device supported is the monitor, but when a GUI is being created, it is possible to output to the graphics card. Also a modem-sesion could be the output device so you can 'Call' your V2_OS system and it will answer as if you would be behind the computer. When network is implemented, Telnet sesions can be set up etc. etc. etc.