Tom_Klok@mindlink.UUCP (Tom Klok) (04/07/91)
> wilmott@utopia.rutgers.edu (Ray Wilmott) writes: > > 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. Actually, both ANTIC mode 2 (graphics 0) and ANTIC mode F (graphics 40, fullscreen gr 8) use 320x192 pixels. The difference isn't really in the OS, though. The OS's responsibility is to set up the screen, and it handles screen operations via S: and E: devices. However, the OS has no support at all for text in a graphics mode, so any text in mode F has to be written to screen ram by the application. Not that it matters... the speed difference has nothing to do with the OS. The problem is in ANTIC, and what you expect it to do. In text modes, ANTIC fetches a single byte from screen ram. This is the character to be displayed. ANTIC then goes off and fetches 8 more bytes of character set data, all by itself, during DMA transfer. As far as the program is concerned, a graphics 0 screen is made up of 960 bytes of data. A graphics 40 screen consists of 7680 bytes of data, because there is no character set lookup. It doesn't matter much to ANTIC, but it sure makes a big difference to the poor application that wants to move stuff around. If the OS supported text in graphics 40, it would be the same problem... far more screen memory to deal with. The biggest speed killer is scrolling. Imagine a 80-col terminal at 9600 baud. Every time it gets a LF at the bottom of the screen, it has to move 7360 bytes and clear 320 bytes. If the LF's come consecutively, that means it's expected to move all that ram at up to 960 times a second. The Atari just ain't up to it. Hopefully, the scrolling won't be that demanding, and the Atari can buffer the input and catch up as soon as some regular text or terminal codes come by. Long strings of LF's can cause buffer overflow, and the the software gags. There is a well-known technique to speed the scrolling up, taking advantage of ANTIC's smarts. Instead of blindly moving all that screen ram around, the 80-col emulator constructs a custom display list. When it's time to scroll, it moves the DL pointers instead of the actual ram. Now it has 320 bytes to clear and 48 bytes to calculate, which is much easier to accomplish. I wrote an 80-column ADDS ViewPoint emulator a few years ago that did this, and it could keep up to 2400 baud without difficulty. Never had an opportunity to try anything faster. I never got around to adding typical terminal features like capture or file transfers, so please don't request a copy. :) Tom Klok a344@mindlink.UUCP
nin15b0b@merrimack.edu (04/07/91)
In article <Apr.6.20.27.51.1991.770@utopia.rutgers.edu>, wilmott@utopia.rutgers.edu (Ray Wilmott) writes: > > The question concerns 80 column (via software) term programs and the > (apparent) 1200 baud limit. BobTerm, I've heard, works at up to 9600 > baud just fine on an unmodified 8-bit in 40 column mode (I say *heard* > because I don't have a 9600 baud modem to confirm it). I have 3 > different 80 column VT100 terminal emulators, and 1200 baud is as high > as they go. I've heard in discussions here and elsewhere that the > reason for this is that what these programs are doing is actually > drawing, character by character, every byte on a graphics 8 screen, > and that there's so much overhead for doing this that the little > old Atari can't keep up. 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? No, this type > of approach I wouldn't expect to yield the same 9600 baud rate since > a "higher res" screen is being handled, but I would think that 2400 > baud should be able to be achieved. 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. > Kermit-65 provides 80 columns and baud rates between 50 & 9600 baud and the truest vt100 emulation I have seen on the Atari. I am using it at 2400 baud right now, and have benn using for a couple of years. When using it at baud rates above 1200, you have you have to issue the command "set flow on" to prevent it from losing characters, and it works flawlessly at 2400 baud. I haven't tested any of the baud rates greater than 2400. Kermit-65 and its source code is available at the atari archive. -- David E. Sheafer internet: nin15b0b@merrimack.edu or uucp: samsung!hubdub!nin15b0b GEnie: D.SHEAFER Freenet ap345 Bitnet: Sheafer_davi@bentley
jsd@arcadien.rice.edu (Shawn Joel Dube) (04/07/91)
In article <1991Apr7.022352.17416@uokmax.ecn.uoknor.edu>, norlin@uokmax.ecn.uoknor.edu (Norman Lin) writes: [ Bunches and bunches of stuff on trying to get the poor little machine do lots and lots stuff really really fast ] I haven't been keeping up with this thread but here are my suggestions on getting 80 col with a buad rate over 1200 [1] How about a queue? [2] Maybe use a smaller font size. [3] As for bitwise operations, have the most popular character combinations store as one which should boast output. (If any of the above have been discussed, sorry) |> ---|\-#-/_|-------/|-------,*.----||---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"--------------- /\ Nice .sig || ________________________________________________________________ Shawn Joel Dube "Never before have so many people known jsd@owlnet.rice.edu so little about so much." -James Burke ________________________________________________________________
wilmott@utopia.rutgers.edu (Ray Wilmott) (04/07/91)
--- Okay, I ask forgiveness from all of you out there for posting this question without even bothering to seriously think about it, or trying to look up relevant information on the topic, but I just thought of something in passing a minute ago, and figured I'd put my foot in my mouth and ask... The question concerns 80 column (via software) term programs and the (apparent) 1200 baud limit. BobTerm, I've heard, works at up to 9600 baud just fine on an unmodified 8-bit in 40 column mode (I say *heard* because I don't have a 9600 baud modem to confirm it). I have 3 different 80 column VT100 terminal emulators, and 1200 baud is as high as they go. I've heard in discussions here and elsewhere that the reason for this is that what these programs are doing is actually drawing, character by character, every byte on a graphics 8 screen, and that there's so much overhead for doing this that the little old Atari can't keep up. 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? No, this type of approach I wouldn't expect to yield the same 9600 baud rate since a "higher res" screen is being handled, but I would think that 2400 baud should be able to be achieved. 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. 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. 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. -Ray
norlin@uokmax.ecn.uoknor.edu (Norman Lin) (04/07/91)
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"---------------
Ordania-DM@cup.portal.com (Charles K Hughes) (04/07/91)
Ray asked about 80 columns (software) and baud rate. Ok Ray, here's the scoop - graphics 0 uses about 2k of memory - 1k for the character set, 1k for the actual screen, and about 50 bytes for the display list. graphics 8 text uses about 9k of memory - 1k for the character set, 8k for the actual screen, and another 250 bytes or so for the display list. Antic is what generates the screen displays. To do this it interrupts the 6502, reads memory, and then returns control to the 6502. It performs this interrupt once per screen line. In a gr. 0 screen there are only 24 lines. In a gr. 8 screen there are 192. As you can see, this means that a gr.8 screen takes about 8 times more interrupts. That isn't all of it... When a gr.0 screen is scrolled, only 1k has to be moved. When a gr.8 screen is scrolled, 8k has to be moved. This movement is the real killer. Ok, continuing along...most programs just use the standard handlers for the screen and the modem. The screen handler is slow, and the modem handlers usually aren't super fast either. Bobterm will work at 2400 (and probably higher) using an XEP80. Express 3.0 tends to fail at 2400 using the XEP80. The difference (so I've been told) is in the screen handlers - Bobterm uses a custom one which is faster. The only adequate reason for 1200 only term programs is because the authors just couldn't figure out how to get 2400 to work. It's possible, but not worth the effort (to the authors in any case). As for rewriting the OS to use the 80 column screen normally - this can be done, but isn't worth it unless the screen memory (8k) is taken from extended memory and only the 130xe has that feature. Charles_K_Hughes@cup.portal.com
scale@abode.wciu.edu (Luis Outumuro) (04/07/91)
Good point! Yes BobTerm is perfect for high speed transfers. I have done both 9600 and 19.2k baud null modem transfers using BobTerm (the 19.2k is possible using an ICD Multi I/O). I believe the latest version of BobTerm is 1.21. Bye............. Luis -- """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Luis Mark Outumuro III | "Well... you're damned if you do, Computer Office Products 818/813-1051 | and you're damned if you don't!" Infoline 818/813-1053 | - Bart Simpson, 1990...
parsons@matt.ksu.ksu.edu (Ghost in the Machine) (04/07/91)
scale@abode.wciu.edu (Luis Outumuro) writes: > Good point! Yes BobTerm is perfect for high speed transfers. I have >done both 9600 and 19.2k baud null modem transfers using BobTerm (the 19.2k is >possible using an ICD Multi I/O). I believe the latest version of BobTerm is >1.21. Bye............. Sure Bobterm can do 19.2k transfers, as long as nothing goes to the screen. The only thing on the screen during a file transfer in Bobterm is the status line which only changes a dozen bytes every 1k. Try a 19.2k or even 9600 ASCII capture and I bet it would lose characters reguardless of what display mode it was using (40 or XEP80). Of course, I don't think you would lose that many with Bobterm even at those speeds, since Bobterm is an excellent program. -- Scott Parish a.k.a. | "I don't believe it." -- Luke Skywalker parsons@matt.ksu.ksu.edu | "That is why you fail." -- Yoda, Jedi Master
jsd@arcadien.rice.edu (Shawn Joel Dube) (04/08/91)
In article <4727.27ff572d@miavx1.acs.muohio.edu>, rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes: |> What would be good would be to produce a new upgrade to the Antic chip (Its |> the graphics chip, isn't it?), one that would have an 80 column mode, and |> patch the OS to be able to take advantage of this new graphics chip. This is |> what Atari should have done in the first place, instead of the XEP80. How about somehow rigging a Hercules graphics board to the machine. -- _____________________________________________________________________________ Shawn Joel Dube "Better men than you and I have tried to disprove jsd@owlnet.rice.edu Ohm's Law. They're ALL gone now." -Massey, Elec 241 _____________________________________________________________________________
rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) (04/08/91)
What would be good would be to produce a new upgrade to the Antic chip (Its
the graphics ship, isn't it?), one that would have an 80 column mode, and
patch the OS to be able to take advantage of this new graphics chip. This is
what Atari should have done in the first place, instead of the XEP80.
BTW, could anyone recommend the best vt100 emulator for someone with a
XM301 modem?
------------------------------------------------------------------------------
Ryan 'Gozar' Collins Question for MAC Users: rlcollins@miavx1.BITNET
|||| Power Without What IS the format of a rc1dsanu@miamiu.BITNET
/ || \ The Price!! MAC HFS floppy disk? R.COLLINS1 on GEnie
------------------------------------------------------------------------------potter@speedway.DAB.GE.COM (Jeff Potter) (04/08/91)
Hello again, Ray! Regarding your questions about 80 columns, baud rate, and the graphics 0 and 8 screens: The graphics 0 screen uses just as many pixels as the graphics 8 screen (40 columns by 24 rows, each character being 8x8 pixels = 320 x 192). The big difference is that graphics 0 is a character mode. This means the OS only has to write to an array of 960 bytes (40 x 24), and Antic will display this as 61,440 pixels. Each byte is used to address the character set RAM (remember all those routines to redefine the character set in old magazine articles?), which contains the 8x8 pixel definition. In graphics 8, however, there are only 8 pixels per byte, and thus 7680 bytes (61,440/8) must be manipulated per screen. Because this is eight times as much memory to be manipulated, the terminal program will run eight times slower (1200 vs. 9600) (I don't believe how nicely that worked out). Jeff -- Jeff Potter ...potter@ge-dab.ge.com ...uunet!ge-dab.GE.COM!potter ...uunet!sunny.dab.ge.com!potter
parsons@matt.ksu.ksu.edu (Ghost in the Machine) (04/09/91)
If jrd@Stony-Brook.SCRC.Symbolics.COM is still around here, maybe he can tell you how Kermit65 does its character manipulation. -- Scott Parish a.k.a. | "I don't believe it." -- Luke Skywalker parsons@matt.ksu.ksu.edu | "That is why you fail." -- Yoda, Jedi Master
asgardia@unixland.uucp (Craig Rothman) (04/10/91)
scale@abode.wciu.edu (Luis Outumuro) writes: > Good point! Yes BobTerm is perfect for high speed transfers. I have > done both 9600 and 19.2k baud null modem transfers using BobTerm (the 19.2k i > possible using an ICD Multi I/O). I believe the latest version of BobTerm is > 1.21. Bye............. NOPE! BT 1.22 is out, but its just for people who had trouble with the dialing in 1.21. 1.21 was the same as 1.20 but it added a driver for xep80.. theres really been no significant changes since 1.20 came out in the program other than the driver for xep.
asgardia@unixland.uucp (Craig Rothman) (04/10/91)
parsons@matt.ksu.ksu.edu (Ghost in the Machine) writes: > If jrd@Stony-Brook.SCRC.Symbolics.COM is still around here, maybe he can > tell you how Kermit65 does its character manipulation. > > -- > Scott Parish a.k.a. | "I don't believe it." -- Luke Skywalker > parsons@matt.ksu.ksu.edu | "That is why you fail." -- Yoda, Jedi Master For that matter id like to know what the rs232 register should be set at. Im using a MIO with this thing and it gives me the error codes that my pal (using an 850) gets when he CONNECTS with the 850 off. What would the register have to be set at!?!?! $WHAT?
potter@speedway.DAB.GE.COM (Jeff Potter) (04/13/91)
re: transplanting a Hercules graphic card: About a year back on GEnie I used to meet (on the realtime conference) a guy who purported to be doing just that. I don't think he succeeded, and I haven't heard from him in a while. Probably not an impossible task, but a thankless one. Jeff P. -- Jeff Potter ...potter@ge-dab.ge.com ...uunet!ge-dab.GE.COM!potter ...uunet!sunny.dab.ge.com!potter
jsd@spotted.rice.edu (Shawn Joel Dube) (04/13/91)
In article <1991Apr12.170745.3125@ge-dab.GE.COM>, potter@speedway.DAB.GE.COM (Jeff Potter) writes: |> re: transplanting a Hercules graphic card: |> |> About a year back on GEnie I used to meet (on the realtime conference) |> a guy who purported to be doing just that. I don't think he succeeded, |> and I haven't heard from him in a while. Probably not an impossible |> task, but a thankless one. |> I would guess all that's involved is converting the Atari bus over to an IBM bus. There may be problems with timing though. As for thankless, probably. At least you get 80x25 text and 7?? x 3?? graphics. Too bad I can't change the OS on my 800. -- _____________________________________________________________________________ Shawn Joel Dube "Better men than you and I have tried to disprove jsd@owlnet.rice.edu Ohm's Law. They're ALL gone now." -Massey, Elec 241 _____________________________________________________________________________