On Mon, May 25, 2020 at 1:05 AM B 9 <hacke...@gmail.com> wrote: > 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. > >
It's complicated. There's a lot of ROM code you can leverage for sure. > 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 > > http://bitchin100.com/wiki/index.php?title=Model_100_LCD_Programming https://bitchin100.com/files/hardware/HD44102.PDF https://bitchin100.com/files/hardware/lcd.pdf > 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. > > Ken Pettit is the author of VirtualT which has a full implementation of the display chip. You can look at that source code if you're interested. My web based emulator https://bitchin100.com/CloudT has a partial implementation of the display chip + some bugs specifically related to the unused hardware scroll. Once I find my box of round tuits... > (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). > > I used to maintain and enhance DLPlus. But now I focus on LaddieAlpha which runs on Windows, Linux and OSX. It is linked from the front page of bitchin100. Some people have an objection to the Mono or .NET runtime. But I like C# and not having to hand-roll all my own data structures. 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!) > > You're welcome. As to hardware capabilities Bill G didn't spend development effort on... always trade-offs. Get to market sooner or implement one more feature... > > >> 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. > > It's just slightly different choices. HTERM limits to 16-bit unicode characters. The wiki page has some better mappings for characters if you're willing to go for 32-bit unicode. -- John.
