. * . * . . * . * . * . * . * . * . . * . * . . * . * . . . * * . * . * . . ÉÍÍÍÍÍ*ÍÍÍÍÍÍÍÍÍÍÍ*ÍÍÍÍÍÍÍÍÍÍÍÍÍÍ*ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ*ÍÍÍÍ» ÇÄÄÄÄÄÄÄÄÄÄÄÄÄ*ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ*ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º ßÛÛß ÛÛÜ ÛÛ . ÜÛßßÛÜ ßÛÛß. * ÜÛßÛÜ. ÜÛßßÛÜ ÜÛßÛÜ * ÜÛßßÛÜ *º º * ÛÛ . ÛÛßÛÜÛÛ ÛÛ * . ÛÛ ÛÛ ÛÛ * ÛÛ . ÛÛ . ÛÛ . ÜÜÛß º º . ÛÛ ÛÛ. ßÛÛ ßÛÜ. ÜÜ ÛÛ ÜÛ ßÛÜ*ÜÛß ßÛÜ ßÛÛ . ßÛÜ ÜÛß ÜÛß*ÜÜ .º º ßßßß ßß ßß. ßßßß * ßßßßßßß . ßßß . ßßß ß * ßßß . ßßßßßß º ÇÄÄÄÄÄÄÄÄ*ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ*ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ*ÄÄÄÄÄÄÄÄÄÄ*Ķ ÈÍ*ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ*ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ*ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ . * . . . * . . * . * * * * . * * . . . R E V E N G E O F T H E S N O W * . * . . . * . * . . * . . * W r i t t e n a n d C r a f t e d b y N u l l S e t * . * . * . * . * * . . * * . * . . * A s s i s t e d b y B i t - M a n i p u l a t o r * . * * . * . . . . * . . * * . ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Disclaimer ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; Neither I, Null Set, nor Bit-Manipulator can be held responsible in any way for any damage, problems, or otherwise alterations to hardware, software, or other properties that may occur as a direct or in-direct result of using this product and/or its associated products. By using this product and/or its associated products, you are hereby assuming all responsibilties and consequences thereof. In addition, the ideas behind the creation INCLogo2 are based upon other people's work (see the credits below), however, all actual implementation of these ideas is my own (or Bit's). (I write a stupid little program and now I think I'm a lawyer. Shesh! :-) ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ How It All Came to Be ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; After the birth of INCLogo less than a year ago, I have always wanted to write another loader. It would have to be better than the first, yet still be tiny in size. A great idea spawned INCLogo and now no ideas were spawning a second. So I let it be and worked on other projects instead. As it always seems to be, I found the idea I was looking for when I wasn't looking for it. While preparing PC's for use at my place of employment, I came across a tiny program called EGASno.Com. The program simply simulated snow in a small window of the screen in hi-res EGA mode. Bingo! An idea was born. About two months after that original idea, I had a fully functional INCLogo2. After several personal delays, I completed the program and began testing it on every PC I could get my hands on. A mere four months after the initial coding, INCLogo2 was complete. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ What INCLogo2 Can Do ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; INCLogo2 is quite a step up from the original INCLogo. I have made a great deal of changes and enhancements to make this the best loader around. The following is a simple list of features INCLogo2 has to offer a user. If the user DOES have VGA or MCGA graphics; ù Display the INC logo with full palette cycling (this was the entire functionality of the original INCLogo program) ù Let it snow, let it snow, let it snow (and accumulate) ù When the snow accumulates too high, have the Lemming clear it ù If there is any, display up to 20 lines of 40 characters per line as a downward scrolling message If the user has non-standard VGA or MCGA graphics; ù Allow the user to override INCLogo2's graphics detection and force it to run in graphics mode (WARNING: This may be dangerous - see below) If the user does NOT have VGA or MCGA graphics (or if graphics cannot be run); ù If there is any, print up to 20 lines of 40 characters per line to the screen REGARDLESS of the user's graphics; ù If one is specified, execute a program (typically a game) passing INCLogo2's command line arguments to the executed program ù If one was specified, display the signature of the person who put together this particular copy of INCLogo2 (ie; who customized this loader) ù DOS "type"-ing an INCLogo2 Com will display INCLogo2's version information ù Take up a one or two clusters of disk space on most large media (meaning hard drives and the like, not floppies) ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ How Does INCLogo2 Work? ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; For a mere 3k, INCLogo2 has many facets to it. Let me take a moment and discuss some of the internals of INCLogo2. For lack of a better way to do it, here is a list of all the pertinent information about INCLogo2. ù Although on disk it's less than 4k, in memory INCLogo2 needs a full 64k to run graphics. If INCLogo2 does not have enough memory to run graphics, it will simply run in text mode instead. ù During the exec call, however, INCLogo2 takes up less than 1k of memory ù VGA/MCGA specific BIOS is used to determine if VGA/MCGA is available (systems not conforming to normal Extended BIOS standards will not be recognised by INCLogo2 - ie; it will run in text mode only. This, however, can be overridden (see forcing graphics below)). ù Low resolution VGA/MCGA mode 13h is used (320 x 200 x 256) ù For speed, all graphics are implemented via direct memory accesses ù The palette cycling will run as fast as your computer can go ù The snow, scrolling message text, and the animated Lemming are CPU independent and run at nearly the same speed on all computers ù All characters are supported and can be displayed in the message (Note: Some special characters, like the CR, LF, and BELL, will not be properly displayed when INCLogo2 runs in text mode) ù INCLogo2 uses interrupt 43h to get the character set bitmap. According to "official" compatibility documents, this interrupt is only supposed to point to the first 128 characters, however, I have yet to see any char above 128 rendered incorrectly (and, in addition, I have seen many other programs and programmers use this int in this way) ù Messages of greater than 800 characters (20 lines * 40 chars per line) will cause unpredictable results ù PKLite can compress some INCLogo2's with long messages, but I've never seen greater than 1.0% compression, which means the result will most likely occupy the same number of disk clusters, so it's not worth it (besides, PKLite-ed files are not DOS "type"-able like INCLogo2 is :-) ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Forcing INCLogo2 to Run in Graphics Mode ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; During beta testing, I found an instance where the standard VGA/MCGA BIOS calls were non-existant even though the computer had a VGA card in it (the computer was a lame-o Zenith 386-25 with BIOS from 1988). Since this computer was the box that I had at work and I wanted to show off my latest project . . . INCLogo2 can be "forced" into running in graphics mode if it detects the environment variables "INCLOGO2=VGA" in it's environment. Note, all CAPS must be used or INCLogo2 won't recognise it. When the graphics override string is detected, INCLogo2 will tell you that it found it. Then, it will check to make sure that you have enough memory for graphics. If you don't, then it will still bomb and run in text mode, otherwise, you've got it! CAUTION: Forcing INCLogo2 to run in graphics mode when you do not really have VGA/MCGA graphics will cause *UNPREDICTABLE* results on your computer. Remember, INCLogo2 writes DIRECTLY TO THE HARDWARE. If that hardware is not there when you say it is, who knows what will happen! Please, only use the graphics override environment variable when you are certain that your computer supports VGA/MCGA graphics. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Customizing an INCLogo2 Loader with INCL2Msg ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; Being meant as an all-in-one game loader, INCLogo2 has to be customized for each and every game. Since I really didn't want to distribute the source code to INCLogo2 around the globe, I had to come up with a way to customize INCLogo2 without altering the compiled code. The solution was simple, create a file that contains the customization information and append it to the end of a precompiled INCLogo2. There are two simple steps to customizing INCLogo2. First, create an INCLogo2 message file using INCL2Msg.Exe. INCL2Msg is a very rudimentary utility that I wrote for myself becuase I was tired of manually creating an INCLogo2 message file. It is very basic and has several bugs, but it does work (most of the time :-). If it bombs or crashes or whatever, that's life. The following is a list of what special editing keys do in INCL2Msg; Cursor Keys, Enter, Backspace, Insert, Delete, Home, and End There work as you would expect them to behave Control-End Delete all chars from the current char to the end of the line Esc The next character typed is placed into the current position (with the Alt-numeric keypad trick, any char can be entered) F1 Center the current line with spaces F5 Load INCLogo2.Dat (overwrites any current message in memory) F7 Delete the current line and move all below it up 1 F8 Move the current line and all below it down 1 (insert line) F10 Exit and optionally save the current message information Prompts for the number of lines to write (0 aborts) Then prompts for a signature string (enter means none) Finally prompts for the filename to exec (enter means none) Writes the entered data to a file called INCLogo2.Dat For those of you who hate INCL2Msg, the format of an INCLogo2 message file is: ; Nul term'ed signature of who prepared this loader ; If the first byte is a nul, no sig will be displayed Prep_By_Sig LABEL BYTE ORG $ + 40 ; Nul term'ed filename of the program to exec ; If the first byte is nul, no program will be exec'ed Exec_File_Name LABEL BYTE ORG $ + 38 ; The length of the scroll message (0 means no message) ; If it exceeds max message len, bad things happen Message_Len LABEL WORD ORG $ + 2 ; The scrolling message characters (see above about max len) Message LABEL BYTE ORG $ + Max_Message_Len Secondly, copy the INCLogo2 message file to the end of an uncustomized INCLogo2 program. For example, "copy /b inclogo2.com + inclogo2.dat runmeinc.com" will append inclogo2.dat to inclogo2.com creating a runable INCLogo2 loader called runmeinc.com. I have provided a batch file called MakeINC2.Bat to assist in doing this copy. Please look at this batch file for more info on this process. CAUTION: Running INCLogo2 without any customization information will cause *UNPREDICATBLE* results. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Using INCLogo2 as a Complete RUNME ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; INCLogo2's exec function coupled with the scrolling message text is an attempt to have INCLogo2 replace the current RUNME.BAT system of releases. Normally you'd write a batch file that types or echos out your release information message, does a pause, and then loads the game. With INCLogo2 you can simply create your message with INCL2Msg, do a copy command, and you've got a RUNME.COM that will display your text, wait for a keystroke, and exec the game for you (all with the bonus of displaying the INC logo (if possible)). The problem with this is that INCLogo2's exec function is not very smart. It will simply run any .com or .exe that can be explicitly declared in the 38 characters allowed. This allows you to explicitly define paths and such, which is good and bad. It's good because games that have their executables located in some weird subdirectory structure (ex; "GAME\VERS1\EXECS\GAME.EXE") can be exec'ed. It's bad because it allows you to exec anything that can be anywhere. This means that someone could simply ASSume that you are running the game from the "C:\GAMEDIR" directory and try to exec "C:\GAMEDIR\GAME.EXE". This is *INCORRECT!!*. I made the exec'ed filename's length large to allow for games that have sub-dirs to retain the sub-dir structure and still be run, *NOT* for some ass hole to hard code their drives and sub-dirs into the exec'ed filename. Note: The long filename field is not an invitation to a trojan or hacker as it may seem. The filename field is solely that, the filename to exec. No command line parameters can be passed via the filename field. Trying to pass any command line parameters in the filename field will cause the exec call to bomb. Batch files are *NOT* supported! To run a batch file via an exec, you would need to proc another copy of your DOS command shell (typically COMMAND.COM) passing it an argument that says "run batch file LOADGAME.BAT" (ie; "COMMAND /C LOADGAME.BAT"). This would greatly increase the amount of memory used by INCLogo2 to exec the game (another DOS command shell has to be loaded, which is generally 20+ kb) and defeats the purpose of having a small loader. In cases where you cannot use INCLogo2 as a RUNME.COM, I suggest (and *ask*) that you name it RUNMEINC.COM. Weird people that want to know what the actual loader is have but to DOS type the RUNMEINC.COM to see INCLogo2's version information. Your RUNME.BAT file should then simply start (after turing echo off, of course) with a RUNMEINC command followed by whatever runs the game. There are only 3 instances (I'm sure there are more - use common sense) when I see it appropriate to use RUNMEINC.COM instead of RUNME.COM; 1) The user has to run a different executable depending on which game configuration he/she has (ex; gamevga.exe, gameega.exe, etc). 2) The game is run by a batch file that either determines which different game executable is to be run, or runs several executables in a row to load the game. 3) Game executables that require their configuration information as command line parameters still allow you to make a RUNME.COM (remember, INCLogo2 passes it's command line parameters on to the program it exec's). However, be careful with ill-behaved games. If running the executable with no parameters assumes certain parameters (especially graphics mode), then the game could hang when run from a RUNME.COM (most users just type RUNME the first time they get a game - don't let INCLogo2 exec a game that cannot be run on all systems - this is frustrating to the user and plain stupid). If the game is ill-behaved, then a RUNMEINC.COM is called for. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ What INCLogo2 was Tested Against ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; INCLogo2 is targeted towards the greater population of the planet. Therefore, it MUST be compatible. I have gone to great pains to try and keep INCLogo2 within "documented bounds" of true IBM compatibilty. INCLogo2 has been thoroughly tested, but I doubt that it is bug free. I do, however, believe that any bugs in INCLogo2 will be rather trivial in nature. The following people tested INCLogo2 on the following computers and configurations with problems or "weird side effects" noted: Cool Hand found no problems on his i80386DX-20MHz (in a 25MHz motherboard), AMI BIOS (1990), Oak SVGA card w/512k, and CTX Multiscan monitor over DOS v5.0. The CrackSmith found no problems on his i80386DX-33MHz, Chips and Technologies DM BIOS, Trident 8900 SVGA w/1MB, and Hyundai SVGA monitor over DOS v5.0. Bad Ass tested on his i80386DX-25MHz w/64k cache and Neat Chipset, AMI BIOS, 8MB RAM, ATI SVGA card w/1MB, and a Power 2 monitor. He also tested on his i80386SX-16MHz, 4MB RAM, Paradise VGA card with 512k, and an Emerson monitor. Neither system showed any problems. The Specialist tested over his '386 and '486 systems, however, I unable to get his exact configurations from him prior to release :-(. Line Noise tested on his i80386SX-20MHz, 2MB RAM, Orchid Pro Designer Plus w/1MB, Sony MultiScan HG over DOS v5.0. Magnum tested on the following computers: AMD 80386DX-40MHz, AMI BIOS, 4MB RAM, Orchid Pro Designer w/1MB, DOS v5.0 AMI i80386DX-25MHz, AMI BIOS, 4MB RAM, Paradise Professional w/1MB, DOS v.50 AMI i80386SX-16MHz, AMI BIOS, 2MB RAM, Standard 640 card w/256k, DOS v5.0 AMI i80286-16MHz, AMI BIOS, 1MB RAM, PaperWhite 256 Color GrayScale, DOS v5.0 Apple Macintosh in IBM Emulator (no VGA support - runs in text mode only) i8088, Pheonix BIOS, 640k RAM, Standard Pro VGA card w/256k, DOS v3.30 IBM PS/2 Model 20, 2MB RAM, 8514 monitor, DOS v5.0 Sharp NoteBook PC6220 i80C286-12MHz, 1MB RAM, Triple SuperTwist 64 Color GrayScale LCD monitor, DOS v4.01 (the monitor was too slow to effectively show the palette cycling of INCLogo2 - so it looked jumpy) Bit-Manipulator tested on his i80386SX-20MHz w/32k cache, AMI BIOS, 4MB RAM, Trident 8900 SVGA with 1MB, NEC Multisync II 14" monitor: With ConCurrent DOS 386 v3.01 INCLogo2 had some palette problems (see below). When run inside DESQview/X beta version on top of Compaq DOS v3.31, INCLogo2 ran correctly while it was the forground (current) window as both a full screen and a partial screen. When not the foreground window, INCLogo2's palette was incorrect (the palette is altered to correctly display the new foreground window, which screws up most of the 256 colors INCLogo2 is using). I had the brief oppotunity to test INCLogo2 on OS/2 v2.0 beta release 6.167 dated 10/8/91. When run full screen, INCLogo2 experienced the most haneous (sp?) flicker that I have ever seen. The flicker was full screen, not just at the top (where it normally is). It almost looks like I tried to do this, and, in fact, it blends in rather nicely with the snow. When run non-full screen, OS/2 did nicely rescale and resize INCLogo2 (it's sooo cool when it's tiny!), but the color palette cycling was "lessened". By lessened I mean that rather than, for example, ten distinct shades of light red, then five distinct shades of pink, followed by seven distinct shades of bright red, OS/2 would shift different shades of each color to one color. So, in the above example, a block of the same ten light red, then a block of the same five pink, and finally a block of the same seven bright red colors would be produced. From this behavior it seems obvios that OS/2 is constantly monitoring, intecepting, and chaning INCLogo2's output to the VGA ports. This is what I believe to be the reason for the full screen's enormous flicker. Since OS/2 v2.0 is still in beta (and will be long after INCLogo2 is released), I cannot persure this matter any further (any knowledgable input gladly accepted!). I tested on the following computers: Data General Dasher 386/SX, i80386SX-16MHz (BIOS dated 1/15/88), 2MB RAM, Chips and Technologies VGA w/256k, Data General VGA monitor, and DOS v3.21. IBM PS/2 Model 55SX (IBM BIOS dated 11/02/88), 8513 monitor, and DOS v5.0 Zenith i80386-25Mhz, Zenith BIOS (1988), Sigma VGA card, Data General VGA monitor, and Compaq DOS v3.31 On my i80386DX-33Mhz w/128k cache, AWARD BIOS (11/22/89), 8MB RAM, Trident 8900 SVGA with 1MB, Goldstar 1460 14" monitor, and Compaq DOS v3.31: When run with DESQview v2.4 and QEMM386 v6.00, INCLogo2 ran correctly when it was full screen (with the strange exception of some odd "stuck" snow when INCLogo2 starts running). When not run full screen, DESQview had some serious problems with INCLogo2. At times the snow was all over the screen and the palette was cycling the entire screen (DESQview menu and all) rather than not cycling or only cycling within INCLogo2's confines. These problems are a direct result of how DESQview is handling INCLogo2's direct VGA screen memory and hardware accesses (and my lack of proper DESQview configuration). When run under the DOS box of MicroSoft Windows v3.01A, INCLogo2 worked fine (only pausing while Windows grabbed the system timer tick to do some housekeeping or run a background task). When not the foreground task (and thus off screen), INCLogo2 politely waits in the background not doing anything until it is called back to foreground and full screen, at which point it simply picks up where it left off. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Problems with INCLogo2 ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; When running INCLogo2 under protected mode (ex; QEMM386, DESQview 386, Concurrent DOS 386, MS Windows v3.0), INCLogo2 will most likely have problems cycling the palette. This is not a bug in INCLogo2. It is the protected mode manager stopping INCLogo2's direct i/o with the VGA ports and/or the screen. Note that all CPU independent graphics (the snow, scrolling message text, and the Lemming) are CPU independent because they are all attached to the system timer tick. If you are running some TSRs that hog the system timer, then INCLogo2 will appear to run jumpily (everything will function as normally, but they will jump rather than smoothly move). This is not a flaw in INCLogo2. I must admit, with great chagrin, that the original INCLogo *DID* screw up certain colors of the palette. I have corrected this problem and have yet to see any palette problems with either INCLogo program. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Source Code and Custom Logos ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; I will not give out the source code to INCLogo or INCLogo2. End of discussion. Requests for a custom INCLogo2 (or INCLogo for that matter) version will be entertained. Realise that any INCLogo2 program cannot be used as part of any product that is sold for any amount of money - nor can it be used for any advertising. INCLogo2 has several components that conflict with existing programs and I refuse to let INCLogo2 be used to breach any Copyrights (ok, ok, so I breached the Copyrights - but I am not selling nor claiming to have written those parts of INCLogo2). So, if you would like a custom version of INCLogo2, grab yourself some graph paper and plot some pixels. You can plot anything that will fit inside an 16 rows by 55 columns box. If you want something larger, special accomodations will have to be made (I wouldn't count on me doing anything larger than 16 by 55 though). Simply write me up some legible (sp?) text file and then get in touch with me (see below). If I'm not deluged with requests for custom loaders, I should be able to accomodate a few honest requests. I can be reached mostly through my other INC brothers or sometimes inhabiting some North Eastern USA BBS's. If you're desperate to reach me, ask Bit-Manipulator, or Jenetic Bytemare to find me. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ The Future of The INCLogo's ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; To be quite honest, I'm not sure what the future of the INCLogo's is. I am always open to writing new logos, but I need a smashing idea to spur me on. Suggestions are always welcome! Right now, I think INCLogo2 is exhausted as far as it can go (what else could I add to it?), so I am almost back to square one (ie; prior to the birth of INCLogo2). I have no attachments to the big INC over the little INCs framework and I am willing to move on if I get a good enough idea. Please remember, though, that I simply will *NOT* write some outrageously huge or slow logo. Actually, since I have written the above few paragraphs, I have come up with an idea for an INCLogo3. I will have to first see if it's possible given my stringent space requirements (4k) and second see if I have time for it. Stay tuned to this same INC-channel for more information as it develops. I would like to add some simple Sound Blaster support, but I don't have a clue (yet) as to how or if it's possible in such small space (anyone, anyone, Beuller :-). ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Credit Where Credit is Due ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; David A. Kerr wrote the original IBMLogo program for the 8514/A display in C. IBMLogo was adapted to VGA / MCGA and to Turbo Pascal 4.0 by Christian Michel, with palette cycling routines provided by Daniel Butterfield (author of DAZZLE). This VGALogo program formed the base idea for INCLogo. This was then painstakingly converted to 100% Turbo Assembler by Null Set, with some creative indulgence and general debugging help from Bit-Manipulator, giving birth to the original INCLogo. EGASno was written by Bruce Hicks and triggered the birth of INCLogo2. The animated dude that clears the snow was largely lifted from the game Lemmings which is (C) Copyright 1991 by Psygnosis Ltd. After four months of work, and (again) some similar help from Bit-Manipulator, Null Set wrote INCLogo2, INCL2Msg, and the associated palette utilities. ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ Special Thanks and Greets ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; Special thanks to Bit-Manipulator for being a great "rubber blackboard" that I could bounce my many ideas off of. In addition, he helped spur on my efforts with some ideas and algorithms that I used in INCLogo2. Although, if I had waited for him to draft the animated Lemming frames, INCLogo2 wouldn't be done yet :-). Thanks to Cool Hand, The CrackSmith, Bad Ass, The Specialist, Line Noise, Magnum and Bit-Manipulator for helping me beta test INCLogo2. Greets to all of my INC brothers around the globe. Hope you all enjoy my latest efforts. GREETS ( <- "big greets" ) out to The Undefined Being for just being himself. (... and I'd like to thank my producer, and my writers, and my director, and all those little people that I stepped on to get here, and blah, blah ... :-) See you in my next project! Null Set {}