Ramblings

Building with structural foundations - Turbo Pascal

Problem statement

When creating a metallic contact on a semiconductor surface, two broad types of behaviour can occur. The contact may be ohmic, acting like a wire with no strong restriction on current flow in either direction. Alternatively, the contact may form a Schottky diode, in which current flow is preferentially allowed in one direction.

In an experiment to create Schottky diodes on n-silicon, aluminium contacts were bombarded with various ions. In this process, known as ion beam mixing, an attempt was made to improve the quality of the Schottky diode.

The quality of the diode can be tested by comparing temperature dependent current-voltage characteristics with theoretical predictions.

The diode equation is given by:

$$I=I_s(e^{\frac{\mathrm{qV}}{nkT}}-1)$$

where

• I is the measured current
• I_s is the saturation current, which is the limiting value of the reverse current (or leakage current)
• V is the applied voltage
• n is the ideality factor
• q is the charge on an electron
• k is the Boltzmann constant
• T is the temperature.

The equation was generated using MathML; rendering quality varies between browsers.

The ideality factor n should be as close as possible to one for the diode to behave correctly.

The sketch above is reproduced from Spinning Numbers. The saturation current, I_s, is typically much smaller than a microampere.

The diode equation provided a working framework for analysing the measured I–V data as a function of temperature, even though its underlying assumptions are only approximately satisfied in practice. In particular, the saturation current was treated as constant over the measurement range, not because this is strictly true, but because it was a necessary assumption for any practical attempt at parameter extraction. The task therefore shifted from refining the physical model to extracting meaningful parameters from imperfect data using the computational tools available at the time.

This was not a trivial exercise, as the equation contains two unknown parameters and cannot be rearranged into a simple linear form, particularly when applied across multiple temperature-dependent data sets.

(12 January 2026)

Solving the problem

The experimental work was relatively straightforward, consisting of measuring the current flowing through the metal-semiconductor contact as a function of the applied voltage, at a range of temperatures, both before and after the ion beam mixing. This was fairly tedious work as measurements were recorded manually. The real challenge lay not in collecting the data but in analysing it in a way that would meaningfully quantify the effect of the ion beam mixing on the I-V-T characteristics of the contacts.

I had successfully used a non-linear least squares fitting algorithm (loosely based on one from Hubin) to determine thin-film thickness on metal surfaces using ellipsometry measurements. This gave me confidence that same numerical approach could be used to determine I_s and n. The algorithm I implemented required an initial (seed) value for n which helped guide the fitting routine towards the minimum in the least-squares error function χ² and thereby reduce the number of iterations required.

My first attempt was carried out on my home computer, a Spectravideo SV-328, equipped with an SVI-605B Super Expander and two 5¼" floppy disk drives. The fitting program was written in BASIC and run under the SV-328’s ROM-resident interpreter, rather than being compiled into machine code. While the algorithm itself worked as intended, the combination of limited processing power and the overhead of interpretation meant that analysing even a 50 point data set took an excruciatingly long time.

The Spectravideo SV-328 was based on a Zilog Z-80 processor, an 8-bit CPU with a 16-bit address space, limiting it to a maximum of 64kB of addressable memory. The machine was fitted with 64kB of RAM and a 32kB ROM containing Microsoft's Extended BASIC. When running under the built-in BASIC interpreter, half of the address space was occupied by the ROM, leaving only 32kB of RAM available for user programs and data.

Booting into an alternative operating system such as CP/M removed the BASIC ROM from memory. However, the operating system used 32kB of RAM, again leaving about 32kB of RAM to the user. In practice, this imposed a hard limit on both program size and the amount of data that could be handled at any one time.

CP/M did not magically remove the memory limitations, but it did provide access to a proper toolchain, including assemblers and, crucially, a compiled high-level language in the form of Turbo Pascal, complete with what would now be recognised as a rudimentary integrated development environment.

Pascal was new to me, but I soon realised the power of the structure inherent in this language. Rebuilding the program in Turbo Pascal was not trivial, but the ability to decompose the problem into functions and procedures, and then compile the result into native machine code, which could be executed directly by the processor, was a genuinely new experience.

The program still took several hours to reach the final result, but this represented a substantial improvement and no longer required an overnight run. Even so, the turnaround time remained a limitation, and this led me to start looking towards an IBM PC clone running MS-DOS.

The new machine was based on an Intel 8088 processor, running at 8MHz, with 640kB of RAM and ran MS-DOS 2.11. As a bonus, Turbo Pascal had been upgraded to version 3.0. The existing code compiled and ran without modification, but the effect on performance was dramatic: the runtime for a typical dataset was now under an hour. This clearly demonstrated the advantage of a more modern CPU, a higher clock speed and more memory.

Colleagues were starting to feel my pain with the time taken to analyse the data, and there was a growing sense that this work really ought to be done on the university's mainframe computer. There was, however, there was one small problem: the program would have to be rewritten in FORTRAN, yet another new language. Fortunately, by this stage the Pascal programming language, had taught me what to look for as the key control structures in a language, so the conversion went quicker than expected.

Getting to use the mainframe was an education in itself. Time had to be booked in advance, so that the operators could load the FORTRAN module, after which only a short window of access was available before some other more important job took precedence. With the additional overhead of testing and uploading data, this often felt slower than simply running the program on the SV-328. That said, once the job finally ran, the results were returned at close to the speed of light (relatively speaking), typically under 10 seconds.

I eventually managed to convince my supervisor that it was far more efficient to do this work in the lab, and I was provided with a machine identical to my home computer with the added advantage of an Intel 8087 mathematics co-processor.

Having a computer permanently available in the lab made the whole process considerably easier. Results could now be printed directly, and publication quality I-V graphs plotted on an HP7475A plotter via the RS-232 port, using a new Turbo Pascal program. The biggest improvement, however, came from the mathematics co-processor: the runtime for analysing a data set had dropped to under two minutes. At this point it became clear that the mainframe was no longer essential for data analysis in the way it had been only a few years earlier.

The final step was the integration of an HP 4140B picoammeter and voltage source with the laboratory PC via an HPIB interface card. HP only supplied software libraries for BASIC, so a small interface program was written to provide the necessary control functions. Once this layer was in place, the entire experiment — biasing the device, measuring the resulting current, and logging the data — could be controlled directly from the PC.

The voltmeter used to measure emf corresponding with the temperature was also connected via HPIB , allowing the emf data to be transferred directly to the PC. The conversion from voltage to temperature could then be carried out by software. The only remaining manual interventions were adjusting the temperature and the physical changing of samples.

The graph above shows log(|I|) plotted against |V|. A logarithmic current scale is used because the negatively biased current is much smaller than the positively biased current, while absolute values are used so that both bias polarities can be displayed in the same quadrant of the graph, as is conventional in the literature.

In addition to plotter output, as shown above, graphs could also be displayed on the monitor, and tabulated data could be sent to the printer.

(22 January 2026)

Some reflections

• Microcomputers were becoming viable tools for serious data analysis and process control, shifting this work away from exclusive reliance on mainframes and shared facilities.
• Pascal’s strongly structured syntax encouraged a more disciplined way of thinking about programs, which carried over even when working in other languages. At the time, Turbo Pascal also stood out for its integrated development environment, which shortened the cycle between writing, testing, and refining code, even if direct control of laboratory hardware still required other tools.
• Limited memory forced a level of rigour that is increasingly rare. When programs had to fit into tens of kilobytes, inefficiency had immediate and visible consequences — a sharp contrast to modern environments where abundant resources often mask poor structure.
• Specialist software often underpins the entire analysis of experiment and theory, yet the effort involved in writing it is rarely acknowledged explicitly in academic literature.

(17 January 2026)

References

• Carr, B.A. (1987). The effect of ion beam mixing on the electrical characteristics of aluminium contacts on n-silicon. (M.Sc. thesis). University of Pretoria.
• Hubin, W.N. (1978). BASIC Programming for Scientists and Engineers. Prentice-Hall, N.J.

Useful reading

• A brief history of CP/M.
• An overview of Turbo Pascal on its 40^th birthday.

---

Back to the Accidental Programmer