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.