My first overlay program

    In the time of the widespread dominance of tablets and smartphones, it’s hard to believe that just recently, you could get a lot of fun playing with a calculator. Of course, I do not mean an ordinary (or even engineering) calculator, but a programmable one . I want to talk about a device that literally turned my life around and actually pushed me to become a programmer.

    In the late 70s of the last century, with computer technology in the USSR was tight. My father worked as a programmer. Campaigns for his work at the Central Department Store, where I played in Nimes with a Minsk computer, will forever remain in my memory.and prolonged stuffing of programs with brass rings on the tablets for Sparks, used by Sberbank at that time. To have, at my personal disposal, something capable of executing programs, of course, I could not even dream of.

    Everything has changed with the advent of programmable microcalculators (PMK). Now I could dream. This is what I did, reading articles in the Technique of Youth , since it was not possible to acquire this programmable miracle in Kazan. But, one day, my parents and I got out to Moscow.

    Having made considerable efforts, I convinced my parents to purchase the MK-61 , which was not cheap at the time , and, for delivery, to file old Quant magazinesthen, having barricaded himself at the apartment of our relatives, he stopped responding to external stimuli, right up to his departure.

    I re-read everything that was printed at that time on programmable calculators, set up a general notebook and diligently copied especially liked programs into it. Gradually, I came to the point that I was able to make my corrections and improvements to them (the experience gained in the vigil on programming Sparks was not in vain). After a while, I was able to write programs myself.

    When I was pretty comfortable with the MK-61, one of my friends got an improved version - MK-52. According to the command system, it practically did not differ from MK-61, but had the ability to save programs in the EEPROM and was supplied with several cartridges with ready-made programs. Of course, I immediately wanted to write something specifically for her.

    Lyrical digression
    I must say that the issue of storing programs for the PMK, at that time, caused increased interest. It was really inconvenient to re-fill a rather large program each time. In addition, the introduced program had to be carefully checked for various errors.

    Enthusiasts have proposed many circuit solutions to this problem. Once I even saw an article describing a device for storing magnetic tape calculator programs. The issue of MK-52 put an end to this difficult question.

    The choice fell on the "Sea battle". I have long wanted to do it, but I couldn’t squeeze all the required functionality into the address space of the calculator. The ability to load programs from the EEPROM allowed to split the program into two parts. The first block - arranged the ships, the second (actually the game) provided a dialogue with the user. Some of the routines were used by both blocks.

    Here is how this miracle looked (the picture is not for the faint of heart)
    image

    Since in this form this cave painting is practically impossible to decipher, I will give this code in a more readable form:

    Ship placement unit
    00|46 01.07 02.12 03.08 04.11 05.34 06.15 07.45 08|53 09:75 
    10.06 11.53 12:67 13.5E 14:08 15.62 16.53 17:37 18.6E 19.01 
    20.11 21.4E 22|53 23:34 24.6E 25.02 26.10 27.4E 28.53 29:34
    30.5D 31:08 32.63 33.50 34|62 35.02 36.10 37|65 38.12 39.01
    40.10 41.DE 42.38 43.BE 44.52 45.11 46.4E 47.53 48:58 
                                                          49.6E
    50.02 51.10 52.4E 53.53 54:58 55.5D 56:22 57.27 58|61 59|65
    60.12 61.01 62.10 63.DE 64.38 65.BE 66.52 67|65 68.12 69.01
    70.10 71.DE 72.37 73.35 74.52 75|66 76.01 77.01 78.12 79.20
    80.10 81.35 82.46 83.07 84.12 85.07 86.10 87.4E 88.65 89.04
    90.15 91.12 92.45 93.01 94.11 95.59 96:A2 97.65 98.07 99.15
    A0.13 A1.45 A2|52
    
    Downloadable game block
    00.40 01.50 02.57 03:41 04.0B 05.15 06.45 07.14 08.06 09.10
    10.4E 11.02 12.53 13:67 14.57 15:22 16.0F 17.DE 18.39 19.BE
    20.64 21.52 22|53 23:75 24.01 25.53 26:67 27.5E 28.22 29.15
    30.53 31:59 32.6E 33.06 34.11 35.62 36.12 37.65 38.17 39.11
    40.52 41|53 42:58 43.6E 44.01 45.11 46.4E 47.53 48:58
    

    Here I use command codes, since their designations proposed by the PMK manufacturer are not very convenient for listing listings. The correspondence of the codes to the commands can be seen on the tablet (kindly drawn by me in those same years):

    Codes MK-52
    image
    A brief excursion into the command system
    With some practice, the command codes were easy to remember (which was necessary, since the entered programs had to be checked). The most commonly used were:

    1. Arithmetic commands (10-13) that perform the corresponding action with the two lower registers of the operational stack (X, Y) and put the result in X
    2. Commands for writing and reading from memory registers (40-4E and 60-6E, respectively)
    3. Commands that control the execution of the program (50-5E), among which should be noted the stop command (50), as well as the command to call the subprogram (53) and return from it (52)
    4. Indirect addressing commands (B0-BE, D0-DE) were very useful, allowing you to access the memory register, whose number was written to another register

    Although hexadecimal digits were used in the command codes, their display on the screen evoked images from the movie “Predator” in memory:

    image

    For convenience, I highlighted in the code the address of the transition commands (a colon after the command address), as well as the entry point (vertical bar). This allows you to more clearly see the relationship of the subprograms (the subprogram call command located at address 22 and providing a kind of “polymorphism” is especially interesting. When accessing this subprogram, control was transferred to various places, depending on which block was loaded).

    You may notice that the transitions to the middle (and not to the beginning) of the subprogram were not something extraordinary. Due to the extremely limited size of addressable memory, it was necessary to save literally on everything. Transitions to the address of another transition (treated in this case as a command code) were considered to be especially chic.

    Since the working calculator is no longer at hand, I usedemulator :

    image

    All prepared images were uploaded to GitHub .

    The first image can be used to arrange “ships”: The

    image

    initial value for the pseudo-random number generator (0.1234567) can be changed. After starting up for execution (I / O s / p), the program runs for a rather long time, ultimately displaying the address for loading the game module from the ROM (there was no possibility of automatically accessing the ROM from the program):

    image

    Since the emulator (at least that the version I used) completely ignored my attempts to access the EPROM, I prepared an image with the game module driven in by my hands and the arrangement of ships already completed.

    The arrangement itself is stored in the memory registers from 7th to D. Here is an example of the second line (8th register):

    image

    Twos encode the position of the “ships”. Based on the initial value given above, the following arrangement was generated:

    0 0 0 0 1 0 1
    0 0 1 0 0 0 0
    1 0 0 0 0 1 0
    0 0 1 0 0 0 0
    0 0 0 0 0 0 0
    0 1 0 0 0 0 1
    0 0 0 1 0 0 0
    

    You can see that the program placed nine non-contiguous “single-deck ships” on a 7x7 square field.

    To start the game, you need to enter the number of ships (9 in / about s / n) and then enter the coordinates of the "shots" (for example, 2 V ^ 2 s / n). Since we spied the location of the “ships”, it was not difficult for us to sink the “one deck”:

    image

    However, we won’t be able to get on it the second time:

    image

    We’ll try (2 V ^ 2 s / n). As expected, the calculator strikes back:

    image

    The first digit here is the vertical coordinate (starting from bottom to top), the second - horizontally (left to right).

    A little later, I noticed that changing just a couple of teams (in the very first photo with the program text, they are marked in red), it is possible to ensure that the ships being placed can be in contact, but not with corners, but with sides (images 0003 and 0004 ). The result was the following arrangement of "multi-deckers":

    0 0 0 0 1 0 0
    0 0 0 0 0 0 0
    0 0 1 0 0 1 0
    0 0 1 0 0 0 0
    0 0 0 0 0 0 0
    1 1 0 1 0 0 1
    0 0 0 1 0 0 0
    

    God knows what, but not bad, considering that only two teams had to change.

    Separately, it should be said about bugs (even more likely about bugs), although this is a topic for a separate article, if not their cycle. The fact is that the calculators of the described series were literally crammed with various examples of errors and undocumented behavior. Among amateurs, this led to the development of a culture of exploring these undocumented opportunities, known collectively as YSGOG-ology .

    Some examples of such bugs are funny, others are dangerous, and some of them are surprisingly useful. A good example of this potentially useful behavior is the execution of the “order entry” (VI) command after writing to the memory register. In the program execution mode, it led to the “cutting off” of the first digit of the number in the X register (displayed on the indicator), and with step-by-step execution (yes, yes, it was like that), the team worked out quite normally. It was impossible to achieve such a result in any other sensible way.

    Frightened by such non-standard behavior of the VP command, I made a correction to the program by changing the sequence of commands 35. VP 36.1 to 35. IP2 36.x (I had to store the constant 10 in the 2nd register). Since there is no live calculator, I can no longer check whether the VI command led to an error in this context. Under the emulator, both options work quite normally.

    Unfortunately, I do not know the implementation of the emulator reproducing all examples of undocumented behavior.

    After all this, there were Mikroshi, BK-shki and Spectrum. There was an EU-1046 that I encountered at the institute. There were PDP-shki and VAX-s. Before the advent of the IBM PC, the wait was short.

    Also popular now: