Interface hardware - Firmware

Firmware

The current version 1.2 of the controller firmware was made in July 2008. It has been in use one year already and passed many tests during this time. So, it should work without problems. The core functions of the KCNet-Protocol are very generic commands, this prevents updates.

An update would be necessary only if additional commands should be added or for expanding existing service functions. I have no future plans in this direction, because the effort is high, through the individualization with the unique MAC address for each firmware.

But it is software only, it can be updated in contrast to the interface-hardware.

Without this software, the interface is dumb hardware. The KCNet goes into operation with a programmed MCU only. You don't have to pay for the firmware, but fulfill some conditions, to get one. This is explained in paragraph "Delivery" later.

MCU-Programming:

You can burn the firmware by yourself, or get a preprogrammed MCU. I use an AVR ISP parallel port interface from the STK200, which is connected to a standard PC LPT port. The circuit for this simple ISP adapter can be found in the internet easily. If you place the optional ISP plug on the KCNet hardware, it can be used directly : this is handy for updates, too.

The settings of the controller fusebits are very important for the self-programmers. In each case, they must be changed! If you buy a new  ATmega 162, they will not match the settings needed for the KCNet!

The following screenshot shows the correct settings of the fusebits for the widely used "Ponyprog 2000" burning program:

Two files have to be burned, one for the flash memory and one for the EEPROM memory of the controller (nnnn = serial number of your firmware):

nnnn.hex - firmware file for the flash memory (Intel hex file format)
nnnn.eep - firmware file for the EEPROM memory (Intel hex file format)

Don't forget to burn the EEPROM file! This is a common mistake, the KCNet interface does not work with an empty EEPROM! Use the verify-function of the burning software to ensure the correct contents of the chip after burning.

Check the help of your burning program, how intel-hex files have to be loaded. Some programs work properly only if the filetyp is "hex". Then, you have to rename the delivered EEPROM file before using it.

Step by step guide for "Ponyprog 2000":

• Command -> Security and Configuration Bits ...
• adjust all settings according to the picture above
• Button 'Write'
• File -> Open Program (FLASH) File ...
• select and open the "nnnn.hex" file
• File -> Open Data (EEPROM) File ...
• select *.eep filetyp with the drop-down selector
• select and open the "nnnn.eep" file
• Command -> Write Program (FLASH)
• Command -> Write Data (EEPROM)
• Command -> Verify All
• message "Verify successful" must be shown.

PIO-Handshake:

The firmware of the controller can be adjusted flexibly, in contrast to the hardware of a PIO, which is hard-connected to the clock rate of the Z80 system. A crucial point is the PIO hardware handshake for data input and output to the periphery, which can be viewed in the Zilog datasheet.

I didn't found exactly information about the minimal length of the strobe-pulse, so the following way was chosen. This length is adjusted in dependency of the PIO clock rate. The minimal length is always a little bit longer than 1 clock length of the PIO clock rate. So, the PIO should surely recognize the strobe-pulse of the controller. Then, the handshake is able to synchronize the different system clock rates during data transfers under all circumstances.

The diagrams show the handshake of the KC85 system for example. These pictures were recorded during the development and test of the second firmware version 1.2 in summer 2008.

 
Thus, the interface should work reliably with varying Z80 systems, and the pulse width of the /strobe signals are adjusted according to the clock rate of a system. On the other hand, the length of the pulses is only as long as necessary, and the speed of data transfer is always in the optimum range.

The right adjustment is made by the assembler, using the PIO clock frequency during the translation of the firmware. The pulse width is larger in slower, and smaller in faster Z80 systems. A range from 500 kHz up to 8 MHz PIO clock frequency is covered, which should fit for most of the systems.

These settings are readable over the Debug-Terminal. They can be viewed, just as the computer name of the Z80 system, for which the interface firmware has been translated.

Ethernet-MAC:

An unpleasant but very important thing is the MAC address for the network interface. It is required for the operation of the ARP protocol in the Ethernet layer and must differ with each participant in a network of the related segment (subnet). Therefore, it must be unique in order to connect to any networks, without disturbing the other (unknown) participants.

Unfortunately, the WIZnet chip comes without an built-in MAC address. Hence, the firmware in the controller must deal with this matter. Normally, manufacturers of network cards buy a pool of MAC addresses in whole packages for money! Because the KCNet is a hobby project, this was not an option for me.

I reject a distribution of the interface firmware without MAC address because this makes the commissioning of an interface more difficult. Furthermore, there is the danger that (foreign) networks are disturbed in their operating, if there are problems with the MAC address. Identical MAC addresses in a subnet can cause for a lot of confusion, and such problems are very difficult to diagnose.

For this reason, a valid MAC address has to be provided from interested users for each individual copy of the firmware and, thus, each interface.

The supplied MAC address is hard coded in the firmware, which manages it automatically during the operation of the interface. Since the MAC address cannot be changed  subsequently, the firmware files must not be confused or double used : each interface needs its own version of the two files, so that the MAC addresses are different! The firmware executes a CRC test during the boot sequence, to guarantee the smooth running of the interface.

In order to get a MAC, use an old NIC (or new for 3,99 EUR) whose  address can be adopted. Firstly, it ensures that the MAC address is valid and, secondly, that it is unique. The manufacturer of the real NIC is prohibited to sell network cards with the same MAC. After the acquisition of the MAC, the NIC should be trashed!

Sometimes, the MAC address is printed on the backside of the network card, or on a sticker. In the worst case, you have to install the card in a PC and get the MAC with a program  or with the help of the operating system. Old ISA bus cards can be read out with the MS-DOS utilities from the NIC manufacturer websites.

A sequential serial number is awarded to each KCNet interface and is assigned, in conjunction with the MAC address, in an internal list. Before the release of a provided MAC address, a comparison with this list is carried out. An use can only be done, if this MAC address does not exist in the list!

Delivery:

Basically, there are two possibilities to get a copy of the firmware. A preprogrammed controller is delivered, which contains your individualized  firmware. Or, an individualized copy of the firmware is delivered via E-mail, which must be burned into a controller itself.

Besides the important MAC address, I need the following information from an interested user for each copy of the firmware in separate form:

1. Last and First Name
2. E-mail address
3. valid MAC address(es) for each copy of the interface firmware
4. short name of the Z80 system (this name is displayed in the Debug-Terminal only, for example "KC85")
5. clock frequency of the PIO (in most systems, identical with the system clock rate)

For each copy of the firmware there will be assigned a serial number. All important parameters of the individualized copy can and should be controlled in the delivered config file (plain text).

For each interface, a related pair of two files is required. Do never alter the content of files or swap files of different pairs. Do not use a pair of two files for more than one interface! Otherwise, in the worst case, the network can be brought to a standstill!

If an individual copy of the KCNet firmware with your data is delivered via E-mail, you will get a zipped folder with 3 files: