doc/design.txt

   1 BOS design
   2 ----------
   3
   4 The kernel will load internal system modules like STDIO,
   5 VFS and so on, by calling a dd list in "init.inc".
   6 STDIO should be the first to load, as to be able to print
   7 loading status of other parts.
   8
   9
  10
  11 STDIO will use internal buffer/debug console as STDOUT at
  12 first, until textmode, VESA or serial output driver is
  13 activated, at which point the internal buffer/debug console
  14 will be flushed to new STDOUT.
  15
  16 Module for STDOUT could even include a file handle for
  17 systems with no normal output device, so that debugging
  18 information can be read out from file. All drivers
  19 for STDIO will have to follow a common STDIO interface
  20 and can be dynamically loaded and unloaded at runtime.
  21
  22 Keyboard/mouse drivers for PS/2 and later USB also needs
  23 to register itself to STDIO as STDIN devices in the system.
  24
  25
  26
  27 Other primary services tightly connected to the BOS kernel
  28 is the VFS for all storage devices and filesystems, the
  29 interrupt and system call interface for adding new calls
  30 and groups of calls within the standard int 0x32 interrupt.
  31
  32 Groups of calls is for primary system services to be
  33 accessed from within the same interrupt, 0x32. For
  34 example the VFS, could use AL = 0x05 for it's "group-ID"
  35 and AH = 0x?? for a specific function-call. STDIO, could
  36 have AL = 0x01 with AH = 0x?? for the function number.
  37
  38
  39
  40 Another primary systemcall group will be the "loader",
  41 for applications and modules/drivers not present inside
  42 the kernel image file - kernel.sys
  43
  44 It will initially support 2 types of applications,
  45 normal programs and drivers/modules/TSR.
  46
  47 Loading will be handled by means of segmentation at first,
  48 as the simpler format with less overhead. Similar to
  49 DOS .COM files. Another format for relocatable programs
  50 is planned but will require modifications to fasm for
  51 native output.  This will be similar to .EXE files in
  52 DOS. No limitations will be made to the formats,
  53 except the segmentated one will not have base set to zero
  54 in RAM, and will not have program headers and relocation-
  55 tables as overhead.
  56
  57 This makes it somewhat trickier to preform certain RAM
  58 operations in higher level languages but also ideal for
  59 space constrained applications, such as scene demos - which
  60 often has very low size limits.
  61
  62 File format exstensions is not yet decided, but might
  63 differ for the two formats. Maybe .APP for the simpler
  64 segmentated format and .PRG for the relocatable?
  65
  66
  67
  68 The kernel image file will need to include some loadable
  69 drivers at the end for further access to media such as
  70 the floppy disk, and the FAT12 filesystem. With this it's
  71 possible that the file on a fat12 formatted floppy will
  72 be named kernel.img while internally it might be visible
  73 as kernel.sys, floppy.drv, fat12.drv and so on.
  74
  75 Initially the VFS will have internal drivers for parsing
  76 this image format and deploying it as a RAM-drive with
  77 SBFS - static BOS filesystem. A very simple read-only FS
  78 in linked-list style. As simple as it gets.
  79
  80 So the VFS needs RAM-drive and SBFS support built-in for
  81 it to be able to load additional drivers for floppy, fat12,
  82 harddrives and other media. System drive will always
  83 be this RAM-drive. Any drivers loaded at a later stage can
  84 be on any other media or drive, such as the floppy.
  85
  86 There should be commands to load a driver like "LOAD"
  87 for one time use and "LOADPERM" for it to be permanetly
  88 inserted into the kernel image file for loading at boot.
  89 "UNLOAD" and "UNLOADPERM" could be used for unloading
  90 and removing drivers from the kernel image.
  91
  92
  93
  94 Memory managment and allocation in BOS will be another
  95 primary system service with it's own group-ID in AL,
  96 for access with int 0x32. It will provide one allocation
  97 and freeing service for memory above 1mb and another
  98 service for memory below 1mb.
  99
 100 Memory below 1mb should only be used in applications that
 101 needs to run 16-bit code or allocate DMA buffer space. It
 102 will be possible to demand 64kb align on allocations made
 103 in low memory - to properly support DMA transfers.
 104
 105 The memory managment service group will also have functions
 106 to get RAM size, and maybe system location/size or others.
 107
 108
 109
 110 Running custom 16-bit code will be possible by allocating
 111 low memory space, relocating any 16-bit code to that area
 112 and then calling a BOS system service to start execution
 113 in realmode at that address. This will allow for greater
 114 flexibility in utilizing BIOS services than a direct
 115 bridge call to for example interrupt 0x10 or 0x13.
 116
 117 All (segment) registers can be used and BIOS interrupts
 118 demanding buffer space pointers will easily be supported by
 119 pre-allocating the necessary low memory before executing
 120 the real mode code.
 121
 122 Direct execution of a native 16-bit executable file format
 123 is not planned, but could be supported by a third party
 124 loader written in 32-bit to take 16-bit binary filename as
 125 input, allocate low memory for it, relocate it, execute
 126 and clean up at exit.  Such a program could be extended to
 127 contain interrupt 0x21 services for basic DOS compability.
 128
 129 BOS kernel is loaded at the 64kb mark right now, but should
 130 be moved sufficently below that for internal 16-bit code
 131 to work without address fixes. The ORG offset should be
 132 below 0xFFFF for all internal 16-bit code. Now it starts
 133 at 0x10000, which means this offset has to be substracted
 134 from all 16-bit code that deals with variables.
 135
 136 For external 16-bit code, relocated and runned by the kernel,
 137 this is no issue.
 138
 139
 140
 141 BOS should include a scripting language, similar to DOS batch
 142 files for scripting and "autoexec" usage. If the extension
 143 is .RUN - the file to autostart drivers and customize the
 144 system at boot could be called "auto.run".
 145
 146 The scripting language needs some internal commands not tied
 147 to any shell, for program control - and also for the auto.run
 148 file to be able to load the shell at boot, the LOADSH command
 149 is needed. This could be directly tied to the VFS for
 150 selecting which shell to load.  The shell needs to set some
 151 system vars like %SHELLNAME% and %SHELLVERSION% for the
 152 scripts to know what other commands are available from it.
 153
 154 Basic commands, independent of shell could be:
 155 LOADSH = "fd0:/path/shell.app"
 156 GOTO LABEL
 157 :LABEL
 158 REM comment
 159 IF [NOT] %xxx%==something GOTO LABEL
 160 ECHO %1 is first command line parameter
 161 ECHO.
 162 ECHO %SHELLNAME% is env. var for shell used.
 163 SET ENV_VARIBEL=Hi
 164 SETLOCAL LOCAL_VAR=Bye
 165 LOOP %var%
 166 ENDLOOP
 167 CALL filename.run
 168
 169 Nothing is set in stone, but DOS batch file similarity could
 170 be good for those that know it well. It should be as easy to
 171 parse as possible.
 172
 173
 174
 175 Graphics in BOS will probably be tied to the STDIO services
 176 with many additional function calls for drawing shapes and
 177 outputing sprites. Text output will be possible as in any
 178 textmode, but the cursor will be hidden by default, and if
 179 enabled, simulated with blinking and all - by BOS.
 180
 181 With text output options even in VESA modes, a system crash
 182 will still be able to print out some facts about it with
 183 the same STDOUT functions as in textmode. Font&size will be
 184 optional, but optimized for best look and usability as default.
 185
 186 Other graphics function will include anything that helps
 187 and eases the development of games, added as I port and
 188 develops my own game clones.
 189
 190
 191
 192 The sound service group will have a unified function interface
 193 no matter what device is installed, only PC speaker, AC'97,
 194 SoundBlaster/AdLib compatible or Intel HD audio.
 195
 196 It will be possible for the programs to detect capability of
 197 the installed driver for best utilization.
 198
 199
 200
 201 A driver will be loaded in the exact same way as any other
 202 application but will install itself with the service group
 203 it belongs to, or as a new interrupt itself before quitting
 204 in a TSR way.
 205
 206 The interrupt handling code will have functionality for drivers
 207 not only to install a completly new interrupt, but also to add
 208 itself as a new service group in the system interrupt 0x32.
 209 It will then be given a free service number (AL=0x??) for calls
 210 made to that group.  It could also request to take over an
 211 existing service number. What internal function to be called is
 212 decided with the value in AH and could go to external drivers
 213 that has been loaded and added itself to the service group.
 214
 215 A driver might use .DRV extension or something to distinguish
 216 itself from a normal executable. It's not decided how to tell
 217 if it's a .APP type segmented driver or .PRG relocatable driver
 218 with just one .DRV extension. Could probe for relocatble format
 219 header for .PRG and assume .APP format if not found. This could
 220 be done for programs as well, if I choose to use one extension
 221 on both executable formats.
 222
 223
 224
 225 The End
 226  - for now.