VDU Modifications - nealcrook/multicomp6809 GitHub Wiki

Changes/Bug-fixes to Grant's original code:

  1. CUBIX does a line ending as a LF, CR rather than the usual CR, LF and this showed a bug with the VDU design when the whole screen scrolls up by a line. The blank line that should have appeared at the bottom of the screen was corrupt: it had characters from the line that had just disappeared off the top. The RTL fix to this problem was simple.
  2. The VDU design used a mixture of rising-edge and falling-edge clocks. Although it works fine, timing analysis shows its timing is out-of-spec. The RTL fix to this problem involved a change to the video data output pipeline. The result is a design that is completely timing clean through the FPGA flow at 50MHz. There was little or no gate-count penalty.
  3. The FLEX port showed another line-end problem. FLEX outputs 4 ASCII NUL (0) characters after a CR. In the Olden Days, a CR meant that the (teletype) print head had to move back to the left, and it took some time to do so. The NUL characters provided that time delay. A terminal treats NUL as a non-printing character. The VDU design treats it as a printing character (like a space) and the result is that output lines are indented, and that backspace does not work properly. THIS ONE IS NOT YET FIXED.
  4. The "functional reset" of the UART was glitchy. This has been cleaned up, and the reset function has been extended to reset the pointers of the keyboard input FIFO.
  5. The keyboard map has been extended to add support for the "#~" and "|" keys (key42 and key45) and to make the ESC key generate 0x1b.
  6. The line insert and line delete were not working correctly (it's possible that I introduced this bug when I made changes for single-edge clocking). The RTL fix for this involved some other adjustments so that the insert and delete copy always proceed from 0 to line end; this should reduce the number of comparators needed because it makes the behaviour consistent with the line clear flow.

All of the fixes are in my latest release of the FPGA code.

Futures:

  1. Since the pixel clock is at least 2 system clocks, there is plenty of time to read the character generator and data/attribute store twice per pixel. This means it should be possible to build a double-headed display. Needs some state storage so that the output state machine (which processes the escape codes) can be context-switched.
  2. The FPGA has no true ROM, just RAMs that are initialised at boot. Therefore, for the sake of an additional data path (and appropriate control) the character generator could be made programmable.