From 8a3171c236cd8607ccf6584400e050116ab9e8ed Mon Sep 17 00:00:00 2001
From: livingcomputermuseum <joshd@livingcomputermuseum.org>
Date: Wed, 20 Jul 2016 13:17:02 -0700
Subject: [PATCH] Delete Notes.txt

Removing dead file.
---
 Contralto/Notes.txt | 91 ---------------------------------------------
 1 file changed, 91 deletions(-)
 delete mode 100644 Contralto/Notes.txt

diff --git a/Contralto/Notes.txt b/Contralto/Notes.txt
deleted file mode 100644
index 00e6c36..0000000
--- a/Contralto/Notes.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-
-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