Model 100 Hints and Tips

There is a problem within the TRS-80 Model 100 that makes the machine seem to "hang". This is usually caused by pressing the PRINT key, which attempts to copy the contents of the non-graphic Model 100 screen to an attached printer. The problem manifests itself if there is no printer attached.

Additionally, this can be caused by a BASIC or Machine Language (M/L) program, or one of the ROM programs TEXT, TELCOM, SCHEDL, and ADDRSS attempting to output to a non-existant printer.

Usually, pressing SHIFT-BREAK will produce an "aborted" message within a ROM program, or "?IO Error" within a BASIC program. If a machine language program is executing and the (non-documented) error vector is not 'plugged', an "?IO Error" will be generated and a return will be made to BASIC.

Disabling the PRINT key is touchy at best. Actually, it is possible to disable the key, and all the 'miniature' keys immediately underneath the display (F1-F8, PASTE, LABEL, PAUSE/ BREAK, etc.). In my opinion, though, the loss of the function keys is greater than the problem of the PRINT key.

Since there is no easy, '1-poke' method of totazlly disabling the printer in the Model 100, we must be satisfied with the "?IO Error" in BASIC (unless it is trapped with an ON ERROR statement). On the other hand, there is a simple way in Machine Language or BASIC to tell if there is a printer attached.

The PASTE buffer has been documented by more than one program (although NOT by Radio Shack!) to reside at the address at F88CH-F88DH (63628-63629 decimal). This address is stored in typical 8080 LSB/MSB format. What isn't so well documented is that the two bytes preceding that address F88A-F88BH (63630-63631 decimal) contain the pointer to the text returned by pressing the SHIFT and PRINT keys simultaneously. (In BASIC, SHIFT-PRINT points to the text "llist" followed by a carriage return in ROM... try it!) Both of these "buffers" are terminated by a null byte, or CHR$(0). The SHIFT-PRINT key can thus be useful in both BASIC and Machine Language programs.

The CHKDC ROM Call documented by Tandy at 5AA9H contains a "small" bug. It seems that the routine was actually written for the ADRSS and SCHEDL ROM programs to search for ADRS.DO and NOTE.DO. The limitation here is that the routine will only work if the filename being searched for contains 4 characters or less in the file name (preceding the required ".").

The solution is really quite simple, just load the A register with 10 (Hex 0A) and enter the routine at the addess 5AABH.

Disabling the BREAK key can be accomplished by POKEing a value of 128 into the reserved RAM location 63056 (Hex F650).

This effectively eliminates all of the top row of keys (function keys, etc.). To re-enable, just POKE the value 0 back into the same location.

Model 100 ROM Calls

Radio Shack has been kind enough to document quite a few ROM calls, but they do not state that these entry points are inviolate (ie. will not change with a new ROM revision), nor do they give too much information regarding how to use them in BASIC programs.

The following is a series of ROM calls that can be used in to perform some odds and ends. To facilitate using some of the more "esoteric" calls, I will also be providing a method of providing an "interface" to BASIC variables.

First, however, we will discuss the DOCUMENTED (by Tandy) ROM Calls that can be used directly in BASIC:

This ROM Call will cause the internal modem to "pick up" the phone line. This would be used when trying to detect if carrier is present (see CARDET), but has other uses. A crude "dialing" mechanism could be done using the DISC and CONN ROM Calls to "pulse" the phone line. In fact, this is how the Model 100 actually dials!

The call expects to find a valid phone number "string" (see manual on auto-dial strings) at the address pointed to by the HL register. It is not documented, but the phone number must have a "terminator". This can either be a NULL CHR$(0), or an "auto-log" string. If an auto-log string is used, the Model 100 will wait indefinitely for carrier before sending the auto-log string.

This ROM Call would be useful for resetting ALL the function key definitions. It is not too useful for BASIC programs, but it cannot be performed simillarly in a BASIC program (!).

The STFNK call is often used in BASIC program to reset the function keys to their default cold start values. It can also be used to set the keys to any value desired. The STFNK call requires the address of a table of function key values to be stored at (HL), or the second argument to a CALL function.

In the above example, the code up to the "KEY 1" statement is used to save the current function key settings into the variable B$. The STFNK function call requires that the definitions for all the keys be "delimited" by setting the most significant bit of the last byte. The FOR...NEXT loop performs this delimiting. At the end of the program, assuming that the variable B$ has not been modified, the last three instructions are performed, which reset the function key definitions to their original values.

