• Please review our updated Terms and Rules here

Model 4 TRSDOS/LS-DOS versus CP/M

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.
Again you are comparing a first release of LSDOS with something that had a litte more development.

By time LSDOS 6 arrived as I have said before, it was DOA. Yes there were some additional releases but mainly to fix y2k etc.
I have no doubt with time DCT would get opened as files.

Overall you could see where design of OS was headed. They had just begun and was trying to keep compatiable with older klugs of TRSDOS.

Had they been given a blank page I am sure it would have been much different.
 
Again you are comparing a first release of LSDOS with something that had a litte more development.

Of course this whole thread is about comparing two families of OSes with completely different design philosophies and development timelines to try to determine which one is “better”, which is pretty dirty pool from the get-go. The most common version of CP/M, 2.2, dates to around the same time as TRSDOS 2.1 for the Model 1, and still mostly stuck to the design constraints dictated by the original 1974 version. CP/M, which was designed to work on machines with as little as 16K of RAM and only swap one component, the CCP, in and out to disk (no huge pile of overlays) is obviously going to seem feature deficient by comparison to TRSDOS/LS-DOS 6, an OS arguably too heavy for the 64K+ platform it ran on…
 
Of course this whole thread is about comparing two families of OSes with completely different design philosophies and development timelines to try ,,........


TRSDOS/LS-DOS 6, an OS arguably too heavy for the 64K+ platform it ran on…
This thread is about comparing CP/M and TRSDOS.


UNIX was a small venture into 3rd OS.

All intelligent powerful OS have overlays in one form or another.

Sure they were slow on a M4 with 4mhz clock, simple floppy controller, no DMA, no cache just most basic of designs

However Soltoff did allow systems command to load them in RAM.

Or better yet place them in memdisk.

Overlays with proper hardware are not any sort of bottleneck.

I was a systems programmer on PDP11/45 for years.

It had 64k RAM with 16 bit address bus just like Z80. Memory management that then took lots of code to manage gave us up to 128k but just like a model 4 only 64k at any one time.

I suspect modern eZ80 is far more powerful than a PDP11/45.
 
So…
I suspect modern eZ80 is far more powerful than a PDP11/45.

Just to be clear here, this is in the opening post:
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.

How well TRSDOS runs on a CPU a bizillion times more powerful than that in the Model 4 seems a little off topic. The eZ80 is fast enough (at least for some applications) to give a decent 486 a run for its money, so if we’re comparing TRSDOS to operating systems that can run on that calibre of hardware (talking raw performance, not specifically the eZ80) I’m pretty sure you’ll find one with a better implementation of UNIX paradigms. Like plenty of actual 32 bit UNIXes.

All intelligent powerful OS have overlays in one form or another

Nobody ever claimed CP/M was or was trying to be those things. It was a set of simple APIs to implement, in a fairly hardware-agnostic way, a rudimentary command line processor and file/disk management system for running statically compiled character-based applications. It does that with a tiny memory footprint, trivial CPU overhead, and is extremely easy to port to new platforms as long as the hardware memory map has RAM starting at x0000h. For a useful small computer or embedded application this level of simplicity may well be preferable to a big bloated whale of an OS that really needs a bigger RAMDISK than its original platform could even do from the factory to run well.
 
… ultimately I guess what it comes down to to me is if you’re trying to argue that TRSDOS is a better OS than CP/M *today* for the eZ80 because it incorporates some vaguely UNIX-like ideas I guess maybe if I were absolutely stuck using the eZ80 as my hardware platform I might get onboard. But if UNIX is what I want there are plenty of $5 ARM SoCs that run real Unixoid OSes much faster than the more expensive eZ80 hardware and allow me to develop for them with fully modern tools so… I dunno, seems like kind of a tough sell for non-hobby applications.
 
