Msg: 6438 *Conference*

04-15-96 14:57:01

From: RON WIESEN

To : ALL

Subj: OPINIONS NEEDED FROM RAMPAC/DATAPACK USERS

EME Rampacs and NODE Datapacks of 256K or less capacity have a precious and yet
unused resource.  I discovered this while helping someone with a Rampac
problem.  I'm seeking opinions from Rampac owners about what is most needed
that we can apply this resource toward.  Everyone's opinion is needed,
especially folks who aren't technically inclined and who can least appreciate
what a gold mine this resource represents.  Trust me, your experience and
technical detachment make your opinions as precious as the resource!
 
This Rampac resource has a capacity of 512 bytes. Dovetailed to similar
capacity "unused resources" in Model 100/102 and Model 200 laptops, one heck of
a lot of "useful" stuff can be obtained at "no cost". Useful "packages" can be
developed. You run an install program one time to put "package code" into the
Rampac resource, and the Rampac remains "useful" forever more. Note that the
"package code" stays in the Rampac and is "useful" in any laptop that you mount
the Rampac onto.
 
Here's some things I've done with this resource to date.  Although some
technical detail can't be avoided here, everyone should note that none of these
things consumes much of the resource capacity.
 
1. As an alternative to the 8-line 163-character RAM100 Cold Loader program, a
no-line immediate 69-character statement cold loads the RAM100.CO file. It's
less prone to typing errors. Unlike the program which depends on certain
things, this depends on nothing.
 
2. Via the same 69-character statement, Rampac user "help screens" are
presented. One case is where a 7-line equivalent RAM100 Cold Loader program,
along with commentary, remains listed on the screen while you use the 8th line
of the screen to type in the 7-line loader and all the while have the listing
in view for comparison to avoid typing errors. This consumes less than half of
the resource  so additional "help screens" can follow.
 
3. Using the same 69-character statement as a line in a BASIC program, a
general Get/Put interface is booted for subsequent use. This interface provides
high-speed "get from Rampack, put to memory block" on a 1/4, 1/2, or 1 sector
(1,024 byte) basis. The boot consumes 9 bytes of the resource but depends on
the general Get/Put interface which consumes 21 bytes. The boot establishes all
interfaces contained in the resource. As future interfaces are developed, based
on opinions from folks, the boot remains unchanged but more of the resource is
consumed.
 
We need to develop this Rampac resource in a way that helps everyone and can
never hurt anyone. To help everyone, non-techno folks must tell techno folks
like me what they need. To not hurt anyone, all techno folks must agree upon a
"boot" with the following attributes.
 
1. Has a fingerprint so that a Model 200 interface package is never established
in a Model 100/102 and vica versa. Because a Rampac can physiclly migrate
between laptop models, this must be done.
 
2. Uses the same physical address block in the Model 200 and Model 100/102.
This keeps the BASIC statement that brings in the boot the same for all laptop
models. A block of about 38 bytes can accomodate and select between "abort on
wrong Model" and "load entire resource and start" functions.
 
The region at FD1Fh seems a good candidate. For M200 it's the "typeahead
buffer" (32) followed by "cursor bit pattern" (5); for M100/102 it's within the
"Alternate LCD buffer". If no such region exists, then "abort on wrong Model"
logic must be added to the BASIC statement.
 
3. Includes, today, provision for the future.
 
If the needs expressed over time become so diverse that the Rampac resource
can't support them all, then "tailored packages" can be made. There are two
ways to do this: different "versions"; extensions that consume Rampac capacity.
Different versions might evolve for: help screens only, mix of help and
interfaces, special purpose applications. At an extreme, the Rampac resource
might be just sufficient to support an alternative to RAM100.CO. Then you get
RAM100.CO utility at no cost to either laptop resources (free memory or HIMEM
consumption) or to Rampac capacity. Where the Rampac resource is not sufficient
to wholly support a package, then it can support a "kernel" while any needed
"extensions" consume one or more Rampac files. An alternative to RAM100.CO made
this way has no cost in laptop resources and minimal cost in Rampac capacity.
 
Notes to techno folks:
 
1. BASIC statement  -  As a one-line BASIC program it costs 48 bytes of Free
memory, and one file name slot of the Menu. Inserted into a line of an existing
BASIC program, it costs 42 bytes of Free memory.
 
2. Rampac resource capacity  -  512 bytes. Of these, about 33 bytes must be
consistant in all packages: 21 for Get/Put interface, 9 for boot load of the
entire 512 bytes, and 3 for jump to package start (varies per package).
Although it's not a requirement, where the boot puts the 512 byte block such
that the last 320 bytes correspond to the boundary of "Previous LCD/Current
LCD" buffers, there is great advantage.
 
So let's hear your opinions please.