OMNI-395 payment terminal from the inside

    My real acquaintance with the "under" PC happened (by chance) in the early 2000s, when I got a job in the plastic card processing department of one bank. And more specifically, in the development of software for payment terminals, POS-s. A POS for receiving payments with plastic cards is usually a complete device, a mini- or micro-computer, with a screen, a keyboard, a magnetic strip reader from a card, often with a printer, and now also a reader for chip cards.

    I started with OMNI-395. Built on Zilog Z180, it has up to 1M non-volatile memory for storing data (operation logs, for example), an AT-modem for 2400 (even with some kind of correction), twelve-volt RS232 ports for a PIN keyboard, printer and just a general purpose port (we used it to connect to the multiport gateway in TCP / IP) (alas, not all ports have a full set of RS232 lines, which forces inventing software bikes), well, and the LCD screen.



    The architecture, by the way, is interesting. To execute user code, a virtual machine was used (apparently, restrictions on addressing, pages and so on were bypassed). This allowed us to use a lot of memory for data, but the size and speed of the code was very modest. It was necessary, for example, not to use the native sprintf, but to write your own in order to avoid overflowing the local stack, etc. Calculation of tabular CRC for 5-10KB of data worked visible seconds.



    Although, honestly, compared to the terminals of other companies at that time (Injenico, Nurit, etc.), where you often had to deal with nonsense like manually switching memory pages and storing magazines there, the VeriFone (TXO) environment yielded almost C standard library, where you could work with ports and files through read / write / ioctl, etc. And the fact that the playful minds of developers usually want to shove the elephant into the unfortunate device is causing problems. When, over time, the restrictions were more or less assimilated, the development became almost seamless.

    Compiler C supported almost the entire standard library and separate compilation of modules. The boot modules (R-modules), it was possible to dynamically run directly from user code (such as the mechanism of overlays or CHAIN ​​in classic BASIC).

    And then Santa Claus brought a decommissioned old OMNI-395, and my joy knew no bounds. Will we uncork? Of course!

    We turn it on, just in case, and, lo and behold, one of my firmware is still loaded there.



    So, the view from the inside.



    Two boards - the upper one, under the keyboard, and the lower one, with connectors.





    I’ll dig up the compiler and the loader in gimmicks, try to write something.

    Alas, I did not find descriptions of the details of the hardware, and the official documentation describes only the standard library and a bit of a virtual machine, into the codes of which user code is compiled.

    Of course, OMNI-395 can be safely used as a NEDO-PC as it is. For example, as a controller of something. If you need general-purpose ports, then RS-232 is suitable (DTR / RTS - output, CTS / DSR - input).

    And ideally, you can disassemble the firmware (there is only 64KB), and having understood the architecture, you can already write purely on the Z80, and then it will work much faster.

    PS


    I must say that, despite the change of the hardware platform and the compiler (more than once), VefiFone has an excellent front-end library interface, which allows you to port the firmware to subsequent models with minimal changes. After the 395th, I still worked with OMNI-3350, 3750, VX510, VX610.

    By the way, on the tag #cardpayments on Twitter I post photos of PICs, pinpads and other devices for receiving bank cards, which I meet in life if anyone is interested.

    Also popular now: