----------------------------------------------------------------------------
	Assorted SOLO Notes:
----------------------------------------------------------------------------

This file is just a place for lots of notes that I don't have the time
to properly write up and organize and put somewhere else.  
So, it's probably a good idea to look it over before doing anything,
and refer back to it before mailing me with questions, to see
if the answer is already here...


----------------------------------------------------------------------------
General notes:

	o	SOLO = Shag/OS LOader, or Standalone Only LOader	

	o	Partition naming:
		Unlike Linux, I've gone with the traditional naming scheme
		of drive_type/drive_number/partition_letter
		such as:  hd0a
		Also, for IDE drives, PC's support two drives on	
		two controllers, so I just consider those as drives
		0 through 3, but Linux likes to put the controller 
		specifically in the device, thus having names like 
		"hd1a4" for controller 1, first drive, 4th partition.
		I prefer "hd3d", to keep it short and simple.

		Of course, you may have your own preferences.  There's
		no reason you need to follow my scheme.  Just go 
		into the "solo.cnf" file and rename all the devices
		to the Linux standard, or any other standard, if
		you prefer.

		Conversion chart:
			Shag/OS:	Linux:
			hd0		hda
			hd0a		hda1
			hd0b		hda2
			hd0c		hda3
			hd1		hdb
			hd1a		hdb1
			hd1b		hdb2
			hd1c		hdb3
			hd2		hd1a
			hd2a		hd1a1
			hd2b		hd1a2
			hd2c		hd1a3
			hd3		hd1b
			hd3a		hd1b1
			hd3b		hd1b2
			hd3c		hd1b3
			fd0		fd0
			fd1		fd1

		Note that the Linux scheme is inconsistent in regards
		to naming of floppies vs. hard drives...
			You have fd0 and fd1,
			and hda, and hdb
		Going with the traditional scheme gives
			fd0, fd1, hd0, and hd1

		If anyone knows why Linux chose to break with
		tradition in this area, please mail me about it,
		because I'm curious to know if there was a good reason for it.

		
	o   Serial Devices
		There is no actual serial device driver yet,
		although there is code to redirect the console 
		to work over the serial port.  (See the 'redir' command)
		 This code was tested once,  long ago,
		and used to work, but chances are that it doesn't
		anymore.  If anyone wants to test it, feel free, but when
		the time comes to fix it, it will be rewritten to use
		any device driver, and a serial device driver will be 
		written, rather than locking redirection to one type
		of device.

	o   Video mode bug 
		The standard setup code for Linux does not check the 
		number of lines on the screen.  It assumes that it
		is 25 by default, so that if you switch to a custom
		mode before booting Linux, it will only use the first
		25 lines of your screen.  I have always modified my kernel
		as follows to fix that:

		(note that this is for Linux 1.2.X kernels... it may
		not work for other versions... I don't know)

		Go into the Linux sources and find 'setup.S'
		(it should be in arch/i386/boot)
		There should be a segment of code in there that says:
			mov	ah,#0x0f
			int	0x10
			mov	[4],bx
			mov	[6],ax
		Right after that, add:
			push	ds
			xor	ax,ax
			mov	ds,ax
			movb	al,[0x484]	! get bottom line
			incb	al		! inc to get # of lines
			pop	ds
			movb	[14],al		! save # of lines for con_init

		And rebuild your kernel.

		Note that this uses an unofficial BIOS address to get
		the screen height.  It seems to work on all machines
		that I've ever tested it on, but there's no
		guarantee, so I'm not sure if this should become
		an official modification to Linux or not.

		
----------------------------------------------------------------------------
Standalone program/kernel writing/debugging:
(in future releases, this will probably have more complete documentation,
with real sections, examples, and step by step details, as well as
notes)


	o	When a 32-bit executable starts running, it is mapped
		to whatever virtual address it was linked to run at,
		which *must not* be less than 0x00100000.  
		Virtual addresses from 0x00000000 to 0x000fffff are 
		all identity mapped to the corresponding physical
		locations.  All page table information used by SOLO
		will be allocated within this region (the first 1MB 
		of memory), so that, in order to read page tables
		directly, the physical addresses can also be used
		as the virtual addresses, until the executable remaps
		memory (if it does).

	o	If PIT timer0 is changed, the values stored MUST be also
		put in the timer0 section of bootparam, since there is
		no way to read them from the hardware, and BIOS calls
		need to alter this.  (this only applies if you will
		be making calls through BootParam after changing
		Programmable Interval Timer 0)

	o	"initial_stack_top"	 -- declare this global pointer
		for choosing your initial stack pointer
		otherwise it defaults to the top of available virtual memory
		If you want to use the top of available virtual memory,
		you can declare "initial_stack_size" to specify the size,
		otherwise it defaults to 64K.

	
	o	When booting SOLO, bootparam->base_lomem will be
		0x8000, since SOLO uses memory from 0x1000
		to 0x7fff.  However, when writing kernels or other programs
		that load from SOLO, do not depend upon fixed constants.
		Use 'bootparam->base_lomem' to find out the lowest base
		physical address you can safely use, and assume that
		all memory below it is reserved unless your kernel is
		at a point where it will never use any of the BootParam
		functionality again.

	o	All interrupts and traps are already trapped, so until
		you change their vectors, everything, including fatal
		errors that cause a CPU reset, will be trapped.
		So, if the machine actually resets itself, or locks
		up totally, chances are that you did something that
		caused low physical memory from 
		0x1000 to bootparam->base_lomem-1 to be overwritten.
		(0x0000 to 0x0fff is protected and will
		cause a page fault if you try to access it, thus
		effectively trapping most null pointers)

	o	When your kernel gets to the point where it no longer has
		an identity mapping for the memory from 0x1000 to 
		bootparam->base_lomem-1,
		you will have to ensure that the region is mapped in 
		before calling any functions from the BootParam structure
		(and make sure you have your own interrupt/trap table,
		and that your kernel maps this region back in if it ever
		tries to exit)

	o	If your kernel never needs any of the BootParam functionality
		after it loads, it can reclaim physical memory from
		0x1000 to bootparam->base_lomem-1.
		Of course, if it ever needs to call any
		BIOS functions, it will have to provide its own BIOS
		interface functionality.  If your kernel does not intend 
		to ever use the BIOS, then it can also reclaim the first
		page of physical memory from 0x0000 to 0x0fff. 



------------------------------------------------------------------------------
Short Glossary of terms:
(currently *very* short)


	chunk:
		when referring to the boot procedure, and file mapping,
		a chunk is some number of mapped sequential sectors,
		up to 255 in a row.  Each chunk is stored in a mapfile
		as 4 bytes, with the first three representing an encoding
		of the first cylinder, head and sector, and the last one
		being the number of sectors to load in a row.  If the
		first sector number is 0, then it represents a zero'ed
		out chunk of data of the specified number of sectors.
		Part of the chunk format actually includes a way to 
		specify 'partial' chunks, for blocks of memory less
		than one sector in size, but this has not been fully
		implemented yet, since no existing file system seems
		to need it.  Future versions of the Shag/OS filesystem
		may require this, however, to allow for the efficient storage
		of many small files.

	identity mapping:
		a virtual memory mapping where a region of physical memory
		is mapped to the same addresses in virtual memory, such that
		the physical address can be used as the virtual address also.

