[comp.sys.tandy] Ldos vs. NeWDOS

dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/01/70)

In article <24@umn-d-ub.D.UMN.EDU> rhealey@ub.d.umn.edu (Rob Healey) writes:
     Ah, but the point of minidos is: Any dos command, except copy,
     format, and append, load into the sys file overlay area, so a
     program can load at 5200H (or X'5200') and still use dos. (You can
     copy files with 'mdcopy').

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.

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.

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.

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.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

michael@stb.UUCP (Michael) (08/31/87)

In article <19@umn-d-ub.D.UMN.EDU> rhealey@ub.d.umn.edu (Rob Healey) writes:
>In article <7863@shemp.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes:
>>
>>Gee, let me put my 3 cents in :-)
>>
>>I use NeWDOS for a good Basic. No Kidding. I program in assembly (I could
>>do mnumonic to octal in my head when I was active) when I need to, and I
>>use NeWDOS/80 V2 basic for most of my work. Why?
>>
>	I mostly use C and assembly so the basic doesn't matter to me. The
>	basic does sound much better tho.

I never saw a good C for NeWDOS, only LC for Ldos.

>> (Comments about syntax of Ldos)
>  (reply showing syntax of Ldos Set command)

Ok, so set isn't such a bad command. But:
1) You need two commands before any changes to the default can be made
2) You need "dummy" devices to route out to a disk file

But my original complaint was about the syntax of Ldos commands in general.
Things where you say 
command filename (option1=X'ABCD')

and it complains if you don't have the close paren.

Consider
dump file 5200h 7000h 5200h

with

DUMP FILE (START=X'5200',END=X'7000',TRA=X'5200')

or compare
copy :0 to :1

with 

BACKUP
Source drive number? 0
Destination drive number? 1
(Some other, forgotten questions, deleted)

>>  (Complaints about density recognition and double density on model 1)

>	I only use model 3's and 4's so I don't have this problem. The main
>   problem is that the Model 1 ROM's only know about single density so track
>   0 side 0 will have to be in single density, don't know how well a MIXED
>   density track would work. The automatic density recognition is aimed at
>   THE WHOLE disk, on model 3/4's this works just fine but the model 1 get's
>   screwed in the deal. As I understand "sole", the program that allows you to
>   boot model 1's in double density, requires you format the disk as double
>   density first. Sole then format's a single density track 0 side 0 and
>   places the primary boot strap on the track. How does NewDos allow for
>   mixed density disks?

Ok. I was not talking about mixed density tracks, but mixed density cylinders.
SOLE's problem WAS that it only reformatted track 0 side 0, and not cylinder 0.
This was why it failed on double sided, double density disks.

NeWDOS does not allow mixed density tracks either. But it has a flag in the
drive type field to say "track 0 side 0 is in opposite density and should
not be used".

>>C) The utter waste of a device independent boot/sys! If you can't write a boot
>>routine in one sector, you are not doing a very good job. NeWDOS can boot on
>>the same types of drives as LDOS, and it nevers needs more than one sector.
>>
>	The boot routine only uses one sector. sys0/sys takes up the rest
>	of the track if I remember correctly. Are you saying NewDos fits
>	in 256 bytes!!! I think not. The trouble comes in that the boot
>	routine has to assume that the sys0/sys file and the directory are
>	all in one density. If it doesn't then you have to write code to
>	toggle density on read error which takes up valuable space on a
>	256 byte sector. NewDos must alter the boot routine to always use
>	one density on boot.

Hmm, as I remember Ldos needed 512 bytes (two sectors) because of the
overhead in loading the entire disk input routines with the boot
code. Maybe they trimmed it down since then.

NeWDOS's assumes that sys0/sys will be contiguous from lump 0. How it tells
the disk density I don't remember, but I belive it is customized at backup
or pdrive time for the specified density.

>>D) Minidos. Newdos's will let you do everything except backup a disk,
>>or append files, or format. Ldos's not only restricts you to about 5
>>commands, but the syntax is completely different than the regular mode
>>syntax.
>>
>	Never make use of minidos since I use DOS assembly calls that
>	will run library programs in the overlay area and then return to
>	the calling program. Overlay area is 5200H to 5fffH on a model 3
>	so if you code from 6000H on your ok and don't have to take any
>	special precautions.

Ah, but the point of minidos is: Any dos command, except copy, format, and
append, load into the sys file overlay area, so a program can load at
5200H (or X'5200') and still use dos. (You can copy files with 'mdcopy').

