Complete ROM Development Tool Kit

For use with Borland C/C++

English User manual of "grifo® C To Rom"

Ver.5.40 - Rel. 06 February 2002.


GCTR is a complete ROM development package which enables developers to create stand-alone embedded programs using Borland C/C++. It is available for all the grifo® boards based on I86 microprocessor family and the completed embedded program may run on a system with only a CPU, ROM, and RAM.

The GCTR package, consisting of software and manual, offers full source level remote debugging using the Turbo Debugger Remote kernel. The package includes ROMable startup code, a ROMable library, and the Locator which allows the developer to locate code and data anywhere in conventional memory space of the selected card.


Borland C/C++ is a great language for developing DOS and/or WINDOWS programs. Its compiler and linker may be used to develop embedded code, but the libraries and debuggers distributed with this language require an operating system in order to be useful. In other words these products provide great support for the DOS and/or WINDOWS developers but little or no support for the embedded developers that have no operating system on board. GCTR povides the needed support for these embedded developers who uses Borland C/C++.

A C/C++ program requires startup code to setup a stack and segment registers, initialize all the on board hardware peripheral devices, define any extra math options, setup initialized data, and zero uninitialized data. The startup code provided with standard DOS and/or WINDOWS compilers handles this correctly under operating system, but when the latter one is not available it will cause your system to crash. GCTR has special startup code and libraries designed specifically for embedded environments without BIOS, DOS and/or WINDOWS.

Debugging a program on a system with no operating system can be done using an emulator or a remote debugger. The standard DOS and/or WINDOWS debuggers will not work for this purpose, so GCTR contains a special TDxxx kernel for use with standard Borland's Turbo Debugger. This debugger allows powerfull source level debugging, directly on the target system.

Programs running under DOS and/or WINDOWS are loaded and located at run time. An embedded program must be located to the exact address at which it will execute on the target system. The program also must be changed into the proper format for burning into ROMs. The GCTR Locator is used to locate the program at the correct addresses and produce the format needed for placement in the target system.

The located code must be burned on the board's ROM memory device. Both EPROM and FLASH EPROM are currently managed by GCTR: in the first condition an external EPROM programmer is required , while in the second one, the target card can save the code in FLASH without additional systems.



GCTR allows you to Debug applications with Borland's Turbo Debugger on the grifo® target boards that are not provided of BIOS, nor operating system. GCTR has a special program called TDxxx (xxx = card name) which gives the Turbo Debugger access to the target system through a simple serial connection. It allows you to use the Turbo Debugger in the remote mode with the full source level debugging features both for code and data structure. You can download a program to the board, watch variables, modify variables, set break points, step through functions, view and/or modify hardware resource, set hardware breakpoint, etc.

The grifo® target card has enough ROM and RAM, and a serial port dedicated to TDxxx. The TDxxx requires only 6K bytes of ROM and 2K bytes of RAM. There must be enough RAM to load and execute the embedded application as well, this means that the available RAM area must be equal to or greater than the application program code area + double data area + stack and heap size. The TDxxx is a complete stand alone program that takes CPU control from the initial hardware reset and then interacts with the user through a standard development PC, that executes Turbo Debugger.

In order to debug with Turbo Debugger, the TDxxx must be configured for the target system memory configuration, and it is burned into the memory device (EPROM or FLASH EPROM), which is placed in the target system. With the first GCTR order grifo® supplies this device already burned in accord with card configuration, while each subsequent modifications can be easily performed by the customer that obtain the TDxxx in binary format, ready to burn. The serial port on the target system is then connected to the serial port on the PC: at this point you are ready to use the Turbo Debugger and debug applications on your target system.

Four windows can be open at one time, each with specific functions:

The remote debugger has a flexible command interface. Commands may be entered via drop down menus, single key macros, or by typing them into the command window. The drop down menus provide an additional ease in remembering commands and their format. When commands are numerous and repeated, they may also be entered from a command file.


The GCTR startup code provides the ability to take the CPU from a boot (reset or power on) to calling the main function of C source program, without depending on DOS, WINDOWS or a BIOS. The startup code supports all card memory configurations and is provided in object file format that is directly used by the linker. The user is only required to define the card memory configuration during the install phase of GCTR. The startup code requires about 400 bytes of ROM space, only.

The startup code sets up the stack and heap in RAM. The initialized data is copied to RAM and the uninitialized data RAM area is zeroed. All segment registers are set up for proper C operation and some on board hardware peripheral devices are correctly initialized.

The startup code also has several features for debugging: in fact It can check for stack overflow and null pointer assignments. Moreover the startup also install an interrupt 21H handler for trapping unexpected DOS calls.


The GCTR locator allows you to locate code and data anywhere in conventional memory space. It operates on standard executable (EXE) and MAP files produced by Borland C/C++ and it creates output in a binary image files that can be burned in EPROM or FLASH EPROM. If required, the Intel absolute OMF file can be generated, providing support for most standard emulators.

