Easter Eggs – ROM/BIOS
COCO
In Color Basic ROM v1.1, clearing the screen to an invalid color (9-255) will give you a Microsoft copyright message
COCO III
Press CTRL-ALT-RESET and a 256×192 hi res picture comes up the screen. This is actually the power-on cold start sequence for the CoCo 3. The picture is of 3 Microware guys that did work for Tandy on enhancing the Extended Color Basic ROM into CoCo 3 capabilities. Tandy knew of this pix just before release into the market and decided to ship the units as is instead of reworking the ROM code. (Rogelio)
The picture consumed about 6K of the 8K of additional ROM that Microware was given in those systems to make some enhancements for BASIC. Generally known as “The Three Stooges” image, you frequently found it up on the store computers …. The three people were employees at Microware. The Tandy buyer knew or became aware of the picture before the machines shipped, but no one in R&D knew. If it was known, the VP of the hardware groups would have replaced the 8K with a 2K part to save a nickel. (Frank Durda IV).
Model III
Model III and early Model 4 ROMs had “RON” for Ron Light hidden down in the “A” ROM. As far as Frank knows there wasn’t anything that caused it to be displayed, but that is what that is. (Frank Durda IV).
Model 4 Boot ROM
Frank Durda IV’s footprints are in a few places in the the Model 4P boot ROM. When you turn on a Model 4P, after the initial “di” instruction at location 0, the next four instructions executed are actually the ASCII characters “FDIV”! The instructions don’t do anything useful in this context. In addition, lowercase “fdiv” appears a bit further down, and the words “Frank” and “Durda” can be found mixed in with the French and German error messages. (Tim Mann).
Model III/A
“fdiv” also occurs in various places in all versions of the MODELA/III file. (MODELA/III is the ROM image that was loaded into RAM for Model III compatibility mode on the Model 4P.) In some it’s in the actual ROM image; in others it’s in extra bytes at the end of the file that are not loaded into RAM. (Tim Mann).
Tandy VIS Systems
On the Tandy VIS systems, Microsoft tried to sneak a new product line logo for Modular Windows in at the last minute (it looked like a rip-off of the “Wool” logo you see on garments), but as it was displayed on each boot, replaced the VIS logo, which Tandy didn’t like, and MS was over their ROM budget in the first place even before adding this bloat, Tandy complained loudly.
The Next release MS sent Tandy doesn’t display the logo and we are told it has been removed, BUT the modules are even bigger. We get suspicious. A disassembly shows the image is still there and MS added new code to make the image appear only in certain situations. Only after John Roach called Bill Gates on this, did the logo really get removed. Of course, we didn’t know that in retaliation, MS decided to torpedo the VIS project anyway by changing Modular Windows in a very minor but incompatible way with the version in VIS, and told us just two days after the VIS ROMs were sent to be fabbed. Modular Windows was disowned by Microsoft after a few more months (they denied it was even a product in public statements), but it was eventually remarketed with bigger system CPU and memory requirements, more bloat and a brand new name: Windows CE.
Of course, if you examine the VIS ROMS, you will find hundreds of messages telling you that the network printer is out of paper and other messages that don’t make sense for a machine with no network or printer capabilities. That’s Windows CE (I mean Modular Windows) dragging around great steaming chunks of regular Windows that could not be cut-out, or at least that’s what Microsoft claimed. After the stunt with the logo, relations were real bad. (Frank Durda IV).
Easter Eggs – DOS / OPERATING SYSTEMS
TRSDOS v2
In TRSDOS v2.x for the Model I, run BOOT/SYS.WHO while holding down the R and V keys (Randy Cook’s first two initials) you will get a notice screen. Because of the way it was coded, any key combination that results in a in 68 (0x44) (such as holding down the 2 and 3) will decode the message properly. The “00 FE” bytes at the beginning of the sector are cleverly disguised load module codes (equivalent to a comment record).
For TRSDOS v2.1 and v2.2 the message was:
Tandy caught on and the message was changed in TRSDOS v2.3
That message is one of the key items that made Randy Cook and Tandy part ways so violently, and probably why Tandys various revisionist histories of that period frequently fail to mention him or Steve Ls role in putting Tandy in the computer business. As Frank recalls, the original message also had a non-Tandy telephone number Randy set up to do his own support from, which ticked-off Tandy even more. Either George Robertson or Ron Light (both now deceased) created the patch that changed the message after Randy went away. (Frank Durda IV).
TRSDOS v1.3
In Model III BASIC under TRSDOS 1.3 type CMD”&”& and you will get:
LDOS v5.1.0
Type the command A! or B! at the LDOS Ready prompt. It will print “Hi there! This command is reserved for the future by your LDOS Support group. Roy, Bill, Tim, Chuck, Dick.” (The “Tim” was Tim Mann.)
Tandy made LSI change the message in the versions Radio Shack shipped to something different, probably due to vivid memories of Randy Cooks activities. (Mike Yetsko).
You’ll also find “Roy” or “Tim” here and there in the middle of a few /CMD or /DVR or /SYS files. When the development team needed a 3-byte data area that didn’t have to be initialized to anything in particular, they’d sometimes have the assembler put their names there. (Tim Mann).
Roy thought that the “T” in RS232T/DVR (the Model III RS232 driver) was meant to stand for “Tim”. (Tim really didn’t, Tim just thought RS2323/DVR would look silly, he picked T to stand for “three”.) So Roy changed the name of the Model I RS232 driver to RS232R/DVR, claiming that “R” stood for “Radio Shack”, not “Roy.” (Tim Mann).
Easter Eggs – XENIX v3.0
On XENIX 3.0, in a really obscure hardware failure condition (the Z80 got back to the main operation dispatch loop with the stack at a different depth than it was on the previous pass), z80ctl would spit out:
Bugchk: Sckmud
"Shut her down Scotty, she's sucking mud again!"
“Shut her down Scotty…” was somebodys’ sig line on USENET back around 1984 and the vision of Captain Kirk yelling this down to Scotty always struck Frank as very funny, so when Frank needed a message for this insanely implausable condition Frank had seen a few times in test, Frank felt you needed a special reward if you managed to get here, so Frank picked that message. The technical support documentation describing this message suggested that rebooting soon would be a good career move. (Frank Durda IV)
Easter Eggs – Scott Adams’ Adventures
In the specially formatted copy protection sector on track 0 of an Scott Adams (Adventure International) disk, there is a message from Kim Watt, who designed the copy protection scheme, saying roughly “If you can read this, phone Kim Watt at xxx-yyy-zzzz to find out what reward you get.” (Tim Mann).
Bugs
Olympic Decathlon (Richard Merryman 2016-04-12)
In the high jump event, after you press [SPACEBAR] to start running wait for the athlete to appear on the left side of the screen. As soon as the athlete appears press [DOWN] followed immediately with [ENTER]. The athlete will proceed to jump backwards off the left side of the screen which results in a GOOD JUMP!
You can do this over and over as the bar gets higher and higher until the bar gets to 270cm. For some odd reason at this point the pole vault box appears in front of the bar and your running speed increases from 620 CM/SEC to 56276 CM/SEC. Your distance goes haywire and your athlete never appears on the screen and it says YOU DIDN’T JUMP! after a few seconds. It will do this until you exhaust your three attempts to clear the bar and you will end up with a score of 1290 for the event.
TRS-80 ROM
In BASIC, if you enter 3 spaces and then a ‘(apostrophe), followed by ENTER, and then enter 4 spaces and then a ‘(apostrophe), followed by ENTER, your TRS-80 will crash.
George Phillips noted that this can also be accomplished by RIGHT ARROW‘ENTER‘ENTER.
That’s it. The computer will not return to READY. Following a pause, the computer will restart.
The right-arrow acts like a tab key and is equivalent to 8 spaces in this case. The bug depends on spaces at the start of your command and needs at least 3. What appears after those spaces doesn’t much matter. Typing this will do the trick:
SPACESPACESPACEDIE!ENTER‘ENTERThe apostrophe in the second line is critical but other characters can be put in front of it as long as they don’t contain any reserved words longer than two characters. This will cause a crash:
SPACESPACESPACENEWENTERI WOULDN’T PRESS ENTER IF I WERE YOU!ENTERBut this will not:
SPACESPACESPACENEWENTERDON’T PRESS ENTER!ENTERbecause the reserved word ON appears before the apostrophe. Yes, being part of the larger word DON counts.
The crash occurs in the subroutine where BASIC tokenizes what you typed in. Tokenizing is nothing more than translating BASIC commands and operators into single byte codes. It’s a form of compression that makes a BASIC program take less memory and run faster. BASIC lines can be pretty long, about 255 characters, so that much space must be reserved for what you type. Doesn’t seem much by today’s (2010) standards, but that may have been as much at 6 percent of total available memory if you had 4K. That’s like letting a modern machine have an input buffer 64 megabytes long. In the worst case the input line doesn’t compress at all and you need a whole 255 characters for the tokenized version.
But the programmers of BASIC were clever. Since tokenization never makes the input bigger you can write the tokenized version over what was typed in. Completely worthwhile.
It turns out there’s a small catch. There is one thing that gets bigger when you tokenize it: the apostrophe. In this dialect of BASIC the apostophe means to ignore the rest of the line. That is, treat it as a comment. I can only guess why it gets turned into 3 whole bytes, but the point is that a tokenized line with an apostrophe could end up two bytes bigger than the input.
No worries. Instead of tokenizing the input over itself, we’ll put the tokenization two bytes back. Problem solved. Now what about if there are two (or more!) apostrophes in the input? That’s OK. The first one will bloat by two bytes but the others will stay as a single byte because no tokenization happens in the comment.
Everything is perfectly fine, but there’s another little bug. When you type in a line you have two fundamental options. Either you’re saying “do this now” or “add it to the program I’m working on”. If you start with a number it means “add to the program at that line number”. Without a number it means “run right away”. Thus when BASIC gets a line of input it doesn’t tokenize it right away. Instead it first looks to see if there’s a number at the start. If so, it notes the line number and calls the tokenizer on whatever appears after the line number. If not, then it can call the tokenizer right away.
Well, it can’t call it right away. To look for a number it called a common subroutine. That subroutine does something generally useful. It skips over spaces before looking for a number and skips any spaces after the number. No big deal, but unless something is done you won’t be able to indent your BASIC lines. For instance, if you typed:
10 FOR I = 1 TO 5 20 PRINT "HELLO" 30 NEXT I It would come out looking like this: 10 FOR I = 1 TO 5 20 PRINT "HELLO" 30 NEXT I
The indent on line 20 to make it readable has been lost! Horrifying. Again, easy to fix. After getting the line number we’ll back up over any spaces. That way they’ll be included in the program. And we don’t have to worry backing up because there’s the line number to bump into.
And that’s it right there. That’s the bug. What if there isn’t a line number to bump into? What if someone typed something to be executed directly without a line number?
In that case we’ll end up starting BEFORE the input buffer and skipping backwards over any spaces we see. This is bad news but often it works out OK. Remember that due to the overlapping what’s just before the input buffer is the first two bytes of the previously tokenized line. In almost all cases that character before the input line won’t be a space. In fact, I believe it will be a space only if the previous line started with three spaces (sound familiar?). You might think two spaces would do the trick, but BASIC has one more little fudge. Before it tokenzies a line it skips the first space. If the previous input started with three spaces, we’ll see two spaces as we back up. And then, by some miracle, we stop. I don’t know what stops us, but it must be something that isn’t a space. We’re about to tell the tokenizer to work from the input buffer directly over itself. It’s not quite that bad as we skip over one of the spaces. Too little, too late. There’s only a one character safety margin. But you know what, that’s OK. Just as long as we don’t hit an apostrophe things will be just fine. In fact, if we manage to save some space by tokenizing even a two letter word before the apostrophe we’ll be fine.
But if not, look out! That apostrophe will get turned into three bytes. The last of those three bytes is $FB and will be written right where we’re looking for our next input character. Recall that once we see the apostrophe we’re to copy over the rest of the input verbatim. And we do so until we see a nul ($00) character. We pick up the $FB, write it one down, move to the next character which is the $FB we just wrote because we’re overwriting the input buffer on ourself. Thus we being filling memory with $FB until infinity. But we don’t hang like one might expect. Eventually we’ll get to the end of RAM. On a 48K system the next thing after RAM is the ROM starting over at address 0. We can’t write $FB into the ROM we’ll break out of our loop as soon as we hit the first zero in ROM. But when the tokenizer goes to return it will have a problem. The return address on the stack got overwritten with $FBFB (as did most of memory). Now we end up going to $FBFB instead of back to BASIC. $FBFB and on up is filled with $FB which the Z-80 will race down quite quickly until it gets to the end of RAM and back to 0. Which is great, because that’s where it starts when you power on the machine. So there you are at the “MEMORY SIZE?” prompt or similar.
Things might go down slighly differently if you don’t have 48K or have disk drives, real time clocks or anything else that may interrupt the Z-80 in the middle of its death spiral. The end result is likely the same. You’ll be OK on the Model III even with its real time clock because the one small piece of RAM that didn’t get stomped has all the critical interrupt routine variables in it. If you have and kind of DOS running it will be stomped and who knows what happens. If you have less that 48K you’ll still end up jumping to $FBFB. With no valid RAM at that address the processor will see $FF which means “call the interrupt routine”. If you even survive that first call, there are a whole bunch more to do. Either it crashes right away or makes a whole bunch more calls before finally hitting zero. There’s a simple patch to fix the bug – zero out $1A8C through $1A90. That will get rid of the “backing up” code. But it’ll mean you can’t type in spaces at the start of your BASIC lines any more.
DOS Oddity re Hexadecimal
When using the hex to decimal conversion in a DISK BASIC or LEVEL 3 BASIC program you will not be able to enter any hex number with the &H notation that has a “DEF” embedded (e.g., FDEF, DEF1, etc). Since DEF is a reserved word you will get an incorrect (partial) hex conversion, and then a SYNTAX ERROR!!!