# Summary of known issues for w11a CPU and systems

General issues are listed on a separate document
[README_known_issues.md](README_known_issues.md).

This file descibes issues of the w11 CPU.

### Table of content

- [Known differences between w11a and KB11-C (11/70)](#user-content-diff)
- [Known limitations](#user-content-lim)
- [Known bugs](#user-content-bug)

### <a id="diff">Known differences between w11a and KB11-C (11/70)</a>

- the `SPL` instruction in the 11/70 always fetched the next instruction
  regardless of pending device or even console interrupts. This is known
  as the infamous _spl bug_, see
  - https://minnie.tuhs.org/pipermail/tuhs/2006-September/002692.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002693.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002694.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002695.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002701.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002695.html
  - https://minnie.tuhs.org/pipermail/tuhs/2006-October/002702.html

  In the w11a the `SPL` has 11/70 semantics in kernel mode, thus next no 
  traps or interrupts, but in supervisor and user mode `SPL` really acts as 
  `NOOP`, so traps and interrupts are taken as for all other instructions.   
  **--> The w11a isn't bug compatible with the 11/70.**
- A 'red stack violation' looses PSW, a 0 is pushed in stack.
- The 'instruction complete flag' in `SSR0` is not implemented, it is 
  permanently '0', `SSR2` will not record vector addresses in case of a
  vector fetch fault. Recovery of vector fetch faults is therefore not
  possible, but only 11/45 and 11/70 supported this, no OS used that, and
  it's even unclear whether it can be practically used.
- the 11/70 maps the 18 bit UNIBUS address space into the upper part of
  the 22bit extended mode address space. With UNIBUS mapping enabled, this
  allowed to access via 17000000:17757777 the memory exactly as a UNIBUS
  device would see it. The w11a doesn't implement this remapping, an access
  in the range 17000000:17757777 causes a NXM fault.

All four points relate to very 11/70 specific behaviour, no operating system
depends on them, therefore they are considered acceptable implementation
differences.

### <a id="lim">Known limitations</a>

- some programs use timing loops based on the execution speed of the
  original processors. This can lead to spurious timeouts, especially
  in old test programs.  
  **--> a 'CPU throttle mechanism' will be added in a future version to 
  circumvent this for some old test codes.**
- the emulated I/O can lead to apparently slow device reaction times,
  especially when the server runs as normal user process. This can lead
  to timeout, again mostly in test programs.  
  **--> a 'watch dog' mechanism will be added in a future version which
  suspends the CPU when the server doesn't respond fast enough.**

### <a id="bug">Known bugs</a>

- **TCK-038 pri=H: DL11: output chars lost**  
Part of the output can be lost when `xxdp` test `eqkce1` is run on FPGA, also
some kernel messages during the 211BSD boot sequence. Most likely cause is that
device ready polls timeout before the rlink interface can serve the interrupt.

- **TCK-036 pri=L: RK11: hardware poll not working**  
The RK11/RK05 hardware poll logic is probably not reflecting the
behaviour of the real drive.

- **TCK-035 pri=L: RK11: no proper `NXM` check in 18bit systems**  
No `NXM` error is generated when a RK11 read or write reaches the top 
of memory in 18 bit addressing. Crash dump routines use this to detect
end-of-memory.

- **TCK-032 pri=M: RK11: polling on `DRY` in `RKDS` doesn't work**  
`DRY` in `RKDS` goes 1->0 immediately with `RDY` in `RKCS` when a function is
started. In a real RK05 drive `DRY` went to 0 after a short delay. Some
basic hardware tests are sensitive to this.

- **TCK-030 pri=L: CPU: `SSR0` trap bit set when access aborted**  
The 'trap bit' (bit 12: 10000) is set even when the access is aborted.

- **TCK-029 pri=L: CPU: `AIB` `A` bit set for all accesses**  
The MMU trap condition isn't properly decoded
   
- **TCK-028 pri=H: CPU: interrupt and trap precedence**  
In case of multiple trap, fault, or interrupt conditions the precedence
isn't implemented correctly.

- **TCK-026 pri=L: CPU: src+dst delta added in `SSR1` when same register**  
The `SSR1` content after a fault is logically correct in w11a, but
different from 11/70.

- **TCK-025 pri=L: CPU: no mmu trap when bit9 clearing instruction traps**  
In the 11/70 the instruction which affects mmu trap can cause a trap
already, in w11a only the next instruction will trap.

- **TCK-014 pri=M: RK11: write protect action too slow**  
Some simple RK11 drivers, especially in tests, don't poll for completion
of a write protect command. Due to the emulated I/O this can cause errors.

- The last four issues are caused by an incorrect implementation of the trap
logic, which leads to a different precendence when multiple trap, fault,
or interrupt occur
  - **TCK-007 pri=H: CPU: no trap-4 after emt on odd stack**
  - **TCK-006 pri=H: CPU: no yel-stack trap after `jsr pc,nnn(pc)`**
  - **TCK-004 pri=H: CPU: yel-stack by interrupt causes loop-up**
  - **TCK-003 pri=H: CPU: yel-stack by `IOT` pushes two stack frames**

