Front burner
------------
add basic FAT loader to forth environment.. 12/16 bit, use ide driver
	currently finishing LOAD_FILE in ide.inc (almost done)
	then streamline the routines a bit
	This will be good enough for loading Forth programs and XCOM's


v9 todo list
------------

Update drivers (floppy, serial, terminal, task, page, xcom)
(convert them to FORTH conventions, etc.)

Modularity/convenience stuff:
	DOS FAT support
	INCLUDE (load another Forth file)
	INCLUDE-XCOM (load an XCOM module and import "extern" symbols to
		the dictionary.. or, have a "dictionary" section of the
		XCOM, built w/ NASM macros, to name the words.
	DOS FAT boot loader:
		Done, but needs a little improvement

XCOM:
	finish section handlers: program, symbols, relocs

Disk drives:
	organize them, clean up the interface..
	standard FORTH block/sector I/O & block/sector cache (maybe)
	memory mapping: file<->memory  (esp. for persistent store)

FORTH:
	MARK/FORGET, CREATE..DOES>, SOURCE, STATE
	allow changing flags of words in dictionary (chflags)
	fix IMMEDIATE and COMPILE-ONLY
	fix ." and S" (alias ") to work when compiling (use CREATE..DOES> ?)
	Machine-Forth: @+ and !+, and an address register (ebx?), etc...

Keyboard:
	'KEY?' word
	Are extended keys handled right? 'EKEY', 'EKEY?'
	Allow Forth words to be run from a keypress (should be easy now!!!)
	Greek keys (use right Alt? or Win95 keys?)
	Composition

VGA:
	More graphics primitives: line, circle, triangle, filled triangle
	Organize it!
		1) Something like Allegro's BITMAP structure
		2) Show what you type in graphics mode
		2) Display sharing: splitscreen, windows, console switching
	SVGA (ET4000, S3, etc.) support - hi-rez, bank switching, linear fb

PAGING MEMORY ALLOCATOR
	Maybe just something simple like in john fine's 'tasktest' demo

SERIAL:
	When DOS-fs works, move stuff from bforth.fo to serial.fo
	Get it working with a modem, then do PPP...

Docs: Use LaTeX for a more professional look? (and LyX to make it quick)

boot: fix disk error message so it shows the error code!

improve number parsing routine (text->integer)  (TO_NUMBER?)
	(???) fail if a "digit" exceeds the radix, ie, "G" in radix-16
	accept !, $, %, & as prefixes to specify radix

Experiment!! Should be easy now.. very interactive (for those who know
forth, anyway :-)

Get some Forth tutorials, and finish the one I was writing



Things to do (from v8 and before)
---------------------------------

Count RAM size.. similar technique to waiting for A20.
Then page alloc/free routines

Handling extended keys (function keys, arrows, etc.)
 * Need to discuss this on TUNES-LLL, etc.
