On Fri, Nov 11, 2022 at 4:00 PM B 9 <hacke...@gmail.com> wrote: > On Fri, Nov 11, 2022 at 11:12 AM John R. Hogerhuis <jho...@pobox.com> > wrote: > >> >> >> I think you probably are the discoverer of that, even if the Model T was > over twenty years old when you started. I don't believe hobbyists had easy > access to datasheets in the 1980s. >
Right. But I got that reference from Ken so he saw it when he wrote VirtualT. But maybe I was the first one to play with it on real hardware since Gates and Co chose not to implement hardware flow control and higher baud rates (who would ever need more than 19200 bps?) > > I wonder when the last book for Model T tinkerers was published? So much > new knowledge has been found since then. Wikis are great for looking up > information, if you already know what you don't know, but they're not so > great for giving a person new to a subject an idea of what is available and > what is even important. It's hard to read through an entire wiki, or even > to flip through one. By design, wikis are supposed to be quick to write, > not well thought out or coherent. That's one reason I've more often turned > to the Model T books and documentation instead of mailing list archives or > wiki pages. > The best books I've seen are Inside The Model 100 (Oppedahl) Hidden Powers of the TRS-80 Model 100 (Morgan) > > > While Tips, Peeks, and Pokes > <https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers/> > (Anderson, 1985) can't be said to be coherent, it is a carefully curated > collection of short, non-obvious tips, expressed succinctly. > I feel like a second volume of such tips could be created with everything > that has be learned since 1985. For example, the ability to point a string > to a memory address is a pretty neat trick, as is the ability to exceed the > serial port speed limit. Also, some of the tricks could be updated. > > I've never read it, I will have to check it out. Yeah I've been thinking about writing something. It would mostly be a research project. And there's a lot I don't know, and a lot that only a few ever knew. How about "TRS-80 Model 100 Pet Tricks: Rediscovering The Lost Dark Art of Performant BASIC and ML Programming" > Just in my own research, I've found that I could expand on a few of > Anderson's articles. For example, the PEEK to distinguish > <https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers/page/n25/mode/1up> > between a Model 100, Tandy 200, and Tandy 102 could also distinguish the > Kyocera Kyotronic-85, the Olivetti M10 (Italy), the M10 (US), and the NEC > family of portables. And Anderson's discussion of the RAM Directory > <https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers/page/n43/mode/1up> > describes the addresses of files in memory as only useful to assembly > language programmers, but there are actually good use cases for accessing > RAM files directly in BASIC using PEEK (fast, random access of binary data > without needing a duplicate in RAM). > > If you want to understand the filesystem stuff you need to read the NEC programmer's guides over at Web8201. Fantastic stuff. > > Is the source code to TBACK.EXE available to learn from? >>> >> >> No. HTERM source is available if you want to look at serial stuff. >> > > I was actually wondering about how TBACK.EXE handles XON/XOFF. Does the > program it sends to the Model T use hardware handshaking? Does it work with > a Tandy 200 or only a Model 100? How does it configure the serial port on > the PC side? > I will look. I don't think it depends on that. Since the magic words are RUN"COM:98N1E", the E means enable, so XON/XOFF is in play. But I it's not enough to slow things down on Linux, so, IIRC, when injecting it simply adds a sufficient delay to avoid overrunning the receive buffer + tokenizer logic. For backup/restore it uses hardware flow control to achieve maximum possible speed. TBACK is model 100 only. -- John.