This ROM call is not too useful to be used directly in BASIC because BASIC has no way of returning values from ROM Calls.

But... we can create a machine language "front end" that will suffice nicely. You do not need to know machine language to use this routine:

The values on the left side of the listing above are the hexidecimal values of the assembly language instructions on the right. These values can be "paired" off to be stored in an "integer array" as shown below. The decimal equivalent of the integer pairs is shown to the right:

At this point, we now have a relocatable machine language routine of our own. What does it do?? It allows us to call a ROM routine that returns a value in the A register, and get the value into an INTEGER variable in BASIC.

How? Let's say that we want to call this routine stored in ML%(0-4) and return the value in the BASIC variable CT%.

Pretty simple, once it is implemented. The ML% array above is useful for other routines. All that need be changed is the value in ML%(1), which should contain the address of the routine to be called.

This routine is another that can be useful in BASIC in conjunction with the ML% array shown above. Change the value of ML%(1) to 28030 by executing a statement like:

And the ML% routine can be used to get a character from the RS-232 queue. The advantage of using this routine (as opposed to the BASIC INPUT$ statement), is that ALL values passed from the RS-232 queue will be available. The INPUT$ statement does not allow the value CHR$(127) or CHR$(26)... in fact, receiving CHR$(26) has the effect of CLOSING the RS-232 file!!

These two routines are usefull for pausing and resuming transmission from a host that acknowleges XON/XOFF protocol.

This can be useful for times when general "housekeeping" must be done. After an XOFF character (Pause) is sent, the host should stop transmitting. At that point, the program can do what it needs to do, such as outputing to a slow device (such as cassette), etc. When ready to resume transmission, send the XON character (Resume).

This routine can be used to send a single character to the RS-232 port. In all actuality, there is no real benefit to using this call, as the PRINT # command allows you to send as many characters at a time as you wish with no restrictions.

Since this routine returns a value, it is necessary to use a machine language "front end". The ML% array described above can be used if the statement:

is executed. When the ML% routine is used to call the CARDET routine, the status returned is:

An original compilation of Compuserve Model 100 Forum messages for use by Forum members only.

Users of the Model 100/102/200 often find it desirable to make certain files invisible. Some make SCHEDL and ADDRSS invisible to clean up the menu. Other programs are made invisible to avoid inadverently killing of them. And in other cases security is a factor. These messages discuss some of the pitfalls and cautions to be considered in using programs such as INVISI.100 to make files disappear from the menu.

OK; I give. Why not? Don Ps..I know it's dangerous to make Hyashi and Suzuki VISIBLE.

Oh! Dat was so OBVIOUS... Or, do you mean it won't run when you type it at the bottom of the main menu?

Yeah, as a matter of fact it will. Except on the 200, which doesn't allow typed input at the bottom... But lots of folks forget that.

For real fun, make both BASIC and INVISI invisible -- but first load up your machine with programs and make THEM invisible -- you'll have an "empty" machine with only 200 bytes free! Then run "USEFUL"...

On the 100, if you access an invisible TEXT file by typing in the name at the bottom of the menu, it will corrupt the beginning of the file.

That's interesting. How come nobody's ever done a TXTTIP file on that one for DL2? (hint hint)

There is no tip because the sig had no tips when I put the first INVISI here. The problem is that the OS does not mask the invisible bit in the attribute so it thinks as follows:

the attribute is not a (visible) .DO file the attribute is not a (visible) .CO file it must be a .BA file let's reset all all the line pointers and walks through memory until it (maybe) finds something that it thinks is a line pointer that points to two 0's in a row, mucking memory as it goes.

Hmmm...I'm pretty sure the same problem occurs when running an invisible .CO program from that window. I vaguely recall running into that problem a couple years ago and getting cold-starts, which you wouldn't get with a .DO file.

An original compilation of Compuserve Model 100 Forum messages for use by Forum members only.

When doing assembly of Model 100/102/200/Kyo machine language programs on my Model 100 with TDD2, I've often considered setting up a development environment on a bigger, faster desktop. These messages discuss approaches to doing just that.

I've done a lot of development on the 100, Option Roms, Assembly type stuff and have hit a bug/snag/anomaly etc in the 102.

