Unit (MMU)
All Verix V terminals support virtual memory using hardware-based memory management features. One goal of the MMU is to give each task its own “private”
view of memory that cannot be seen or altered by any other user task. This goal is achieved by reloading key registers in the MMU each time a new task is
scheduled to run. The SCHEDULR module performs the actual reloading of the MMU registers.
User memory, both code and data, is mapped as tiny pages (1 KB) in virtual memory space.
Codefiles, including library files, must always begin on 1KB boundaries. The file manager performs this alignment automatically.
Virtual Memory Map
User memory is allocated using the “7xx” sections, that is, all application memory lies in the virtual 256 megabytes with hexadecimal addresses in the range
0x70000000 through 0x7FFFFFFF.
Normal applications have a virtual memory map with the following general plan:
• 0x70000000..0x700FFFFF: system global library. The library itself is
approximately 20 KB; the remainder of this virtual megabyte is unavailable for users, since all users share the mapping of this megabyte using a common MMU table.
• 0x70100000..0x703FFFFF: expansion space, usually for shared libraries, but can include expanded stack space.
• 0x70400000..0x7041FE00: high end of user stack. The stack limit is always 0x7041FE00, with the lower address computed based on the value in the user’s header. If the stack size exceeds 130560 bytes, then additional virtual megabytes must be mapped at 0x703xxxxx, extending to 0x702xxxxx, then to Offset Description
0 ENDPTR: Address of first byte beyond this FIFO
4 RDPTR: Address where first byte of user data can be read, if RDPTR !=
WRPTR
8 WRPTR: Address where next byte of user data can be written 12 Up to N bytes of user data
12+N+1 (first byte beyond this FIFO)
APPLICATION PROGRAMMING ENVIRONMENT
File System
0x701xxxxx. The entire stack cannot exceed 3276288 bytes (3.124 MB) and must be contiguous.
• 0x7041FE00..0x7041FFFF: part of global data area (reserved for system use:
for example, errno)
• 0x70420000..0x7046FFFF: user code; then user data; then space for shared libraries (which can also use whatever remains in the region
0x70100000..0x703FFFFF not used by the stack).
For most applications, whose virtual memory requirement is less than 1 MB, only one MMU section is required, corresponding to 0x70400000..0x704FFFFF. This MB is mapped as 1024 tiny pages using one 4KB table.
File System
The Verix V OS implements a file system in non-volatile RAM and flash memory.Applications can create and access files using function calls such as open(), read(), write(), and seek(). Though their use is not recommended, the C language standard input/output interface (fopen, fprintf, and so on) is also implemented.
To provide system and application access to the file space, Verix V manages this memory region as a virtual device, much in the same manner as physical devices.
File Locations The physical location of a file can be designated by a drive prefix—either I: for the RAM file system, or F: for the flash system (flash files are subject to some restrictions on writing and updating, as detailed in File Management). If a filename does not include a drive prefix, it defaults to I:.
Note that there are multiple independent file systems in Verix. The most commonly used file system are those residing in SRAM. The RAM-based file system can be updated as well as read. There is, however, a flash-based file system that can be updated as well. Since it behaves identically to the RAM-based system in nearly all respects (except that it cannot be changed as easily), it is not explicitly mentioned except in those few cases where its behavior is unique.
There are additional similar file systems in the first sectors of the flash called boot-block sectors. The first such file system is called the boot-boot-block file system, and the prefix “B:” is used to identify files in this file system. Additional files systems, labeled “S:”, “T:”, “U:”, “V:”, and “W:” for convenience, occupy succeeding sectors of FLASH. (The first 64KB of flash contains the kernel. The “B:” file system begins at physical address 0x00010000.) These Verix V file systems (B, S, T, U, V, and
File System
• Group 1 tasks are allowed to change their effective group (by calling set_group) to any Group 2–15. This allows them to access files in other groups (but only one group at a time).
• Any task can change its group to 15. Thus, Group 15 serves as a global shared file group. Group 15 files can also be directly designated by a slash (/) prefix to the filename (for example, /batch.dat or F:/cardlist).
Record-Structured Files
In addition to simple stream-of-bytes files, Verix V also supports several forms of record-structured files. These include variable-length record (VLR), compressed variable-length record (CVLR), and keyed files (a special type of CVLR file that maintains a collection of key-value pairs). See Variable-Length Records.
CONFIG.SYS File The CONFIG.SYS file is a keyed file residing in terminal memory that contains system options and parameters. It plays a role analogous to environment
variables in other systems (and can be accessed through the C get_env() library function as well as by direct file reads). For example, the record with key *GO designates the application program that automatically launches when the terminal is powered up or reset. Variables can be set in the CONFIG.SYS file using the download utility, from the keypad, or from application programs using the
put_env() library function. Use of the CONFIG.SYS file and the available variables are described in System Configuration File.
Power-fail File Protection
Verix V ensures that file input/output operations are reliable in case of power failures. If a write() or other system call that modifies files is interrupted by a power failure, it completes on terminal restart.
Handles Applications manipulate devices, files, and pipes with handles assigned during the open() call. Verix V currently can support up to 32 device handles.
The file manager assigns up to 30 handles (by default), nominally between 32 and 61. To change the maximum from 30 to some other number, set the CONFIG.SYS variable *FILE.
Similarly, the pipe manager assigns up to 256 pipe handles. To save memory, set the CONFIG.SYS variable *PIPE to a lower value.
Device APIs Following are general functional definitions of the device services. The usage here is intended to conform to standard POSIX conventions.
• write (int handle, char const *buffer, int count);
This function is used to transfer application data from the calling application to the external world. Failure is reported using a result code of -1 and further identified by setting the caller's errno variable. Otherwise the result code indicates the number of characters transferred.
Note that a write operation returns immediately to the caller. Typically,
however (especially for serial devices) the actual transfer of data occurs on a
APPLICATION PROGRAMMING ENVIRONMENT
File System
delayed basis. The caller must not conclude that a successful write operation means that the intended receiver has actually received the data.
• read (int handle, char const *buffer, int count);
This function is used to transfer application data from the external world to the calling application. Failure is reported using a result code of -1 and further identified by setting the caller's errno variable. Otherwise, the result code indicates the number of characters transferred.
Data usually transfers from the external world (for example, over a serial line) to an intermediate buffer maintained by the device driver. The read operation fetches the data from that intermediate buffer, not directly from the device.
Thus read is an immediate operation which does not include device delays.
On the other hand, substantial amounts of processing may be involved. For example, when reading from the magnetic stripe reader, the raw data bits that the interrupt service routine stored are decoded at three levels to return nicely ordered ASCII data to the caller.
For files in the RAM-based or ROM-based file system, the handle identifies an open file and the data transfers directly from the file system to the caller's buffer.
• open (char *pathname, int opentype);
The open command prepares the device for operation. This call means different things to different devices. Generally, any initialization steps which must occur before the device can be useful, such as clock divisor
programming, should be handled within this call. Also, in MOST cases the open call initiates the interrupt-driven, background mechanism of the device driver. This means that henceforth the device driver is periodically awakened by interrupts, so that it can function within the background, independently of the normal foreground activity of the system. The exception to all of this is found in COM device drivers, as previously mentioned.
If an error is detected during open processing, a return code of -1 is given to the caller, and the caller's errno variable is set to reflect the type of error detected. Otherwise the open call returns a file handle with which subsequent
“device” calls reference the activated file.
• close (int handle);
Other Devices
• lseek (int handle, long offset, int origin);
This entry point supports the standard U*ix lseek() call for manipulating the file pointer of an open file. Although all drivers are required to support this entry, it is currently used only by the file manager. Refer to File Management for more information.
Other Devices
In addition to the console, Verix V-based terminals include a variety of other input/output devices. These vary among terminal models but typically include a beeper, real-time clock, magnetic card reader, and serial communication ports (that can be used to connect to a printer or external modem). Other devices that may be present include an internal modem, bar code reader, smart card reader, and internal thermal printer.
Application tasks access devices by opening them by name—for example, open(DEV_CLOCK)—and making read, write, and control function calls. The operating system arbitrates requests for device use by different tasks using an ownership model similar to that used for the console.
Console The console comprises the display and keypad. The LCD display size is 8 lines by 21 characters (8 x 21) for 168 characters on Vx5xx/Vx610 terminals, and 21 x 16 for 336 characters on Vx670 terminal. An ASCII font is built into the unit. Other fonts can be downloaded as files. Graphic images can be displayed by creating custom font files.
The Verix V-based terminal keypads contain a 12-key numeric keypad and a set of additional programmable function keys under the screen, the functions are defined (as with all keys) by the application running on the terminal. The four ATM-style keys to the right of the 12-key numeric keypad are OS-defined. See Figure 1 for a keypad illustration.
Verix V mediates sharing of the console among the application tasks. A task that successfully opens the console becomes its owner, preventing other tasks from using it. The owner task can relinquish the console either permanently or temporarily to allow other tasks to use it.
System Mode System mode is the first task run when a terminal is powered up or reset. System mode is responsible for administrative tasks such as starting the initial application, receiving downloads, setting CONFIG.SYS variables, setting the clock, setting display contrast, starting the debug monitor, and so on. The system mode task remains active as long as the terminal runs, and can be reentered at any time by pressing F2 and F4 (or 7 and Enter) and entering a password. Applications interrupted by entering system mode can be restarted only by a complete terminal reset. Refer to the reference manual for your terminal for a detailed description of system mode.