The location commands have a readable format. They describe the files to be used by the Locator, the address in ROM, the RAM addresses of segments, and lastly, the memory chips available in the target system. The users must not define these location commands, in fact they are already saved in a proper file, during GCTR installation.

The locator performs cross checking during location. It checks for ROM overruns, overlapping code, overlapping RAM and ROM chips, out of sync EXE and MAP files, and complete location of the program. The amount of ROM usage is also displayed, both by percentage and actual number of bytes.

There is an optional absolute map file that reports each public data item, with its absolute address. This file has the same format as the link MAP generated by Borland linkers except that the addresses are modified.


Full support is provided for floating point and all the related C math and trigonometric functions. Obviously the math support for Borland C/C++ on grifo® cards coincides with the floating point emulation, as the math coprocessor is not available.

Math errors are handled by a specific romable function that stops application program execution and returns a dedicated error code. This code can be used by the customer to check what happen.


Many of the standard library functions available in the Borland C compiler's library do not require DOS, WINDOWS or the BIOS and are therefore usable in a ROM environment. The functions that depend on operating system (such as open, close, read, write, textcolor, arc, circle, line, etc.) are not usable in the GCTR environment. A function requiring DOS, mistakenly linked into your program, is identified by the startup code's INT 21H call trapping facility.

GCTR contains a library of ROMable functions that can be directly used on the embedded board. The library is distributed in compiled format but when required grifo® can supply also the source format. Some support files, that simplify the links of the right library to user program, are included in GCTR

The library functions include:


GCTR includes example programs that show how to compile, link, and locate some demo programs. These examples come with full source, and they are well documented. They use floating point, dynamic memory allocation, interrupts, on board hardware peripherals, etc.


The GCTR has been developed with the intention to simplify the programmer's life and for this reason, as already stated in the previous descriptions, it is provided of:

1) An installation program that guides the programmer in the development environment configuration, according with his requirements.

2) A support program, named CTODEB, that runs the integrated development environment (IDE) of the programmer's Borland C compiler. In this way the editor, on line help, syntax checker, etc. can be used exactly as the programmer is already used to do.

3) Once the application program is edited, the CTODEB automatically compile and link it, obtaining the executable code.

4) At this point the CTODEB, always in a transparent mode for the programmer, runs the Turbo Debugger and downloads the executable code to the connected board.

5) In this condition the programmer can check the functionality of his program by using the powerfull commands of Turbo Debugger, with the advantage to perform this check in the real work condition, or on the other hand directly on the hardware connected to system under development.

6) If the programmer founds errors, then he executes again the step 2,3,4,5 until his application program is completely tested.

7) Another support program, named CTOBIN, can be executed at this point. It locates the application program and produce the romable code without any intervent of the programmer: everything run automatically.

8) The obtained romable code can be burned on EPROM that replaces the one installed on the board, or in FLASH EPROM through the proper higl level burning software: FLASH WRITER.

9) All the described steps can be executed both with DOS command line (up to GCTR 3.3 version) or with simple operations executed with mouse (only from 3.4 version).

Any programmer that follows the instructions of "HOW TO START" chapter, of the supplied user manual, and uses a specific tutorial program is ready to work autonomously in a couple of hours.


I86 based control card

It is the electronic card that belong to grifo® industrial set, based on I86 and compatible microprocessors, as:

Independently from the application to develop, the target card must be provided of:
- EPROM with TDxxx or FLASH EPROM with FWRxxx and TDxxx
- at least 128K bytes of RAM
- one asyncronous RS 232 serial line

Development personal computer

A personal computer provided of:

(N.B. with WINDOWS xx we refer to 3.11, 95, 98, ME version)

Borland C/C++ compiler

It is one of the Borland C/C++ compiler starting from version 2.0, including all available derivations and variants.

Suggested materials

To simplify and to speed the GCTR use even by untrained customers, the following items can be profitably used:


To satisfy all the different requirements of the customers, the GCTR is available in the following versions:

GCTR xxx
Development tool for target card GPC® xxx on EPROM.

FGTR xxx
Development tool for target card GPC® xxx on 128K Bytes FLASH EPROM.

FGTR xxx.512K
Development tool for target card GPC® xxx on 512K Bytes FLASH EPROM.

FWR xxx
128K Bytes FLASH EPROM for target card GPC® xxx, with FLASH WRITER saved on its first sector.

FWR xxx.512K
512K Bytes FLASH EPROM for target card GPC® xxx, with FLASH WRITER saved on its first sector.

The five codes above listed are for the target card with base clock frequency (20 MHz for GPC® 188F/D and 26 MHz for GPC® 884 and GPC® 883); when the user needs to use GCTR with higher clock frequency, he must use the proper version identified by .xxM suffix (i.e. .40M for GPC® 884 with 40 MHz clock). Please remember that the described codes can be directly used for possible orders.

Page up-dated at June 13, 2002

homeHome Languages CartellaUtility Software Tables