big bloated whale of an OS that really needs a bigger RAMDISK than its original platform could even do from the factory to run well.
Model 4 was available for purchase and delivered with 128k upgrade.
Entire non-resident portion of TRSDOS fits in a ram drive <64k. So from factory you had entire DOS resident in RAM.
CP/M has overlays too, not sure what revision level.

TRSDOS ROCKS!
 
… ultimately I guess what it comes down to to me is if you’re trying to argue that TRSDOS is a better OS than CP/M *today* for the eZ80 because it incorporates some vaguely UNIX-like ideas I guess maybe if I were absolutely stuck using the eZ80 as my hardware platform I might get onboard. But if UNIX is what I want there are plenty of $5 ARM SoCs that run real Unixoid OSes much faster than the more expensive eZ80 hardware and allow me to develop for them with fully modern tools so… I dunno, seems like kind of a tough sell for non-hobby application
ummm.....no i am not arguing that TRSDOS is better *today*,,,,,my argument it was better yesteryear, yesterday, today and tomorrow.
As to being vaguely like UNIX, well I guess that is in eye of beholder. But to assembly programmerers on both platforms, there is a bell that seems to ring in background when reading Soltoffs books or code.

Heck I dont know and would not know him if he walked in door. Maybe he hated UNIX and wanted nothing to do with any of it and its all my immagination (that is possible).
 
Of course this whole thread is about comparing two families of OSes with completely different design philosophies and development timelines to try to determine which one is “better”, which is pretty dirty pool from the get-go. ...
As the OP, I started the thread to talk about pros and cons of each system. It was not my intent to see which was 'better' in all aspects, but rather a simple, factual, mature, comparison of features. If nothing else, the thread was intended to perhaps display why those who really enjoy LS-DOS and TRSDOS before it are as passionate as they are. Passion for the OS has certainly been on display.

LS-DOS in its last Misosys-developed incarnation was a maximal OS for minimal (by today's standards) hardware.

Is it a cool thing to port LS-DOS to more modern hardware? Sure it is, at least in the context of a hobbyist/enthusiast group such as this one, and I applaud Daniel's efforts in this space. But I'm a pragmatist, and if another OS has more application-aligned features for particular use case, I'm going to use that system. Thus a comparison between CP/M and LS-DOS. Perhaps I was a bit naive in thinking an objective comparison between these OSes with their different design philosophies could be performed.

For me at least LS-DOS is going to always have a place in my vintage-loving heart, if nothing more than I can actually understand the system and how it works and why it does what it does. I wrote some software for it, and those were really good days. It's nice to relive the 'thrill of victory' but you never rest on your laurels.
 
ummm.....no i am not arguing that TRSDOS is better *today*,,,,,my argument it was better yesteryear, yesterday, today and tomorrow.
As to being vaguely like UNIX, well I guess that is in eye of beholder. But to assembly programmerers on both platforms, there is a bell that seems to ring in background when reading Soltoffs books or code.

Roy put a great deal of effort ('blood, sweat, and tears' even) into the TRS-80 community. I have a great deal of respect for what he was able to do. I have attempted to reach out to him a couple of times over the decades, but have never gotten a response. Others who have gotten responses tell that he had at that time no interest in reliving what must have been very disappointing days as the TRS-80 market dried up. He is still out there as far as I know.

Heck I dont know and would not know him if he walked in door. Maybe he hated UNIX and wanted nothing to do with any of it and its all my immagination (that is possible).
While I can't and won't try to speak for him, I will say that you won't find anyone who was any more passionate about the TRS-80 Model 4 and LS-DOS even all the way into the early 1990's than I was. When my old non-GA Model 4 was stolen from me when I was in college, I received an insurance settlement for it, and went to Radio Shack and bought a new Model 4D. The salesman thought I had lost my mind by not getting a Tandy 1000 or 3000 (this was 1988). But no, I wanted a 4, even though I got enough to buy a fairly well equipped 1000. I finally had to sell it in 1992 shortly before I got married, since I would have much less space. It was a toss-up between selling the Model 4 stuff and the Tandy 6000 stuff, and the 6K ran Xenix (much superior for BBS communications, with the excellent pcomm software, as well as a solid Usenet implementation (C-News) and email via uucp, which were not available on LS-DOS), so I did two things: 1.) Kept the 6K and spares (a 16B and a 12); 2.) I bought LS-DOS 6.3.1A for the Model II/12 from Misosys so that I could get my LS-DOS 'fix' from time to time. The last thing I did with the 12 was make duplicates of my LS-DOS 6.3.1A for II/12 working disks for Tim Mann, back in 2000.

