> > From: "John R. Hogerhuis" <jho...@pobox.com> > To: m...@bitchin100.com > > Yes the Model T screen driver is slow. It's possible we could speed it up > a little because there is some hardware scrolling capability built into the > video chip drivers that the ROM does not make use of. > > But that would > a) Require creating code in option rom or in RAM to do all character > generation >
Are you sure that's required? The demos I found don't seem to be doing that. > b) It's not clear how much the speed-up would be. > One demo, by Philip Avery, claims over 10x speed acceleration using hardware scrolling. According to Hidden Powers of the Model 100 <https://archive.org/details/HiddenPowersOfTheTrs80Model100/page/n183/mode/1up/>, the screen can only show 90 characters per second with a maximum download speed to RAM of 240 cps. My own tests with scrolling speed in TELCOM is that I can get about 1KB in 6 seconds (170 cps) if the screen has to scroll during download, but I save about a second per kilobyte (200 cps) if I disable screen scrolling but still send characters to the screen. Of course, this is with software flow control, so that may be an additional bottleneck. It's strange and fascinating that the Model T had hardware scrolling acceleration it never used. Do you have a link for more information about it? I tried googling and all I came up with was: http://www.club100.org/memfiles/index.php?action=view&filename=LCDTST.DO&directory=Steve%20Adolph and http://www.club100.org/memfiles/index.php?&direction=1&order=nom&directory=Philip%20Avery/Hardware%20Scroll Neither one worked on my Model 200, but I don't know if it's a lack of hardware support or if it's just writing to the wrong addresses. The Philip Avery documentation mentions "Kenneth Pettit", but googling for him and "hardware scroll" turns up nothing. (By the way, the Bitchin100 site could use a friendly "how to transfer binary files over a serial port using only builtin software" right on the front page. Fortunately, after some more googling, I found a Github repository that made it easy: https://github.com/bkw777/dlplus). > You can read my research into Model 100 flow control (that went into > HTERM) in the wiki article > http://bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface > Wow! After reading through that, I'm impressed you figured it all out. Thank you for documenting it so well. (Again, I'm struck by how weird it is that these computers had hardware capabilities that were never used, not even documented!) > Does HTERM have a terminfo file listing the escape sequences it can do? >> Not that it needs one if it has full ANSI compatibility, of course. >> > I can't put my hands on the T102 version but I've attached the one I have > for T200. > I'm not sure if it's because I had the mailing list in "digest" mode, but I didn't receive the attachment. Could you please send again or post it somewhere? > The mapping for the extended characters is in the code and on the wiki. > Thanks, the wiki didn't seem to have all the characters, so I went straight to the source which also seemed more accurate. Just to double check: You use the same Unicode mapping on the Model 100, >> 102, and 200, right? >> > Yeah I think we did the 102. But they are indeed different so we actually > need separate mappings and different builds of HTERM. > I believe HTERM uses the Model 100 character set. I've been told the Model 102 and Tandy 200 sets are the same, and it's definitely not the Tandy 200 character set. —b9