I develop large .CO programs using CPM's MAC assembler and use an RS-232 loader to load the Intel Hex file and translate it and poke it into memory.

The procedure is download a short BASIC loader using RUN "COM:88n1e". The BASIC loader is too slow for large files, so the first file I down load is an Intel Hex file for a machine code loader. This loader is poked into memory by the BASIC program and then CALL'ed. The machine loader is very fast and I can transfer 20k .CO files in no time.

Problem: This technique works 100% of the time for the Model 100. For the 102 which I recently started working on the result is erratic. It seems to depend on the telcom program running on the Host computer.

SmartCom running on an AT clone always works on the 100 but frequently fails (75% of the time) on the 102.

The error always appears in the first 100 or so bytes of the final .HEX file that is downloaded.

Why is there a difference between the 100/102? The Disassemblies I have done do not appear to show any significant difference, but I haven't been through all the COM code in detail.

Can anyone help?? Has anyone heard of a difference in the 100/102 in the RS232 handler?

There are some difference files, I think in DL8. Diff is mainly in the keyboard matrix -- and I think there are others. Not that I know of in Telcom, tho.

I always use FLTIBM.COM (see FLTIBM.DES, DL3) for such chores. Works on PC-compatibles. Versions for COM1: & COM2:. Give it a try and let me know if it doesn't do what you want, reliuably.

Now -- what computer are you running MAC on? Do you have a V-20 or one thos NEC chips that will run CP/M, or what??

Thanks for the tip Phil. I'm out of town for a few days and will check it out when I get back.

I'm running UniDos on an Equity III+. It comes with a Z80 chip on a plug in board. Unidos is a TSR. Once installed I presume it filters the DOS command line if DOS fails to find a program you requested. Anything named with a .CPM extension is picked up and run under a CPM emulation using the Z80 board. It is very fast.

I also have Wang PC. The Wang runs a non-IBM DOS. The PC comes with what they call a 928 Com board that allows the PC to be used as a standard Wang terminal on the Wang VS Mini Computer. The 928 board is a Z80 that takes control of the terminal when you are logged on to the big VS.

Wang provides software that also allows you to use the board for a CPM emulator.

