Model 4 TRSDOS/LS-DOS versus CP/M

[lowen]

Ok, so after reading through the Running TRSDOS on Z180 & eZ80 thread, I guess I'll open this up.

In the context of ONLY the TRS-80 Model 4/4P machines, let's look over the pros and cons of TRSDOS versus CP/M for the vintage enthusiast. The CP/M port I'm going to stick with is the Montezuma Micro one. I'm not nearly as familiar with CP/M as with TRSDOS/LS-DOS, so I'm relying on the CP/M experts here to help out.

TRSDOS:
PRO:

1. Came with the machine and supported by Tandy. $0
2. File access control with two passwords (6.2 and lower) or a single password (6.3.0 and newer) and multiple access levels.
3. File date and time.
4. Multilevel multitasking, IRQ-driven. Used by several packages.
5. Loadable device driver architecture allows flexible support for hard disks, etc.
6. Terminate-and-stay-resident software using the same loadable module model as with drivers.
7. SCRIPSIT, SuperSCRIPSIT, and ScripsitPRO, along with other Radio Shack software.
8. Flexible disk device model, allows pseudo subdirectories using DiskDISK and other software.
9. Many more library commands and a full help system.
10. Flexible device I/O redirection.
11. Add-on: PRO-NTO/PRO-WAM productivity TSR programs.
12. Add-on: DoubleDuty, which allows a 128K M4 to act like two 64K M4s.

CON:

