Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!rutgers!clyde!cbatt!ihnp4!ihwpt!knudsen From: knudsen@ihwpt.UUCP (mike knudsen) Newsgroups: comp.sys.m6809 Subject: Re: 64 COLUMN TEXT SCREEN Message-ID: <1237@ihwpt.UUCP> Date: Mon, 17-Nov-86 12:27:51 EST Article-I.D.: ihwpt.1237 Posted: Mon Nov 17 12:27:51 1986 Date-Received: Tue, 18-Nov-86 01:31:44 EST References: <8463VMR@PSUVMA> Organization: AT&T Bell Labs, Naperville, IL Lines: 32 > I HEARD THAT THE COCO III COULD USE A 64 COLUMN TEXT SCREEN AS WELL AS 32,40, > AND 80 COLUMNS. IS THIS TRUE? DOES ANYONE KNOW HOW TO DO IT? > VIC RICKER Ah, another Penn Stater still healthy after the Notre Dame cliffhanger. Yes, the CocoIII hardware can set 64 columns by putting 5 in bits 2-4 of FF99. It's a shame BASIC doesn't support this, since 64 cols is good for word processing and much easier to read on TVs and some monitors. However, the new BASIC graphics modes are all 40 or 80 bytes per line, so the text screens had to follow suit. Also, you'd have to write your own screen driver to use it, unless BASIC's is parameterized enough to adapt to 64 cols on its own once you've poked a few variables in low RAM. More general problem: You can poke all sorts of stuff into FF90-9F, but BASIC is continually flogging (refreshing) all these GIME regs. Thus, to get your own GIME bit mods to stick, you must either: (1) sieze all control from BASIC (block interrupts, don't call BASIC routines to print screen or read keyboard; (2) find where BASIC gets its refresh values and POKE those instead of the GIME directly; or (3) find BASIC's refreshing code and NOP it out. Since BASIC ends up in RAM, doing (2) or (3) should be easy "once we know how." Are you disassembler jocks listening? BTW, some refresh values and interrupt vectors live in FEXX. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs (AT&T) (312)-979-4132 (work) You think AT&T thinks about CoCos, music, or Star Trek? No? Then, these opinions must be all mine!