One of the most amazing things with Soviet programmable micro calculators is the way their un-documented and, perhaps, un-intended functions overshadow the "normal" ones. If, say, MK-54 was made by Hewlett-Packard, it would never become such a hit as it had. After all, what great is there in it? 98 program steps (each of them a two-byte instruction code), 14 registers. Not even a hyperbolic sinus. Nothing to boast about. It's only when we start to do various things that no one in their right mind would to to his calculator, we start to discover the potential those machines have for raw hacking. They're not even very useful by themselves, but they do make an excellent hacker's training ground.
Let's take big numbers, for example. The manual says that all those calculators can deal with numbers from 0.000001e-99 to 9.999999e99. Right. However, if we start to look at this more closely, we'll discover that in fact this range covers just the numbers that can be displayed properly. Just because it is an ERROR, or causes the calculator to fatally crash, it doesn't mean that we can't work with it. So, we'll try a little hacking. Take your favorite 54-compartible calculator (B3-34, 38; MK-54, 61, 52) and let's start stretching the limits...
Simple Errors (100-199)
Let's try something simple. Enter a small number (say, 1e50 - 1 VP 50) and store it into some register (for convenience) - STO 1. Now multiply it by itself : ENTER *. Naturally, you'll get 1e100, which is too big for our poor calculator to display. It will happily respond by signaling an ERROR.
Scared? Don't be. Just because it says that it's an Error, it doesn't mean that you can't live with it. In fact, the only "monstrous" thing about those numbers is that they can't be displayed properly. In fact, you can add, subtract, multiply or divide them (say, let us add 1e99 to our bignum, and then un-monstrify it by dividing by 10 : 1 VP 99 + 10 / ; you'll get 1,1e99) You can store them to registers and then freely recall them back. You can work with them from within your program, and it won't even stop (like it should, theoretically - that' s an error, after all, isn't it?) You may even try to take its logarithm (the result is a little strange though... as you'll see later, it does make sort of a sense).
Whenever you want to check the "real" value of an ErrOr, simply divide it by a "basic" error : 1 EXP 50 F x2 /. Before you start to do this, you might want to check whether this ErrOr is a bignum or a "real" error : K NOP. If it was an error, it'll go away, but "real" bignums will remain ErrOr's. (But then, it's entirely possible that some operation with an ErrOr bignum caused an error, which will go away after K NOP, leaving behind a previous value, that is, a bignum ErrOr... Ok, ok, I'll shut up!)
3RROR : Errors get stranger (200-299)
Now let's take this little erroneous monster we have, store it to some register for convenience and multiply it by itself : STO 2 ENTER *. You'll see the first real monstrosity : a 3RROR (some people pronounce it "a trirror", some prefer "zerror", and russophiles read what they see before themselves : "zggog"). It may look frightening, but cheer up, folks, it does not byte. Everything you could do with an Error, you can do with Trirror too.
There are a few cool things about a Trirror. First of all, would you believe it : it copies itself into your subroutine stack! If, for example, you generate a 1,234e200 (multiply that Trirror you already have by 1,234), subroutine stack will contain adresses ?0, 12 and 34, where (?) is the number of digits in the number that you had on your display before calling up a Trirror). You can test the subroutine stack by creating a one-step program (F PROG 00.RET/0 (52) F AUTO), and continually returning to address 0, making one step and checking the current address (RET/0 SUB F PROG F AUTO)
Then, you can "identify" a Trirror with a very handy method : store it somewhere (so you won't lose it ; STO 3), press F AUTO . ( on the right part of the screen you'll see the exponential part, with only the top part of "2" present : "3rrOr 200") K NOP (you'll see mantissa, with some weird stuff in the place of exponential part : "1, --3".
Now, let's prepare for a first really wicked part of out journey:
Running away (300-399)
Let's multiply our 3RROR by an Error to get the monster that will be the next stop on our way to infinity. (RCL 1 RCL 2 *)You'll immediately notice that this creature was so foul that your calculator "runs away" from it, switching to program-running mode and blinking its little indicator away! If you are quick enough, you can stop the program before it does anything (S/P). There's no real need to try, though - let it perform a few steps. As long as you didn't write any programs before starting to experiment - wise choice - all codes will be 00, which means pressing the digit 0, and so all that program does is pushing the value in X up in the stack (to Y) and filling the X register with 0's (a full program of them!) Now you may just exchange the values in X and Y (your calculator has a special button for it, EXCH), and look at this awful thing your calculator was so afraid of...
All right. So looking at it directly was a bad idea. That time, your
machine jumps into a program writing mode, fouling up one of your program
steps with an "unnatural" code F0 (where F is displayed as an empty space).
That's it - we've had almost all fun that can be had with this particular
monster, let's cage it now. You have to write a program to do it, though
: return back one step to overwrite this "strange" code, tell it to store
X into a register, clear up and stop (STEPBACK (it
will ignore your first keypess), STEPBACK, STO 3, CX, STOP/START).
Now return to automatic mode (F+AUTO), and it will immediately start running your program. After a few blinks it will get to STOP/PUSK statement and stop. Ugh. The monster is caged, and your calculator is safe. For now. Would you like a little rest before our next stop? :)
By the way, those monsters are NOT quite harmless, even when caged up. That is, anytime you attempt to call it up (even if it's within a program), it will perform its "scaring" trick again : your calculator will end up on program step 30 with "empty-0" code on display. You might also like to know about the horrible danger you've escaped by modifying a program before returning to automatic mode : well, it seems that if you would forget about those STEPBACK commands and tried to write a program immediately after F0 (or if you'd simply return to AUTO mode without doing anything), your calculator would start to run a program and enter an eternal loop on F0. No matter what you'd press, it would just blink and blink, looking almost as if it tried to do something useful. Don't be fooled by this sight if you'll ever find yourself in such a situation. Just turn it off and on again.
To manipulate the lurkers on this level, we'll create a simple program :
00. K NOP (54) 01. 1 (01) 02. EXP (0C) 03. 5 (05) 04. 0 (00) 05. F x2 (22) 06. F x2 (22) 07. F x2 (22) 08. * (12) 09. STO a (4A) 10. Cx (0D) 11. STOP/RUN (50)
As you see, this program takes the number in rX (K NOP resets the input mode), multiplies it by 10^400, cages the resulting monster in register A and clears up. Let's try the simplest beast we can get : 1 RET/0 STOP/RUN. After a few seconds, calculator will stop : our bignum is "caged". Let's see it : RCL a. Nothing. 0. However, the beast has left its "tail" in register C : RCL c. Depending on the model of your calculator, you'll see different things, but most devices will show you a very strange sight : "20.000000E" (where 2 seems to occupy the "proper place" of minus). If you "change the sign" of this "number" (/-/), the place of 2 will be taken by 9. Very strange indeed. If you experiment a little with those bignums, you'll see that every time a "beast" is called up to rX, it replaces itself with a 0, leaving a "trail" behind in rC (it does not depend on where we stored it). The mantissa of this "trail" will always be "real" one, except that it's shifted left, it's first digit is incremented by 1 and "E" is added to the right (thus, "20.000000E" means 1.0000000). Sadly, there's no interesting way to find out the exponential part. And, unfortunately, some of all this splendor was brutally fixed in MK-52 : on this machine, everything would work like explained above, but instead of "2" you'd see a familiar and boring minus. Must have been a necessary sacrifice for energy-independent memory.
But... all this was only a beginning! If you'll start our program with 1^10 (1 EXP 1 0 RET/0 STOP/RUN) and then try to have a look at monster's trail (RCL a RCL c), you'll see an ErrOr. 1^20 would give you a 3rrOr (try to "identify" it!), 1^30 - a "running away" beast... It seems that the trails of the beasts copy the structure of bignums themselves, only with an exponential "step" of 10 instead of 100. And indeed, if you try to experiment with values from 10^440-10^450, you'll see that they will give you "level-two werebeast trails" : 1 EXP 40 RET/0 STOP/RUN RCL a. That would store a trail in rC, but this trail is a werebeast itself! So, RCL c will give you "0". However, if we try again : RCL c, we'll finally get this "level two" trail : 20.00000EE. 10^441 would result in a "level two" ErrOr trail, and so on... And, finally, if you'll feed our program something like 10^444, you'd get a "level three" monster, which would "crawl" out of his rC only after the third "summoning" : 1 EXP 44 RET/0 STOP/RUN RCL a RCL c RCL c RCL c : "20.0000EEE". Well, thankfully, there are no "level four" horrors. Ugh.
Naturally, if you try to go beyond 10^445, you'll start to get bignum
trails that go beyond what we've already learned. So, read further and
learn about how to deal with those...
Here's to Darkness (500-599)
The beast that occupies the regions between 10^500 and 10^600 is so destructive, that our calculator can not do anything with it. Every time it tries to appear on the screen, your little MK will just go down... forever (if you don't believe me, just type 1 EXP 7 0 F x2 F x2 F x2, and then try to wait until it does something!). Turn it off and on again, and try to be more careful the next time. That does not mean that you can't work with the bignums in this region, though - do anything you like, just do it from within a program. And never, you hear, NEVER try to stop such a program while it's running!
Unfortunately, the only way to "identify" the "creatures" so monstrous as Darkness and Werebeast, is to calculate their log10, and then try to work with this number (something like F lg 1 0 0 0 - /-/ STO 9 K RCL 9 EXCH RCL 9 - F Bx EXCH F 10^x STO a STOP/PUSK, where the exponential part end up in r9 and mantissa in rA).
There is a way to call up a Darkness to rX, even if you are in a "Calculation" mode. You write in a program something like "RCL a K -". Of course, it ends up with an ErrOr, and then you get your chance to perform whatever operation you want - square it, take a square root from it or even (God forbid) calculate a sinus. It's your choice, but don't delay! Even an innocent K NOP will plunge your calculator into Eternal Darkness :)
(more to come later)
Some parts of this page were prepared with a help of the articles
from Sergei Frolov - expert in
the field of Soviet calculators. Visit his Soviet calculator pages at http://i.am/sergei.
Thank you, Sergei!
All the information on this page was initially found on the pages
of a magazine "Tekhnika - molodezhi" (Technic for the youth) in a column
called "Club of electronic games", written and edited by Michael Pukhov.
Those columns appeared in 1986-1988. Various contributors to this column
are too numerous to list here, sorry.
This page is (C) Gregory Escov 1998. Please contact
me at firstname.lastname@example.org if
you want to do anything with it..
Some parts of this page were prepared with a help of the articles from Sergei Frolov - expert in the field of Soviet calculators. Visit his Soviet calculator pages at http://i.am/sergei. Thank you, Sergei!
All the information on this page was initially found on the pages of a magazine "Tekhnika - molodezhi" (Technic for the youth) in a column called "Club of electronic games", written and edited by Michael Pukhov. Those columns appeared in 1986-1988. Various contributors to this column are too numerous to list here, sorry.
This page is (C) Gregory Escov 1998. Please contact
me at email@example.com if
you want to do anything with it..