Since most compiled languages (aside from Borland's stuff) is MS-DOS rather than IBM PC based, Iworked on that Wang PC happily for years.

I have a collection of development tools for the Model 100 all developed under CPM (emulations) including a C compiler. I have since ported the C compiler over to MS-DOS so that it runs in native DOS mode rather than under a CPM Emulation. The output is 8080 Assembler. I haven't finished writing the cross assembler yet, so I still use MAC.

Hmmmm..just discovered that I have a cross-assembler in my Z-150 and did not knwo it. I'm running with a V-20 which emulates an 8080. And (which I had forgotten) in my CPM directory I have MAC.COM, the standard CP/M macro assembler. It will assemble M100 source files (tho they must be in the ROM2/Cleaseau style, it seems) and make an Intel Hex file, to be laoded with HEX2CO.BA (or such) in DL8. The last part may be the rub: Slow, I suspect.

But this is a possible alternative to the use of CS asm with the TDD -- and would let me deal with big sources in the PC.

An original compilation of Compuserve Model 100 Forum messages for use by Forum members only.

Have you ever wondered how to clean the screen of your Tandy laptop? This file reports the experiences of one user who did it with a well-known commercial window-cleaning product. Woe is he! A short thread, with potential for further addenda.

I am a Tandy 102 owner. I just cleaned the screen of the 102 with windex. After that I turned on the computer only to find dark lines all over the screen on the main menu and even in files. I would like to know what is wrong and is there anything I can do about it. I really need my computer the next two weeks and cannpt afford to be without it. Also I would like some tips on cleaning the screen of the 102.

Sound like you really scrubbed the little guy!! Windex is awful stuff. Use 1 drop of a detergent in a quart of water then use 2 drops on the screen, wipe gently with a kleenex until it is dry. Don't let any moisture get inside. Either you built up a lot of static electricity, or you dripped liquid inside, or you pressed so hard you cracked the inside layer of glass. Just 'dark lines' is a little on the non-descriptive side so it is hard to tell. If you are good with tools and clever you can take it apart and dry it out, but if you have to ask how then you are probably not clever enough even with directions -- it isn't easy nor really recommended. Hint: turn the M100 over and find 4 screws, then pry case apart gently from the sides. By the way, I have four M100's and have never cleaned any of them in about 4 years (or is it 5 -- bought my first M100 the week they came out). Why do you need to clean it at all -- short of strawberry jam?

Possible that some of the cleaning solution leaked into the screen electronics and is causing electrical shorts. For starters, I would do nothing: the problem may go away as the fluid evaporates. If you see no change in a couple of days, you could open up the computer case and try a blow-dryer ( medium heat recommended) in the area where the cleaning solution might have penetrated. I have used Windex previously with no ill effects -- but I spray it on a cloth or paper towell, never directoy on the computer itself. I have also used *toothpaste* to clean the screen; if you work at it, the toothpaste abrasives will get rid of hairline scratches on the screen surface.

I bet what you have is just a case of static. On the rare occasions when I've needed to clean the finger smudges off of my screen, I use a single drop of eyeglass cleaner on a piece of lens tissue. Sometimes I get the "dark lines" you're talking about, but they go away pretty quickly. Don't panic. If the lines are still there next week, you may have cause for concern (might mean you got some windex around behind the cover over the LCD). The 100/102 is a tough little critter - it should take more than a shot of windex in the eye to take it out of action.

Well, we are dying to know what happened. Liquid is more likely to make blobs than lines, and would get smaller with time. Did the lines go away like static lines, or does it look like a spider-web of a fracture. (one of mine looked that way after I dropped it 30 feet onto concrete -it still worked OK, but was mighty hard to read.)

An original compilation of Compuserve Model 100 Forum messages for use by Forum members only.

An increasing number of Froum members are moving toward machine language programming for the Model 100 and its relatives. A good assembler can make the experience a pleasant one, while a bad one can result in drudgery and pain. This is a short set of messages discussing the selection of a Model 100 assembler.

Does anyone know of a good assembler package for the Model 100, or even a not so good package? I am about to start development on a piece of code that needs to be much faster than BASIC interpreted on the M100 ...

Greg, there is a new assembler in DL8 called BYTEIT. I have not tried it, and it is in Basic and therefore slow -- but it looks good and the price is right.

I use the Custom Software assembler -- but I've heard that it is no longer for sale; but if you can get it, it is about the best m/l assembler and has blazing speed. Assembles to menu, so you don't have to assemble to operating location.

Many swear by Polar Engineering's ROM2 package -- which is much more than just an assembler, I believe. Buu it does occupy the ROM socket -- a problem for me, since I use ROM's for my "business" programs.

Lots of choices -- one of them availagle here (actually, there is another one here -- but I've forgotten its name. ASM.BA?).

There is an M/L assembler in the DL8 that I uploaded here called BYTEIT.BA. I developed it to program a wordprocessor for the 100 which is also here called TXTFMT.CO. It supports all INTEL codes, and data types. It's slow (it's written in BASIC), but a lot faster than other BASIC assemblers I've tried. Try it out for a few days. If you have questions let me know. PAUL

Paul, thanks for the line on BYTEIT. You are quite right about the speed, but it is certainly the best assembler in its price range! In fact, right now I am talking with CompuServe via a little (134 byte) terminal program written using BYTEIT. It is tempting to consider rewriting BYTEIT in assembly code -- then it would truely blaze! Perhaps when this program is done.

Would you object if I uploaded this assembler to the local BBS that M100 types hang out on here in Santa Barbara? My query there about assemblers only turned up the standard ones you pay many dollars for, and something like BYTEIT would be just right for experimentation and small programs.

There are assembly language assemblers available. One of the best was written by Greg Susong, and early supporter of the Model 100, and was sold through Custom Software in Kansas. You'll find a file describing it in DL13, ASM100.PRD. It included a well written, manual with documented ROM calls. Cost, $10.

Another is from Micro Demon (David Sumner, and is described in the file ASM.PRD (DL13).

Tony, thanks for the info on Custom Software's assembler. Why do you say "was sold" and "included" -- have they stopped selling this product?

Feel free to upload any of my stuff to local bulletin boards. I have been working on writing it as M/L myself, but have too many other projects going as well. You might want to check out TXTFMT.LDR as well if you are looking for uploads. It's an M/L Text formatter that I wrote using BYTEIT. PAUL

Last time I talked to Greg, he was attempting to sell his Model 100 interestes and move on to newer computers. I don't know if they're still available. I asked if we should withdraw the file from DL13, and he said no, not at the present time. So, maybe yes, maybe no.

I am looking for a book on assemby language programming for the 8085 chip used in the Tandy 102. I haven't had any luck finding one at my local bookstores. If anyone knows where I can order one, please let me Know. I believe the 8085 uses the same instruction set as the 8080, so I would settle for a book on that chip instead.

You can "order" any book you like, at any good bookstore, or any chain, such as Walden Books, B. Dalton, Crown Books, or The Little Professor. They have a big catalog, which may even by computerized by now, which lists all the books in print, gives the author, publisher, and ordering information. Assembly language books would be listed under generic titles, like "Assembly Language for the 8080/8085" or "8080/8085 Assembly Language".

You can also find stacks of such books in college bookstores which have any sort of computer courses. Here's a list of some recommended ones:

Additionally, the following two books, which are available from Granite Street Portables, Box 651, Peterborough NH 03458.

Tony's list pretty much covers the spectrum. If you already program in m/l, and just need a reference work for the 8080/8085, the first of those Leventhal books is probably your best bet. On the other hand, if you're new to machine language, the Fernandez/Ashley work (if you can find it!) is a very good introduction. One of the few works I've encountered that deserves the phrase "self-teaching guide" in its title.

Today I went to Walden Bookstore to order one of the books you recommended. The clerk got out her microfiche reader and started searching. She claimed they were all out of print! Next I went to B. Dalton, and none of the books were on their list either! They then told me that maybe she could get one of the books directly from the publisher, so I filled out a form to order "8080A-8085 Assembly Language Programming" by Lance A. Leventhal. It will be 6 to 8 weeks before I get it. Thanks for the tip on the BASIC compiler - it sounds good.

Mike, With your background, you may find the Leventhal book is all you need. It describes each of the 8085 opcodes in significant detail, then takes you through some "typical" application programs. What Leventhal =doesn't= do, of course, is tell you how to interface your programs with various system routines in the M100 ROM. If I haven't already recommended the Robert Covington ROM maps in Lib 8, let me mention them here: you'll find them invaluable. In fact, I'd suggest that you download a set of all the catalog files in Lib 8, for a decent overview of other material that will be useful.

For an extensive list of 8080-8085 Assembly Language books, contact Opamp Technical Books, Inc., in Los Angeles; (213) 464-4322. They advertise "Always in Stock". (whatever that means....)

I'm sure that the suggestions that others have made are good ones, but I have one more to add to your list: If you want to go straight to the source, in April I bought the Intel book on the 8080/85 family directly from Intel for $16.40. It is probably still available. Info:

This book is quite technical, but maybe that's what you want. It describes each instruction in detail, including number of clock cycles. It also describes hardware details about the chip.

M100/102 Useful??

I'm a free-lance writer doing some research on older computers that are still in use. I'd appreciate anyone here writing to me with your comments about the Model 100/102. Is it still useful? How do you use it? What is its appeal in a world of tiny powerhouses like the Compaq LTE's and Toshiba 1100se's?

You can still buy a 102 at your local Radio Shack. I wouldn't call it an 'older computer'. Not yet, anyways. <grin> I still have an original Imsai 8080 running, now that's an old computer.

You've probably asked a dangerous question... most portable owners are somewhat fanatical about their portables. What is the appeal? It's my guess you've never used one...

First, when you turn it on, it's at the main menu, ready to use - IMMEDIATELY. You don't have to wait for two minutes while it "boots up", then wait another minute or two while you load your application.

Second, a set of four AA batteries will give you 20 hours or more of use, and can be replaced with internal nicads if you prefer, for less than ten dollars. AA cells are available everywhere in the world. How much does it cost to replace a dead or defective battery in a PC "laptop", how easy is it to get, and how much actual use do you get from each "charge"? Can you replace it with readily available batteries if it goes dead in some out of the way place?

Third, what is a laptop use for most? Probably 80% of portable use is in writing and telecommunications; both of which the Tandy portable class of computers do real well. (REAL portables, by the way...) Professional writers, many journalists, and business travelers wouldn't take a PC "laptop" if you offered it to them. There's nothing that equals a two to three pound workhorse like the 100/102 or 200. An whatever you may need to do, if a program isn't available to do it, you can probably whip it up yourself in a matter of minutes to do exactly what you need. PC's do not lend themselves to "quick and dirty" programming efforts - especially by marginally computer literate users.

I'm a reporter for the NBC-TV station in San Francisco. I use the Tandy 200 every workday, and I haven't seen an MS-DOS machine I'd be willing to trade it for -- regardless of price. Before I had the the T200, I used the Model 100 and would say the same thing about it. Tony Anderson has already mentioned some of these computers' most prized features: light weight, instant power-up access to files and application software, a universally available, inexpensive, and long-lasting set of batteries, and a very capable built-in version of BASIC. I will add a couple of items to that list. First, the physical ruggedness of these computers is incredible. I have carried mine for more than three years now in an unpadded leather briefcase that gets slammed around constantly in the field. The unit has been dropped, sat upon, and even buried under the contents of a bookcase that fell during the October earthquake. Through it all, the computer has always been ready to go whenever I am -- and even when I'm not. Next, the Tandy 100/102/200 laptops are remarkable for their ability to connect with the rest of the world. They offer parallel and serial ports, and a barcode interface, in addition to the built-in modem. Internal software supporting these ports is, for the most part, quirkless. Then there is the large base of both public and commercial programs that supports these computers. It will never turn them into powerhouse desktop machines; but it means their users can do virtually anything they really =need= to do with a portable. That last point, for me, best answers your question about the "appeal in a world of ... LTE's ...." My T200 does all the things I need a portable computer to do. I use it to write scripts, log video tapes (a program to read television "time code" with the T200 costs less than $100, compared with hardware needed to do the same job on a PC and priced at $700 or more), telecommunicate with my station's newsroom computer, maintain my expense account, keep a database of phone numbers, and entertain me occasionally with a game of chess. When somebody thinks of something I need to do with a laptop, and can't do with the T200, I'll consider a Compaq or Toshiba. Or, I may just write a program to do it on the Tandy.

These Tandy computers may have pea brains, but they are in fact all that most of us really need to do most of our business. I've gotten by for four years on my Model 100 very happily, only occasionally resorting to a desktop when I have an impossibly large file to deal with. This occurs, oh say, maybe once every six months. At those times I just go to my college's computer center. Hardly a reason to own a desktop.

And in fact, with all of the third party support, free-ware on CIS and people like Tony Anderson and the other very helpful SYSOPs on this FORUM, you can do almost anything you want to with a Model 100, as long as you're dealing in smaller data files.

I've had a 100 for years, and have been happy with it. I know it's limitations and strong points. My 100 was an upgrade from a PC-1 that I used for field work. (PC-1 is still kicking) The 100 has also served me well in the machine and wood shop, where it has stored formulas and figured all sorts of calculations. And you can get them cheap too!

re: Dealing with smaller files...What is a smaller file? With the laptop add-ons - disk drives(s) and Powr-Dos' "D-text" a 90+K or 190+K can be edited. With Gold Card System and "Gold Text" a file of up to 20-30meg can be edited...kinda expensive tho!. I sit here with 2 ea 256K Gold Cards-easily accessable and 2 TDD drives all very easy to utilize...don't have the portability of the drives but, 512K + 32K is enough for me...so it is there, if you want to spend the $$$. Best, Gene

Yes, if you've got the gold card, or perhaps the forthcoming Ultracard, but most of us are limited to working in text files of no more than about 29.5K. Of course, as you suggest, if you're willingaccess to much more.

Mike, I use the M100 and T102, as the brains in scientific instruments and in data loggers out in the field. They have so many options to connect to the outside world, and a truly marvelous programming capability. They are rugged. To buy an intelligent instrument, you'd expect to pay $2000 for a custom-designed computer with a stunted keyboard and a diddly little screen, along with a Byzantine programming language. And you'd expect to pay out the nose for every addition--printer interface, serial interface, modem. In the M100 series, you have a mass-produced, and therefore economical alternative. Maybe you could devote a PC or a Mac to the purpose, but you'd lose the easy battery backup and most of the portability. Lots of applications don't need speed overkill, and in lots of applications mechanical parts like a disk drive are a liability. That's true even of the Toshiba or other portables of the latest generation. I hope to see the 100/102/200 or something very much like them on the market for many years to come.

My "day job" is with a national insurance company in our premium audit department. We have been using laptop computers for over five years now for field audits. Although I have an M100, unfortunately, its small memory makes it impossible for our field team to use. Instead we have been using Hewlett Packard laptops--the HP110 at first, and the Portable Plus since. I'm writing this on my P+ in a motel while on a business trip.

We just selected new units for our field use. HP got out of the portable business, you see. We selected the Compaq LTE because of its long battery life (3 hours), compared with the HP's 16 hours ( or the M100 20 hours). Of course, HP uses a specialized battery at about $50 a pop, not the four AA's in the Tandy. The LTE has a large memory--640K of RAM and 20meg hard disk (internal no less). Now that is really impressive. For our use it is an absolute. Yet our old HP's could easily store a day's work before transmitting into the office. What more could be asked for?

Alas, HP's best minds decided that fragile, oversized units with no battery life, but which were IBM compatible, are really what people need. Eventually, when that's all people can buy, the purveyors of those units can say, "We were right. Look. No one buys those old style little machines anymore."

That's why I'm interested in writing about the units that really do the job that people want. Now that computers have become a business tool, the market is being driven by business. In the '90s, that means mostly glitz before substance, hype before facts. So, if I'm out to impress a client, a fancy box that'll whistle and sing in the background while I do my song an dance will sell better than a box that simply allows me to write a report or prepare an accounting summary.

Yes, I own a M102, and a HP P+, and I use a lot of those other fancy boxes. When I have my choice, its the Tandy. I hope they continue.--mcw

Starting message #: 24378 Starting date: 19-Apr-90 18:18:27 Participants: Mike Wright 76274,14 David J. Campbell 72707,1346 PETER ROSS 72027,3653 Tony Anderson 76703,4062 Wilson Van Alst 76576,2735 Gene Nestro 73727,1015 TRACY ALLEN 76670,326

#: 189074 S14/Private For-Sales 25-Oct-89 13:40:21 Sb: #189068-#Model 100/600 Sale Fm: MEL ZWILLENBERG 75746,3705 To: Tony Anderson 76703,4062 (X)

Tony, Interesting comment. Could you tell me why anyone would prefer an M100 to an M102 if price were the same? ---Mel

#: 189075 S14/Private For-Sales 25-Oct-89 15:18:25 Sb: #189074-#Model 100/600 Sale Fm: Tony Anderson 76703,4062 To: MEL ZWILLENBERG 75746,3705 (X)

Well, the biggest reason would be to replace an existing 100, or to keep handy as a backup for an existing 100 machine which already had several Model 100-only accessories. Example, P.G. Design's and P.C.S.G's original RAM expansion units that fit inside the computer, under the hatch door in the bottom, and connected to the system buss. Likewise a Chipmunk disk drive header that fit the same system buss connector, or mated with a socket on the RAm expansion board. Likewise an early D/VI, before it became available with multiple cables. If such an owner switched to a 102, all those accessories would immediately become obsolete.

Second, esthetics. There are a number of users who prefer the "feel" of the 100... it's a bit heavier, and feels more substantial. The 102, by contrast doesn't "feel" like it can take rough handling. Of course, that's purely subjective. Lots of users prefer the 102, for the one pound weight difference and the 1/2 inch thinner size.

Third, there may be some folks who like that random changing of the calendar knows as the Date Bug. (grin) If it were a matter of a first computer, or with no existing accessories to consider, then the 102 would probably be the better choice, if only for elimination of the Date Bug problem.

But an additional consideration is that there are more 100-only accessories on the used market, and it might cost less to expand a 100 than a 102.

Title	Author(s)	published by	ISBN
8080A-8085 Assembly Language Programming	Lance A. Leventhal	Osborne/McGraw-Hill	0-931988-10-1
8080/8085 Assembly Language Subroutines	Lance A. Leventhal and Winthrop Saville	Osborne/McGraw-Hill	0-07-931058-3
Z-80 and 8080 Assembly Language Programming	Kathe Spracklen	Hayden Book Company	0-8104-5167-0
Introduction to 8080/8085 Assembly Language Programming	Judi Fernandez and Ruth Ashley	John Wiley and Sons	0-471-08009-8

Hidden Powers of the TRS-80 Model 100	Christopher Morgan	Plume/Waite Group	0-452-25578-3
Inside the Model 100	Carl Oppedahl	Weber Systems	0938862-31-6

Model 100 & 200, 102 Hints and Tips

Model 100 ROM Calls

M100/102 Useful??

Model 100 & 200, 102
Hints and Tips