Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!uokmax!norlin From: norlin@uokmax.ecn.uoknor.edu (Norman Lin) Newsgroups: comp.sys.atari.8bit Subject: Re: 80 columns and baud rate Keywords: why? Message-ID: <1991Apr7.022352.17416@uokmax.ecn.uoknor.edu> Date: 7 Apr 91 02:23:52 GMT References: Organization: Engineering Computer Network, University of Oklahoma, Norman, OK Lines: 97 wilmott@utopia.rutgers.edu (Ray Wilmott) writes: >That's all well and good, but wouldn't it be >possible to patch directly into the OS and make the machine think >that it's normal mode of operation is graphics 8, not graphics 0 and >give it the 80 column character set as its normal character set, thus >letting the OS directly deal with drawing the screen? You can, but you would gain nothing. In fact, most (many) 80-column emulators use a custom device handler to hook into the Operating System, which "lets the OS directly deal with" the screen handling; it's not the OS link that's the problem. See below... >Isn't a graphics 0 screen made up >of 8x8 bit characters, 40 column across and 20 columns down? And a >graphics 8 screen 320x192 pixels? (this is from memory so...) >If so, thats 51,200 pixels versus 61,440 pixels. So why can one only >go 1200 baud while the other can go 9600 baud? Seems to me its only >because one *directly* uses the OS to draw the screen in a native >manner, while the other fights against the OS to forcibly draw >a slightly higher res screen. The difference lies in the way that screen data is interpreted in each mode. In graphics mode 0, one single byte acts as a pointer to the ROM-based character set at $E000. Thus, the value of 1 stored into screen memory in graphics mode 0 causes a '!' to appear on the screen (note that these "internal" character numbers are not ATASCII). One single byte causes 8 predefined bytes of data, with 8 bits per byte, to appear on the screen in the form of a character. So with one byte, you're getting 64 bits, but you don't have the same kind of control you do in bitmap modes (see below). Graphics mode 0 takes up 40 x 24 = 960 bytes. Graphics mode 8, on the other hand, is a bitmap mode. One single byte causes 1 byte of data to appear on the screen, in the form of 8 bits horizontally. A '1' stored to screen memory in graphics 8 would appear as X Where X is the bit you turned on. A '255' stored to screen memory in graphics 8 would cause the following to appear: XXXXXXXX See? The binary representation of '255' is '11111111', and this is mapped directly to the screen. A graphics mode 8 (or, to be technically precise, mode 8+16 -- mode 8 with no text window) screen takes 40 x 192 = 7680 bytes. Why 40 x 192? 320 pixels horizontally / 8 pixels per byte = 40 bytes horizontally, and vertically there are 192 individually addressable lines in the display list, so that's 40 x 192. >And so...wouldn't it be possible to patch into and rewrite part of >the OS to make *it* naturally handle a graphics 8 screen of text? >On the old 800 and 400 this would be a trick since the OS is in ROM, >but on the XL/XE class machines, you could copy the OS to the RAM >underneath and then just patch whatever you want in there. The problem is not the Operating System. Actually the Atari is amazingly flexible in that it allows you to create your own device handlers, which is what most 80 column programs do. These device handlers interface to the O.S. just as the built-in device handlers do, with no inherent loss of efficiency; all you do is modify a few pointer tables. It's the programmer's responsibility to write efficeient real-time device handlers. For instance, a typical 80-column emulator will replace the E: handler, which is the screen editor. You could, for instance, write an E: handler to emulate a graphics mode 0 screen in graphics 8, but it would run SLOWER even though it would appear to be the SAME. Why? You'd have to write the 8 times as much data to the screen. You'd need to, yourself, use the character number as a pointer, fetch the 8 bytes of character set data from the character set map, then write those EIGHT bytes to the screen. In graphics mode 0, the hardware (presumably ANTIC) does this by itself (incidentally it 'steals' cycles from the CPU to do this, which is why things run thirty-some percent faster when you turn off the screen). Things slow down even more when you try to go to 80 columns. An 80 column character is 4 bits wide, while screen data in graphics 8 is 8 bits wide. This means you have to do bit shifting or, at the very least, bit masking, which adds a bit of overhead to every single character you write to the screen. And when updating a whole screen, that adds up quickly. >Again, this is just a brief idea, without much thought into the >matter - I eagerly await someone to tell me where my reasoning is >fouled up (or to prove me right and make a 2400 baud 80 col term). >Thanks. Whew. Hope that made some sense. Feel free to ask for clarifications if anything's unclear. > -Ray ---|\-#-/_|-------/|-------,*.----||---Norman Lin, University of Oklahoma---- ---|/-----|------/-|---,"--|---,"-||------norlin@uokmax.ecn.uoknor.edu------- --/|------------/-*'---|/------|--||-----(IP addr: 129.15.[20|22|24].2)------ -|/|\---/_|-----|-----------------||-"I gazed in your eyes, and saw the moon- --\|/-----|----*'-----------------||------------and the skies"---------------