Introducing the Science of Microchip PIC14

Engineers of my generation in the UK will remember the Science of Cambridge Mk14. Intended to be Sir Clive Sinclair’s first home computer kit for the general public, it served to train a generation of electronics engineers in how to program microprocessors.

The Mk14 was based on, and virtually identical to, the ‘Introkit’ that was available in America at around the same time. It had a 512 byte monitor ROM, 256 bytes of RAM, an eight or nine digit LED display with bubble magnifiers, and a notoriously bad twenty key keyboard.

Microchip PIC14

The Mk14 was the first computer I ever got to program. Most are long gone now and if, like me, you feel a nostalgic desire to relive or repossess one of these venerable machines, then the options a really pretty limited. Basically, you either have to try buying one on Ebay (rare and expensive), searching around obscure component vendors to pull together the parts yourself, or using one of the excellent PC emulators that people have made.

Up until now, if none of those options were acceptable then you were stumped.

Introducing the PIC14 – a full speed emulation of an unexpanded Mk14 on a PIC!

The PIC14 is a ‘cycle perfect’ emulation insofar as every SC/MP instruction executes in the same time as it would on a real SC/MP chip. However, the emulation departs in a number of ways from true Mk14 behaviour:

  • The memory map of the PIC14 is not identical to the Mk14 although it is broadly compatible insofar as the ROM, display and standard RAM are to be found in their correct Mk14 locations. The PIC14 memory map is shown in an associated table which includes the Mk14 memory map alongside for comparison. Note that items not present in the unexpanded Mk14 are shown in brackets (Note also that, although the PIC14 RAM features several times in the memory map, they are just copies – there is only 256 bytes of RAM in total).

  • Sense A interrupts are not implemented.

  • SC/MP paging is not implemented. Both program counter increment and pointer arithmetic will carry normally into the top four bits of any address calculation. Mk14 behaviour follows from the fact that these four bits play no part in address decoding. Nonetheless, if a program examines these bits, they may be found to be different to what they would be in an Mk14.

  • The display column latch is not updated by reads of the display. This aspect of Mk14 behaviour required programs to exercise discipline when scanning the display and keyboard, otherwise ‘ghost’ digits could be generated. This discipline is not needed with the PIC14. Problems can occur with programs that implement column latch update using display read cycles, though the author has never seen such a program.

  • The emulation is of a 4MHz SC/MP. The Mk14 had a 4.43MHz crystal and clock. In practise this will just cause programs to run 11% slower than they would on an Mk14. Programs that synthesise tones on the flag outputs, for example, would still produce clean tones but they will be around 2 semitones lower in pitch. For those who want a true 4.43MHz emulation, they could try fitting a 22.15MHz crystal to the PIC. This is driving the PIC beyond its specification but might work for some chips. A version of the ‘Alarm Clock’ example found in the Mk14 manual has been produced which is cycle trimmed for a 4MHz SC/MP.

  • Illegal SC/MP instructions cause a reset. This is actually an advantage – in the Mk14 a program crash went completely undetected and often lead to total RAM obliteration.
    The emulation is cycle perfect only for programs executing in RAM. ROM execution runs slightly slower due to approximately an extra cycle overhead on program fetches from ROM (note however, that data reads from ROM by programs running in RAM execute at the correct speed). This has connotations for the use of cassette interface routines provided in some SCIOS monitor ROMs.

The Mk14 had a characteristic by which the display would sometimes freeze with a single bright digit when the reset button was pressed. Reassuringly, the PIC14 exhibits the same behaviour!

The Mk14 display segment drivers were a bank of AND gates, one input of which was tied to a common line, which itself was tied high through a resistor (one suspects that these gates were present only to protect the preceding make-shift segment latches from the non-TTL levels on the segment lines).

It always struck me as odd that this line wasn’t exploited as a ‘display enable’ signal that could be tied to the SC/MP reset input. This would ensure that the Mk14 display was blanked while the microprocessor was held in reset. There were even a couple of spare gates that could have been used to clean up the relatively slowly changing signal on the reset button. As usual, I suspect time pressure was the reason that this small embellishment failed to get realised.

The PIC14 has a couple of additional features over the Mk14:

  • The RAM, as programmed through the SCIOS monitor, is non-volatile. This means that programs are retained through power cycles. It also means that a program can be recovered if it overwrites itself.

  • A serial download facility allows Intel hex files to be sent to the PIC14. This feature is entered automatically following a PIC reset. If this feature is not required, then it can be exited by pressing the SC/MP reset key, in which event the RAM is loaded from non-volatile memory. Files should be transferred at 9600 baud, 8 data bits, 1 stop bit and no parity. As the link is one way, no flow control or handshake should be enabled for file transfer.

  • The PIC14 program will run in a PIC16F876, Ports A, B and C providing an interface to the display and keyboard. If the PIC14 program is run in a PIC16F877, then the SC/MP flags can be accessed on the additional Port D and Port E pins. The author is confident that these processor flags and sense lines work, though they have only been tested in simulation, and even then not very thoroughly!

The PIC14 was constructed on square pad board. With the exception of the power rails, all wiring was point-to-point using enamelled 18 gauge copper wire. A heat sink was fitted to the voltage regulator but is probably unnecessary. A 78M05 device could certainly be substituted here, though a 78L05 device is probably optimistic. The ten or so milliamps of segment current gave a very satisfactory display brightness using the specified displays. A keypad escutcheon suitable for use with push switch Maplin part no. FF87U is provided.

Serial connection is through a 2.5mm jack socket that takes a serial lead intended for a PDA. Be careful if you use a PDA lead – some have strange wiring and / or resistors built into them. Under consideration is a two chip NIBL computer using an external RAM chip for program storage. Strictly speaking, of course, this will be a three chip solution when the RS232 transceivers are included!

Some would argue you can’t do anything in 256 bytes of RAM. How wrong they are! To show just what is possible, I present my Babbage difference engine emulation! I wrote this partly to demonstrate just what can be done with apparently meagre hardware, but also to provide a test of the emulation, in particular, the decimal addition algorithm.

The Babbage difference engine was remarkable because it accomplished a lot with no more than simple addition. It used the principle of differences to generate high order polynomials. To illustrate how this works, consider the simple situation where we keep adding a constant to a number. We know that the number will keep escalating linearly (e.g. 0, 1, 2, 3, 4…).

Now, suppose the number we add is not a constant, but itself is escalating. The sequence we then produce is 0, 1, 3, 6, 10, 15. This sequence is actually a parabola – a second degree polynomial. By cascading stages of adders in this way, Babbage was able to synthesis polynomials of any order, typically tenth order.

The example Babbage.asm uses tenth order differences but only sixteen digits of precision (only!!!). Babbage knew that resolution at high orders was going to be a problem, and the real difference engines used thirty digits. The example has the engine pre-primed for generation of the function 4.arctan(x) over the interval 0.0..1.0, in fifty steps. If the run is successful, it should finish on the value 4.arctan(1) which is π. Even with just tenth order and sixteen digits, the example arrives at π to within about 11 parts per million!

For more detail: Introducing the Science of Microchip PIC14

About The Author

Ibrar Ayyub

I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.

Follow Us:
LinkedinTwitter