[comp.sys.tandy] GOS for the Model 4

7GMADISO%POMONA.bitnet@vu-vlsi.Villanova.EDU (04/03/88)

Date: 2 April 1988, 14:07:50 PST
From: 7GMADISO at POMONA
To:   COMP-SYS-TANDY at VU-VLSI

Part of the reason some HiRes programs are slow is, to put it bluntly,
inept coding.  Many of the PD programs I've seen don't seem to use address
clocking, for example, which GREATLY speeds things up.  Also, clever use
of the Video Waits bit can speed up some functions.  (If video waits are
OFF, you get snow... but there are some places you don't mind that.)  For
example: you want to clear the HiRes screen.  Instead of leaving the screen
visible and doing the clear with VW on, you hide the HiRes screen and clear
the display with VW *off*, gaining a lot of actual speed and even more
apparent speed.  If you have people who know what they are doing when they
write the screen driver code, screen access speed shouldn't be that
much of a restriction.

Like any argument about CISC vs. 'RISC', you have to realize the following:
the Z-80 can accomplish with one instruction (which may take as many as
four bytes) what it might take the 6502 MANY more instructions to accomplish.
A great example of this is the LDIR instruction; for block memory moves,
the Z-80 *demolishes* the 6502.  Furthermore, let's look at the actual im-
plementation.  Apple II running a 6502 at 1MHz vs. a Model 4 running a Z-80
at *4* MHz; even if we make the radical assumption that the 6502 is twice
as fast as a Z-80 at the same clock speed, the Model 4 will still on the
average be 2x as fast as the Apple II.  I have little doubt that such a
graphical interface could be supported on the Model 4.

Another Idea:  Such a graphical interface might want to recognize the ex-
istence of expansion RAM beyond the usual 128k, like the 256k the XLR8er
card adds, or the Alpha Tech memory card.  This would permit the GOS
(Graphical Operating Shell) to act like a Super-Double-Duty, allowing
multiple applications to be loaded and active (though only one would actually
be running) at a time.  Also, if one had extra ram, one could speed up the
GOS by using part of it as a RAMdisk for fonts, overlays, etc; out of a
384k XLR8er enhanced Model 4, one might have as many as 4-5 64k programs
running AT ONCE!!!  I'd also include a provision for one of those 'tasks'
to be complete access to the system; think how useful it would be to be
able to format a disk in the middle of doing something else, should the
need arise; and that's only one example.

If we really wanted to get extreme, we could come up with a version that
would REQUIRE expansion ram; it would take over the entire 'original'
128k for itself, and use the 256k of expansion ram to run 2 128k programs
(like Multiplan or AllWrite), 1 128k and 2 64k programs, or 4 64k programs
all at once, with complete access to all system functions at any time!  I
concede that this last would require some clever programming, but I see no
reason it couldn't be done; Double Duty exists as an example that it CAN
be done.

                    ---- George Madison


--------------------
''Your logic is impeccable, Captain; we are in grave danger.''
                           -- Mr. Spock ('The Changeling')

''Outside of a dog, a book is a man's best friend.
 Inside a dog, it's too dark to read.''
                           -- Groucho Marx

''Shut off that light, Stella; I won't be looked at in this
  merciless glare!''
                           -- Donald (from 'Brothers')
--------------------
BITNET: 7gmadiso@pomona
UUCP:   psuvax1!pomona.bitnet!7gmadiso