Scancodes are easy: extended ones are mapped to unused ones.
(Which is fine, for games like Star Control, Quake, etc..)
But how should extended keys be converted to "ASCII" codes?
 * Put a 0 in the low byte, keycode in high byte? (like in Turbo C)
 * Or start the extended codes right at 256?
 * ANS Forth model: "key" ignores extended keys, waits for a normal keypress.
   "ekey" reads extended keys also.
 * The unix method sucks (convert non-ASCII keys to escape codes like ^[[3).


Forth interpreter - implement/finish the following:

CORE:	( ) 2! 2@ >BODY >IN >NUMBER ABORT ABORT" ALIGN ALIGNED COUNT CREATE
	DOES> ENVIRONMENT? ***EXIT*** LEAVE MOVE QUIT RECURSE S>D SM/REM
	SOURCE SPACES STATE U. U< UM* UNLOOP WORD ['] [CHAR]

These optional wordsets aren't as daunting:
CORE-EXT: some useful things (many of them already implemented)
BLOCK: wrapper for ide/floppy
	BLOCK BUFFER FLUSH LOAD SAVE-BUFFERS UPDATE EMPTY-BUFFERS LIST REFILL
FACILITY: lots of nice console i/o, delay, date&time..
	MS TIME&DATE ...
FILE: access raw objects in the Store (or in DOS, and later Linux, BSD, etc)
	CLOSE-FILE CREATE-FILE DELETE-FILE FILE-POSITION FILE-SIZE
	INCLUDE-FILE INCLUDED OPEN-FILE READ-FILE READ-LINE REPOSITION-FILE
	RESIZE-FILE WRITE-FILE WRITE-LINE FILE-STATUS FLUSH-FILE RENAME-FILE
MEMORY: calls to the OS memory manager:
	ALLOCATE FREE RESIZE
OTHER:
	!AX and AX@ (for all 8+ registers)	(Machine Forth)
	!+
	A (address register)


Multitasking:
	*** Aim for a "Realtime OS" with good response time & flexibility
	* Create a task & switch to it (and stay there) - DONE
	* Run multiple tasks - DONE
	* Test out user-mode (ring 3)
	* Priority heap, insert/sift/delete operations
	* Allow different timeslices for each task?


Virtual Consoles (keyboard & screen multiplexing)
	Each VC gets its own keystroke buffer & video buffer.

	System variables:
		current_VC, previous_VC: Pointers to VC objects.
		keybuf: Pointer to current VC's keystroke buffer.

	Switching process:
	* Switch to incoming VC's keyboard buffer (change a pointer)
	* In text mode, switch video page (change pointer, port-write)
		In 80x25 mode, there's room for 8 VC's at 0xB8000.
		Or treat text the same as graphics...
	* In graphics mode:
		Save graphics buffer to outgoing VC
		Load graphics buffer from incoming VC

	Graphics video buffers may be intertwined with the video driver and
	memory manager, especially in bank-switching modes.



Inane ramblings
---------------

Counted strings & null-terminated strings (ASCIIZ)
	Conversion: 4,"asdf" <--> "asdf",0
	cstring->asciiz: shift bytes left, put 0 at end
	asciiz->cstring: shift bytes right while counting, put count at
		beginning


Per-task variables (in EVT, in task.asm)
	Next task
	Output stream OID (VC, serial, network, file, etc...)
	Input stream OID
	Block-flag (task is idle, waiting for input)
	Pause-flag (task is paused indefinitely)

Keyboard controls: (this isn't what they are now!)
	Pause: Pause current task
	Ctrl+Pause (break): Kill current task (no questions asked)

"real" memory management? (VMM)  Implement as needed...
* Heap of free RAM (in kernel pagedir)
* Separate pagedir for each process.. almost 4gig available for mapping.
* Code (r/o) and data (r/w) - about 2gig each (minus kernel, ROM, video...)

Use a heap to keep track of contiguous free areas? (this is simpler with
paging, but still necessary to keep track of physical RAM).
Same goes for disk storage.

Count RAM size, by testing a location in every megabyte, or whatever.
Fetch, 1's-complement it, store, fetch, compare w/ 1's complement..
	(then replace the original value)
No, need to compare with a value in low mem to make sure it's not wrapping
around.. my 486 wraps at 16 megs (24 address lines)

Return values: C always returns in the accumulator (EAX). That's why it only
lets you return one value, I guess :).  You can return as many values as you
want on the stack (I've done this in loader.inc).  Of course, for
large amounts of data, it's best to return a pointer.

Linker: If a routine/variable being linked replaces one that's already in
the symbol table, re-link all references to it. That means we need to keep
some link tables in memory, as small as possible (in a reduced form, without
strings). Do this w/ RDF modules? Maybe. But definitely with the new format.
Important for reflection.


Timing under multitasking? Without OS support, a program can implement a
delay by checking the system time, and "passing on its turn" if the delay
time hasn't elapsed yet.  Or, the OS could keep track of delays for each
process/thread... is that unnecessarily complicated, though?

Scheduling... We could allow programs to say "I need to be called every xxx
microseconds at most" (within the limits of good taste, as configured by the
user).  [i.e., an RTOS - RealTime OS]


Device/interrupt sharing under multitasking?  ITS might be a good
inspiration here.  Hmm.. need a table of devices, showing which process is
using each device. Need "interrupt forwarding", too.  Processes "block"
(pause) while waiting to use a device, or while waiting for the device to
finish an operation (ie, in the "blocking" state).  Good places to start:
Floppy driver, where it waits for IRQ6.  Also, any time a program is waiting
for keyboard input (ie, in getc), other programs could be running.

Interrupt handling: Provide "register ISR" and "unregister ISR" functions. 
These would allow several handlers to be linked to one interrupt, without
any message "chaining" as in DOS.  There could also be some sort of "user
interrupts" as in ITS, if that's useful.
The default interrupt handler should:
	1) Increment the counter for the interrupt
	2) Iterate through a list of ISR's, calling each


IO module -- Abstracted input/output routines.  These routines look at the
current task's input/output objects and use the appropriate low-level
routines to communicate.  If the output object is a VC, direct screen output
will be used (as opposed to VT320 emulation as in Linux, etc).  Routines
will include putc, getc, clear screen, position cursor, etc.  When
outputting to a terminal, routines like clear-screen will use escape codes,
like 'curses' in Unix... but that'll all be handled by the TTY module.

BUFFERS!  Need a 'standard' buffer, since buffers will be used so much..
keyboard, serial ports, shared memory, etc.. especially w/ multitasking. 
For example, a task can have input and output buffers, i.e., stdin and
stdout.  These buffers can connect to VC's, files, serial lines, networks,
whatever.
	Each buffer object has these variables:
		data	buffer area itself (could be a pointer...)
		head	for the transmitting end
		tail	for the receiving end
		src	ptr to source object
		dest	ptr to destination object
		flags and/or types...

	Buffers with multiple sources and/or destinations?  We need one
head, one buffer, and a tail for every output... or a whole buffer for every
output, and every time input is received, we copy it to all the output
buffers.
	Unix fifo's allow multiple input sources, but only one output.  I
guess that's because all the inputs can use the same 'head', but when
someone reads it, the 'tail' gets moved forward, and nobody else can see
what was just read.
	We could just have a 'tail' for every destination, and if one lets
its buffer overflow, it gets an error/warning, and that's its problem :)


IDE: (Careful! Try to avoid corrupting the DOS partition!)
1. IDE driver with no disk write capability
2. 'fdisk' command (Partition table reader - READ ONLY for now)
3. FAT16 filesystem (read-only, for now) - this will come in handy, too.
4. Test test test!
	*** WE ARE HERE as of 8/21/99 ***
5. Enable disk writes
6. Test writing to a "junk" partition (ptn.3 is 8MB, formerly Linux swap)
7. 'fdisk': Enable partition writes (just to set FS type and *boot* flag)
8. 'install' program to install Retro from floppy to hard disk
9. Install Retro, verify it, enable the Retro partition's *boot* flag..
10. Cross fingers.
11. Boot.
12. Autopsy.
13. Rewrite :)


Programs to write, eventually
-----------------------------

Multitasking, paging, memory management

* IDE driver
* Virtual consoles, a la Linux
Serial I/O
Parallel I/O
RTC: Real Time Clock driver (IRQ 8)

TCP/IP
PPP
Ethernet
Telnet
HTTP
FTP
IRC
