My real acquaintance with the “under” PC happened (by accident) in the early 2000s, when I got a job in the plastic card processing department of one bank. More specifically, in the development of software for payment terminals and POS. A POS for accepting payments with plastic cards is usually a complete device, a mini- or micro-computer, with a screen, a keyboard, 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 correction), twelve-volt RS232 ports for a PIN keyboard, a printer and just a general-purpose port (we used it to connect to a multiport gateway in TCP/IP) (alas, not all ports have a full set of RS232 lines, which forces us to reinvent software wheels), and an LCD screen.
The architecture, by the way, is interesting. A virtual machine was used to execute user code (apparently, this was how restrictions on addressing, pages, etc. were circumvented). This made it possible to use a lot of memory for data, but the size and speed of the code was very modest. I had to, for example, not use the native sprintf, but write my own to avoid local stack overflow, etc. Calculating a table CRC for 5-10KB of data worked for visible seconds.
Although, frankly, compared to terminals from other companies at that time (Injenico, Nurit, etc.), where it was often necessary to deal with nonsense such as manually switching memory pages and storing logs there, the VeriFone (TXO) environment gave almost the standard C library, where ports and files could be worked with via read/write/ioctl, etc. And the fact that the naughty minds of developers usually want to stuff an elephant into an unfortunate device is what caused problems. Once the limitations were more or less mastered over time, development became almost problem-free.
The C compiler supported almost the entire standard library and separate compilation of modules. Loading modules (R-modules) could be dynamically launched directly from user code (such as the overlay mechanism or CHAIN in classic BASIC).
And then Santa Claus brought a decommissioned old OMNI-395, and my joy knew no bounds. Will we uncork it? Certainly!
We turn it 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 one, under the keyboard, and the bottom one, with connectors.
I'll dig up the compiler and loader in the deep end and try to write something.
Alas, I did not find a description of the hardware details, and the official documentation describes only the standard library and a small virtual machine into which user code is compiled.
Of course, OMNI-395 can be safely used as a UNDO-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).
Ideally, you can disassemble the firmware (it’s only 64KB), and having understood the architecture, write purely on the Z80, and then it will work much faster.
P.S.
It must be said that, despite changing the hardware platform and compiler (more than once), VefiFone has excellent continuity of the library interface, which allows the firmware to be ported to subsequent models with minimal changes. After 395, I also worked with OMNI-3350, 3750, VX510, VX610.
By the way, using 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 correction), twelve-volt RS232 ports for a PIN keyboard, a printer and just a general-purpose port (we used it to connect to a multiport gateway in TCP/IP) (alas, not all ports have a full set of RS232 lines, which forces us to reinvent software wheels), and an LCD screen.
The architecture, by the way, is interesting. A virtual machine was used to execute user code (apparently, this was how restrictions on addressing, pages, etc. were circumvented). This made it possible to use a lot of memory for data, but the size and speed of the code was very modest. I had to, for example, not use the native sprintf, but write my own to avoid local stack overflow, etc. Calculating a table CRC for 5-10KB of data worked for visible seconds.
Although, frankly, compared to terminals from other companies at that time (Injenico, Nurit, etc.), where it was often necessary to deal with nonsense such as manually switching memory pages and storing logs there, the VeriFone (TXO) environment gave almost the standard C library, where ports and files could be worked with via read/write/ioctl, etc. And the fact that the naughty minds of developers usually want to stuff an elephant into an unfortunate device is what caused problems. Once the limitations were more or less mastered over time, development became almost problem-free.
The C compiler supported almost the entire standard library and separate compilation of modules. Loading modules (R-modules) could be dynamically launched directly from user code (such as the overlay mechanism or CHAIN in classic BASIC).
And then Santa Claus brought a decommissioned old OMNI-395, and my joy knew no bounds. Will we uncork it? Certainly!
We turn it 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 one, under the keyboard, and the bottom one, with connectors.
I'll dig up the compiler and loader in the deep end and try to write something.
Alas, I did not find a description of the hardware details, and the official documentation describes only the standard library and a small virtual machine into which user code is compiled.
Of course, OMNI-395 can be safely used as a UNDO-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).
Ideally, you can disassemble the firmware (it’s only 64KB), and having understood the architecture, write purely on the Z80, and then it will work much faster.
P.S.
It must be said that, despite changing the hardware platform and compiler (more than once), VefiFone has excellent continuity of the library interface, which allows the firmware to be ported to subsequent models with minimal changes. After 395, I also worked with OMNI-3350, 3750, VX510, VX610.
By the way, using 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.
