Dave Milici on Porting SciTech SNAP on OnTime RTOS-32

On Time specializes in providing software development tools for real-time embedded systems on Intel x86 compatible CPUs. Founded in 1989, On Time has offices in Massachusetts and Hamburg, Germany. On Time offers a complete range of real-time operating systems and development tools for 32-bit flat address protected-mode and 16-bit real-mode environments. Recently the company got a port of SciTech’s SNAP graphics suite. Here is an Interview with SciTech‘s Dave Milici, who was responsible for porting SciTech SNAP to On Time RTOS-32.1. Dave thanks for taking the time to answer these questions for us. Let me start off by asking you to briefly explain what was involved in porting SciTech SNAP Graphics to an already existing platform?

Dave Milici: Porting SNAP Graphics to On Time RTOS-32 system was relatively straightforward based on the similarity of its core OS services to Win32 and DOS protected mode. The first pass of the PM library worked right away for popular graphics chipsets from Matrox, ATI, and NVidia. Using filesystem support with the RTFiles-32 library module made development compatible with existing SNAP and MGL SDKs, while many of the demos could easily be bound in a self-contained RTTarget-32 RTB binary without requiring the filesystem option.

2. You mentioned the “PM Library” can you give us a bit more information on this portion of the project?

Dave Milici: The SNAP Graphics Architecture Binary Portable Drivers (BPD) are able to run on many different operating systems by using a Portability Manager (PM) library to isolate all OS-specific functions. Therefore the only source code which needed to be implemented for RTTarget-32 is the PM library. Developers will find this code in the SNAP SDK located at %SCITECH%/src/pm/rttarget.

Developers may notice that near the same location are other PM library implementations for DOS and Win32, as well as the stub code that new PM libraries can build on, plus simple PM test apps. When some of the basic PM functions such as identifying the OS name and type are filled in, a developer may begin building the library which can test various PM functionality with samples such as Hello, CPU, and ShowPCI.

3. I assume that RTOS-32 has its own memory management methodology, including service etc, were you able to use the existing services or did you replace them?

Dave Milici: Since RTTarget-32 provides memory allocation services via the standard C library functions, functions like PM_malloc() did not need alteration, including the shared memory versions which are not relevant for RTTarget-32 applications.

The essential RTTarget-32 specific functions which had to be implemented were for mapping physical memory and getting physical addresses. Although not apparent in its final form, the first-pass implementation called the equivalent RTTarget-32 API functions for physical address mapping one-to-one. The additional code for directly adjusting page table entries was added later to manage multiple address mappings for optimization purposes, and was based on the DOS PM library version’s DPMI and VXD services.

4. Ring 0 callbacks always seem to be an issue when dealing with graphics systems on Win-32 based OS’es, was this also the case with the On Time RTOS-32?

Dave Milici: Some of the PM library functions require execution of privileged instructions at ring-0, such as reading the page table directory PDB, reading and writing machine specific registers (MSRs), and setting up the CPU-specific memory type range registers (MTRR). Although RTTarget-32 apps may be configured to run directly at ring-0 privilege level, apps that would be running at ring-3 default level would have to be accommodated.

This was implemented via a ring-0 callgate service provided by RTTarget-32, and was similar to other PM library ring-0 services like VXD mechanism for Win32 and Windows 9x DOS sessions. In the RTTarget-32 case, all privileged instructions were located in a single x86 ASM file, and executed via the RTTarget-32 callgate mechanism using unique IDs corresponding to the equivalent C functions.

5. How difficult was it to add support for On Time RTOS-32 file management structures?

Dave Milici: Since RTTarget-32 file management uses both standard C library and Win32 APIs, the PM file management functions were easily implemented by copying the equivalent code from the PM library for Win32. These functions are typically used in SNAP apps for loading graphics drivers and saving options, and would be additionally needed in MGL apps for loading resource files like bitmaps, fonts, and cursors, etc.

When starting the port, a developer was interested in using RTFiles-32 module for filesystem support. With RTFiles-32 linked in, it was easy to use the existing SNAP and MGL SDK paths for locating graphics BPDs and resource data files on the target system’s hard disk. However the RTTarget-32 binary image executes from the root path by default, so either the SNAP_PATH variable needed to be added to the RTB configuration file’s environment settings in order to locate the SDK files, or all the SDK files would have to be installed relative to the root directory level as well.

Alternatively a developer may choose to bind the SNAP and MGL files directly into the RTB target binary image. The executable is able to load all necessary files bound into the image using RTTarget’s RAM filesystem, where any file path specifications compiled into the app are ignored. Fortunately all of the file names used for SNAP drivers and MGL resources are unique, so ignoring path names is not a problem. The SNAP and MGL demos posted on On Time’s web site use this method, and include sample RTB configuration files for interested developers to generate binaries for testing on their own target systems.

6. Were you able to use the event handling code built into the PM shell or were you forced to completely rework this in order to fit the On Time RTOS-32 model?

Dave Milici: RTTarget-32 provides some keyboard and mouse handlers which facilitated implementing the PM event handling functions. Initially the keyboard handler was dependent on the RTKernel-32 keyboard driver but not all of the key press and release information could be interpreted from the returned data. Since RTTarget-32 provided interrupt service support similar to DOS, it was therefore more efficient to use the PM library DOS-style keyboard code directly.

The RTTarget-32 mouse driver was able to be used without RTKernel-32 services, and PM event records were managed using RTTarget’s Win32-style console IO records. Time stamps need to be added to the PM event records so as to distinguish mouse click and drag events, so ideally the console records could be asynchronously read in a separate running thread. However polling the records from the single task thread exhibited no noticable latency for apps like MGL MegaVision GUI demo, so the DOS-style polling was able to work efficiently without requiring RTKernel-32 thread and semaphore management.

7. Were there any other unexpected or extra steps that you took in order to complete the port of SciTech SNAP Graphics IES for use with On Time RTOS-32?

Dave Milici: Additional functions were implemented for completing RTTarget-32 PM support for all SNAP graphics drivers, some of which required more time and attention. For instance AGP support needed for some Intel graphics chipsets required contiguous physical memory allocations. MTRR write combining is a useful optimization option on later CPUs but was essential to work properly for some early ATI chipsets. Interrupt handler service routines were available for implementing timer-based stereoscopic page-flip emulation, which is something that has always been simple to do on DOS but extremely complicated on Win32’s multi-tasking kernel. Although these functions may be considered optional since many popular chipsets were able to run without them, completing them makes the RTTarget-32 PM library fully compatible with all the other OS’es that SNAP Graphics currently runs on.