OMNI-395 payment terminal from the inside
My real acquaintance with the “under” of the PC happened (by chance) in the early 2000s, when I got a job in the processing department of plastic cards of one bank. More specifically, in the development of software for payment terminals, POS-s. A PIC for accepting payments with plastic cards is usually a complete device, a mini or micro computer, with a screen, a keyboard, with a magnetic stripe 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, 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, a printer, and just a general purpose port (we used it to connect to a multi-port gateway in TCP / IP) (alas, not all ports have a full set of RS232 lines, which forces them to reinvent software bicycles), and also an LCD screen.
The architecture, by the way, is interesting. A virtual machine was used to execute user code (apparently, this was how the addressing restrictions, pages, etc. were treated as). This allowed us to use a lot of memory for the data, but the size and speed of the code was very modest. It was necessary, for example, not to use native sprintf, but to write one to avoid overflow of the local stack, etc. Calculation of tabular CRC on 5-10KB data worked visible seconds.
')
Although, frankly, compared to the terminals of other companies at that time (Injenico, Nurit, etc.), where it was often necessary to do nonsense such as manual switching of memory pages and store magazines there, the VeriFone (TXO) environment gave standard C library, where you could work with ports and files through read / write / ioctl, etc. And the fact that the naughty minds of developers usually want to stuff an elephant into a miserable device - and that caused problems. When, over time, the limitations were more or less mastered, the development became almost trouble-free.
Compiler C supported almost all of the standard library and separate compilation of modules. The boot modules (R-modules) could be dynamically run directly from the user code (such as the overlay mechanism or CHAIN in classical BASICS).
And then Santa Claus brought an old OMNI-395 written off, and there was no limit to my joy. Will we uncork? Of course!
We turn on, just in case, and, lo and behold, one of my firmwares is still loaded there.
So, the view from the inside.
Two boards - the top, under the keyboard, and the bottom, with connectors.
I will dig out the compiler and the loader in the bottom of the barrel, try to write something.
Alas, I did not find the descriptions of the hardware details, and the official documentation describes only the standard library and a little virtual machine, into the codes of which the user code is compiled.
Of course, OMNI-395 can safely be used as a NEDO-PC as it is. For example, as a controller of something. If general purpose ports are needed, then RS-232 is suitable (DTR / RTS output, CTS / DSR input).
But ideally, you can disassemble the firmware (there is only 64KB), and having understood the architecture, you can write purely on the Z80, and then it will work much faster.
It must be said that, despite the change of the hardware platform and the compiler (more than once), VefiFone has an excellent succession of the library interface, which allows porting 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 POS, pinpads and other devices for accepting bank cards that I meet in life if anyone is interested.
I started with OMNI-395. Built on Zilog Z180, 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, a printer, and just a general purpose port (we used it to connect to a multi-port gateway in TCP / IP) (alas, not all ports have a full set of RS232 lines, which forces them to reinvent software bicycles), and also an LCD screen.
The architecture, by the way, is interesting. A virtual machine was used to execute user code (apparently, this was how the addressing restrictions, pages, etc. were treated as). This allowed us to use a lot of memory for the data, but the size and speed of the code was very modest. It was necessary, for example, not to use native sprintf, but to write one to avoid overflow of the local stack, etc. Calculation of tabular CRC on 5-10KB data worked visible seconds.
')
Although, frankly, compared to the terminals of other companies at that time (Injenico, Nurit, etc.), where it was often necessary to do nonsense such as manual switching of memory pages and store magazines there, the VeriFone (TXO) environment gave standard C library, where you could work with ports and files through read / write / ioctl, etc. And the fact that the naughty minds of developers usually want to stuff an elephant into a miserable device - and that caused problems. When, over time, the limitations were more or less mastered, the development became almost trouble-free.
Compiler C supported almost all of the standard library and separate compilation of modules. The boot modules (R-modules) could be dynamically run directly from the user code (such as the overlay mechanism or CHAIN in classical BASICS).
And then Santa Claus brought an old OMNI-395 written off, and there was no limit to my joy. Will we uncork? Of course!
We turn on, just in case, and, lo and behold, one of my firmwares is still loaded there.
So, the view from the inside.
Two boards - the top, under the keyboard, and the bottom, with connectors.
I will dig out the compiler and the loader in the bottom of the barrel, try to write something.
Alas, I did not find the descriptions of the hardware details, and the official documentation describes only the standard library and a little virtual machine, into the codes of which the user code is compiled.
Of course, OMNI-395 can safely be used as a NEDO-PC as it is. For example, as a controller of something. If general purpose ports are needed, then RS-232 is suitable (DTR / RTS output, CTS / DSR input).
But ideally, you can disassemble the firmware (there is only 64KB), and having understood the architecture, you can write purely on the Z80, and then it will work much faster.
PS
It must be said that, despite the change of the hardware platform and the compiler (more than once), VefiFone has an excellent succession of the library interface, which allows porting 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 POS, pinpads and other devices for accepting bank cards that I meet in life if anyone is interested.
Source: https://habr.com/ru/post/164693/
All Articles