But I KEPT the LS-DOS 6.3.1A master disk; I am passionate about this OS.

But I'm a pragmatist; I couldn't do my normal stuff (such as post to VCF, for instance) if I were to only use LS-DOS.

So, I guess that gives me one more pro for each OS:

LS-DOS: a passionate user base, if small. There's a lot can be done with the bare OS alone.
CP/M: a much broader user base that is still pretty passionate about the OS, but more interested in the large application software catalog. Broad application availability is more important since the OS is really minimal.

When I found Tim Mann's xtrs I was pretty happy that I could run my TRS-80 software (I sold only the master disks of the Model 4 software; I kept my backups) on my more modern machines, and proceeded to archive my disks to DMK and I still every once in a while fire up the SDLtrs or trs80gp emulator (I have used both, although I find the trs80gp UI better and it can run Model II/12/6K stuff) and enjoy some nostalgia. Doing the same with a modern-built board such as the Min-eZ or eventually the Z280RC is a bit closer to the old feel; and again I do really appreciate what you have done in this space.

So I guess part of the reason I started this thread is to maybe put into black-and-white why someone would go to the effort of even bothering with LS-DOS these days.

According to what I've read, Roy has had a good career in software development and management since the closing of Misosys, but I can understand him not exactly having good memories of that time.
 
Last edited:
Thus a comparison between CP/M and LS-DOS. Perhaps I was a bit naive in thinking an objective comparison between these OSes with their different design philosophies could be performed.

Tisk, tisk, you should have known better. This is the Internet, over the top completely non-objective OS wars has been one of its foundational reasons for existing for something like thirty years now. ;)

Jokes aside, to be clear, I don't think it's at all wrong to ask the question what OS you prefer on the Model 4 and why. Considering there's really no practical reason to use a Model 4 today other than nostalgia I think TRSDOS out of the chute has a serious leg-up here because it is the native OS for the machine, it's special sauce. There's not much to distinguish a Model 4 running CP/M from any other roughly equally capable machine like a Kaypro or whatever, and I also would at least suspect that the majority of people who bought Model 4s did so as upgrades for older TRS-80 models, since by the time the Model 4 came out the writing was already on the wall for 8-bit machines. (Curious if there are any survey results or whatever shedding light on what the customer base was at the time.) These people probably came into the 4 predisposed to go with TRSDOS and thus it's an integral part of their passion for the machine. This passion especially seems relevant if you had some of the fun peripherals that made your TRS-80 more special, like the high-res board, Orchestra 90, etc, etc.

Anyway. Honestly, personally. I'm actually not much of a fan of CP/M; I mean, there's a place for vanilla and sometimes I'm up for a bowl, but it's definitely not what I think of when I think "TRS-80". But I do respect its simplicity, and I don't think it's really fair to dump on it because it's not more complicated. It does what it does perfectly well. I get the argument that TRSDOS has a lot more in the way of sophisticated OS API services, but if we're changing the subject to talking about doing development today I suppose the counterargument would be that there are comparatively vast bodies of support code/libraries that a CP/M developer can readily use that pretty much dispense with the need to care much about what the OS offers; CP/M is just the filesystem layer and that's all it needs to be if all the other resources can be baked into your binary at compile time. Different strokes for different folks, I guess.
 
Back
Top