9/15/15:
Current issue:

DCB @ 521 is set to 1 by emulator uCode; then clobbered once sector task runs (set to zero) so the disk controller never picks up a control
block and never does anything.

9/16:
"solved" previous issue by issuing a Wake for the KS task on init; this causes the sector task to run first, the Emulator uCode then sets things up correctly.
Not sure if this is how it's supposed to work.

New issue:  Emulator uCode sets up a DCB starting at 1 that looks like:

DCB:   1		<next DCB, not really used here since it will be overwritten by the sector that gets read in -- ALSO a JMP 1 instruction the EMU task is running continuously!>
DCB+1: 1		<status: meaningless, just a placeholder and will be overwritten by the KS/KW tasks>
DCB+2: 44000	<command: read header, label, and data off of drive zero>
DCB+3: 402		<header address: 402>
DCB+4: 402		<label address: 402>
DCB+5: 1		<data address: 1 -- overwrite this very data and the short jump that the CPU is executing at 1 (JMP 1) such that the emulator will start running a real program at 1 when loaded>
.
.
.
.
.
DCB+9: 0

The sector task is noting when sector 0 comes around, and the word task is getting woken up -- at which point it seems to be miscalculating the memory address for disk data (in KNMAR/KNMARW, reg 33).
This ends up being 177777 (-1) and this causes issues.  KNMAR is shared between the sector and word tasks (it's KNMARW in the word task) and is set up by the sector task -- this setup code is not running,
leaving R33 at 0; later 1 is subtracted and we hit our problem.

KNMAR is loaded at KS 01153, this appears to be where we're going wrong (other places in the word task repurpose it for a counter, except for KW01746 which just decrements it)
NO, the above is incorrect.  See below...

KNMARW is loaded at:

KW 01665 (in prep to use as length register for record 0 (header))
KW 01732 (same, for records 1 and 2)
KW 01742 in prep for loading something...
KW 01746 at the beginning of the transfer loop as an address, just decrementing it

At KW1732 we load in the memory block for the record.
KNMARW is used as a count
at REC12A, we load L with the memory block address and load it into KWDCTW (R31) -- KWDX loads this into L, and then puts it into KNMARW.

We are never reaching KW1732 -- why?


10/19/15:

Current issues are around how the "INIT" mode of RWC works (the mysterious fourth dispatch mode aside from Read/Write or Check).

The logic is 


12/3/15:

Project is on backburner while working on SUPDUP; notes for myself on current status:

 - Disk reads/writes work (code is a bit hacky, but it's bound to be), need to allow persisting in-memory disk image back to disk image file.
 - Drive selection logic seems to be correct, but "drive" logic needs to be decoupled from "controller" logic before multiple drives can be implemented
 - Certain programs hang waiting for the disk to complete an action, the disk is inactive, so there is a deadlock.  Unsure exactly, but suspect a race condition
    where the Alto code writes a new DCB (and expects the disk to notice it), but the DCB pointer gets clobbered by the controller after completing a previous task.
 - Keyboard input has a few bugs (SHIFT gets stuck on occasionally) and UI needs major cleanup / refactoring.
 - Disk controller is currently running 75% slower than normal to allow it to work properly; need to figure out why this is necessary -- are my timing calculations
    off or are there issues with the microcode engine?
 - 


 12/17/15:

 Bug found:

 Following code (hit while booting bravox.dsk) gets stuck forever:

 0001 SUB 3,0
 0002 DSZ@ AC3+0
 0003 JMP AC3+1

 regs 0 and 3 are both zero; location 0 contains 177777, this is outside of the RAM area so cannot be modified; this loops forever.
 unsure if this is intentional... (i.e. marks a non-bootable pack)


 Never mind -- pack was corrupted


 12/18/2015:

 Remaining disk controller signals:

 NFER		-- look at -KFER signal to determine what a "fatal error" is
 SWRNRDY	-- llok at -SRWRDY signal to see what "ready" means