>>And lets not forget that giving LDOS all those nice features that almost
>>make it as usable as NeWDOS takes HUGE, HUGE chunks of your memory
>>away from you. Sheesh.
>>
>	For the model 1 drivers had to be loaded to compensate for the
>	hardware design flaws. On a model 3 I can use from 5200H on
>	if I don't want to make use of library routines or 6000H on
>	if I do. What is the low address for NewDos? Ldos uses overlayed
>	library commands so that you have to code from 6000H up if you use
>	the library commands. 3.5K doesn't seem too unreasonable a loss
>	for the added utility of the library programs.

Well, 3.5K for Ldos compares to 0K for NeWDOS. But even besides that,
NeWDOS has no overhead for their keyboard driver which gets rid of bounce
and gives autorepeat. LDOS has a large overhead for that. LDOS has
overhead for lowercase video support, NeWDOS does not.
>
>>Oh yes, before I forget. I prefer NeWDOS's "Logical Track" lumps and long
>>directory format. LDOs only let you give one track to the directory, much
>>too small. Not to mention that it would resize GRANS on you all over the
>>place making it impossible to compare different sized disks. Heck, NeWDOS
>>would let you do a disk to disk copy on different sized disks if they had the
>>same number of sectors.
>
>	I admit LDOS and similar systems nail you in the gran dept. Although
>	being limited to 254 files seems to be a blessing to me. Since
>	TRS-80 DOS'S are all flat directory structures having more than
>	254 files on a logical disk would seem to be a pain. 

Well, lets say I wanted 222 files on a disk, but my track size
wasn't big enough for that many.
NeWDOS lets you chose the directory size from 10 sectors to 30 sectors on
any size disk, even if you only have 18 sectors per cylinder.

>	Why do you use so many different sized disks? Wouldn't date stamps
>	handle the problem of different file versions? Ldos is more file
>	file oriented than sector oriented. You can write programs to do
>	sector by sector compares but isn't it the files one worrys about
>	and not the sectors? Ldos allows you to backup different sized
>	disks no problem, it even prompts you to insert more blank disks
>	if your source disk is larger than the destination. It couldn't
>	care less about track/sector sizes, it copys as files not raw
>	disks which I think to be much better.

I use different sized disks because:
A) Most of my stuff is on 40 track DSDD
B) A few are 43 DSDD
C) Old stuff is 40 SSSD

But I don't remember if copy with copy-by-file option would prompt you for
the next disk if the source was larger. I think it did, but I never used
that very much.

>	Ldos requires that all disks be formatted before you try to backup
>	onto them. This allows backup to figure out whether or not to
>	do a sector by sector copy or a file by file copy. Ldos marks a
>	file as being altered since last backup so you can easily see what
>	files have been changed and which ones haven't, this shows up in
>	the directory display.

Gee, NeWDOS uses a command line option to determine, and will format a
blank disk for you (why not? The format code loads at the same time, the
data needed is all there). And yes, NeWDOS has a "file modified" flag.

>	It looks like we use our computers for different things, there is no
>	one-size-fits-all dos so maybe that's why NewDos works great for you
>	and Ldos works great for me. Most of your complaints seemed to be
>	related to Model 1 problems, I only have a 4 so these problems are
>	moot in my case. I would really like to hear more about the guts
>	of NewDos, it sounds like it takes a different approach to alot of
>	things. How exactly does "logical tracks" work? Where could I get
>	a copy of NewDos for my 4?

Logical tracks are as follows:

A gran is always 5 sectors.
A lump is from 2 to 8 grans, user settable.
The Directory entry has Lump number and gran within Lump.

Replace "lump" with "track" and you have trsdos SSSD.

And yes, when you do raw I/O to the disk you do I/O to a sector number,
not a track and sector within track.
					Michael
-- 
: Michael Gersten		seismo!scgvaxd!stb!michael
: Copy protection? Just say Pirate! (if its worth pirating)

rhealey@umn-d-ub.UUCP (09/03/87)

In article <94@stb.UUCP> michael@stb.UUCP (Michael) writes:
>But my original complaint was about the syntax of Ldos commands in general.
>Things where you say 
>command filename (option1=X'ABCD')
>
>and it complains if you don't have the close paren.
>
>Consider
>dump file 5200h 7000h 5200h
>
>with
>
>DUMP FILE (START=X'5200',END=X'7000',TRA=X'5200')
>
	Has to do with the user callable command line parser for lazy
	assembly programmers, actually it does save alot of space in your
	own code. C provides it's own command line parser so I don't use
	the system one. My Ldos don't complain about no closing parens tho.
	Minimal version would be: dump file (s=x'5200',e=x'7000',tra='5200'
	Still yucky compared with the newdos version.

>or compare
>copy :0 to :1
>
>with 
>
BACKUP :0 :1  - For exact copys, backup $/$:0 :1 to force file by file copys.

	On LDOS backup is really more of a copy program than simple backup
	program. A subset of it's copying is "mirror image" or cylinder
	by cylinder copying.

>
>Hmm, as I remember Ldos needed 512 bytes (two sectors) because of the
>overhead in loading the entire disk input routines with the boot
>code. Maybe they trimmed it down since then.
>
	Might be the model 1 version oinked the code, the model 3/4 disk
	system needs very little code to load in sectors and only needs
	256 bytes.

>NeWDOS's assumes that sys0/sys will be contiguous from lump 0. How it tells
>the disk density I don't remember, but I belive it is customized at backup
>or pdrive time for the specified density.
>
	LDOS finds where the directory cylinder is from the boot sector,
	searches the directory for sys0/sys, actually it's in a known
	offset of the directory, and loads it in. sys0/sys has the restriction
	that it must be contained in continuous grans with no fragmentation.

	Since model 3/4's use double density all the time there is no need
	to set the density in the boot code. My guess is that "sole" futtsed
	with the boot code the same way backup or pdrive does on NewDos.

>Ah, but the point of minidos is: Any dos command, except copy, format, and
>append, load into the sys file overlay area, so a program can load at
>5200H (or X'5200') and still use dos. (You can copy files with 'mdcopy').
>
	LDOS's library commands use 5200h to 5fffh for their load addresses
	so NewDos get's points in that dept. System calls don't use any
	area outside of the DOS area tho. How big is the NewDos "Kernal"?
	The minidos commands must be larger than 256 bytes and the code
	has to go somewhere. What programs do you use minidos in? For
	the most part all the model 4 programs allow you to execute a
	system command from within them. Model 3 Ldos basic does allow
	use of system library commands via cmd"command".

	
>Well, lets say I wanted 222 files on a disk, but my track size
>wasn't big enough for that many.
>NeWDOS lets you chose the directory size from 10 sectors to 30 sectors on
>any size disk, even if you only have 18 sectors per cylinder.
>
	Hmmm, does it hog two tracks for let's say 22 sectors or does it only
	use the number of sectors that it has to?

>>	Ldos requires that all disks be formatted before you try to backup
>>	onto them. This allows backup to figure out whether or not to
>>	do a sector by sector copy or a file by file copy. Ldos marks a
>>	file as being altered since last backup so you can easily see what
>>	files have been changed and which ones haven't, this shows up in
>>	the directory display.
>
>Gee, NeWDOS uses a command line option to determine, and will format a
>blank disk for you (why not? The format code loads at the same time, the
>data needed is all there). And yes, NeWDOS has a "file modified" flag.
>
	Backup on LDOS is a copying only program so the format code isn't 
	loaded in. They do provide a QFB program which formats and backups
	at the same time. Backup has alot of switches for backing up by
	date, modification and whether the file exists on the other disk.

>And yes, when you do raw I/O to the disk you do I/O to a sector number,
>not a track and sector within track.

	Looks like they made the sector the key unit on NewDos, one could
	code a sector to cylinder/sector routine fairly easy but I usually
	operate with files rather than raw sectors. Interesting concept 
	with the logical sectors and lumps and such. Do they make a model 4
	version on NewDos? Might be interesting to play with. I basically
	bought utilitys that compensate for the DOS, zshell for redirection
	and pipes is the main one. I tend to use programs I wrote myself
	with C or assembly so that, combined with zshell, I very rarely
	need to use any system commands beyond dir, format, and backup.

	Looks like NewDos really helps out model 1 people more than any
	other DOS but since I have a model 4 it doesn't help me much.
	It looks like both of us have found ways to keep using our '80's
	in a world that's gone IBM blind. MSDOS is a piece of @#$% compared
	with ANY version of TRS-80 DOS's.

	If you have anymore interesting tidbit's on NewDos I'd be glad to
	hear 'em, it sounds like an interesting system.

			-Rob Healey

			rhealey@ub.d.umn.edu

michael@stb.UUCP (Michael) (09/07/87)

In article <24@umn-d-ub.D.UMN.EDU> rhealey@ub.d.umn.edu (Rob Healey) writes:
>>Ah, but the point of minidos is: Any dos command, except copy, format, and
>>append, load into the sys file overlay area, so a program can load at
>>5200H (or X'5200') and still use dos. (You can copy files with 'mdcopy').
>>
>	LDOS's library commands use 5200h to 5fffh for their load addresses
>	so NewDos get's points in that dept. System calls don't use any
>	area outside of the DOS area tho. How big is the NewDos "Kernal"?
>	The minidos commands must be larger than 256 bytes and the code
>	has to go somewhere. What programs do you use minidos in? For
>	the most part all the model 4 programs allow you to execute a
>	system command from within them. Model 3 Ldos basic does allow
>	use of system library commands via cmd"command".

Kernel is 2.75K, overlay area is 1.25K BASIC uses two overlay areas, the system
one and its own 1.25K overlay, plus a fair amount of "space reuse" to keep
free space large.
So, minidos commands are restricted to fitting within a one gran sys file,
and can be called from any program that either leaves interrupts enabled
or uses the standard key scan code.


>>Well, lets say I wanted 222 files on a disk, but my track size
>>wasn't big enough for that many.
>>NeWDOS lets you chose the directory size from 10 sectors to 30 sectors on
>>any size disk, even if you only have 18 sectors per cylinder.
>>
>	Hmmm, does it hog two tracks for let's say 22 sectors or does it only
>	use the number of sectors that it has to?

Only the number of sectors you tell it to use. Limit is 30 sectors.

>>And yes, when you do raw I/O to the disk you do I/O to a sector number,
>>not a track and sector within track.
>
>	Looks like they made the sector the key unit on NewDos, one could
>	code a sector to cylinder/sector routine fairly easy but I usually
>	operate with files rather than raw sectors. Interesting concept 
>	with the logical sectors and lumps and such. Do they make a model 4
>	version on NewDos? Might be interesting to play with. I basically
>	bought utilitys that compensate for the DOS, zshell for redirection
>	and pipes is the main one. I tend to use programs I wrote myself
>	with C or assembly so that, combined with zshell, I very rarely
>	need to use any system commands beyond dir, format, and backup.

Well, yea, when you use files you just worry about the sector within the file.
But a disk is treated more like a large file.

And no, there is no M4 version. In fact, they made NeWDOS80/V3, but canned
it when R/S announced the 4.
				Michael
-- 
: Michael Gersten		seismo!scgvaxd!stb!michael
: Copy protection? Just say "Off site backup"

rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (09/09/87)

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

zog@laidbak.UUCP (Christian G. Herzog) (09/10/87)

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.
>

	Spare us !  These OS's were written for a 8-bit microprocessor
	which provided no hardware support for program relocations.

	Hardcoded system calls weren't a problem since they were documented
	and the OS always loaded in the same place. (Interrupts were a more
	treasured resource on earlier 8-bit micros)

	What's the problem if you always set your programs to load at the
	lowest user area of memory and used the HIGHMEM pointer to find out how
	much memory was left ?  Have you ever written any position-
	independant code for the Z80 ? (LDOS filters come to mind along with
	the TRSDOS print spooler I wrote)  Do you remember the special ROM
	sequence to allow you to do this:

			POP	HL	; get the PC into HL
			JMP	(HL)	; get back to where we were


	Called by:

			CALL	----
			XYZ	ABC	; at this time the address of the
					; current instruction is in HL
					; where we can use an offset to
					; reference a buffer in our pos-ind
					; code


	(If anyone is interested, I can find the address of this routine
	 and forward it)

	Guess what, doing this was a pain in the ass unless you had a program
	that absolutely required it.  The OS would be massive if it needed to
	constantly adjust pointers dynamically or even call through a table
	set at boot time.  It also wouldn't really serve any point to "float"
	the OS since who knows how your program would need to be split if the
	OS might appear in your intended program space.

>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.

Obviously taking advantage of 5 years experience in micro OS's and
also the relocation capabilities of the hardware it is running on.
Contrasts like this don't mean anything.

What about when only COM files were available ?  OH NO ! No relocations !
>                                                                  This
>is bad software design at its worst.


>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.

What do you mean haven't managed to fix it's problems ?  Is anyone at
Tandy still working on TRSDOS 1.3 enhancements ?  As a Tandy stock holder
I'll drop John Roach a line and ask him to place that person on something
a little more productive.

Why beat a dead horse ?  The future isn't TRSDOS, but many applications
developed for it are still going strong !

>-- 
>Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

You post the most bizzarre things !
							 __  __________  __
							|  ||_______   ||__|
	    Christian G. Herzog				|  | _______|  | __
							|  ||   ____   ||  |
          {ihnp4,sun}!laidbak!zog			|  ||  |____|  ||  |
							|  ||__________||  |
          Lachman Associates, Inc.			|  |___________ |  |
							|______________||__|

dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/11/87)

A couple of people said that MSDOS can load programs at any
address only because the hardware supports relocation.

Actually, relocation under MSDOS happens in two ways.  Programs that
use only near pointers and near jumps can be loaded at any address
(probably aligned at a 16-byte boundary, I think).  The segmented
architecture takes care of the relocation.

Programs that use 4-byte pointers, however, need to have relocation
done load time.  This is done by the MSDOS loader routine looking at
the relocation table that EXE format load modules have.  The MSDOS
linker produces EXE format files by default.

What Radio Shack needed was a documented load module format that
allowed for a relocation table.  To the best of my knowledge, none was
ever provided.

I had many struggles with programs that wanted to load over each other,
most commonly an applications program I was trying to trace or debug,
and a debugger.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi