trost@reed.UUCP (Bill Trost) (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.
I think that your understanding of TRSDOS is less than you suspect.
Not only will it allow you to load a program into memory anywhere
above the overlay area, but it will allow you to load different pieces
into different chunks of memory, a process known as scatter loading.
This allows you to some really neat and nifty things, like loading
drivers into high memory or even loading into screen memory instead of
having to draw an opening string.
--
...!(ogcvax|tektronix)!reed!trost @ All characters @ My opinions may or
"Ooh ick!" -- Penfold, anonymous @ are ficticious @ may not represent
assistant of *Dangermouse*, the @ unless they @ those of my employer,
world's Greatest Secret Agent @ are real. @ etc, etc.karl@ddsw1.UUCP (09/12/87)
In article <7118@reed.UUCP> trost@reed.UUCP (Bill Trost) writes: >In article <1123@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >% serious design flaw. They both want programs to load at a specific >% address. >I think that your understanding of TRSDOS is less than you suspect. >Not only will it allow you to load a program into memory anywhere >above the overlay area, but it will allow you to load different pieces >into different chunks of memory, a process known as scatter loading. >This allows you to some really neat and nifty things, like loading >drivers into high memory or even loading into screen memory instead of >having to draw an opening string. Yes, it will load the code ANYWHERE (and I do mean literally Anywhere, including attempting to load into ROM on a Model III -- although this will produce an error message because the loader can't write to ROM!) It will also happily load a program on top of a protected high memory region, destroying whatever might be there (and probably crashing your system as well). Now *that* is a serious problem -- especially if you keep drivers and other nifty stuff in the top of RAM, as I do (prime example: ERACS, our host/bbs system). There is literally no test for a proper (unused) load address, and no guarantee that you're in a 'safe' place.... Anyone (and I do mean ANYONE) who uses 'scatter loading' to load device drivers and such in high memory deserves slow execution -- these will fail EVERY TIME on a system which contains anything in high memory. The correct technique is to load in a non-scatter mode, then relocate your code to the *correct* place in memory. Oh, wait! I see the man in the back who says you can't write relocatable Z-80 code.... Baloney - at least on a Tandy I, III or IV! All three of them have a system call which is named "@Where". This system call returns the current physical address in (HL). Now, using this, and only a little black magic, it is quite possible to write relocatable long jumps and even CALL instructions! If your code is written in this manner it will execute properly at *any* legit physical memory address. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)
dhesi@bsu-cs.UUCP (09/12/87)
From trost@reed.UUCP (Bill Trost):
I think that your understanding of TRSDOS is less than you
suspect. Not only will it allow you to load a program into memory
anywhere above the overlay area, but it will allow you to load
different pieces into different chunks of memory, a process known
as scatter loading.
My understanding of TRSDOS is just fine. Suppose I compile a program
that normally loads at address x. But then I decide I really want it
to load at address x+1000, because I have loaded a debugger at
address x.
TRS-DOS can't handle this. Even if you could arrange to load it at
x+1000, the program will crash when you transfer control to it, because
all its absolute memory references still assume that it's loaded at x.
Sure you can write a self-relocating program, that calls the ROM to
find out where it is, then relocates all absolute addresses in itself.
This is a ridiculous situation. Your program is now forced to do
something that a well-designed operating system should have already
done for it.
(By the way, the @WHERE entry point was undocumented in all the
versions of TRS-DOS that I used, and this was some years ago. I found
out about it only by disassembling the ROM, and I think LDOS later
documented it. So from the TRSDOS user's point it might as well not
have existed.)
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesimichael@stb.UUCP (Michael) (09/14/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. Not quite: the address of a JUMP VECTOR is hardwired. From 4400H to about 44A0H is a table of jump vectors and rst calls. There are dozens of these defined, but only about 10 documented. These are the only ones you are supposed to use, and the only ones radio shack will use in our own programs, or at least thats what the trsdos 2.1 documentation said. (BTW, they did use other calls. Made porting binary from model 1/3 pretty hard (from the 3 to the 1). You want bad design? Quick--what does the call at 4409H do. -- : Michael Gersten seismo!scgvaxd!stb!michael : Copy protection? Just say "Off site backup"