1. Slower to perfom some operations due to the system needing to pull in an overlay from disk.
2. Proprietary to the TRS-80 line (with a very few exceptions, including the new eZ80 work and the MAX-80's Maxdos 6)
3. Much more difficult to port to another system; the process is not documented.
4. Not nearly as much third-party software as CP/M.

CP/M:
PRO:

1. Industry-standard 8080/Z80 operating system, portable to many 8080/Z80 computers. CP/M was built from the ground up to be easily ported, with a well-defined and documented BIOS interface.
2. Minimalistic design provides the least functionality possible while still doing the job.
3. Incredible third-party support, both hardware and software.
4. Montezuma's CP/M has wide support for multiple disk formats (as far as I know; someone who knows better please comment!)
5. Upgrade path to full multiuser on other systems with MP/M. I don't know if there was ever an MP/M for the Model 4, but I don't think there is any reason why someone couldn't port one.
6. Clear migration of data files to other CP/M systems.
7. Montezuma implements the optional IOBYTE feature that provides limited device I/O redirection capabilities.
8. Monte's Window productivity applications (similar to Pro-WAM/Pro-NTO); only available on Montezuma's CP/M

CON:

1. Cost.
2. Not well-supported by Tandy (as if that matters at all, now).
3. Minimal design and minimal services, just the bare essentials.
4. Different ecosystem from the TRSDOS group; not sure which group was actually larger, but the CP/M group would have been more platform-diverse. The 'traditional TRS-80 group' is going to be typically using TRSDOS and will be geared to that OS; if you run MM CP/M on your M4/4P you'll get more generic CP/M support and chat with other CP/M users.

Looking for more input.....as I always reserve the right to be wrong!

 

[ldkraemer]

TRS-80 Model 4 Hardware Supports the following with Montezuma Micro CP/M:

1. Drives
1 thru 4
2. Size:
5" or 8"
3. Tracks:
35, 40, 77, 80
4. Sides:
1 or 2
5. Step Rate in ms:
6, 12, 20, 30

Can access the following CP/M Format Floppy's:

*Access Matrix (40T, SS, DD, 171K)
36,3,7,0,170,63,192,0,16,2,9,2,40,128
1,4,7,2,5,8,3,6,9
*Adler Textriter Series III (40T, SS, DD, 160K)
32,3,7,0,159,31,128,0,10,0,16,1,40,128
1,4,7,10,13,16,3,6,9,12,15,2,5,8,11,14
*Altertext Diskreader (40T, SS, DD, 144K)
36,3,7,0,143,127,240,0,32,3,18,1,40,128
1,7,13,2,8,14,3,9,15,4,10,16,5,11,17,6,12,18
*Ampro Little Board (40T, SS, DD, 190K)
40,4,15,1,94,63,128,0,16,2,10,2,40,128
1,2,3,4,5,6,7,8,9,10
*Ampro Little Board (40T, DS, DD, 390K)
40,4,15,1,194,127,192,0,32,2,10,2,40,192
17,18,19,20,21,22,23,24,25,26
*AOS/VT S-10 (80T, DS, DD, 626K)
32,4,15,0,312,127,192,0,32,3,16,1,80,192
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
*ATR-8000 512 byte sector (40T, SS, DD, 190K)
40,3,7,0,189,63,192,0,16,2,10,2,40,128
1,2,3,4,5,6,7,8,9,10
*ATR-8000 1024 byte sector (40T, SS, DD, 190K)
40,3,7,0,189,63,192,0,16,2,5,3,40,128
1,2,3,4,5
*AVATAR TC1 Terminal Converter (40T, SS, DD, 184K)
40,4,15,1,91,127,192,0,16,3,10,2,40,128
1,5,9,3,7,2,6,10,4,8
*AVATAR TC1 Terminal Converter (40T, DS, DD, 384K)
40,4,15,1,191,127,192,0,16,3,10,2,40,192
1,5,9,3,7,2,6,10,4,8
*Cifer 2683 (40T, DS, DD, 384K)
40,4,15,1,191,127,192,0,32,3,10,2,40,192
1,3,5,7,9,2,4,6,8,10
*Compustar Model 30 (35T, DS, DD, 340K, *)
40,4,15,1,169,63,128,0,16,2,10,2,35,210
1,3,5,7,9,2,4,6,8,10
*Cromemco Z-2 (40T, SS, SD, 82K)
18,3,7,0,81,31,128,0,8,3,18,0,40,0
1,6,11,16,3,8,13,18,5,10,15,2,7,12,17,4,9,14
*Cromemco Z-2 (40T, SS, DD, 190K)
40,3,7,0,189,31,128,0,8,2,10,2,40,128
1,5,9,3,7,2,6,10,4,8
*DEC Rainbow 100+ (80T, SS, DD, 390K)
40,4,15,1,194,127,192,0,32,2,10,2,80,128
1,3,5,7,9,2,4,6,8,10
*DEC VT-180 (40T, SS, DD, 171K)
36,3,7,0,170,63,192,0,16,2,9,2,40,128
1,3,5,7,9,2,4,6,8
*Digital Research 8" CP/M Standard (77T, SS, SD, 243K)
26,3,7,0,242,63,192,0,16,2,26,0,77,0
1,7,13,19,25,5,11,17,23,3,9,15,21,2,8,14,20,26,6,12,18,24,4,10,16,22
*Eagle (80T, SS, DD, 390K)
40,4,15,1,194,191,192,0,32,2,5,3,80,128
1,3,5,2,4
*Eagle (80T, DS, DD, 790K, *)
40,4,15,0,394,191,224,0,32,2,5,3,80,194
1,3,5,2,4
*Epson QX-10 (40T, DS, DD, 380K)
40,4,15,1,189,127,192,0,32,4,10,2,40,192
1,2,3,4,5,6,7,8,9,10
*Epson QX-10 MF (40T, DS, DD, 280K)
32,4,15,1,139,63,128,0,16,8,16,1,40,192
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
*Hewlett-Packard HP-125 (40T, DS, DD, 252K)
32,3,7,0,251,127,240,0,32,3,16,1,40,192
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
*Holmes Engineering VID80 (40T, SS, DD, 195K)
40,3,7,0,194,63,240,0,16,1,10,2,40,128
0,1,2,3,4,5,6,7,8,9
*Hurricane Labs Inc. Compactor I & II (40T, SS, DD, 190K)
40,4,15,1,94,127,192,0,32,2,5,3,40,128
1,4,2,5,3
*IBM PC using CP/M 86 (40T, SS, DD, 156K)
32,3,7,0,155,63,192,0,16,1,8,2,40,128
1,2,3,4,5,6,7,8
*IBM PC using CP/M 86 (40T, DS, DD, 316K, *)
32,4,15,1,157,63,128,0,16,1,8,2,40,195
1,2,3,4,5,6,7,8
*Intertec Superbrain (35T, SS, DD, 164K)
40,4,15,1,81,63,128,0,16,2,10,2,35,144
1,3,5,7,9,2,4,6,8,10
*Intertec Superbrain (35T, DS, DD, 340K, *)
40,4,15,1,169,63,128,0,16,2,10,2,35,210
1,3,5,7,9,2,4,6,8,10
*Kaypro 2 (40T, SS, DD, 195K)
40,3,7,0,194,63,240,0,16,1,10,2,40,128
0,1,2,3,4,5,6,7,8,9
*Kaypro 4 (40T, DS, DD, 392K)
40,4,15,1,195,63,192,0,16,1,10,2,40,200
0,1,2,3,4,5,6,7,8,9
*LNW Research LNW80 (40T, SS, DD, 166K)
36,4,15,1,82,63,128,0,16,3,18,1,40,128
1,6,11,16,3,8,13,18,5,10,15,2,7,12,17,4,9,14
*Lobo MAX-80 (40T, SS, DD, 166K)
36,3,7,0,165,63,192,0,16,3,18,1,40,128
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
*Lobo MAX-80 (40T, DS, DD, 346K)
36,4,15,0,172,127,192,0,32,3,18,1,40,192
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
*Memory Merchant Shuffle Board (40T, SS, DD, 190K)
40,4,15,1,94,127,192,0,32,2,10,2,40,128
1,2,3,4,5,6,7,8,9,10
*Monroe OC 8820 (40T, DS, DD, 308K)
32,4,15,1,153,63,128,0,16,3,16,1,40,196
1,5,9,13,2,6,10,14,3,7,11,15,4,8,12,16
*Monroe OC 8820 (80T, SS, DD, 308K)
32,4,15,1,153,63,128,0,16,3,16,1,80,128
1,5,9,13,2,6,10,14,3,7,11,15,4,8,12,16
*Morrow Micro Decision (40T, SS, DD, 190K)
40,4,15,1,94,127,192,0,32,2,5,3,40,128
1,4,2,5,3
*Morrow Micro Decision MD3 (40T, DS, DD, 390K)
40,4,15,1,194,191,224,0,32,2,5,3,40,192
1,4,2,5,3
*NCR Decision Mate V (40T, DS, DD, 308K, *)
32,4,15,1,153,127,192,0,32,3,8,2,40,194
1,2,3,4,5,6,7,8
*NEC PC-8001A (40T, SS, DD, 148K)
32,3,7,0,147,63,192,0,16,2,16,1,40,128
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
*Omikron Mapper I, Model 1 & 3 (40T, SS, SD, 83K)
18,3,7,0,82,63,192,0,16,3,18,0,40,0
1,5,9,13,17,3,7,11,15,2,6,10,14,18,4,8,12,16
*Omikron Mapper II (40T, SS, DD, 134K)
28,3,7,0,133,63,192,0,16,2,28,0,40,128
1,6,11,16,21,26,3,8,13,18,23,28,5,10,15,20,25,2,7,12,17,22,27,4,9,14,19,24
*Omikron Mapper III (40T, SS, DD, 190K)
40,4,15,1,94,127,192,0,32,2,5,3,40,128
1,2,3,4,5
*Osborne 1 (40T, SS, SD, 90K)
20,4,15,1,45,63,128,0,16,3,10,1,40,0
1,3,5,7,9,2,4,6,8,10
*Osborne Executive (40T, SS, DD, 185K)
40,3,7,0,184,63,192,0,16,3,5,3,40,128
1,2,3,4,5
*Radio Shack TRS-80 Model 4 CP/M Plus (40T, SS, DD, 156K)
32,3,7,0,155,63,192,0,16,1,8,2,40,128
1,2,3,4,5,6,7,8
*Sanyo (40T, DS, DD, 312K)
32,4,15,1,155,63,128,0,16,2,16,1,40,192
1,4,7,10,13,16,3,6,9,12,15,2,5,8,11,14
*Sanyo MBC-1200/1250 (80T, DS, DD, 624K)
32,5,31,3,155,127,128,0,32,4,16,1,80,192
1,4,7,10,13,16,3,6,9,12,15,2,5,8,11,14
*Tecron TEF System 10 (80T, DS, DD, 790K)
40,4,15,0,394,319,248,0,32,2,10,2,80,192
1,4,7,10,3,6,9,2,5,8
*Teletek Systemaster (80T, SS, SD, 72K)
18,3,7,0,71,127,240,0,32,3,18,0,80,0
1,5,9,13,17,3,7,11,15,2,6,10,14,18,4,8,12,16
*Teletek Systemaster (40T, SS, DD, 144K)
36,3,7,0,143,127,240,0,32,3,18,1,40,128
1,7,13,2,8,14,3,9,15,4,10,16,5,11,17,6,12,18
*Televideo 802 (40T, DS, DD, 342K)
36,4,15,0,170,63,128,0,16,4,18,1,40,192
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
*Toshiba T-100 (40T, DS, DD, 256K)
32,3,7,0,255,63,192,0,16,6,16,1,40,192
1,5,9,13,2,6,10,14,3,7,11,15,4,8,12,16
*Video Genie III (80T, DS, DD, 692K)
36,5,31,3,172,127,128,0,32,6,18,1,80,200
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
*Xerox 820-1 (40T, SS, SD, 82K)
18,3,7,0,81,31,128,0,8,3,18,0,40,0
1,6,11,16,3,8,13,18,5,10,15,2,7,12,17,4,9,14
*Xerox 820-2 (40T, SS, DD, 157K)
34,3,7,0,156,63,192,0,16,3,17,1,40,128
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
*XOR S100-4 (40T, SS, DD, 185K)
40,3,7,0,184,127,240,0,32,3,10,2,40,128
1,6,2,7,3,8,4,9,5,10
*Zenith H89 (40T, SS, SD, 94K)
20,3,7,0,93,63,192,0,16,3,10,1,40,0
1,2,3,4,5,6,7,8,9,10
*Zenith H89/H90 (40T, SS, DD, 152K)
32,3,7,0,151,127,240,0,32,2,16,1,40,128
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
*Zenith Z100 (40T, SS, DD, 152K)
32,3,7,0,151,127,240,0,32,2,8,2,40,128
1,2,3,4,5,6,7,8
*Zenith Z100 (40T, DS, DD, 312K)
32,4,15,1,155,255,240,0,32,2,8,2,40,192
1,2,3,4,5,6,7,8
*Zorba GC200 (40T, DS, DD, 390K)
40,4,15,1,194,63,128,0,16,2,10,2,40,200
1,2,3,4,5,6,7,8,9,10
*Montezuma Micro CP/M v 1.26 & 1.30 (40T, SS, DD, 170K)
36,4,15,1,84,127,192,0,32,2,18,1,40,128
1,5,9,13,17,3,7,11,15,2,6,10,14,18,4,8,12,16
*Montezuma Micro CP/M v 1.26 & 1.30 (40T, DS, DD, 350K, *)
36,4,15,1,174,127,192,0,32,2,18,1,40,194
1,5,9,13,17,3,7,11,15,2,6,10,14,18,4,8,12,16
*Montezuma Micro CP/M v 1.32 (40T/256S, DS, DD, 350K, *)
36,4,15,1,174,127,192,0,32,2,18,1,40,194
1,3,5,7,9,11,13,15,17,2,4,6,8,10,12,14,16,18
*Montezuma Micro CP/M v 1.42 & 1.44 (40T, DS, DD, 342K)
36,4,15,1,170,127,192,0,32,4,18,1,40,192
1,3,5,7,9,11,13,15,17,2,4,6,8,10,12,14,16,18


Larry

 

[geowar1]

Ok, so after reading through the Running TRSDOS on Z180 & eZ80 thread, I guess I'll open this up.

In the context of ONLY the TRS-80 Model 4/4P machines, let's look over the pros and cons of TRSDOS versus CP/M for the vintage enthusiast. The CP/M port I'm going to stick with is the Montezuma Micro one. I'm not nearly as familiar with CP/M as with TRSDOS/LS-DOS, so I'm relying on the CP/M experts here to help out.

TRSDOS:
PRO:

1. Came with the machine and supported by Tandy. $0
2. File access control with two passwords (6.2 and lower) or a single password (6.3.0 and newer) and multiple access levels.
3. File date and time.
4. Multilevel multitasking, IRQ-driven. Used by several packages.
5. Loadable device driver architecture allows flexible support for hard disks, etc.
6. Terminate-and-stay-resident software using the same loadable module model as with drivers.
7. SCRIPSIT, SuperSCRIPSIT, and ScripsitPRO, along with other Radio Shack software.
8. Flexible disk device model, allows pseudo subdirectories using DiskDISK and other software.
9. Many more library commands and a full help system.
10. Flexible device I/O redirection.
11. Add-on: PRO-NTO/PRO-WAM productivity TSR programs.
12. Add-on: DoubleDuty, which allows a 128K M4 to act like two 64K M4s.

CON:

1. Slower to perfom some operations due to the system needing to pull in an overlay from disk.
2. Proprietary to the TRS-80 line (with a very few exceptions, including the new eZ80 work and the MAX-80's Maxdos 6)
3. Much more difficult to port to another system; the process is not documented.
4. Not nearly as much third-party software as CP/M.

CP/M:
PRO:

1. Industry-standard 8080/Z80 operating system, portable to many 8080/Z80 computers. CP/M was built from the ground up to be easily ported, with a well-defined and documented BIOS interface.
2. Minimalistic design provides the least functionality possible while still doing the job.
3. Incredible third-party support, both hardware and software.
4. Montezuma's CP/M has wide support for multiple disk formats (as far as I know; someone who knows better please comment!)
5. Upgrade path to full multiuser on other systems with MP/M. I don't know if there was ever an MP/M for the Model 4, but I don't think there is any reason why someone couldn't port one.
6. Clear migration of data files to other CP/M systems.
7. Montezuma implements the optional IOBYTE feature that provides limited device I/O redirection capabilities.
8. Monte's Window productivity applications (similar to Pro-WAM/Pro-NTO); only available on Montezuma's CP/M

CON:

1. Cost.
2. Not well-supported by Tandy (as if that matters at all, now).
3. Minimal design and minimal services, just the bare essentials.
4. Different ecosystem from the TRSDOS group; not sure which group was actually larger, but the CP/M group would have been more platform-diverse. The 'traditional TRS-80 group' is going to be typically using TRSDOS and will be geared to that OS; if you run MM CP/M on your M4/4P you'll get more generic CP/M support and chat with other CP/M users.

Looking for more input.....as I always reserve the right to be wrong!

What “cost”? Is anyone selling CP/M anymore? It can probably be found for free somewhere on the web.

 

[lowen]

What “cost”? Is anyone selling CP/M anymore? It can probably be found for free somewhere on the web.

For today's enthusiast it's no cost, that's true. Back in the day there was a cost. Thanks for pointing that out.

 

[lowen]

TRS-80 Model 4 Hardware Supports the following with Montezuma Micro CP/M:

1. Drives
1 thru 4
2. Size:
5" or 8"
3. Tracks:
35, 40, 77, 80
4. Sides:
1 or 2
5. Step Rate in ms:
6, 12, 20, 30

Can access the following CP/M Format Floppy's:

*Access Matrix (40T, SS, DD, 171K)
36,3,7,0,170,63,192,0,16,2,9,2,40,128
1,4,7,2,5,8,3,6,9
*Adler Textriter Series III (40T, SS, DD, 160K)
32,3,7,0,159,31,128,0,10,0,16,1,40,128
1,4,7,10,13,16,3,6,9,12,15,2,5,8,11,14
*Altertext Diskreader (40T, SS, DD, 144K)
36,3,7,0,143,127,240,0,32,3,18,1,40,128
1,7,13,2,8,14,3,9,15,4,10,16,5,11,17,6,12,18
*Ampro Little Board (40T, SS, DD, 190K)
40,4,15,1,94,63,128,0,16,2,10,2,40,128
1,2,3,4,5,6,7,8,9,10
...

Thanks, Larry!

 

[mloewen]

Back in the day, Montezuma CP/M was my daily driver on my Model 4. All my serious CP/M development was done on that platform. The ability to exchange data between different disk formats is invaluable, and you can roll your own format if it doesn't exist in the MMCPM list. MMCPM also had a RAMdisk program to utilize the extra 64K on a 128K Model 4. With a utility I wrote to copy the system tracks to the M: drive and make it the system drive, I could copy between two foreign disk formats in the floppy drives. Warm/cold boots from the RAMdisk were practically instantaneous.

There certainly were a lot of BBS programs for TRS-DOS, but for CP/M you had the classics like Citadel, TBBS, RBBS, QBBS, RCPM. The selection of language compilers was pretty good, with several C compilers, Turbo Pascal and Modula-2, FORTRAN, COBOL and Lisp, among others.

 

[Chuck(G)]

Re: CP/M cost. Many systems were bundled with CP/M along with any number of applications. See, for example, Morrow's Micro Decision package--but there were many others, such as Access Matrix (Actrix), Osborne, Keypro... Even though PCDOS with the 5150 was only $40, my initial reaction was "why do I have to pay for something just to use the darned machine?". I suppose that the big reason for BASIC-in-ROM was intended as a legal defense--"see, you can still do things without an operating system."
Speaking of old operating systems, does anyone still run Morrow's Micronix?

 

[danielbooneamerica]

Well of course LS-DOS is far superior ;-)

LSDOS 6.x came too late. It was end of TRS-80 work life (first life anyway).

6.x was designed to overcome many things they had always wanted OS to do but it didn't (on Tandy side anyway).

Apps could work across multiple TRS-80 platforms w/o change (meaning apps created for 6.x forward), device routing, linking, filtering are just a few examples of new features.

LS-DOS 6 is very UNIX like. I think you will find a utility on Tim Mann website that gives you piping, i/o redirection and more. Sometimes new commands you can make like sort<dan.txt | print is about as UNIX as you can get (on a TRS-80). Long before Linux. You can do all this with a stock model 4.

But hint hint.....systems architects of that day (like @logical Systems) were raised on IBM mainframe and that new upcoming OS of the day in academic circles, UNIX.

Smart programmers could see UNIX and UNIX like was the way of future. Building small modules that can be linked together to do larger jobs like tinker toys.

This is of course, all in my humble opinion.

 

[fritzeflink]

Hi Lown,
interesting question but sadly I never use TRSDOS or LSDOS for a longer time than some hours.

Of course my 1st contact in computing was NEWDOS running on a Videogenie in 1977(?) . Than later I used CP/M on other systems most the time.
Happily I had the source code for my CP/M system (TCS Genie IIIs) and proudly it even was TRS80 compatible so I could run NEWDOS, GDOS (German NEWDOS) and so on.
Of course without enhancements like ZCPR, NZCOM and others CP/M wasn't as comfortable as NEWDOS / TRSDOS but it was a well build grounding.
A big problem with CP/M was the unbelievable quantity of floppy disks formats.

 

[danielbooneamerica]

Users might benefit by studying how similar to UNIX, LSDOS is.

Drivers, modules and apps communicate very similar to UNIX I/O system.

 

[Patrick.B (TTR)]

I have been using TRSDOS/LSDOS Model III or 4/4P/4D as well as MM CPM 2.2 and Tandy CPM 3 Plus.

Well, I am not sure good or bad, but in the LSDOS/TRSDOS Model 4/4p corner you do have the High-resolution video board, Alpha Technology Speedup Board v2.0 pushing your Model 4 up to 6Mhz Z80, Music/Sound Board Orchestra-90 and other hardware that where never "developed" to run under CPM.

I would say it all depends on what it is that you are developing and whom you're trying to reach with your program.

 

[lowen]

...

I would say it all depends on what it is that you are developing and whom you're trying to reach with your program.

Totally agreed. LS-DOS is at it's core a strictly TRS-80 'thing' and the desired 'reach' is to TRS-80 people. CP/M has a much more general audience, and a much larger software base.

The excellent book 'Priming the Pump' has a whole chapter dedicated to the 'DOS Wars' that occurred.

Users might benefit by studying how similar to UNIX, LSDOS is.

Drivers, modules and apps communicate very similar to UNIX I/O system.

To a degree this is true. Device I/O independence was built into the original Randy Cook TRSDOS (from whence came VTOS, then LDOS, then LS-DOS/TRSDOS 6) and could be ROUTEd, LINKed, and FILTERed in many ways, but the typical Unix shell is way more flexible and powerful. Cook's background after all was in the world of professional computing, including building software used by NASA's Apollo program. Again, 'Priming the Pump' has some great information on this that I'm not going to paraphrase here. I would also point to an article, titled "Randy Cook and the Thorny Path that Began with TRSDOS 2.0" in the March 1981 issue of 80 Microcomputing (available at the Internet Archive); the article starts on page 48. This article is a fascinating read. The lines I find most germane to this discussion are:

Shugart contracted with Radio Shack to provide disk drives for their computers. Part of the deal included Shugart taking the tab for a disk operating system. Cook was working on a DOS for minis with Xerox when Shugart contacted him. He began working on a "minimal" DOS to meet Shugart's specifications, he explains.

So the operating systems Cook had been exposed to by that time likely included Unix. This happening in 1978 would mean the Unix in question would have been V6, or Sixth Edition. But this was 'Research Unix' since Unix wasn't a 'product' as yet. Cook spent time at Datapoint prior to Xerox. I'm not really up on Xerox history, but one reference says that Cook was working on packet switching stuff; perhaps even Ethernet.

But the crown jewel at Xerox at the time would have been the Alto. Cook would have at least had a passing awareness of the Alto and its design. Cook was an expert in disk interfacing according to 'Priming the Pump' and was known by Finis Conner as such, and that's how Shugart got ahold of Cook.

So Cook would have had a rather broad operating system knowledge, and his own description of TRSDOS was a 'minimal' operating system. I find it interesting then that device independence and I/O redirection, along with user, owner, and disk passwords, would be considered 'minimal.'

CP/M has a rather different and much earlier history; CP/M is a full five years older than TRSDOS. I'll leave it to others to outline that history.

 

[Eudimorphodon]

This happening in 1978 would mean the Unix in question would have been V6, or Sixth Edition. But this was 'Research Unix' since Unix wasn't a 'product' as yet.

FWIW, even thought it wasn't really a "product" yet V6, circa 1975, was quite widely distributed. Particularly notable is in addition to the "real" Unix V6 (which required a reasonably beefy PDP-11 to run) there was also a "Mini-UNIX" variant designed to run on low-end PDP-11's without memory management/address extension hardware, which had capabilities broadly in line with the sort of redirection/pipe capabilities that were implemented in microcomputer OSes like TRSDOS or the MS-DOS shell, IE, limited capability for implementing filters and redirection in the "kernel" space but largely making use of temporary files/process chaining in place of true multitasking for "pipes". (And it's not like UNIX invented these things from whole cloth.) It's pretty likely anyone working for a "real" computer company in the 1970's would be familiar with these concepts.

So Cook would have had a rather broad operating system knowledge, and his own description of TRSDOS was a 'minimal' operating system. I find it interesting then that device independence and I/O redirection, along with user, owner, and disk passwords, would be considered 'minimal.'

That is what really stands out about TRSDOS, I suppose; it's definitely reasonable to point out that it was remarkably... ambitious for the time, especially considering it was written to run on a computer which was kind of infamous for nickel-and-dime-y cheapness when it came to the hardware. It certainly stands out compared to CP/M for having such a rich and featureful CLI implemented in the form of a built-in command processor that transparently swapped code in and out of memory with overlays. On the downside the resulting OS is pretty difficult to use on a single floppy drive because of its reliance on having a system disk available all the time. (This particularly sort of sucked on the original single-density Model I, since even a drastically stripped-down system disk only left around 50K free. Also, gotta say, I never really got the point of passwords in TRSDOS. If someone wanted to steal your data they could just walk off with the floppy and get it with a sector editor, it's not like it was encrypted. Seems like in general they were more of a hassle than anything else.)

It's also not as if TRSDOS/Tandy had some kind of monopoly on having surprisingly sophisticated concepts buried in their toy computers. I'm actually pretty impressed with how, for instance, Commodore implemented the "KERNAL" core OS in their 8-bit line. Device independence is pretty deeply embedded in those machines; UNIX has its "everything is a file" concept, the Commodore 8-bits have an "everything is an IEEE-488 device channel" paradigm for dealing with I/O.

(To be fair Microsoft was also pretty good with Level II BASIC about implementing a jump table in RAM that allowed some level of device redirection/driver substitution at the ROM level on the TRS-80, but the Commodore design was a lot cleaner.)

 

[danielbooneamerica]

Posts have pointed out in UNIX..... everything is a file.

However they failed to point out in TRSDOS everything is a file or can be treated this way...(I only know bout 6.x when I speak).

 

[danielbooneamerica]

api provides backwards calls for original TRS functions (keyboard, display etc).

But as DOS evolved it developed into a system based on I/O stream I/O.

All commuications are done like UNIX, GET - PUT - CTL.
Of course routing, filtering, linking etc.

But main power lay with GET PUT CTL.
Model 4 compilers generate code that communicate with keyboard and display using I/O stream and GET/PUT/CTL.
This allows for easy redirection of I/O stream.

Model 1/3 was not as defined as this. Many factors.
One they didnt forsee people using these machines for that long and as many different ways as they were.
Remember Tandy didnt think in beginning they would sell.

Devices are seen as files. Roy Soltoff states this in TRSDOS 6,x progrmmers ref manual.

TRSDOS 6 was DOA. Once it got to 6 level it was already doomed, even if they didnt know it yet.
This stopped serious systems programmers and app programmers to keep developing software for it.
So we will never know what could have been.
But like all things I am sure it boiled down to cost and time.

Some calls in 6.x is just to maintain backward compatibility.
Sadly they could not start from scratch but needed to maintain compatibility with earlier versions of DOS/APPs.

I do not know much about CP.M, just that LSDOS is superior.
Logical Systems reserved a RST in TRSDOS 6 for something called CP/M EMULATOR. Have not been able to find any information on this.
Maybe TRSDOS was going to run CP/M apps.

 

[lowen]

Posts have pointed out in UNIX..... everything is a file.

However they failed to point out in TRSDOS everything is a file or can be treated this way...(I only know bout 6.x when I speak).

This is partly true. Devices cannot have a logical record length like a file can. Quoting the Programmer's Reference Guide to TRSDOS/LS-DOS 6: "The operating system permits filespecs and devspecs to be used equivalently in most cases." (page 3-1) As long as @PUT and @GET are being used, device I/O and file I/O are equivalent. Once @READ, @WRITE, and @VER are used, files and devices diverge, as now we're reading and writing records, not characters.

But instead of the standard Unix shell way of having three standard files automatically opened (stdin, stdout, stderr) the TRSDOS/LS-DOS way is to use the @KBD, @KEY, and @KEYIN SVCs for stdin, @DSP and @DSPLY for stdout, and @LOGER and @LOGOT for stdout (@LOGOT does dual output to stdout and stderr). Then there is the multifunction @VDCTL, as well as @PRINT and @prt for the printer.

The framework for good device I/O as a character sequential file is solid, though, and well designed. This dates well before TRSDOS 6, though, as LDOS 5 for the Model I and Model III also have all of these features, including the ability to load an SVC table in memory and use the TRSDOS 6 SVC calling method. VTOS 4 by Randy Cook is the origin of this.

Model III TRSDOS 1.x on the other hand, is not at all the same animal.

...

But main power lay with GET PUT CTL.

Agreed, although for disk files @GET and @PUT are noticeably slower than record I/O where the LRL is 256 bytes. That's part of the reason most programs use the sector calls. For LRLs other than 256 bytes, it's more complicated.

Model 4 compilers generate code that communicate with keyboard and display using I/O stream and GET/PUT/CTL.
This allows for easy redirection of I/O stream.

I did some work with MC back in the day. It's handling was pretty standard, for a K&R compiler.

Model 1/3 was not as defined as this. Many factors.
One they didnt forsee people using these machines for that long and as many different ways as they were.
Remember Tandy didnt think in beginning they would sell.
...

By the time of TRSDOS 6 the spectre of MS-DOS was on the horizon, and there are many posts on the old comp.sys.tandy Usenet newsgroup (especially by Frank Durda IV) talking about what was going on with the management at the time. I'll not quote those here.

Some calls in 6.x is just to maintain backward compatibility.
Sadly they could not start from scratch but needed to maintain compatibility with earlier versions of DOS/APPs.

Backwards compatibility can be a real hindrance, but at the same time people want to use what they've already paid for. For a long while I used the Model III Editor/Assembler to develop TRSDOS 6 programs, simply due to the economics of re-tooling.

I do not know much about CP.M, just that LSDOS is superior.
Logical Systems reserved a RST in TRSDOS 6 for something called CP/M EMULATOR. Have not been able to find any information on this.
Maybe TRSDOS was going to run CP/M apps.

It does appear that this was a least thought about looking at the source code around address x'0005'; but with Montezuma Micro's CP/M being available and very good, the main need for LS-DOS to support this pretty much went away, from an economic standpoint. Basically, who was going to fund it? CP/M users preferred the simpler CP/M to run their apps, and Tandy didn't care as long as a Model 4 was sold.

I personally prefer LS-DOS 6 to CP/M, but that doesn't make it 'superior.' More technical features? Absolutely. More technically advanced? Yep. But 'superior' can mean 'has more applications' too, and for that CP/M wins hands down. Just as one example, the CP/M HiTech C compiler isn't just K&R, but ANSI and much more standard than the TRS-80-only MC, as good as MC was.

As far as technically advanced is concerned, the best and most technically superior OS currently available for the Model 4 line has to be Fuzix. If being like Unix is a feature, Fuzix is the king of Z80 operating systems.

 

[lowen]

FWIW, even thought it wasn't really a "product" yet V6, circa 1975, was quite widely distributed.

I think I saw somewhere that by 1978 there were over 600 Unix installations.

It certainly stands out compared to CP/M for having such a rich and featureful CLI implemented in the form of a built-in command processor that transparently swapped code in and out of memory with overlays. On the downside the resulting OS is pretty difficult to use on a single floppy drive because of its reliance on having a system disk available all the time. (This particularly sort of sucked on the original single-density Model I, since even a drastically stripped-down system disk only left around 50K free.

Overlays were at the same time brilliant and stupid, for all the reasons you say above. At least with a 128K Model 4 you can build a memdisk in the second 64K and load your overlays there. Even when I ran a hard disk system drive :0 became a memdisk soon after boot, thanks to the excellent FDR utility (fast dump/restore) that could pull the memdisk image from hard disk very quickly. But I also had 320K of RAM; this gives enough room for a meaningful drive :0 in RAM.

Also, gotta say, I never really got the point of passwords in TRSDOS. If someone wanted to steal your data they could just walk off with the floppy and get it with a sector editor, it's not like it was encrypted. Seems like in general they were more of a hassle than anything else.)
...

Tandy didn't sell a sector editor, and in early TRSDOS versions for the Model II and Model III the entry points weren't documented for the read/write sector routines. The debugger had protections against breakpointing or single-stepping OS code, and the password hash function used undocumented Z80 opcodes to obfuscate how the has was generated. For the most part it protected things from the typical business user; Tandy wasn't nearly as interested in the hobbyists as they were in businesses. But with a sector editor it became pretty easy to defeat the protections, even including the 'backup-limited' stuff.

(To be fair Microsoft was also pretty good with Level II BASIC about implementing a jump table in RAM that allowed some level of device redirection/driver substitution at the ROM level on the TRS-80, but the Commodore design was a lot cleaner.)

The Commodore design for this was indeed very clean.

 

[Eudimorphodon]

Model III TRSDOS 1.x on the other hand, is not at all the same animal.

It is kind of remarkable what an outlier Model III TRSDOS is in the family tree of TRS-80 operating systems. The root is clearly TRSDOS 2.x for the Model I; there's a bunch of major branches that come off pretty low to the ground as bugfixes for 2.1, IE, NEWDOS/DOSPLUS/ULTRADOS/etc, which ended up evolving along in parallel with what I guess deserves to be called the main trunk, which is the VTOS3/4->LDOS->TRSDOS6/LS-DOS line. What unites all those alternate OS branches, however, is all of them did a better job implementing Model I/III cross-compatibility (once they had Model III versions available) than Radio Shack's TRSDOS 1.x did. All of them had the capability of sharing a common single-density data disk format between the two (and of course they all supported double density boards once those became a thing), and the Model III versions usually had fewer compatibility glitches with Model I software; generally you could apply a single patch and software would work on either machine. Radio Shack's default DOS for the III, by contrast, required a one-way-only CONVERT process to pull over data, had significant operational differences, and used an oddball disk format that nobody else ended up copying. (The double-density formats of the other DOSes tended to be more straightforward conversions of the original Model I format.)

It's weird, it's like Radio Shack intentionally wanted to make it as hard as possible for someone who already owned a fleet of Model I's to be able to just buy some III's and integrate them into the operation. It's like they expected every III customer to throw out what they had after running CONVERT, which I guess might have looked like a good way to sell more computers, but realistically... no. Just no.

 

[danielbooneamerica]

This is partly true. Devices cannot have a logical record length like a file can. Quoting the Programmer's Reference Guide to TRSDOS/LS-DOS 6: "The operating system permits filespecs and devspecs to be used equivalently in most cases." (page 3-1) As long as @PUT and @GET are being used, device I/O and file I/O are equivalent. Once @READ, @WRITE, and @VER are used, files and devices diverge, as now we're reading and writing records, not characters.

But instead of the standard Unix shell way of having three standard files automatically opened (stdin, stdout, stderr) the TRSDOS/LS-DOS way is to use the @KBD, @KEY, and @KEYIN SVCs for stdin, @DSP and @DSPLY for stdout, and @LOGER and @LOGOT for stdout (@LOGOT does dual output to stdout and stderr). Then there is the multifunction @VDCTL, as well as @PRINT and @prt for the printer.

Actually this is only partially true. Most of 1st paragraph is true for both UNIX & LSDOS. Unix sees a stream of char but routines have to be added to block and deblock. Things you point to in TRSDOS do same thing just different names.

TRSDOS uses STDIN & STDO. Close examination will show these are simply routed to video & keyboard device control blocks.

As far as using a sector editor to edit TRSDOS files you can do this same thing on Unix. In fact we used to read payroll records of a fortune 500 company using a sector editor.

These records were written under MVS and contents were simple file layouts you could follow.

Sometimes, behind curtain the magic is pretty simple, its people's imagination that makes things bigger than they are.

Often its is same ideas, just different names and some changes to make it fit target hardware platform.

 

[lowen]

Actually this is only partially true. Most of 1st paragraph is true for both UNIX & LSDOS. Unix sees a stream of char but routines have to be added to block and deblock. Things you point to in TRSDOS do same thing just different names.

For a logical record length of 256, the byte I/O layer is bypassed and a full sector at a time is read or written in TRSDOS.

...
As far as using a sector editor to edit TRSDOS files you can do this same thing on Unix. In fact we used to read payroll records of a fortune 500 company using a sector editor.

Been doing this since my TRS-XENIX 1.x (V7) days myself (TRS-XENIX is why I have been a full-time Linux user since 1997). The major difference here between TRSDOS and Unix/Xenix is that the entire disk is also treated as a file by Unix; editing a binary file and editing a whole disk are no different. On a modern Unix-like operating system like Linux, you can, as long as you have the privileges to do so, run something like 'hexedit /dev/sda1' and you will find yourself editing the first partition on the first enumerated SCSI disk (or SCSI-like disk, like a SATA, SAS, fibre channel LUN, or even a USB drive). For that matter, you could even 'hexedit /dev/kmem' and edit the kernel's memory space as if it were a file, too.

Cook's TRSDOS, which should not be confused with Model II or III TRSDOS (or Model I TRSDOS 2.7DD), had but the rudiments and foundations of device/file stream I/O independence. But it DID have those rudiments.

What you can't do on TRSDOS/LS-DOS is the part of the Unix Philosophy (as stated well by 'The Unix Programming Environment') that encourages the use of small 'tool' programs in I/O pipelines; I frequently use the standard Unix/Linux grep and cut tools in this way to pull apart reports and such. I frequently use constructs like

yum list --installed|grep epel|cut -d ' ' -f 1|xargs -n 100 yum remove

in $dayjob; this type of I/O redirection is highly cumbersome with LS-DOS (Frank Durda IV did write a 'PIPE/CMD' that can emulate what a Unix pipe does, but without robust and full multitasking it becomes difficult). LS-DOS implements a subset of the Unx philosophy, and it does it well and was very advanced for the time.

Having said that, years ago I argued the same point as you, and Frank Durda IV is the one who took exception to it. LS-DOS redirection, as powerful as it is, is not nearly as expressive or pervasive as the redirection abilities of a typical Unix with a typical shell, even the old V6 Thompson shell.

For CP/M, the closest you get is the CONIX CCP replacement, which also gives I/O redirection of a sorts.

Unix takes it a step farther and does away with drive identifiers for the filesystem; no drive numbers, and no drive letters. Directories are just files, too (on LS-DOS you can actually read the directory using DIR/SYS). Volumes are mounted on directories within the one filesystem; this of course requires a hierarchical filesystem, which neither CP/M nor TRSDOS/LS-DOS implement. CP/M has user spaces; TRSDOS/LS-DOS has DiskDISK; both serve the purpose, but true hierarchical filesystems they aren't.

Sometimes, behind curtain the magic is pretty simple, its people's imagination that makes things bigger than they are.

Agreed.

Often its is same ideas, just different names and some changes to make it fit target hardware platform.

Absolutely. The strength of Unix (and of CP/M for that matter) is that it is so very portable to different architectures (yes, I know early Unix wasn't, but once you get V7 and System III you're in solid 'portable Unix' territory). The TRSDOS 6 design is a step in the right direction towards platform portability, but as you have found in your own eZ80 work, the system doesn't enforce as much isolation between LOWCORE and SYSRES as CP/M does between BIOS and BDOS. SYSRES and its overlays have non-API knowledge of LOWCORE and sometimes use that knowledge.

EDIT:

Adding a bit here. If LS-DOS implemented full Unix-style 'everything is a file' then:
1.) You would open a file to get FLAG$ via device byte I/O
2.) You would open a file to get the LOWMEM structure in LOWCORE's driver area.
3.) A DCT would be yet another file and would be no different from any other DCB (file descriptor in Unix terminology).
4.) The memory map would be another file.

This sort of thing is exposed by the Unix-like Linux OS in the special /proc filesystem. I can look at process stats among many other things by using standard file tools (like cat) to read files; want to see the status of the MDRAID subsystem, 'cat /proc/mdstat' and you have a report. Want to see what CPUs you have? 'cat /proc/cpuinfo' and find out. Want to change kernel parameters? Modify a file in the /sys filesystem. The list goes on.