This is not an assembly language, this is a machine language.

Machine language is anything that physically means something to the machine.
In the case of pocket computers, it’s key presses, encoded into numbers in the machine. You don’t give more information about this Electronika MK61 machine, so I’ll give the example of the TI-57: the machine language used the number of the key given as column in the tens and line in the units. So for example, a program that would increment the memory 8 would be:

33 8  57 1 58 23

This is machine language: it’s what’s directly interpreted by the machine.

Assembly language would be the human readable text:

RCL 8 
+
1
=
STO 8

To transform this text into the sequence of machine codes, you would need an assembler, which may be a program, or a human who would translate that text into the sequence of numbers.

The confusion is often done, because there’s often a quite direct translation from the assembly language to the machine language, but this is not always an entirely direct translation: macro assemblers have powerful macros that may do a lot of work in the assembler and generate a lot of machine language instructions from a single assembly instruction. The mere translation of symbolic addresses may involve changing the op-code of the branch instructions (for example, when switching from short relative addressing to long relative or absolute addressing), so it’s not always as direct as you’d think.

I would say that the answer to both parts of your question is no: this calculator’s commands aren’t like assembly language, and programming this calculator is different from programming in assembly language.

The “language” this calculator is programmed in is fairly low level, but it still represents an abstraction on top of lower-level constructs that aren’t visible to you as the programmer. I’m guessing a bit, but from your description, and from looking at the keyboard (and comparing it to similar-looking calculators from Hewlett Packard or Texas Instruments from the late 1970s and early 1980s) I’d say that each program “step” not only could be a simple operation like “add” or “swap X & Y” but also more complex operations like trigonometry, exponentiation, logarithms, etc. Each of these steps is probably implemented as a internal microcoded routine. That microcode probably is programmed in assembly language, but I don’t think it’s visible to ordinary calculator programming at the level you’ve described.

As others have described, assembly language usually is in very close (if not 1:1) correspondence with the facilities of the underlying machine. I’d say that assembly language programming includes the following characteristics that are probably not present in programming this calculator.

• Operations include lower level level operations such as bitwise AND, OR, XOR, shifting; integer and (maybe) floating point arithmetic, on a variety of data sizes (e.g. single or double precision); load/store of a variety of sizes (byte, halfword, word, etc.).

• Higher level operations (trig, logarithms) are usually subroutine calls, not instructions. There are some exceptions, such as the DEC VAX which had a polynomial-evaluation instruction. [Edit: OP pointed out that x87 also has trig functions.]

• The addressing scheme of the machine is exposed. If the address space is segmented, you have to load a base address into a register and then address code or data relative to that register. Even with a flat address space, you’re aware of addresses and address arithmetic. Usually assemblers will allow programmers to use labels to denote addresses. But if an address is in a different segment you may have to load a segment register before you can get to it.

• Memory alignment is exposed. For example, on many machines a 4-byte word can only be loaded from or stored to addresses that are multiples of 4 bytes.

• Data representation is exposed. Usually assemblers provide some way to specify numeric data in hex, octal, decimal, floating point, and occasionally character data.

• Specialization of registers is exposed. Some architectures allow integer and address operations in some registers, but floating point only in others, or allow addressing only relative to certain registers. Sometimes there are specialized registers such as those with condition or status bits that cannot be used for addressing or arithmetic.

• Subroutine calling conventions are exposed. Arguments and return values may be passed in registers, or pushed to and popped from a stack. (This stack is usually a region of memory addressed by a special stack pointer register, not a fixed set like X Y Z and T.)

• You may need to be conscious of how to interact with the OS, or if there isn’t one, how to deal with low-level hardware facilities. With an OS you have to load arguments into registers (or the stack) and trap into the kernel. Without an OS you probably have to deal with interrupts and timers.

My recollection of assembly programming is that it is very, very painful. I think that programming this calculator is easy and fun by comparison. (Sorry.)

Yes, that definitely sounds like an assembly language to me.

It’s hard to say whether or not that actually is assembly just from the description, because the definition–a language whose commands map 1:1 with its target platform’s machine code–is hard to determine without a knowledge of the machine code itself, but that does sound like the way ASM works on other platforms.

It certainly has some close similarities to an assembly language, but I’m going to argue that that’s not what it really is.

In an assembly language, the operations mostly map 1-to-1 to CPU instructions. There are some exceptions, such as macros and pseudo-ops (like, say, a CLEAR instruction that really XORs a register with itself); the real point is that an assembly program exactly determines the CPU instructions to be generated. (That’s the fundamental difference between an assembly language and a higher-level language like C; in the latter, programs specify behavior).

The calculator undoubtedly has a CPU in it, but I doubt that individual CPU instructions refer to the X, Y, Z, and T “registers”, or perform high-level operations like xy or sin (or ПРГ, whatever that means!).

Instead, I’m sure that many or most of the visible operations are done as subroutine calls. And for each operation executed, there must be a significant amount of extra work done to display the result.

You can think of the visible operations as an assembly language for a high-level virtual machine, but that virtual machine is implemented via something like an interpreter running on the real CPU.

Still, I’d say that the answer to the second part of your question:

Did I have a basic idea of assembly languages using this device?

is yes.

That is right, posted code fragment does look like assembly language.
The proper conversion of this code would define the version.

Edit: it has some specific language for this device, but it is not assembly.

It is also look like a USSR made calculator.
Does it run on rounded batteries/cord?

I would argue you’re closer to a BASIC assembly language hybrid but it really depends on the underlying CPU and architecture. There doesn’t need to be direct memory access if you have no true RAM to speak of. Floating point operations also not need be present without a FPU.

I think a simple test would be an addition operation on a floating point number and an integer. Most higher level programming languages would accept ADD 2.5, 7 and return 9.5. Assembly languages however would differ the output based upon the called instruction and depending on the underlying number representation in binary. Most assembly languages require a different instruction to be used based on using floating point vs integer operations. An exception to this might be some kind of fixed point format.

Reverse Polish notation (RPN) calculators were classic. No, although the register designations seem like assembly language it was not. Calculations were performed by translating from algebraic format onto the stack. The numbers used were pushed into the stack and operations were performed on last stacked against next to last stacked values.

You could “rotate” the stack to move the values since the displayed value was a stack member. The results could be swapped or stacked as necessary to perform nearly complex calculation. If you do understand stack hardware and assembly language this calculator was trivial to learn since its paradigm was most similar.