From: Alan Cox <alan@linux.intel.com>
Date: Wed, 25 Apr 2018 13:04:39 +0000 (+0100)
Subject: graphics: updates on notes and UBEE format
X-Git-Url: https://git.ndcode.org/public/gitweb.cgi?a=commitdiff_plain;h=58c1ce440b8b597331c2a7352703ecb0e50ea751;p=FUZIX.git

graphics: updates on notes and UBEE format
---

diff --git a/Kernel/README.GRAPHICS b/Kernel/README.GRAPHICS
index e53455da..a5ff7716 100644
--- a/Kernel/README.GRAPHICS
+++ b/Kernel/README.GRAPHICS
@@ -166,3 +166,25 @@ If we go this way then
    code and some stuff is a lot faster that way (eg TRS80 can use otir)
    YES - GFX_READ and GFX_WRITE core are almost identical on most boxes and
    can nicely self modify.
+
+9. We need an API for sprites, for character based displays with loadable
+   fonts and also for >8bit chars in char display.
+
+	struct fontinfo {
+		uint8_t width;	/* Bits */
+		uint8_t height;	/* Lines */
+		uint16_t base;	/* First symbol that is programable */
+		uint16_t last;	/* Last programmable symbol */
+	};
+
+	struct fontload {
+		uint16_t base;
+		uint16_t last
+		uint8_t *data;
+	};
+
+  or similar
+
+10. What about displays that don't really attach as such to a tty
+
+11. Hardware cursor on/off
diff --git a/Kernel/include/graphics.h b/Kernel/include/graphics.h
index c934198f..c33da054 100644
--- a/Kernel/include/graphics.h
+++ b/Kernel/include/graphics.h
@@ -17,6 +17,7 @@ struct display {
 /* Those sufficiently funky */
 #define FMT_SPECTRUM	128
 #define FMT_VDP		129	/* VDP graphics engines */
+#define FMT_UBEE	130	/* Microbee 6545 modes */
   uint8_t hardware;
 #define HW_UNACCEL	1	/* Simple display */
 #define HW_VDP_9918	128	/* Not neccessarily MSX... */