mirror of
https://github.com/livingcomputermuseum/ContrAlto.git
synced 2026-01-17 08:34:15 +00:00
92 lines
4.0 KiB
Plaintext
92 lines
4.0 KiB
Plaintext
|
|
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
|