--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/level2/modules/kernel/ccbkrn.txt	Mon Feb 06 15:51:13 2012 -0600
@@ -0,0 +1,142 @@
+* I eliminated the manual padding of the kernel.  I inserted a fill
+  directive much further down in the source between the "regular"
+  module part of the kernel, and the fe00 page code.  Down at that end
+  the assembler will auto-compute the size needed
+
+* At entry, the kernel now pulls the size of the bootfile from the U
+  stack, which is still setup from CCB, and saves it to
+  its proper place in the DP.  Also misc. DP flags are set - if boot
+  was attempted, and CPU speed is set (CCB uses high speed for coco3)
+
+* at entry, the kernel now installs it's own debug printing and crash
+  routines, something that REL used to do.
+
+* there's a place where some IRQ-ish tables are copied down to the DP,
+  where I found a bug: reg Y was being filled with a bogus source
+  address.  I'm NOT good with PCR addressing, but after fixing, my code
+  changes started working....maybe you want to verify this change.
+
+* read comments in the "calculate memory size" section... I got way
+  lucky on this one!
+
+* the biggest functional changes occur at label L0170: 
+
+  - The kernel no longer verifies itself (and hense adds itself to the
+    modules directory), it now verifies itself and the preloaded
+    bootfile together. The kernel no longer reserves it's own memory
+    either, it now simply calls f$srqmem to do this for us and the
+    bootfile together as one big block.  
+
+  - AFTER reserving system memory and verifying, we now mark up the
+    sysDAT... I don't understand why we have to do this.  Shouldn't
+    f$rsysmem do this for us?!?!  
+
+  - we link to init and set CRC checking and jump to krnp2's exec.
+
+* Near commented out label L01D2, I've commented out this section, it
+  no longer needed as f$rsysmem DOES do this for the entire kernel
+  now, not just the bootfile
+
+* the code at L01DF can be "inlined", nothing calls it but one place.
+  One of the IRQ vectors borrow's this routine's  RTS though ... goofy
+  speghetti code!
+
+* AFTER all the normal included system call files, and BEFORE the FE00
+  page stuff near label S.SysIRQ I added automatic padding
+
+* S.SysIRQ which is supposed to be in FE page, assembles at around
+  fdf1 or so.... which according to the comments is a BAD thing.
+  Nothing seems to happen.  Basically, the FE page code it TOO BIG to
+  fit!
+
+
+And in f$srqmem.asm:
+
+* I modified this system call to request memory starting from 0xff00
+  rather than ed00... it might be a touch lesss efficient AFTER
+  booting, but it sure helped DURING booting.  This is how I reused
+  fsrqmem to setup the KRN and OS9BOOT file in one swoop.
+
+* I changed f$boot to just issue a kernel panic.  I'm not sure if this
+  is the thing to do.  KRNP2 calls f$boot on chdir and open default
+  device error.  I'm not sure if anything else calls it.  Maybe it can
+  be it can be deleted and KRNP2 changed just to panic itself rather
+  than system calling to do so.
+
+
+*** All changes were made to a fresh CVS'd copy of Nitros9 Version 3.2.9.
+*** I have no idea if this all works on a coco2 or a 6309
+
+
+*** CoCoBoot / OS9 Contract:
+
+- Size of the pre-loaded bootfile (NOT boot and cckrn) is passed as
+  the top 2 bytes on the U stack.  MSB on top... the usually motorola
+  byte order.  In Forth lingo, the top cell of the data stack is the
+  size of the bootfile. Calling the kernel works and appears just like
+  calling any other forth word, except we don't return, e.i.:
+
+: gotokernel ( u -- ) \ jump to kernel passing it u - the bootfile
+\ size in bytes, this funtion doesn't return.
+
+- Module CCBKRN is loaded to block 0x3f at offset 0x1000, or 0xf000 in
+  cpu-space. CCBKRN must be exactly 0x0f00 in size and be in a
+  standard os9 executable module format.
+
+- The OS9Boot file is loaded on a page boundary just low enough in
+  cpu-space to fit below 0xf000 (the CCBKRN module)  physical blocks
+  are allocated in order starting with block 0x01 (or 0x31 on a 128k
+  machine).  
+
+- The source of OS9Boot and CCBKRN is not guaranteed!
+
+- Register Guarantees:
+    D  - not guaranteed
+    DP - not guaranteed
+    X  - not guaranteed
+    Y  - not guaranteed but usually will be in the 0x3800-0x6000 range
+    U  - set to top of a stack usually in the 0x7e00-0x7f00
+    S  - not guaranteed but usually will be in the 0x7f00 - 0x8000 range
+    CC - not guaranteed.
+    
+- MMU Guarantees:
+  physical block 0x3f will be banked in at 0xe000-0xff00 in cpu-space
+
+
+
+
+*** CoCoBoot does this but maybe CCBKRN should do instead:
+  
+- physical block 0x00 is in cpu-space at 0x0000 upon calling to
+  CCBKRN.  DP is set to 0x00 and the DP area in block 0x00 is cleared.
+
+- CPU interrupts and Pia0 side B's interrupts are disabled.
+
+- memory map is guaranteed to look like this (in hex):
+
+  00 39 3a 3b 3c 3d 3e 3f
+
+- Physical Block 3b will be cleared to spaces except offset 0x0000:
+  will be initialized to 0x0008.  This serves as a screen pointer to
+  kernel debug printing.
+
+- The GIME registers will be set as follows:
+  
+  starting at 0xff90:
+  6c      init0
+  00      init1
+  00      irq enable
+  00      firq enable
+  0900    timer register
+  0000    unused
+  0320    screen settings
+  0000    ????
+  00      ????
+  ec01    physical video address (block 3b offset 0x0008 )
+  00      horizontal offset / scroll
+  
+  A mirror of these bytes will appear at 0x0090-0x009f in the DP
+
+
+
+Brett M. Gordon
\ No newline at end of file