How to Use KCC or KPC - teraKUHN integer C and Pascal Compilers for Z80, 68HC11, or 6502 CPUs

To use KCC or KPC, start by downloading the Windows console app to your Windows computer.

Download Debug Z80 (DebugZ80Install.msi)

Download Debug 6811 (Debug6811Install.msi)

Download Debug 6502 (Debug6502Install.msi)

KCC - teraKUHN integer C Compiler

KCCs (teraKUHN integer C Compilers) are Z80, 68HC11, and 6502 C Compilers that might be helpful to the hobbyist or student who wishes to develop code for a Z80, 68HC11, or 6502 architect CPU. These compilers are only intended to support integer, not floating point, math operations for embedded systems. The current implementation only supports a very limited subset of the C language. All C and C++ reserved keywords are reserved in KCC so that users don't use them for identifiers in their code which could limit where they can port their code to in the future. The compiler does not include a preprocessor and only supports single file compilation. The compiler does not support multiline comments, but does support single line comments starting with //. The compiler does not support strings or structures. The compiler does not support function prototypes; functions must be defined before referenced. The compiler does not support C unary operations such as var++ or var -= 1. The compiler should generate correct code for integer calculations and assignment as well as if statements and while, do, and for loops. C is a case sensitive language. Thus, KCC treats all keywords and symbols as case sensitive.

By default KCC produces code that would work in an all RAM system like a CP/M system (Z80) or an Apple II (6502). You can specify the starting code and variable RAM address with the -B command line switch. However, for embedded robotic systems, that aren't loading code from a disk, you want to have code in ROM and variables in RAM in different address ranges. To support this, you can specify the starting variable RAM address with the -V command line switch. If you use the -V command line switch, then starting code ROM address is specified with the -B command line switch.

The KCC80, KCC11, and KCC65 are 32-bit Windows applications that can run on 32-bit or 64-bit Windows. They are not digitally signed so you will get a warning when you install them that the author is unknown. Updates happen a few times a year so if something isn't working, make sure you have the latest version installed. Also, if you identify any problems please report them to teraKUHN.

Compile and assemble code

First you need to write a program. Here's an example of a C program that sets bits in I/O port 081h as if it's wired to an H-bridge circuit for turning on and off motors, and calling a wait routine in between each motor state.

  extern void delay(int nCount)
  {
    while (nCount > 0)
    {
      nCount = nCount - 1;
    }
  }
 
  // stopped
  extern void stop()
  {
    outp(0x81, 0x00);
    delay(1000);
  }
 
  extern void setup()
  {
    stop();
  }
 
  // forward
  extern void forward()
  {
    outp(0x81, 0x0F);
    delay(5000);
  }
 
  // reverse
  extern void reverse()
  {
    outp(0x81, 0x05);
    delay(5000);
  }
 
  // forward on one side and reverse on the other
  // results in turning
  extern void turn()
  {
    outp(0x81, 0x07);
    delay(5000);
  }
 
  extern void loop()
  {
    forward();
    stop();
    reverse();
    stop();
    turn();
    stop();
  }
 
  extern void main()
  {
    setup();
    while (true)
    {
      loop();
    }
  }

Otherwise pick almost any of the numerous pieces of example code on the internet for the CPU that you're working with.

The command to run KCC will look something like this:

  KCC80.exe {source_file_name}.c {output_file_name}.a80
  KCC11.exe {source_file_name}.c {output_file_name}.a11
  KCC65.exe {source_file_name}.c {output_file_name}.a65

KCC will produce a *.asm, *.a80, *.a11, or *.a65 file in the same directory as the *.c source file. Make a note of the path to the directory where this *.asm file is created.

You can use the KAsm80 assembler, KAsm11 assembler, or KAsm65 assembler that come with DebugZ80, Debug6811, and Debug6502 respectively. The command to run KAsm80, KAsm11, KAsm65 will look something like this:

  KAsm80.exe {source_file_name}.a80
  KAsm11.exe {source_file_name}.a11
  KAsm65.exe {source_file_name}.a65

