Frequently Asked Questions about the MK14
Maintained by Paul Robson (email@example.com)
Last updated on 10-June-1998
The MK14 is an early computer kit produced by Science of Cambridge. It was the first really cheap computer kit in England, being launched at a price of £39.95 + V.A.T. Its nearest competitor was the Nascom 1 which was about £200 or so, and was a great machine as well. It's a "hackers" machine - it was for learning about programming rather than actually doing anything. Amazingly, the advertisments didn't say you could run a power station on it.
Yes. Science of Cambridge was used because the National Enterprise Board owned Sinclair at the time. The Sinclair History (part 3) tells of how Ian Williamson designed a kit for the SC/MP processor but was then stuffed by Sinclair when National Semiconductors took over the design of the project, who produced the actual component kits. The text of this excellent book is available on the internet and you can find it by doing a web search for "Sinclair MK14"
The base machine had an SC/MP 2 Microprocessor running at 4.4 Mhz, and 8 or 9 digit 7 segment display, a 16 key keyboard, 512 bytes of ROM. It was possible to expand memory on board by a further 256 bytes, and to add an 8154 I/O RAM Chip with 16 I/O lines and 128 bytes of RAM. There was also a reset switch. There was only support for 8 digits normally but Ray Aucote published a modification allowing the use of the Ninth.
The clock was at 4.4Mhz. There were 4 clocks / cycle, giving a cycle rate of 1.1Mhz. Instructions take between 5 and 25 cycles, and there is a delay instruction which can take over 500,000 cycles.
An SC/MP Microprocessor "Simple Cost Effective Micro Processor" (or alternatively NS part 8050 (mk 1) and 8060 (mk 2)) is an 8 bit control orientated microprocessor. It has 2 x 8 bit registers, 4 x 16 bit index registers, one of which is also the program counter, and a status register. It had 5 bits in the status register which connectly directly to the chip pins (3 out 2 in).One of these was the Interrupt pin. It was unusual in that it could share a bus with other processors almost transparently. A design is available for a multiprocessor MK14, and this feature was also used in the VDU to make it cheap (no dual port RAM required)
It was popular as an 'experimenters micro' in the late 1970's. Electronics magazines published designs for 'trainer' micros using it. (The one that sticks in the mind was in Elektor) as it was fairly easy to design a trainer around. The original design was as a microcontroller, which it wasn't very successful at, though I did read somewhere that some of the design lived on in the NS COP microcontrollers (is this true ?)
It is limited in some respects - subroutines and long jumps are difficult, and interrupt handling uses an index register (leaving only 2). Big programs can be a bit chaotic with bits of code all over the place (see Pico BASIC for example).
The following are known to exist :-
If anyone has any information about these not in the manual or shown above, please let me know, email firstname.lastname@example.org. Any more information on the VDU would be useful (like how were the top and bottom addresses and text/graphics mode selected ?)
There were also some home built projects available, including a "Backplane" system and a Multi-processor system (adding another SC/MP by soldering it on top of the first one).
There were a few programs in the manual. Several programs were printed in magazines around 1979-1981, especially Practical Electronics and Computing Today. I believe Electronics Today International published software listings too - if anyone has a collection I'd be grateful if they'd look through 1979-81. No commercial software was produced, as far as I know. Any and all paper listings are gratefully recieved.
Thanks to Ian Bradbury, I now have a selection of software for the machine, including Computing Today's Pico BASIC interpreter, the first High Level Language for the MK14. Software is steadily being added to the page.
There is also some new software written by me - at present just "SegTris", a Tetris using the LED display and the SC5 intepreter.
There is a .TAB file available for the shareware macroassembler TASM to enable SC/MP development on a PC, which is preferable to doing it through the buttons unless you are a masochist. This is generated by a 'C' program (see the SCIOS section). With this, it is possible to painlessly develop for the MK14. All the programs in the library include TASM source, and there is also a TASM source version of the SCIOS ROM.
Note : if the jump is at the extremities (e.g. the offset is 80h) it is assembled incorrectly.
It is not instinctively obvious how to program the MK14. Briefly, there are two modes. "Address mode", where digit keys pressed change the address, and "Data Mode" where the digit keys change the memory at that address.
There are four buttons :-
TERM changes to "data entry" mode. In this mode, entering hex digits will change the byte at the currently displayed address
MEM increments the currently displayed address, and goes into data entry mode.
ABORT changes to "address entry" mode. In this mode, entering hex digits will change the address.
GO runs the program from the currently displayed address. On exit, the instruction after the program is displayed
RESET resets the processor.
There is a tutorial on running a simple MK14 program here.
The only stumbling block is the SC/MP which is no longer produced, (which shows what lousy taste National Semiconductor has got). I do not know of any sources of SC/MP chips, other than old machines. It should be possible to make a fast microcontroller emulate an SC/MP reasonably well, say the fast Dallas Chips.The fastest instructions take 5us and the slowest about 25us, and most instructions are fairly simple.
The other parts such as RAM and ROM are not mostly available, but there are easy equivalents, except for the 8154 I/O chip. Most of the rest of the design is standard TTL. Given a working SC/MP there should be no problem constructing an MK14 equivalent.
Try advertising on the newsgroups, comp.sys.sinclair I suppose. There aren't very many about, only about 20,000 were made. They are now 'collectable'. There are several collectors on the Web with MK14s, but I don't think you'll persuade them to part with them.
Yes. This is a much better way of playing with an MK14. Paul Robson's emulator is available and allows you to enjoy the MK14 experience. It is compatible with all commercially released software. All the software in the library is tested on it. Other emulators are available, including one designed to be ported in 'C'. See the links on the index page.
Apart from mine, not many. There are several pages in Sinclair or more general emulation which feature the MK14, but they mostly are historical or personal "how I learned about computers" information. There are no other technical information sites that I know of than mine. If you are interested in this machine, I suggest you read the chapter from the Sinclair history which is available on the WWW.
The links I found are here.
Well, there are umpteen SNES and NES type emulators about (I wrote some of them) and I wanted to do something a bit more original. I also wanted to relive a bit of my past, and preserve a machine which might otherwise die. Everyone wants SNES emulators to play Super Mario or whatever, but I found resurrecting this or the Jupiter Ace more satisfying.
This is one of the best machines to write an emulator for for beginners. It's pretty simple in both system design and processor design. For example, most CPUs have extensive flag registers which are set by umpteen ALU operations. The SC/MP only has 2 flag bits, Overflow and Carry, which are only changed by ADD, DAD and CAD type instructions, and the instructions which operate on them directly (CCL/SCL/RRL/SRL/CAS). It is fairly slow (the fastest instruction takes about 5us) so coding efficiency is not so important. The instruction set is very orthogonal for those of you who like to use macros.
Download and understand the SC/MP instruction set, the Circuit Diagram, and the ROM listing. You may also find the C Sources useful if you can read 'C'. The only tricky bit is the display encoding (and this isn't that tricky :) ). Briefly this works as follows (all IC numbers are on the circuit diagram) :-
On a read or write to 0Dxx the lower four bits of the address are latched by IC12 and decoded by IC13 to select the display digit being addressed. All of the outputs of IC13 are logic '1' except for the selected one which is logic '0'. This lights the corresponding digit in the display, the lit segments being decided by a write to 0Dxx and latched by IC9 and IC10 (why is it done this way ?). To light say all segments in digit 4, write 0FFh to 0D04h
The SC/MP can't light all the digits at once, so it circles through the digits lighting them one at a time, and relies on the persistence of vision of your eye to maintain the idea that they are all lit at once. If your program goes into an infinite loop the display should blank. Some programs rely on this (e.g. Dice). As a first base in an emulation, though, the display can simply be treated is 'writeable digits'. Most of the games won't work correctly with this though.
IC11 is a tristate buffer which is gated onto the data bus by a read from 0Daa D7-D4 are normally held to logic '1' by R7-R10 but if a key is pressed the line is pulled to logic '0' via IC13 (the line selected via IC12). Effectively reading 0Daa reads xxxx 1111 where x are 0 if the key is present and pressed, 0 if not pressed or no key is connected.
All this works for 09xx as well as 0Dxx due to incomplete decoding of the keyboard/display hardware. However, I have not discovered any software which doesn't use 0D00 to 0D07 for hardware.
Please feel free to contact me if you have any problems.
Thanks to Ian Bradbury for providing the magazine articles this information was extracted from.
The VDU is yet another classic Sinclair design (as cheap as possible), and is not dissimilar to the ZX80 in some ways. It supports a text resolution of 32 x 16 or a Graphics Resolution of 64 x 64
It uses the 2 main memory blocks at 0B00h and 0F00h, each of 256 bytes, each of which represents half of the screen. The screen is split into 2, vertically, so each half either represents a 32 x 8 character block or a 64 x 32 pixel block.
If it is a character block the display uses 6-bit ASCII characters. Bits 6 and 7 of the byte are ignored, though designs are available to enable Bit 6 to be used as invert (let me know if you want this for any reason). If it is graphics the pixels are memory mapped, 8 bytes representing one line of 64 pixels, there being 32 of these per screen half.
There seems to be no consistency about the VDU set up - which half of the screen is mapped to which block, and whether or not each block is text or graphics. The blocks are independent so one may display text and the other graphics. If there is a 'standard' for connections please let me know. I do have a program which suggests F2 in the Status is used to set graphics mode (F2=1=Graphics) but I don't know if this is a standard or not. It is possible the VDU can be set up with toggle switches, for example.
To avoid the need for dual porting memory and to make the design dirt cheap, the VDU uses the multiprocessor features of the MK14 to freeze the display during display time. This means that the processor only operates during the horizontal or vertical retraces, which will reduce the speed by about 60-70%