Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!umnd-cs!umn-d-ub!rhealey
From: rhealey@umn-d-ub.D.UMN.EDU (Rob Healey)
Newsgroups: comp.sys.tandy
Subject: Re: Ldos vs. NeWDOS
Message-ID: <29@umn-d-ub.D.UMN.EDU>
Date: Wed, 9-Sep-87 15:41:31 EDT
Article-I.D.: umn-d-ub.29
Posted: Wed Sep  9 15:41:31 1987
Date-Received: Fri, 11-Sep-87 05:15:57 EDT
References: <52@nancy.UUCP> <18@umn-d-ub.D.UMN.EDU>
Reply-To: rhealey@ub.d.umn.edu (Rob Healey)
Organization: U. of Minnesota, Duluth - Computing Services
Lines: 59
Keywords: Dos War

In article <1123@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>I used TRSDOS and later LDOS back when I used a TRS-80.  Both have a
>serious design flaw.  They both want programs to load at a specific
>address.  Worse, the original TRSDOS had all the system calls at
>absolute addresses that had to be hard-coded into every program.  This
>is bad software design at its worst.
>
	This is a processor limitation, one can't code completly
	relocatable code on a Z80 although you can dynamically
	relocate programs.

>Constrast this with MSDOS.  At load time, the MSDOS loader performs
>relocation of EXE format files, so the code can be loaded anywhere.
>This is how operating systems should be designed.
>
	MSDOS relocates automatically, LDOS manually. You don't REALLY
	have relocatable code, you play games with segment register's.
	One MINOR point, you CANNOT relocate just anywhere, gotta be on
	a 16 byte alignment if I remember correctly.

>Even stupid old CP/M would let you build an operating system that
>loaded into the top of memory, no matter how much memory you had, so
>applications software and the operating system did not conflict unless
>you were actually short of memory.
>
	CP/M had relocation tables, movcpm did the relocating of the code.
	CP/M more or less REQUIRED your code to start at 100H, you could
	place it elsewhere but it made life a little more difficult. CP/M
	uses the TOP of memory, LS-DOS uses the bottom and doesn't HAVE
	to be relocated since low memory USUALLY, B^), doesn't dissappear
	on you! CP/M couldn't relocate DYNAMICALLY, it had to be relocated
	manually.

>Minidos solves a problem that should not exist in the first place.
>It's been nearly 10 years since TRSDOS was first marketed.  It's a
>shame they still haven't managed to fix its problems.  It's time to
>upgrade to a different oeprating system.

	How would YOU implement a new operating system on a Z80? You
	can chicken out and go to a 16 or 32 bit CPU. LS-DOS does a
	pretty good job for a Z80 machine and the TRSDOS type operating
	systems as they exist today are MUCH better than CP/M is. LDOS
	for model 1/3 CAN use a SVC based system so SYSTEM calls aren't
	hard coded, LS-DOS is 100% SVC driven so NO problems as far as
	system calls/services go.

	On my model 4, LS-DOS takes up 12k, worse case, and CP/M uses
	up 8k. When you take into account for the additional system
	services LS-DOS supplys CP/M and LS-DOS take up about the same
	space. LS-DOS has a MUCH cleaner interface though and also allows
	you to take advantage of job scheduling, low level, and a time clock.

	I prefer LS-DOS over CP/M because of all the extra services LS-DOS
	provides. The only reason I use CP/M is to run public domain
	programs that were written for old 808[05] machines.

			-Rob Healey

			rhealey@ub.d.umn.edu