Computer Solutions Ltd
Whats New | Advanced Search
Downloads | Exchange Rates

Celebrating 39 years
supplying all your CAN and Embedded Development Tool needs



What development hardware do I need?

This depends on what support is provided by the chip and on the requirement of the end target board. There are a number of possibilities; in order of preference they are:

Expanded Mode CPU

Here the final board will use the chip in a mode that allows external EPROM and RAM chips to be used. Development then proceeds as follows:

  • Install the link program in EPROM, then develop code into the RAM area until the RAM is full.

  • Integrate that code into the EPROM.

  • With the link program and some of the application in EPROM, develop more of application, integrating as necessary.

  • Finally, burn an EPROM without the link program.

This is the scheme shown on the right.

It may not be necessary for all the ROM/RAM to be on the board. If enough address lines are available, it is possible to decode extra RAM, purely for development purposes, on a separate supplementary board.

Schematic - testing a chipFORTH program

Schematic - testing with 8051 code memory Some chips, such as those in the 8051 family, have code and data in separate areas of memory. Unless the decoding has been organised to make these overlap, it is not possible for the link program to write into the code space. This limitation does not preclude the use of chipFORTH. Instead of the link program down loading code from the host, a low cost ROM emulator is used, driven from the PC's parallel port.

Minimum Mode CPU

On these devices, only the on-chip memory is used, freeing the maximum number of pins for I/O. The final on-chip memory may either be masked, EPROM, EEPROM, FLASH, ZTAT - zero turnaround time - or write once memory. (This denotes on-chip windowless EPROM - a mid-volume compromise between masked ROM and the cost of an EPROM window). If a chip with a piggyback ROM socket is available, the simplest development route is to use the ROM emulator to hold both the link code and the program being developed. If this is not available then you may need a port replacement unit.

Port Replacement Units

A port replacement unit provides the I/O devices lost by employing the data and address lines to reference external memory. This then can provide accessible EPROMS and is all that need be provided to use chipFORTH with those single chip micros not available with piggyback ROM. These units are significantly simpler and therefore less expensive than conventional ICE.

Computer Solutions has produced such a part replacement unit for the 647180 but in many cases manufacturers low cost evaluation boards provide the necessary functionality (e.g. M68HC11EVB).

Targets with no serial port

On many microcontrollers it is possible to select whether certain pins are to implement a serial link or to provide general bits of I/O. When building a volume product these additional bits of I/O may be vital to an optimum design and hence no serial port may be available for interactive development. In order to provide the chipFORTH development environment in this situation COMSOL has produced a low cost universal serial interface. This device (comROM) plugs into an EPROM socket and, via a small window in EPROM space, implements a UART capable of 38.4k baud bi-directional communications.

Schematic - Targets with no serial link

As an EPROM or a PROMJet can be placed in the comROM socket this can be used to implement all the configurations described earlier for targets with no serial port.

How do I test the application's use of the serial port?

The package as supplied includes a terminal emulator facility such that every standard character I/O routine executed on the target system will display those characters on the PC's screen or await input from the PC's keyboard. If a non-ASCII message protocol is to be used then alternative solutions may improve the testing environment.

The following additional possibilities exist, in order of increasing complexity:

  • Provide a mechanical switch that can select between target and host for development purposes, or target and terminal for application tests.
  • A FORTH word executing in the host can be used to prompt the programmer to change the switch position when that part of the application is to be tested. If the host computer has two serial ports, this could be automated using software that would redirect the input to the hardware to be driven.
  • Extending the terminal emulation mode of the host allows it to be developed into a full simulation of more complex protocols.
  • The link program as supplied can be used to read and write to the target computer's memory, independently of the execution of a target application program. This has been used as a simple master-slave protocol.
  • Using the comROM device to implement the chipFORTH link allows the micro's own serial port to be dedicated to the application.

The Importance of Flexibility

A major consideration when producing chipFORTH was the need to adapt it to a wide range of different development requirements, all using minimum hardware. The examples given above show some of the more common configurations and provide you with ideas on how chipFORTH will work on your hardware. Every target system is different and has its own unique problems. If you were still wondering how we would configure chipFORTH for your application, our engineers would be pleased to show you how chipFORTH will solve your development headaches.

What is Supplied?

Program Production

  • Mass storage of source code.  
  • VDU Editor using IBM function keys.
  • Source copy and revision tracking programs.
  • On line documentation.
  • Source and documentation printing utilities.

Program Development

  • Testing of High Level program on host PC before target hardware is available.
  • Target Compiler.
  • Target Assembler.
  • Host Target link to load target code.
  • Access to on-line documentation of code while testing target application.
  • Interactive compilation of test code.
  • Display of Stack and Register contents.
  • Display of variables and arrays.
  • Interactive execution of I/O instructions.
  • Terminal emulation to test serial I/O.
  • A Link protocol, which is also available for communications between the application and any PC, to which might be connected.
  • Host software can be extended to provide Emulation of more complex target/CPU link protocols.
  • Where the target does not have a serial port or where the UART is to be used for a non-character protocol, drivers for a comROM link are provided.

ROM Production

  • Software is provided to drive a ROM Emulator through the PC's parallel link, capable of loading 32K bytes/sec.
  • Software is provided to drive two popular PROM Programmers


All chipFORTH systems provide a common set of functions (nucleus) and support services. These are supplemented by examples of how to support chip specific hardware.

chipFORTH Nucleus:

  • Support for language constructs IF, ELSE, THEN, DO, LOOP, +LOOP, BEGIN, UNTIL, AGAIN, subroutine call and return.
  • 16 bit signed integer arithmetic.
  • Memory Access.
  • FORTH-83 extensions.

Arithmetic extensions

  • Fixed-point arithmetic.
  • Fixed-point transcendental functions.
  • 32 bit arithmetic.


  • Terminal support for input of character strings, conversions of numeric strings and output of character strings, 16 and 32 bit numbers.
  • Inter task communications and synchronisation.
  • Real-time clock support (European and US calendars) and timing support for task delays.
  • Local variables for re-entrant programs.

Only those facilities required for a given application need to be loaded. Once the application has been tested, the host link program (~256 bytes) may also be removed. The link program can run using on-chip RAM only allowing untried target boards to be tested with the minimum hardware installed. Such a system can then be used to check off-chip ROM, RAM and I/O ports prior to starting a major development project.

All chipFORTH systems allow applications to execute using only on-chip RAM. Multi-tasking has a RAM overhead with a minimum of 48 bytes/task. The viability of running with on-chip RAM in your application is determined by factors such as the available free RAM, number of variables and the CPU's interrupt behaviour.

Home Shop Products Supported Chips Information Zone Contact Site Map
Computer Solutions Ltd
3 b Claremont Road,   West Byfleet,  Surrey  KT14 6DY
Telephone: +44 (0) 1932 355630    
Email:      Web:
Copyright 2018 Computer Solutions Ltd