Use of Virtual Files
Easy handling of large constant data blocks as Files on a ROM Disk.
Easy to implement. Easy to use. Simple maintenance.
Extremely fast file opening. Very fast file data read.
Include application-specific file data in the same storage device as used by Virtual Fonts
Ideal for storage of application "text catalogues" together with fonts
Integrated locating, look-up, and access management. No Standard C FILE support needed.
Can be used independently of the graphic library drivers. Can even be used by application boot code.
The same binary image format as used by Virtual Fonts can in addition be used like a disk for storage of application-specific data files. All file data are stored as binary file blocks, which can easily be found, opened, and read at application run time.
Provides a one-storage solution for text, fonts, pictures, and other application specific constant data in small embedded systems.
Keeping application fonts, pictures, text, and configuration data together in the same
Virtual Font storage image (the disk) simplifies development, programming, maintenance, and product updates.
Updating a product after release time can be as simple as replacing one Virtual Font / Virtual File *.bin storage image.
The RAMTEX Virtual Font features, facilitates and automates this design solution. Supported by all GUI display driver packages.
Virtual memory storage handling:
Get virtually unlimited memory storage for application data.
The number of file blocks and the file size, are only limited by the byte size of each external memory device and the number of external memory devices used for Virtual File storage.
Easy to use
Virtual files can be used in the same way as ordinary serial FILE streams.
In addition to using file streaming, there is support for fast direct data block load, or data fetch at arbitrary file offsets (fast file position jumping).
Open file -> Load data -> Close File
File location lookup.
File open methods
The location of a file data block on the disk is found during the file open procedure. Any of the following methods can be used to identify a file:
- C-string containing the file name (e.g. "FileName.Ext").
Similar to normal FILE stream functionality.
Static file location descriptor
Extremely fast file open (micro-seconds), with minimum processor ROM and RAM consumption.
- Integer handle (enumerated index into a "file directory" list).
Provides simpler handling and usually smaller code when a file is referenced by multiple functions.
The symbolic enumerated index and a directory file list can be auto-generated by GENVF.EXE.
A speed-optimized "directory" is located on the disk. Enables very fast file-block look-up during file-opening, even when a disk contains thousands of file objects.
Compile time "File exists" checking.
Using the Integer handle, or the Static file location descriptor file open methods
enables compile-time checking of whether a file is included on the disk.
Removes or minimizes the requirement for using file-open error-handling and fall-back procedures in the application. Simpler code and less ROM consumption.
Memory chip device driver
Any type of data storage device can be used for the virtual font storage image.
Block copying of the virtual font data from the external storage device (EEPROM, flash chip, etc.) to a RAM buffer is simply done with a small customized device driver function. Template device driver functions are included with the library.
The same device driver is used by Virtual Fonts
Device-independent storage format
The virtual file storage system is compiler and processor endian independent. This ensures full portability between all platform types, for instance between an embedded target system and a PC-mode simulation.
During loading and programming, a virtual file storage image is treated as one linear byte array. This simplifies both the downloading and programming of a virtual file device and the subsequent fetching of virtual file data.
Virtual File files
Creating a Virtual File disk is particularly easy.
The GENVF.EXE program included with the library auto-generates virtual fonts by converting existing soft-font files, pictures, images, BMP files, and PNG files into a single set of virtual font files (here called vf.*). The files contain all information needed for file locating, look-up, and access management.
The original application data files are stored on the disk as (read-only) binary file images. The data in a file can be read as a data block (array of bytes) or as a byte stream (i.e. same read principle as C FILE streams). Any type of application specific data can therefore be stored on the Virtual File disk.
Virtual File files
Virtual file (and font) image
To be located in (programmed into) the virtual memory device.
|vf.c||Virtual file descriptors and/or file directory lists.||To be included in the compilation project.
Accelerate file search and file open.
If static file location descriptors are used, this file contains all the locating and look-up information needed.
Can be configured to contain a ROMed file name list for use with integer handle look-up or with menu-based selections.
|vf.h||Virtual file prototypes||To be included via application modules using virtual files.
Enables compile-time check whether files required by an application actually exist in vf.bin.
Maintenance of Virtual Files can be made extremely simple. Just place all original application data files to be included in a vf.bin image in a single directory. Then activate GENVF.EXE. Updated virtual file *.c *.h *.bin files, containing all files in the sub-directory, can then be generated automatically.
Full PC simulation support
All virtual data files can be run-time tested while the application (GUI) is executed on the PC.
During testing, the device driver just fetches the virtual file data block directly from the binary storage file.
The display driver libraries provide support for run-time testing of a Virtual File application on the PC using ordinary PC compiler tools.