Sunday 8 March 2015

35 years old Arduino-like setup with Pascal

I do not care much about products or constructions from the past, that cannot be reproduced or used, but in this case, my brother's old construction from the late 1970s made me look again, because it looks so much like what people do with Arduino kits.

This is a computer programmed using Compas Pascal or Turbo Pascal:


  1. CPU: Zilog Z80, of model Z80CPU01. This is probably running 1-2MHz. The Z80 was an extended version of the 8080 CPU, on which the 8086/8088/Intel CPU line of CPUs was built.
  2. One EPROM for the runtime
  3. One EPROM for the actual program
  4. 5x4 keyboard on the back, suitable to be used as a 4x4 hex keyboard with some more keys.
  5. Some RAM chips etc.
  6. I/O pins for easy access.
Unlike today, where we can program Arduino boards etc. using flash, easily, that kind of technology was unavailable or extremely expensive. Therefore, EPROMS were used, which could easily be erased using an ultraviolet lamp, and easily re-programmed using this board, which used the Centronics port for I/O to the programmer's computer, as USB was not invented back then.

The main computer, that was used for programming, could be a Zilog Z80 Nascom computer, a CP/M-80 computer, or any homemade computer that was using a 8080 or Z80 CPU.

Compas Pascal and Turbo Pascal were obvious choices for this, as the compiler was fast and generated great code, and therefore boosted programmer productivity a lot.

Wednesday 7 January 2015

Test-driven programming guidelines

We all know about test-driven development. How many actually do this? Well, medical device software is made this way. Maybe the tests are not automated, but developers are required to establish verifiable requirements before starting to write source code. Since you only know if a requirement is verifiable, if you know the verification method, that means that you must know a verification method, i.e. test, before you can start programming.

Let's go one level up: What about programming guidelines? For instance, if your company has introduced the OOD methods mentioned on this page by Dr Bob, how do you verify that they are actually used?

Let's take one example: Derived classes must be substitutable for their base classes. How do we verify that this works? Well, first we need to find all classes that have been derived from another class, and then we need to verify that this class works in a test that works with the base class. We can usually find all class-derivations by scanning the source code, so scanning the source code would be part of the verification method. Next, we get a list of class names, and base classes, and we then must verify, that these classes are substitutable. This can be fairly easy on TStringList inheritance, but how do you verify that TXyzClass works instead of TAnotherClass? It quickly becomes a lot of work.

So, seriously, what if there is one part of the code that violates these programming guidelines, will you care? If you don't care, but you still want to verify compliance on each software release, then you need to mark this class as approved non-compliant so that you can skip it next time, and it does not show up on your error-list on the next product release.

Most people will probably end up saying: We do not verify that we are in compliance with this principle, as that would be too much work. It is only meant to be a guideline or principle... and if they are still ambitious, they might make random checks to measure compliance, and/or make senior developers review code from younger developers before the final commit. But that means that you cannot tell outsiders, whether you conform to the principles, or not. Instead, you can only be sure that you are not conform to the principles. You can only say that you try to be as much as possible.

To outsiders, this is vague information about what is going on in a software development department, which usually reduces the quality of communication to other parts of the company. So, you may want to ask yourself this question: What rules does your source code actually follow? Can you prove it?