ALPHA v0.3

Because of the fun and sarcastic nature of some of these jokes, viewer & reader discretion is advised. Don't read'em and then complain!

This is an alpha release of this section. If you find any problems or would like to recommend something, please be kind enough to give us some feedback.


Intel Unveils Below Board With Expended Memory

Topic: computer

INTEL UNVEILS BELOW BOARD WITH EXPENDED MEMORY ----------------------------------------------

1 April 1986, Hillsboro, OR:

Intel Corporation's Personal Computer Enhancement Operation (PCEO) today announced Below Board, a memory add-on device for the underachiever. Below Board is designed for the IBM PC, XT, AT and their compatibles or incompatibles. Below Board conforms to the -1.4 revision of a memory specification, the most negative revision to date. It is believed that Below Board will spawn a whole new generation of incompatible software as well as hardware.

Below Board operates by moving Conventional RAM down to the memory space below 0K, where DOS can't conflict with it. The new memory space is called expended memory. This is a superior alternative to competitive products which allow normal software to fill-up the memory. Below Board always maintains at least 640K of free memory. A side benefit to this method of memory management is that nearly 100% of the 8086 to 80286 processing capacity is kept available.

Below Board establishes a new class of PC products known as Vacantware. Such products use an undocumented instruction in the 8086 processor family called VANISH. The VANISH instruction places the CPU in Vapor mode, in which the expended memory can be erased or ignored. Expended memory is relatively efficient, since even CPU's that have been greatly speeded up, still only require one wait state. No other states are allowed.

Shipments of Below Board are expected to begin within 2 to 15 months. Prices and billings will be announced shortly after delivery. all orders must be placed prior to last year.

NEW VERSION OF FOREM BBS SOFTWARE ---------------------------------

A new release of FoReM ST arrived yesterday. Among the features is yet another new file transfer protocol, 'ZZZMODEM.' This new protocol transfers data in blocks of 16 Megabytes, giving it the largest block size of any file transfer protocol in the Known Universe. The checksum for each block in a ZZZMODEM transfer is sent via XMODEM, for greater accuracy. "This new protocol will allow us to transfer data at rates up to one one-hundredth of one percent FASTER than by any previous method," explained Phil "Compu" Dweeb, a FoReM aficionado, pausing occasionally to wipe the drool from his chin.

Industry insiders were quick to point out that using ZZZMODEM, it takes roughly 2 hours and 25 minutes to transfer a 20K file at 19,200 baud. Mr. Dweeb said that this problem has been dealt with. "Each block is padded with nulls, which take no time to send," he explained.

The new version of FoReM ST also has the new "Recursive ARCing" feature. As Mr. Dweeb explains: "All download files are recursively ARCed by FoReM before being put online. Our experience has shown that when you ARC a file, it gets smaller. Therefore, the approach we have taken is to repeatedly ARC the file until it reaches a size of roughly 10K. At that point, it's hardly worth the trouble, wouldn't you say?"

Reportedly in the works for a future release is the patented "One Length Encoding" process. Early reports suggest that this procedure can reduce the length of a file to just 1 bit. Mr. Dweeb takes up the story: "One day we were sitting around doing some hacken and phreaken, and one of us started thinking. All binary data is encoded into bits, which are represented by ones and zeros. This is because a wire can either carry a current or not, and wires can therefore be set up in a series that can represent strings of ones and zeros. "Notice, however, that the real information is carried in the ones, since the others carry no current. I mean, what good does a wire do when it isn't carrying any current? So by dropping all the zeros, you can easily cut file sizes in half. So we decided that a cool way to speed up data transfer would be to only send the one bits. The results were phenomenal -- an average speed increase of 50%!! "After we finished the initial implementation, we kept finding ways to make the thing faster, and more efficient. But then we realized that we hadn't gone all the way. If you think about it, after you drop all the zeros, you're left with a string of ones. Simply count all the ones, and you're left with another binary string. Say you end up with 7541 ones. In binary, that's 1110101110101. So immediately we've reduced the number of bits from 7541 to 13. But by simply repeating the process, we can reduce it further. 1110101110101 becomes 111111111, or 9, which is 1001, which becomes 2, which is 10, or 1.

Once we reach a string length of 1, we have reached maximum file compression. We now have the capability to encode virtually unlimited amounts of information into a single digit! Long-distance bills will never be the same! "Now, that's not to say that there aren't a few problems. The biggest one we have encountered is that for some reason, there seems to be a certain amount of data loss during the re- conversion process. It seems that sometimes the file cannot be expanded into its original form. So, the solution we came up with was to have an encryption key associated with each file. When a One Length Encoded file is received and is undergoing decompression, the unique encryption key must be supplied. That way, we end up with a 100% success rate in our conversions!

"A problem which we are having difficulty resolving lies in the fact that to ensure a 100% success rate, the encryption key must be exactly as long as the original file. We are confident, however, that the use of our Recursive ARCing procedure will help to solve this problem..."

ALPHA v0.3