1$NetBSD: ngle_manual.txt,v 1.6 2026/01/08 08:30:36 macallan Exp $ 2 3The Unofficial NGLE Manual 4 5Preface 6This manual covers what I've been able to figure out about HP's NGLE family of 7graphics devices commonly used in HP PA-RISC workstations, namely HCRX24 and 8PCI Visualize EG. It doesn't explain basic concepts but anyone with some 9graphics driver writing experience should be able to understand it. 10Since there is no official documentation available I used the NGLE code found in 11XFree86 3.3 as a starting point, with plenty of guesswork and experimentation. 12The xf86 code is somewhat obfuscated ( register names are random numbers, values 13written are almost all magic numbers ) and does not actually accelerate any 14graphics operations. It does however use the blitter to clear the framebuffer 15and attribute planes, show how to use a cursor sprite, colour LUTs and so on. 16None of this is endorsed, supported, or (likely) known to Hewlett-Packard. 17All register definitions are from 18https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/nglereg.h 19kernel drivers for HCRX and PCI Visualize EG: 20https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/hyperfb.c 21https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/gftfb.c 22Xorg driver: 23https://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-ngle/dist/src/ 24 251. Now how does this thing work 26All NGLE devices work in more or less the same way, with some differences in 27details and additional features. Every device occupies a 32MB range, half of 28which contains the STI ROM and registers, the other is for framebuffer access. 29My HCRX, living at 0xf6000000, lists the following regions: 30 000c0000 @ 0xf6000000 btlb 31 01000000 @ 0xf7000000 btlb - fb 32 00280000 @ 0xf6100000 btlb 33 00040000 @ 0xf60c0000 btlb 34 00400000 @ 0xf6c00000 btlb 35 00001000 @ 0xf6380000 sys last 36The ones we know what to do with are: 37 000c0000 @ 0xf6000000 - this is the STI ROM 38 01000000 @ 0xf7000000 - framebuffer aperture 39 00280000 @ 0xf6100000 - drawing engine registers 40Sizes vary, but these offsets are the same on my PCI EG and I assue on most if 41not all other NGLE devices. Nothing is known about the others, I would assume 42the 'sys' region at the end contains DMA engine registers we don't want to show 43to userland. 44 45The framebuffer aperture can map exactly one chunk of video memory - things like 46front or back buffers, overlay, attribute planes, and a few unusual things, like 47colour maps and cursor sprite bitmaps. Read and write access can be controlled 48independently, and all settings apply to both the drawing engine and CPU access 49through the framebuffer aperture. 50That means there is no such thing as direct framebuffer access, everything goes 51through the graphics pipeline. If you set the engine to 32bit colour expansion 52then whatever you write into the aperture will be expanded. Also, care must be 53taken to not attempt to access video memory while updating the cursor image or 54colour maps. 55All framebuffer access applies a fixed pitch of 2048 pixels. 56The chips support the usual selection of graphics primitives - rectangle fill, 57copy, colour expansion, and indirect access. There's plenty more ( many have 3D 58features ) but these are completely unknown. 59All register addresses listed here are relative to STI region 2, and all 60registers are 32bit big endian, even on PCI. 61There is no available information on video mode programming other than 62disassembling STI ROMs, and the details are very likely board specific ( HCRX 63is fixed at 1280x1024 for example ). So in order to get going one would: 64- setup STI access 65- get the board type, hardware addresses, video mode etc. from STI's INIT_GRAPH 66 and INQ_CONF calls 67- map framebuffer and registers ( STI region 1 and 2 should be enough ) 68- do our own initialization - STI likes to set the planemask to only allow 69 access to the planes used for text output, and leaves bitmap access modes at 70 something suitable for rectangle fills and character drawing, not something 71 useful to write into the framebuffer 72 732. Framebuffer access 74#define NGLE_BAboth 0x018000 /* read and write mode */ 75#define NGLE_DBA 0x018004 /* Dest. Bitmap Access */ 76#define NGLE_SBA 0x018008 /* Source Bitmap Access */ 77 78#define BA(F,C,S,A,J,B,I) \ 79 (((F)<<31)|((C)<<27)|((S)<<24)|((A)<<21)|((J)<<16)|((B)<<12)|(I)) 80 /* FCCC CSSS AAAJ JJJJ BBBB IIII IIII IIII */ 81 82/* F */ 83#define IndexedDcd 0 /* Pixel data is indexed (pseudo) color */ 84#define FractDcd 1 /* Pixel data is Fractional 8-8-8 */ 85/* C */ 86#define Otc04 2 /* Pixels in each longword transfer (4) */ 87#define Otc32 5 /* Pixels in each longword transfer (32) */ 88#define Otc24 7 /* NGLE uses this for 24bit blits */ 89 /* Should really be... */ 90#define Otc01 7 /* one pixel per longword */ 91/* S */ 92#define Ots08 3 /* Each pixel is size (8)d transfer (1) */ 93#define OtsIndirect 6 /* Each bit goes through FG/BG color(8) */ 94/* A */ 95#define AddrByte 3 /* byte access? Used by NGLE for direct fb */ 96#define AddrLong 5 /* FB address is Long aligned (pixel) */ 97#define Addr24 7 /* used for colour map access */ 98/* B */ 99#define BINapp0I 0x0 /* Application Buffer 0, Indexed */ 100#define BINapp1I 0x1 /* Application Buffer 1, Indexed */ 101#define BINovly 0x2 /* 8 bit overlay */ 102#define BINcursor 0x6 /* cursor bitmap on EG */ 103#define BINcmask 0x7 /* cursor mask on EG */ 104#define BINapp0F8 0xa /* Application Buffer 0, Fractional 8-8-8 */ 105/* next one is a guess, my HCRX24 doesn't seem to have it */ 106#define BINapp1F8 0xb /* Application Buffer 1, Fractional 8-8-8 */ 107#define BINattr 0xd /* Attribute Bitmap */ 108#define BINcmap 0xf /* colour map(s) */ 109/* I assume one of the undefined BIN* accesses the HCRX Z-buffer add-on. No clue 110 * about bit depth or if any bits are used for stencil */ 111 112/* other buffers are unknown */ 113/* J - 'BA just point' - function unknown */ 114/* I - 'BA index base' - function unknown */ 115 116The BIN* values control which buffer we access, Addr* controls how memory is 117presented to the CPU. With AddrLong all pixels are at 32bit boundaries, no 118matter the actual colour depth. Otc* controls how many pixels we write with a 119single 32bit access, so for 8bit pixels we would use Otc04, for 24bit colour 120Otc01, and Otc32 is for mono to colour expansion. OtsIndirect enables colour 121expansion, combined with Otc32 every set bit writes a foreground colour pixel, 122unset bits can be transparent or background. 123The *Dcd bit's exact function is a bit unclear - we set it for 24bit colour 124access to both framebuffer and colour maps. I suspect enabling it on an 8bit 125buffer will result in R3G3B2 output from rendering and blending operations, 126which we know nothing about. 127So, for normal access to the overlay on an HCRX we would use IndexedDcd, Otc04, 128Ots8, AddrByte, BINovly, and set a suitable planemask and binary operation. 129 130All writes to the framebuffer, by CPU or drawing engine, have binary operations 131and a plane maskapplied to them: 132 133#define NGLE_PLANEMASK 0x018018 /* image planemask */ 134 135#define NGLE_IBO 0x01801c /* image binary op */ 136 137#define IBOvals(R,M,X,S,D,L,B,F) \ 138 (((R)<<8)|((M)<<16)|((X)<<24)|((S)<<29)|((D)<<28)|((L)<<31)|((B)<<1)|(F)) 139 /* LSSD XXXX MMMM MMMM RRRR RRRR ???? ??BF */ 140 141/* R is a standard X11 ROP, no idea if the other bits are used for anything */ 142#define RopClr 0x0 143#define RopSrc 0x3 144#define RopInv 0xc 145#define RopSet 0xf 146/* M: 'mask addr offset' - function unknown */ 147/* X */ 148#define BitmapExtent08 3 /* Each write hits ( 8) bits in depth */ 149#define BitmapExtent32 5 /* Each write hits (32) bits in depth */ 150/* S: 'static reg' flag, NGLE sets it for blits, function is unknown but 151 we get occasional garbage in 8bit blits without it */ 152/* D */ 153#define DataDynamic 0 /* Data register reloaded by direct access */ 154#define MaskDynamic 1 /* Mask register reloaded by direct access */ 155/* L */ 156I suspect this selects how many mask bits to use in Otc* less than 32. 157#define MaskOtc 0 /* Mask contains Object Count valid bits */ 158/* B = 1 -> background transparency for masked fills */ 159/* F probably the same for foreground */ 160 161These bit definitions are from xf86, the S bit seems to control masking off 162extra bits when the number of pixels written Otc* exceeds the right border. 163Not sure what exactly the *Dynamic and MaskOtc bits do. 164 165For plain framebuffer memory access just use RopSrc, BitmapExtent* matching your 166target buffer, and everything else zero. 167 168Framebuffer geometry is always 2048 pixels ( with pixel size determined by 169Addr* ) by whatever your hardware allows, areas outside the visible screen may 170or may not be accessible, or backed by memory. 171HCRX always runs in 1280x1024, there is always an overlay and at least one 8bit 172image buffer, HCRX24 has a 24bit buffer that can be used as two 8bit buffers. 173There is no usable off-screen memory, in fact there seem to be registers to the 174right of the visible area. 175On a PCI Visualize EG with 4MB we get an actual 2048x2048 buffer which we can 176use any way we want. 177Finally, the xf86 code writes an 8bit one into 178#define NGLE_CONTROL_FB 0x200005 179before framebuffer access, function is unknown but I suspect it turns off 180pipeline pacing, which is then re-enabled whenever we touch the blitter. 181 1823. Drawing engine 183Basically, you poke coordinates into registers and apply an opcode to the last 184write's address to start an operation ( and specify which ), and there are 185registers to control drawing mode, ROPs etc. 186All register writes go through a pipeline which has 32 entries on HCRX and EG. 187 188#define NGLE_BUSY 0x200000 /* busy register */ 189the first byte will be non-zero if the drawing engine is busy, xf86 uses 8bit 190reads here. 191 192#define NGLE_FIFO 0x200008 /* # of fifo slots */ 193 194X and width in the upper 16bit, Y / height in the lower. 195#define NGLE_DST_XY 0x000800 /* destination XY */ 196#define NGLE_SIZE 0x000804 /* size WH */ 197#define NGLE_SRC_XY 0x000808 /* source XY */ 198#define NGLE_TRANSFER_DATA 0x000820 /* 'transfer data' - this is */ 199 /* a pixel mask on fills */ 200#define NGLE_RECT 0x000200 /* opcode to start a fill */ 201#define NGLE_BLIT 0x000300 /* opcode to start a blit */ 202#define NGLE_HCRX_FASTFILL 0x000140 /* opcode for HCRX fast rect */ 203#define NGLE_RECT_SIZE_START (NGLE_SIZE | NGLE_RECT) 204#define NGLE_BLT_DST_START (NGLE_DST_XY | NGLE_BLIT) 205 206So, in order to draw a rectangle you write coordinates into NGLE_DST_XY, set 207NGLE_TRANSFER_DATA to all ones unless you want it stippled, then write the 208width/height into NGLE_SIZE|NGLE_RECT. Rectangle fills move the destination 209coordinates down by the rectangle's height. 210NGLE_BLIT copies a retangle from SRC_XY to DST_XY with ROP etc. applied. It is 211possible to copy data between buffers, supported combinations of source and 212destination access modes need to be investigated. 213There are likely other opcodes for things like vectors, triangles and so on. 214HCRX_FASTFILL is implied by the xf86 code, but not actually used. It seems to 215work, more or less, but with strange side effects. More invastigation is needed. 216 217#define NGLE_CPR 0x01800c /* control plane register */ 218This is used when drawing into BINattr, on EG we use 0x00000102, on HCRX 2190x04000F00 for 24bit. There has to be some conversion, there is no way the 220attribute plane is actually 32bit. No idea what the individual bits do, has to 221be a combination of buffer selection ( front or back), colour mode / LUT 222selection, likely chip specific. Known values are from xf86. 223 224#define NGLE_FG 0x018010 /* foreground colour */ 225#define NGLE_BG 0x018014 /* background colour */ 226 227For a plain rectangle fill into the overlay we would use 228IBOvals(RopSrc, 0, BitmapExtent08, 1, DataDynamic, 0, 0, 0) 229and 230BA(IndexedDcd, Otc32, OtsIndirect, AddrLong, 0, BINovly, 0) 231... which draws 32 pixels at a time, apparently rectangle fills are internally 232implemented as 32-at-a-time colour expansion, and the S bit makes sure overflow 233pixels on the right border are masked off automatically. Set FG for plain fills, 234BG if using a mask ( in TRANSFER_DATA ), set the B bit to make the background 235transparent. For writes into BINattr use the CPR register instead of FG. 236 237For a simple copy we would use 238BA(IndexedDcd, Otc04, Ots08, AddrLong, 0, BINovly, 0)) 239... to copy four pixels at a time, Addr* doesn't seem to matter, disable colour 240expansion. 241IBOvals(RopSrc, 0, BitmapExtent08, 1, DataDynamic, MaskOtc, 0, 0) 242... to write 8bit deep, plain copy, mask off extra pixels if our width isn't a 243multiple of 4. 244 245To do the same operations on a 24bit buffer just use Otc01, FractionalDcd and 246BitmapExtent32. No need to set the S bit on copies since all pixels are 32bit 247anyway, and in order to copy between different buffers just set DBA and SBA 248separately. Make sure they use the same depth or results may get weird. 249 2504. Indirect framebuffer writes 251HP calls the mechanism 'BINC', no idea what it stands for. Basically, you set a 252target address and then write data into registers which trigger operations 253programmed in DBA and IBO, with the target address being updated according to 254which data register we write to. There is also a mechanism to copy blocks, used 255for colour maps. 256 257#define NGLE_BINC_SRC 0x000480 /* BINC src */ 258#define NGLE_BINC_DST 0x0004a0 /* BINC dst */ 259#define NGLE_BINC_MASK 0x0005a0 /* BINC pixel mask */ 260#define NGLE_BINC_DATA 0x0005c0 /* BINC data, inc X, some sort of blending */ 261#define NGLE_BINC_DATA_R 0x000600 /* BINC data, inc X */ 262#define NGLE_BINC_DATA_D 0x000620 /* BINC data, inc Y */ 263#define NGLE_BINC_DATA_U 0x000640 /* BINC data, dec Y */ 264#define NGLE_BINC_DATA_L 0x000660 /* BINC data, dec X */ 265#define NGLE_BINC_DATA_DR 0x000680 /* BINC data, inc X, inc Y */ 266#define NGLE_BINC_DATA_DL 0x0006a0 /* BINC data, dec X, inc Y */ 267#define NGLE_BINC_DATA_UR 0x0006c0 /* BINC data, inc X, dec Y */ 268#define NGLE_BINC_DATA_UL 0x0006e0 /* BINC data, dec X, dec Y */ 269 270SRC and DST are 'linear' addresses, depending on Addr* in DBA, pitch is Addr* 271times 2048. 272The BINC_DATA registers differ only in the way the destination address is 273updated, up or down a line, left or right by Otc* pixels. 274So, in order to draw a 12x20 pixel character to (100,150) we would use the same 275DBA and IBO values we used for rectangles, write 0xfff00000 into NGLE_BINC_MASK 276to make sure we only write 12 pixels per line, set FG and BG as needed, set 277BINC_DST to (100 * 4 + 150 * 8192) - we're in AddrLong - then poke our character 278bitmap into NGLE_BINC_DATA_D, one left aligned line at a time. 279BINC operations by themselves are unlikely to overrun the pipeline but they may 280if a lot of them happen while something more time consuming, like a full screen 281scroll, is in progress. 282Not sure what exactly NGLE_BINC_DATA does, the xf86 code uses it for colour map 283updates. 284Indirect framebuffer writes are generally faster than writing into the aperture, 285x11perf -copypixwin500 went from 22/s when using memcpy() to 74/s using BINC on 286HCRX in 24bit. 287 2885. Colour maps 289LUTs are held in their own buffer ( BINcmap ), size is likely chip-specific. 290HCRX has room for at least three 256 entry colour maps, EG probably has two or 291three. 292Basically, we BINC-write our colour map into BINcmap, then tell the hardware to 293update the actual colour map(s) from that buffer. 294We'd use: 295BA(FractDcd, Otc01, Ots08, Addr24, 0, BINcmap, 0) 296IBOvals(RopSrc, 0, BitmapExtent08, 0, DataDynamic, MaskOtc, 0, 0) 297Not sure how 'Addr24' differs from AddrLong, but that's what the xf86 code uses. 298Then set BINC_DST to 0 ( or whichever entry we want to update - 4 for the 2nd 299entry etc. ) and poke our colour map into BINC_DATA_R, one entry at a time. 300Sending it to the DAC works like this - set BINC_SRC to 0, then write a command 301into the appropriate LUTBLT register: 302#define NGLE_EG_LUTBLT 0x200118 /* EG LUT blt ctrl */ 303 /* EWRRRROO OOOOOOOO TTRRRRLL LLLLLLLL */ 304 #define LBC_ENABLE 0x80000000 305 #define LBC_WAIT_BLANK 0x40000000 306 #define LBS_OFFSET_SHIFT 16 307 #define LBC_TYPE_MASK 0xc000 308 #define LBC_TYPE_CMAP 0 309 #define LBC_TYPE_CURSOR 0x8000 310 #define LBC_TYPE_OVERLAY 0xc000 311 #define LBC_LENGTH_SHIFT 0 312In order to update the whole thing we would use 313LBC_ENABLE | LBC_TYPE_CMAP | 0x100 314Length and offset are in 32bit words. 315 316HCRX uses a different register: 317#define NGLE_HCRX_LUTBLT 0x210020 /* HCRX LUT blt ctrl */ 318... which otherwise works exactly the same way. 319 320On HCRX we need: 321- a linear ramp in the first 256 entries, 24bit output goes through this. 322- the overlay's colour map starts at entry 512 323- hardware sprite colours are controlled by two entries using LBC_TYPE_CURSOR 324 and offset 0 325 326On EG: 327- the main colour map lives at offset 0, type LBC_TYPE_CMAP 328- four entries at offset 0 with LBC_TYPE_CURSOR, the first two do nothing, the 329 other two are cursor sprite colours 330 331There seems to be at least 512 entries worth of buffer space on both HCRX and 332EG, xf86 keeps the entire palette in there, updates entries as needed and always 333LUTBLTs the whole thing. 334 3356. Hardware cursor 336Again, chip-specific. Cursor position works the same on HCRX and PCI EG, uses 337different registers though. Older chips use a different register layout. 338Bitmap access is different on HCRX, both support a 64x64 sprite. 339 340#define NGLE_EG_CURSOR 0x200100 /* cursor coordinates on EG */ 341 #define EG_ENABLE_CURSOR 0x80000000 342#define NGLE_HCRX_CURSOR 0x210000 /* HCRX cursor coord & enable */ 343 #define HCRX_ENABLE_CURSOR 0x80000000 344Coordinates are signed 12bit quantities, X in the upper halfword, Y in the 345lower, enable bit at 0x80000000. There is no hotspot register, negative 346coordinates will move the sprite partially off screen as expected. 347On HCRX we need to write zero into 348#define NGLE_HCRX_VBUS 0x000420 /* HCRX video bus access */ 349before writing NGLE_HCRX_CURSOR. 350 351Cursor bitmap access on HCRX is simple: 352#define NGLE_HCRX_CURSOR_ADDR 0x210004 /* HCRX cursor address */ 353#define NGLE_HCRX_CURSOR_DATA 0x210008 /* HCRX cursor data */ 354The mask is at offset 0, bitmap at 0x80. Subsequent writes to CURSOR_DATA update 355the address as expected. 356 357On EG we have to use BINC writes: 358BA(IndexedDcd, Otc32, 0, AddrLong, 0, BINcmask, 0) 359IBOvals(RopSrc, 0, 0, 0, DataDynamic, MaskOtc, 0, 0) 360set BINC_DST to 0, then poke the mask into NGLE_BINC_DATA_R and 361NGLE_BINC_DATA_DL - write 32bit, move right, write the rest of the line, move 362down/left to the next line etc. 363No LUTBLT analog here, for the the cursor bitmap use BINcursor. 364 3657. Miscellaneous 366#define NGLE_EG_MISCVID 0x200218 /* Artist misc video */ 367 #define MISCVID_VIDEO_ON 0x0a000000 368#define NGLE_EG_MISCCTL 0x200308 /* Artist misc ctrl */ 369 #define MISCCTL_VIDEO_ON 0x00800000 370These control video output on EG - xf86 sets both to enable output, clears both 371to turn it off. Need to check which bit does what exactly. 372 373#define NGLE_HCRX_MISCVID 0x210040 /* HCRX misc video */ 374 #define HCRX_BOOST_ENABLE 0x80000000 /* extra high signal level */ 375 #define HCRX_VIDEO_ENABLE 0x0A000000 376 #define HCRX_OUTPUT_ENABLE 0x01000000 377xf86 uses HCRX_VIDEO_ENABLE, the other bits were found by experiment, functions 378are guesswork. There are other bits with unknown function. 379 3808. Visualize EG notes 381All referenves to 'EG' and the like strictly refer to the PCI Visualize EG card 382with 4MB video memory. There is a GSC variant which may have 2MB or 4MB, other 383differences are unknown. 384The xf86 code does not support the PCI EG at all, it seems to be somewhat 385similar to the 'Artist' variant, the cursor register is at the same address but 386works as on HCRX. I suspect the GSC variant to be more like Artist. 387It is possible to put cards with enough memory into double buffer mode using 388the firmware configuration menu - I need to figure out what exactly that does. 389Same with grey scale mode, which may just select a different default palette. 390 3919. HCRX notes 392#define NGLE_HCRX_PLANE_ENABLE 0x21003c /* HCRX plane enable */ 393Controls which bit planes are used for output. The uppper byte seems to control 394the overlay, the lower 24 are for the image plane(s). Exact bit assignment 395needs to be checked. We set it fo 0xffffffff for 24bit with 8bit overlay. 396 397This is set by xf86, other values unknown. 398#define NGLE_HCRX_HB_MODE2 0x210120 /* HCRX 'hyperbowl' mode 2 */ 399 #define HYPERBOWL_MODE2_8_24 15 400 401This seems to be the HCRX's analogue to FX's force attribute register - we can 402switch between overlay opacity and image plane display mode on the fly 403#define NGLE_HCRX_HB_MODE 0x210130 /* HCRX 'hyperbowl' */ 404 #define HYPERBOWL_MODE_FOR_8_OVER_88_LUT0_NO_TRANSPARENCIES 4 405 #define HYPERBOWL_MODE01_8_24_LUT0_TRANSPARENT_LUT1_OPAQUE 8 406 #define HYPERBOWL_MODE01_8_24_LUT0_OPAQUE_LUT1_OPAQUE 10 407 408Xf86 always writes NGLE_HCRX_HB_MODE twice, apparently working around a hardware 409bug. It also initializes a few unexplained registers with magic numbers: 410#define NGLE_REG_42 0x210028 /* these seem to control */ 411#define NGLE_REG_43 0x21002c /* how the 24bit planes */ 412#define NGLE_REG_44 0x210030 /* are displayed on HCRX - */ 413#define NGLE_REG_45 0x210034 /* no info on bits */ 414 415For 24bit it writes: 416NGLE_REG_42, 0x014c0148 417NGLE_REG_43, 0x404c4048 418NGLE_REG_44, 0x034c0348 419NGLE_REG_45, 0x444c4448 420 421... and for 8bit: 422NGLE_REG_42, 0 423NGLE_REG_43, 0 424NGLE_REG_44, 0 425NGLE_REG_45, 0x444c4048 426 427Also, xf86 has this comment when setting things up for 24bit display: 428 /********************************************** 429 * Write overlay transparency mask so only entry 255 is transparent 430 **********************************************/ 431... and then proceeds to BINC write 0 to (1532,0) in the overlay. 432 433So, to setup HCRX24 my driver does: 434- program the hyperbowl registers as described above 435- blit 0x04000F00 into the attribute plane 436- make overlay colour 255 transparent as described above 437- blit the 24bit buffer all white - NetBSD uses an R3G3B2 palette for console 438 output, that way 255 will still be white 439- write a linear ramp into colour map 0 - STI leaves it at all zero which gives 440 us a black screen no matter what we write into the image buffer 441- write an R3G3B2 palette into colour map 2, aka offset 512, for the overlay 442With this we can 'switch' to 24bit display by blitting 255 all over the overlay 443and back to console output by just resuming character drawing ( and blitting the 444image buffer white again ) 445 446The ROM is in byte mode, as expected of a GSC device, with every 32bit word 447containing one byte of ROM data. The first word also has configuration bits: 448#define HCRX_CONFIG_24BIT 0x100 449 450On my HCRX24Z this reads 0x700, I assume 0x200 or 0x400 indicates the Z-Buffer 451add-on's presence. 452 453