KAsm80, KAsm11, or KAsm65 will produce a *.hex file in the same directory as the *.asm, *.a80, *.a11, or *.a65 source file. Make a note of the path to the directory where the *.hex file is created. That's the directory where you will load the *.hex file from inside of DebugZ80, Debug6811, Debug6502, or in your EPROM programmer.

KPC - teraKUHN integer Pascal Compiler

KPCs (teraKUHN integer Pascal Compilers) are Z80, 68HC11, and 6502 Pascal Compilers that might be helpful to the hobbyist or student who wishes to develop code for a Z80, 68HC11, or 6502 architect CPU. These compilers are only intended to support integer, not real, math operations for embedded systems. The current implementation only supports a very limited subset of the Pascal language. The grammar for the compiler is based on the grammar presented in the back of the book "Compilers" by Aho, Sethi, and Ullman (the dragon book). However, this grammar has not yet all been implemented. The compiler only supports single file compilation. The compiler does not support multiline comments, but does support single line comments starting with {. The compiler does not support strings or records. The compiler should generate correct code for integer calculations and assignment as well as IF statements and WHILE, REPEAT, and FOR loops. Pascal is a case insensitive language. Thus, the latest versions of KPC treats all keywords as case insensitive. However, KPC treats symbols as case sensitive since the KAsm assembler treats symbols as case sensitive. Thus, 'Variable1' and 'variable1' are considered different symbols since the first character has a different case.

By default KPC produces code that would work in an all RAM system like a CP/M system (Z80) or an Apple II (6502). You can specify the starting code and variable RAM address with the -B command line switch. However, for embedded robotic systems, that aren't loading code from a disk, you want to have code in ROM and variables in RAM in different address ranges. To support this, you can specify the starting variable RAM address with the -V command line switch. If you use the -V command line switch, then starting code ROM address is specified with the -B command line switch.

The KPC80, KPC11, and KPC65 version 1.0* or greater apps are 32-bit Windows applications that can run on 32-bit or 64-bit Windows. The older KPC11 and KPC02 version 0.* apps are 16-bit DOS applications that can run on 16-bit or 32-bit Windows, but not 64-bit Windows. They are not digitally signed so you will get a warning when you install them that the author is unknown. Updates happen a few times a year so if something isn't working, make sure you have the latest version installed. Also, if you identify any problems please report them to teraKUHN.

Compile and assemble code

First you need to write a program. Here's an example of a Pascal program that sets bits in I/O port 081h as if it's wired to an H-bridge circuit for turning on and off motors, and calling a wait routine in between each motor state.

  program hbridge(input, output);
 
  procedure delay(nCount : integer);
  begin
    while (nCount > 0) do
    begin
      nCount := nCount - 1
    end
  end;
 
  { stopped }
  procedure stop;
  begin
    outp(0x81, 0x00);
    delay(1000)
  end;
 
  procedure setup;
  begin
    stop
  end;
 
  { forward }
  procedure forward;
  begin
    outp(0x81, 0x0F);
    delay(5000)
  end;
 
  { reverse }
  procedure reverse;
  begin
    outp(0x81, 0x05);
    delay(5000)
  end;
 
  { forward on one side and reverse on the other }
  { results in turning }
  procedure turn;
  begin
    outp(0x81, 0x07);
    delay(5000)
  end;
 
  procedure loop;
  begin
    forward;
    stop;
    reverse;
    stop;
    turn;
    stop
  end;
 
  begin
    setup;
    while (true) do
    begin
      loop
    end
  end.

Otherwise pick almost any of the numerous pieces of example code on the internet for the CPU that you're working with.

The command to run KPC will look something like this:

  KPC80.exe {source_file_name}.pas {output_file_name}.a80
  KPC11.exe {source_file_name}.pas {output_file_name}.a11
  KPC65.exe {source_file_name}.pas {output_file_name}.a65

KPC will produce a *.asm, *.a80, *.a11, or *.a65 file in the same directory as the *.pas source file. Make a note of the path to the directory where this *.asm file is created.

You can use the KAsm80 assembler, KAsm11 assembler, or KAsm65 assembler that come with DebugZ80, Debug6811, and Debug6502 respectively. The command to run KAsm80, KAsm11, or KAsm65 will look something like this:

  KAsm80.exe {source_file_name}.a80
  KAsm11.exe {source_file_name}.a11
  KAsm65.exe {source_file_name}.a65

KAsm80, KAsm11, or KAsm65 will produce a *.hex file in the same directory as the *.asm, *.a80, *.a11, or *.a65 source file. Make a note of the path to the directory where the *.hex file is created. That's the directory where you will load the *.hex file from inside of DebugZ80, Debug6811, Debug6502, or in your EPROM programmer.

Micro Controller Compilers for Hobbyists and Students of Robotics

The most fundamental development tool you will need to develop software for a micro controller is an assembler. For the beginner, an assembler takes a text source file of processor architecture specific assembly source code and converts it into bytes of that processor architectures machine code. This machine code is typically written to a *.bin file (binary file format), *.hex file (hexidecimal file format), or sometimes a *.s19 file that can be uploaded to the controller or burned into its PROM. The file you can load to a particular microcontroller will depend on the type of memory (PROM, EPROM, EEPROM, flash, etc.) the microcontroller chip or board uses and on the download interface software or PROM programming software you are using.

A higher-level programming language compiler can be used to generate the assembly source code or some will create a machine code binary file directly. Languages such as BASIC or Forth might compile into the machines instructions or they might compile into an intermediate instruction file in which case they will have an interpreter or runtime that will need to be uploaded to the controller along with the file to execute the code. Procedural languages such as Fortran, Pascal, and C are typically compiled into the machines instructions and might have a library of support routines that should be included in the assembly code or binary file if used in the code. Some programming languages are based entirely on stack operations (ex: Forth), but most are based on stack frames (ex: Pascal, C, Ada, C++, Oberon, and their common ancestor Algol), or patternless memory access (ex: Fortran, BASIC). Some programming languages encourage object oriented programming where collections of data and code in records, structures, or classes are used to model objects in the world. The concepts or object oriented programming originate from the Simula programming language. On the other hand, data-oriented design is a programming approach motivated by optimizing data access, typically used for video games (usually implemented through the C programming language). This approach is similar to the concepts in the Forth programming language which focuses on data layout in arrays for fast access. C++, an object-oriented programming language (OOP) descended from C and Simula, is also typically compiled into the machines instructions and has a library of support routines that should be included. Other object-oriented programming languages such as a Java or C#, descended from C++, will create an intermediate instruction file that would need their runtime to be uploaded to the controller along with the file to execute the code, and these languages use a heap memory management technique called garbage collection that also requires their runtime in order to execute correctly. In all cases software developers need either a compiler that is processor architecture specific or a runtime interpreter that is processor architecture specific.

Taking a step back, not all embedded systems are the same. Many things called embedded systems would more accurately be called headless servers. Like a server or workstation, a headless server has a lot of RAM and little if any ROM. They will quite often run operating systems derived from server or workstation operating systems such as Linux, Windows, or Unix, but they might have an RTOS like VxWorks. A more traditional embedded system has very little RAM and most of the code is in ROM. They might or might not have an operating system or an executive.

Thus, despite the evolution of object-oriented programming languages, the most used embedded system programming language continues to be the C programming language. C++ comes in second, and processor assembly quite often comes in third. Developed around 1972, the C language has continued to be the most used language for embedded systems for a number of reasons including: simplicity, portability, and availability of compilers, and ability to do almost anything the processor can do. It has also served as the foundation for C++, Java, C#, and other programming languages. While some view C as holding the most used position because of legacy code, others view it as a way to avoid the pitfalls and inefficiencies of object oriented programming languages which typically rely on dynamically allocated heap memory in RAM and pointers. Not only do programming languages like Java and C# require a runtime with garbage collection support, since all objects are created dynamically in RAM and passed by reference, there's a lot of pointers (references are just pointers hidden from the programmer) being stored and passed around. C++ allows objects to be created as globals or on the stack with static members and static method functions which can cut down on unnecessary pointers and dynamically allocated heap memory in RAM. However, using C, Forth, Pascal, or even Fortran will steer a programmer away from this overhead and Forth even encourages a data-oriented design.

While it's easier to write source code in a high-level language than in assembly source code, it might be necessary to have more memory in your controller to load an interpreter or runtime or even more to support garbage collection. Along with the language you use, you might also leverage a library or framework of pre coded procedures, functions, or methods to save time from having to code everything from scratch. Additionally, you might want to use a basic I/O subsystem (BIOS) , executive, or real-time operating system (RTOS), but again these take even more resources on your controller.

While assemblers, compilers, and debuggers, are all specific to the controller or processor architecture family that you're developing for, software written in higher-level programming languages does not need to be controller or processor specific. So if you have software for an algorithm written in C, and you have a C compiler for a Z80 processor and a C compiler for an AVR processor and a C compiler for a 6502 processor, you could compile the same software for any processor by using the appropriate compiler. This only works if there isn't processor or hardware specifics in the high level language code. For example, in the above C and Pascal examples, while the high level language code can be compiled with compilers targetting different processors, The outp() calls would be hardware specific and would not necessarily be portable between Z80, AVR, 68HC11, or 6502 based systems. These differences in hardware can be masked by having a module of code called an I/O system or basic I/O subsystem (aka BIOS) . A BIOS doesn't eliminate the need for different code for different hardware, but it isolates the code that is hardware specific in a subsystem.

If you use any of these tools on a regular basis you are encouraged to register them. With a full registration you will receive the next version of the software when it becomes available.

Disclaimer, Comments on Shareware, and Copyright

KCC and KPC are distributed 'as is', so the user bears all responsibility for testing that the functionality is acceptable. Use KCC and KPC at your own risk. If this software has undesired effects, your sole recourse is to discontinue use of it. That said, we hope you enjoy using this software and are able to get some practical work accomplished with it. Feel free to write to us if you have questions, suggestions, feeback, or bug reports regarding it. Contact us at teraKUHN.

KCC and KPC are shareware programs. Please help more people learn about it by pointing friends, classmates, and co-workers at the download location for them to try it. Please do not redistribute it on your own. If you use KCC or KPC on a regular basis, you are requested to register it. With a registration you will receive an email notification when the next version of the software is available. To register through PayPal send $5.50 US to teraKUHN@yahoo.com with the program name 'KCC' or 'KPC' in the note to seller. Alternatively send a check for $5.00 US payable to R. J. Kuhn and a note with your email address and the program name 'KCC' or 'KPC' to:
R. J. Kuhn
5412 158th Pl NE
Redmond, WA 98052

Copyright (C) 2001 - 2002, 2021 - 2024 R. J. Kuhn - All Rights Reserved

teraKUHN solutions

Hardware Setup	Control System	Hardware Abstraction	Development Tools
Smartphone Controller (with PWM or advanced latch circuit)	USB-Controller	teraKUHN IO System (KIOS)	Debug Z80 KCC80 KPC80
Smartphone Controller (with advanced latch circuit)	AVR-Controller	C & C++ coding abstraction macros	Debug AVR Arduino C++
Arduino Controller .	N/A	C & C++ coding abstraction macros	Debug AVR Arduino C++

Here are some architecture characteristics that can be demonstrated by these two control solutions. These differences can be used for teaching processor and microcontroller concepts.

Text Copyright (C) 2000 - 2002, 2021 - 2024 R. J. Kuhn. Please note that you are not allowed to reproduce or rehost this page without written permission.