Product Support

Producing ROMable Applications
from Prospero Pascal 5.2 and Fortran 2.1

These notes are designed to assist developers who wish to generate ROMable applications coded in Prospero Pascal or Fortran. Because of the wide variety of such environments, they cannot do more than provide guidance, and the reader must adapt the general guidance to meet his own needs. It is however assumed that the application is intended to run completely apart from the DOS operating system and BIOS.

A zip file (ROMABLE.ZIP, ?? KB) containing the files to accompany these notes is available.

Program Layout

In Part II of the User Manual there is a description of the contents of an object module produced by the compiler, and the effect of the H option which selects a memory model; in the Pascal manual this is section 6, in the Fortran manual it is section 5. From the compiled object modules and a selection of the run-time library, the linker builds an executable file which can be loaded and run by DOS. The .EXE file layout is described in detail in many reference books on DOS; briefly, it contains three parts:

  1. A fixed-size header which specifies sizes, the initial CS:IP and SS:SP settings, the number of relocation entries, and other items.
  2. The relocation table, which allows DOS to execute the program in different addresses on different occasions.
  3. The program image.

When DOS loads a program, it reads the image into memory and adds the base address to the words within the image which were specified in the relocation table. It then sets the initial values of SS and SP, and passes control to the point specified in the header. Non-initialised parts of the program such as the stack are typically not included in the image, but are allocated adjacent higher addresses.


 +----------+-----------------+-----------+
 | Code | Static data | Stack |
 | <---- Program image ----> | |
 +----------+-----------------+-----------+
 ^DS ^SS



Program startup

Control is always passed initially to module H01D in the library, for which source code is provided. This sets the DS register to the base of DGROUP, and after performing some mainly DOS-related tasks calls the Pascal or Fortran main program. The main program normally starts with three library calls:

  1. _DEFER which establishes the default exception reporting regime (omitted if the main program was compiled with option E1 or above).
  2. _FINIO which initializes standard input and output.
  3. _HINIT which performs module initialisation.

The main program code then begins.

Coding the application

File operations, the H1 and H2 memory models, the Pascal heap (new and dispose), and Fortran blank COMMON all rely on DOS services, and cannot be used in the final form of a ROMable application, though some diagnostic outputs may be useful while initial checking is done under DOS. It is also necessary to decide how run-time exception reporting will be handled; there is essentially a choice between providing an alternative version of the default reporting routine, or of using "own" exception handling as described in Part IV of the User Manual. This decision will depend on individual circumstances.

Adapting the Program Layout

When running in a ROM/RAM environment, the former holds the equivalent of the program image in the diagram above. Some changes must be made, however, before the image is ready for conversion:

  1. The relocations which DOS would apply at load time must be performed.
  2. The startup sequence in H01D must copy the part of the image corresponding to DGROUP (which holds a mixture of constants and variables) into RAM, and set DS, SS and SP to appropriate values before calling the main program. DGROUP and the stack can be accommodated next to each other in a single RAM area, as happens when a program is run under DOS, or can be separated. The position and size of DGROUP within the program image can be derived from a linker map, as described below.



Overall Procedure

It is generally recommended to check out parts of the program in the DOS environment before embarking on the ROM conversion. At this stage the Probe debugger can be used, or diagnostic statements can be added. However, the value of this step will clearly depend on the quality of the test facilities in the final environment.

When the program is ready for transfer to EPROM, the following procedure is recommended.

  1. Produce a revised startup module H01D (see details below), and if exception reporting is required a suitably modified version of the issued REPORTER module, with alternatives for the normal input/output.
  2. Ensure that the coding of the application satisfies the rules given earlier (any diagnostic statements have been removed, for example), and that it has been compiled with the H0 memory model and appropriate level of the E option.
  3. Link your application with the revised modules H01D and REPORTER, obtaining a full segment map. From the link map, determine the start position and total size of DGROUP. The start (relative to the beginning of the image) can be obtained from the 'Code size' figure.
  4. Insert these values into the modified H01D and reassemble.
  5. Relink the application and check that the sizes determined in step 3 have not changed. A difference is unlikely, but if found repeat step 4.
  6. Generate an Intel hex file from the program image, applying any relocations specified in the table. (The Prospero EXE2HEX utility for example will perform this task.) The hex file can be edited if desired before loading into EPROM.



Modifying H01D

The positions of ROM and RAM areas within the address space of the target environment must be known. Modify H01D.ASM as indicated, and reassemble with the supplied assembler include files.

  1. Strip out DOS-related operations, such as shrinking the allocated memory, enquiring DOS version, etc.
  2. Insert code to set DS, SS and SP to appropriate values. These will typically be absolute values (segment numbers in the case of DS and SS).
  3. Insert code to copy the preset image of DGROUP to its RAM address. The offset and size will initially be dummy values, to be replaced as indicated in step 4 above.
  4. Supply a dummy FAR public procedure called _FINIO which just returns, to satisfy the call from the main program (see above).



Because of the wide variety of target environments, these notes cannot be exhaustive for any individual case. It is assumed that users are familiar with the Intel architecture and assembler programming, and are prepared to adapt the suggestions given here to meet their individual requirements. Prospero cannot undertake to provide advice apart from that related to the functioning of their own products.

Prospero Software Ltd.
May 1992

Product Support Top of page