@device(x2700) @comment( Final year honours project report SCRIBE source for the EMAS implementation and Xerox x2700 laser printer... will not run through Unilogic scribe! ) @make(text) @comment( really want to make(report), but I want to do it my own way! so have to include the whole make file for report and modify those bits which I like changed, cannot do this any other way because I want to affect the contents preparation and counters! ) @style(topmargin 1 inch, bottommargin 1 inch, leftmargin 1.25 inches, rightmargin 1 inch, spacing 0.25 inch, spread 0.25 inch, indent 0, singlesided, justification on) @Define(HDX, Hyphenation Off, Leftmargin 0, Indent 0, Fill, Spaces Compact, Above 0.25 inch, Below 0.25 inch, Break, Need 7, Justification Off, Use B, underline all) @define(hd0, use hdx, above 1inch, below 0.5inch) @define(hd1, use hdx, above 0.5 inch, pagebreak untilodd) @define(hd1a=hd1, centred, above 0, below 0.5 inch, need 9, underline off, facecode L, overstruck 1) @define(hd2, use hdx, above 0.5 inch, below 0.25 inch, need 7, underline all, facecode K, overstruck 0) @Define(Tcx, Leftmargin 2, Indent -2, Rightmargin 2, Fill, Spaces compact, Above 0, Below 0, Spacing 1, Spread 0, Break, Facecode R, justification off) @Define(Tc1=Tcx, Above 1, Below 1, Use B) @Define(Tc2=Tcx, Leftmargin 5) @Define(Tc3=Tcx, Leftmargin 9) @define(Tc4=Tcx, Leftmargin 13) @define(m,facecode M) @modify(subheading, above 0.25 inch, below 0.25 inch, need 7, facecode B) @counter(chapter, titleform "@begin(hd1a)Chapter @parm(referenced) @parm(title)@end(hd1a)", Contentsform "@begin(Tc1)@Parm(numbered) @Parm(Title)@>@Parm(page)@\@end(tc1)", numbered [@1.], referenced [@1], incrementedby use, announced) @Counter(Section, TitleForm "@Begin(HD2)@Parm(referenced) @Parm(Title)@End(HD2)", Contentsform "@begin(Tc2)@Parm(referenced) @Parm(Title)@>@Parm(page)@\@end(tc2)", within chapter, Numbered [@#@1.], Referenced [@#@:.@1], Incrementedby Use, Announced) @Counter(Subsection, Within Section, TitleForm "@Begin(HDX)@Parm(referenced) @Parm(Title)@End(HDX)", Contentsform "@begin(Tc3)@Parm(referenced) @Parm(Title)@>@Parm(page)@\@end(tc3)", Numbered [@#@1.], Referenced [@#@:.@1], Incrementedby Use) @Counter(Paragraph, Within Subsection, TitleForm "@Begin(HDX)@Parm(referenced) @Parm(Title)@End(HDX)", Contentsform "@begin(Tc4)@Parm(referenced) @Parm(Title)@>@Parm(page)@\@end(tc4)", NUmbered [@#@1.], Referenced [@#@:.@1], Incrementedby Use) @Counter(UnNumbered, TitleForm "@Begin(hd1a)@Parm(Title)@End(hd1a)", Contentsform "@begin(Tc1)@Parm(Title)@>@Parm(page)@\@end(tc1)") @Counter(Appendix, TitleForm "@Begin(hd1a)Appendix @Parm(referenced) @Parm(Title)@End(hd1a)", Contentsform "@begin(Tc1)Appendix @Parm(numbered) @Parm(Title)@>@Parm(page)@\@end(tc1)", Numbered [@A.], Referenced [@A], Incrementedby Use, Announced) @Counter(Appendixsection, Within Appendix, TitleForm "@Begin(HD2)@Parm(referenced) @Parm(Title)@End(HD2)", Contentsform "@begin(Tc2)@Parm(referenced) @Parm(Title)@>@Parm(page)@\@end(tc2)", NUmbered [@#@1.], Referenced [@#@:.@1], incrementedby Use, Announced) @Counter(Prefacesection, TitleForm "@Begin(hd1a)@Parm(Title)@End(hd1a)", Contentsform "@begin(tc2)@Parm(Title)@>@Parm(page)@\@end(tc2)") @pageheading(left "", centre "", right "@value(page)") @pagefooting(left "", centre "", right "") @Send(Contents "@Set(Page=2) @Style(Pagenumber <@i>) @Tabclear @Newpage @Prefacesection(Table of Contents) ") @blankspace(2 inches) @begin(text, above 0, below 0, blanklines kept, break after, capitalized off, centred, continue off, indent 0, leadingspaces ignored, leftmargin 0, pagebreak off, rightmargin 0, spaces kept, spacing 1line, spread 0, facecode K) @comment(titlebox) David A. KERR B.Sc. Hons. Project Report An MSF Time Signal Decoder Board for the EUCSD Advanced Personal Machine. 7th. June 1985 @comment(endtitlebox) @blankspace(3 inches) SUPERVISOR : John Butler @end(text) @set(page 0) @style(pagenumber "@i") @prefacesection(ABSTRACT) The National Physical Laboratory broadcast a standard time and frequency signal, MSF, from Rugby near Coventry which includes full time and date information. This signal and the information it carries is described. A microprocessor system based on the Z80 CPU is designed as a slave board in the EUCSD Advanced Personal Machine and the necessary software is written such that the MSF time signal is decoded and used to set an internal clock. A communication protocol is defined to allow the Control Processor or any bus master to query the MSF clock board for the time. A new network service is defined and the installation of the MSF decoder board in the filestore is described. @prefacesection(PREFACE) The final year honours project constitutes a large part of the examinable course work for fourth year Computer Science and joint subjects, most work being concentrated in the second and third terms resulting in this final written report. Intermediate reports are produced at the end of the first and second terms and two verbal presentations given to interested staff and students in the presence of a member of the board of examiners. The project to build an MSF clock decoder for the EUCSD Advanced Personal Machine was proposed, and work supervised by, John Butler. The goals of the work are best outlined by the message below which I received in October 1984. This report sets out to describe how the task was undertaken, the problems that were encountered, and the degree to which the goals outlined have been satisfied. @style(pagenumber "@1") @set(page 0) @begin(verbatim, leftmargin 0.5 inch, facecode S, spacing 1 line) From: JHB 23-OCT-1984 To: DAK A few notes on the MSF clock project... The core of the project is to build an MSF clock interface to receive the Rugby transmissions and present them for use by the APM. Things you may like to think about... 1) How should the data be presented? Pseudo-memory location(s) or serial access through an 8-bit wide register. 2) What data should be available to the APM (presumably everything transmitted) 3) Is our spec. of the transmission up-to-date? 4) What aerial considerations are there? What are the characteristics of an R/F transmission of that frequency? 5) How should the board be constructed? Will the standard EUCS ZAP board be proof enough against interference? Add-ons 1) (Useful for diagnostics) Put a set of 7-segment LEDs down the front edge of the board to display the time as received plus a BST/GMT indication and carrier fail indication (+ ?) 2) (Pretty essential) Put a crystal on the board so the clock can run when the transmitter is down. 3) Enable the board to act as a timer i.e. to interrupt at a pre-programmed real time or after a programmed elapsed time (single-shot in both cases) The emphasis should be on the digital side of the construction so If circuits are available for the (analogue) radio side I suggest you just lift them provided of course you think they'll work! @end(verbatim) @chapter(INTRODUCTION) The basis of this project is to decode the national standard time and frequency signal broadcast by the National Physical Laboratory. The time information derived is then to be made available to the Computer Science Departments Local Area Network. To do this it was proposed that another network server be designed and built, the MSF time clock, and added to the network. This would then become the reference point from which other servers or clients could set their own clocks. This involves the construction of dedicated hardware which would reside in a standard APM on the ether, and the definition of a protocol so that clients can access this time information. @section(Requirements) Before starting to design the system it is instructive to take a look at exactly what is required of such a time server. Below I list some of the important general requirements, how these requirements are met is a topic of later sections. @begin(itemize) Hardware which should be simple and flexible enough to be compatible with the standard APM configuration, yet powerful enough to reside in a filestore configuration without adding additional complexity to the file server software. Flexible enough to cope with modifications and additions to the MSF time standard signal, and to allow additional features to be incorporated in the device. Independent of human intervention. The server should power up into a reset state and start running automatically. Should also be immune from stray fingers searching for a reset switch, and similarly should be unaffected by a reset to the rest of the APM system. Time setting should be automatic as should compensation for leap years and leap seconds. Should remain active on the ethernet irrespective of the state of other servers or clients. Should provide a very accurate time to the network, both in a human readable format and a machine readable format. Any additional information transmitted with the time signal should be made available. @newpage The interface to the network should be such that any client or server with a connection, either directly or indirectly, should be able to query the system without difficulty. @end(itemize) An important aspect of time keeping is the ability to time-stamp files and events. On the filestores and VAX every file is given a time stamp indicating when they were created and last updated. This information is used mainly for archiving and backup, where only files which have been modified since the last backup need be saved. It is therefore important that the time known to the systems is always incremental, it should not be possible to set a clock to a time which is @i(before) the last known time. As an example consider the situation where the MSF time is unavailable to a system, its clock is temporarily set manually. If the clock was set fast, it would be undesirable for it to be set to the correct time later as this would take the system back in time, it could therefore start re-using time-stamps with potentially dangerous results. This is something to be considered when interfacing the MSF decoder to a system. @section(National Time Standards) As implied above a national standard frequency and time signal is broadcast by the NPL from Rugby. This signal is broadcast on a 60KHz carrier and with the properties of low frequency transmission can be received reliably throughout most of western Europe. The international call sign of this transmission is @i(MSF), however the abbreviation MSF has become synonymous with the time signal information. The MSF time transmission is not the only signal which is available. Most countries have their own time and frequency standards and their own regulating body@+(1)@comment(BIH). The Western European countries, and the alternatives within Britain are the only real alternatives to the MSF signal for EUCSD purposes. Each has some problem, the most notable deficiency is that few broadcast for 24 hours continuously, but say only three times every hour. The one serious competitor to the MSF signal is that broadcast by the BBC@+(2)@comment(BBC) on 200KHz, this signal is phase modulated over the national radio four transmission. The problems with this signal are three fold. Firstly the modulation is awkward to decode and the signal must be isolated from the audio radio four signal. Secondly the transmission is only experimental and so there is no guarantee of performance. Finally the transmission frequency is due to change to 198KHz in 1988 in accordance with international agreement. The signal transmitted as MSF contains full time and date information broadcast 24 hours per day. The data is encoded in two formats, a 'fast code' and a 'slow code'. The fast code appears once every minute during the first second, the slow code being transmitted continuously throughout the minute. Full details of this signal and information are given in a subsequent chapter. @section(Published Designs) There have been a number of designs published in the last few years to decode the MSF time signal and it is worth looking at each before starting to design our own. It is also instructive to examine each in chronological order of publication as design approaches have altered over the years. @subsection(Wireless World Receiver 1) The MSF time signal started started sending data in 1974 and was well established by the time Wireless World@+(3)@comment(WWdesign1) published this design, however it was the first one to decode the time signal and present it as a practical clock. The design approach is typical of the technology of the day, based entirely on discrete components (TTL 74 series) and as a result rather complex and completely inflexible. At the time only the 'fast code' time of day information was transmitted and as such this is all the circuit could decode. The addition of the 'slow code' in 1978 is unattainable. The radio receiver exhibits the same characteristics, deploying discrete transistors. @subsection(Mullard Decoder) Work was done within Mullard@+(4)@comment(Mullard) to design an MSF clock decoder and follows a similar approach as the Wireless World circuit, but with the advantage of being developed two years later. Again it only decodes and displays the 'fast code' signal, but has been expanded to read the date information in addition to the time of day. Its only major deficiency is the lack of its own real time clock to back up time keeping when the MSF transmission fails. The design required expansion to accommodate BST/GMT conversion. The radio receiver now uses a dedicated integrated circuit which greatly reduces the component count and probably increases the reliability. Unfortunately the chip used, a TDA1050 device, is no longer readily available, and no data can be found on it. @subsection(Radio & Electronics World REWBICHRON) The first design which used a microprocessor to decode the time signal was published by Radio & Electronics World@+(5)@comment(REWbichron) in 1982 (and updated one year later) The hardware part of the decoder is relatively simple, the received data is fed directly into a Z80 microprocessor from where software can take over. This allows a high degree of flexibility and the data can be thoroughly tested against parity and validity before being accepted. The receiver part of the design, like the Mullard one, employs a dedicated radio receiver IC to perform most of the decoding. This receiver is available as a kit of parts, including a printed circuit board, from the components firm CIRKIT. (Previously known as Ambit international) @subsection(Wireless World Receiver 2) Another design based around a microprocessor was published in Wireless World@+(6)@comment(WWdesign3) in the same year, however in this case a 6502 CPU was used. Again this brings all the advantages of a software approach to this design. It becomes flexible and extremely easy to modify or expand its capabilities. The radio receiver design is interesting in that it avoids the usual RF demodulation, employing instead a multiplier technique and a differential voltage proportional to the carrier level. This helps to make the receiver very tolerant to noise, though it does mean that the device is not as simple as some of the above receivers. @section(Proposed Implementation) None of the above designs have considered the problem of interfacing the decoded time to a larger computer system. Each was designed solely to decode and display the time as a stand alone unit, some what like a normal digital clock. The design proposed and implemented for this project follows similar design philosophies to those above based on microprocessors, though is necessarily more complex to permit an interface with a standard APM system. Although the hardware designs for the above are readily available no software is published. The following design and implementation involves an additional board which can reside in a standard APM configuration without interfering with normal operation of the system. When connected to the MSF radio receiver the incoming signal is decoded and upon validation used to set internal registers which form the basis of a crystal controlled clock. The APM acquires the time by reading a copy of these registers from the MSF clock board. To provide a service to the EUCSD local area network this board must either become part of a new network server or reside in an existing server such that any client can access the time. The possibilities regarding this aspect of the implementation are discussed later. @chapter(THE MSF TIME SIGNAL) Before considering the design of the MSF clock board it is worth examining the signal transmitted, its source, modulation characteristics, information included and coding. It is important to fully understand the signal before starting to develop the reception and decoding equipment. @section(MSF operational properties) The time encoded on the MSF signal is derived from a Rubidium reference atomic clock at Rugby, this is continuously cross checked with a Caesium reference at the National Physical Laboratory in Teddington. This time is thus atomic time (abbreviated to @i or @i) and not the true time derived from the rotation of the earth, Universal Time, @i(UT1). These two times are not necessarily the same throughout the year, although they are guaranteed to be within one second of each other. @subsection(R/F Characteristics) The MSF radio signal is broadcast on a carrier frequency of 60KHz from Rugby (52.35@m<:>N,1.17@m<:>W near Coventry) continuously except for a scheduled down time for maintenance from 1000-1400 UTC on the first Tuesday of each month. The characteristics of low frequency transmission ensure that the signal can be received reliably throughout the United Kingdom, although 60Khz is particularly susceptible to interference from electronic equipment such as television receivers, computers and even fluorescent tubes. In addition there is a skywave and groundwave component to the received signal which in certain areas can lead to cancellation or addition effects where mixing occurs. This effect changes from day to night as the ionosphere changes. The graph in figure 2-1@comment(WWjuly78) shows the estimated field strength of the signal from Rugby. The radiated power of the signal is about 50kW at source and a useful range of 1000Km is predicted. Edinburgh is thus well within this range. Reception problems peculiar to the EUCSD application concern mainly the problem of interference from computer equipment and the location of the APM servers in the James Clerk Maxwell Building. @blankspace(3 inches) @begin(verbatim) @centre<@ux(Figure 2-1: MSF signal field strength.)@+[7]> @end(verbatim) @subsection(Data Encoding) The format and modulation of the time signal is such that it is ideally suited to digital decoding, the costs involved not being that high. Modulation of the binary data on the carrier is by On/Off Keying (OOK) and thus very easy to demodulate into digital signal levels. On/Off keying modulation is the simplest form of data transmission, the presence of the carrier indicating a logical @i(high), the absence a logic @i(low). Thus the MSF carrier is not transmitted continuously but pulsed on and off periodically, the periods of high and low can then be further decoded to interpret the information transmitted. Below there is a description of what this information is transmitted and in what format it is encoded. @section(Information Transmitted) Information is transmitted throughout the period of one full minute and is transmitted in two formats, the Fast Code, and the Slow Code. Generally both forms of the code transmit the same data, however the slow code does contain extra information on top of that transmitted by the fast code. Additionally the slow code is less prone to interference and as the timing is less critical it is more suitable for software decoding techniques. The following sections describe each format and their information content independently. @subsection(Fast Code) The fast code is transmitted once per minute during the first 330mS of each minute. The information coded is the time, day and month as shown in figure 2-2@comment(Mullard?) @blankspace(2.5 inches) @begin(verbatim) @centre<@ux(Figure 2-2: Example fast code information.)@+[4]> @end(verbatim) The code always starts with the same sequence, a minute identifier control pulse 20mS in length, 25mS after the minute. 5mS later this is followed by a 10mS marker bit. The time code is then transmitted as a sequence of 10mS pulses. Hours, minutes, days and months are sent as a binary coded decimal number, the detection of the carrier allows easy decoding into a computer manageable format. Two parity bits are inserted into the fast code, one to check the time, the other to check the date, parity is odd. Between the time and date signals one extra bit is inserted to indicate BST or GMT time for Great Britain, when the BST bit is on, the decoder must add an extra hour to the time as the transmitted signal is always GMT. An interesting point here is that during BST, the date information still changes at 2400 Hours GMT, therefore any clock without a correction for this will show a change of date one hour @i(after) 2400 hours BST. The fast code is complete after 330mS from the minute, at 500mS the carrier returns to give the second pulses. Each second is defined exactly by the falling edge of the carrier. @subsection(Slow Code) The slow code is transmitted throughout the whole minute, generally only one bit is coded into each second, however as will be explained later the last 8 seconds of the minute have two levels of data, effectively two bits. The carrier pulses every second during the minute. Each second is signalled by the falling edge of this carrier, there then follows a gap of 100mS, 200mS or 300mS before the carrier returns, the length of the gap indicates whether there is a binary high or low bit and which level of data is being given. If the gap is 100mS then the data is binary '0', if the gap is 200mS then the first level data is '1' and second level data '0', for 300mS the first level is '1' and the second level is also '1'. Again BCD coding is used for all time and date transmission. The DUT1 information is complicated in that the first level data is always '0' and the second level (between 200mS and 300mS) used to code the value. This results in a double pulse in each coded second and complicates the decoding techniques. Data transmitted is greater that that for the fast code, the information and the position they occupy within the minute is shown in figure 2-3@comment(WW) and each is explained below. @blankspace(4 inches) @begin(verbatim) @centre<@ux(Figure 2-3: Example slow code information.)@+[6]> @end(verbatim) @i(DUT1) is the difference of universal time. As stated above the time information transmitted is derived from an atomic reference, @i(UTC), and is different from @i(UT1), the time derived from the rotation of the earth. To keep the two relatively similar UTC is adjusted when necessary in steps of one complete second such that the two times remain within 700mS of each other. It is the difference between UTC and UT1 which is provided by the DUT1 transmission to an accuracy of 50mS. Every coded pulse in the DUT1 transmission between seconds 1 and 7 give the number of 100mS steps that UT1 is @i(ahead) of UTC. The number of coded pulses between 8 and 15 seconds indicate the number of 100mS steps that UT1 is @i(behind) UTC. If at the end of of the year, UT1 is more than one second ahead of UTC then a 'leap second' is included for the following year to indicate the adjustment in the UTC scale. The remaining seconds of the minute contain the year, month, date, day, hour and minute. The time given refers to the time when the @i(next) minute is passed and not the time for the current minute. The last 8 seconds in the minute contain a minute identifier sequence '01111110' which is unique and cannot occur at any other time in the minute, this can be used to detect the approaching minute and to synchronize the decoder. These 8 seconds also contain a second level of data, this is the BST/GMT bit and 4 parity checks for the time and date signals and a BST/GMT change impending bit which is asserted one hour before the change is due. The slow code transmission is already adjusted for BST unlike the fast code, thus no additional calculation is required before using the time values. When developing decoding algorithms it is important to realise that the time information and DUT1 effectively employ different coding strategies. Also the position of the leap second insertion is significant, being between the two fields. Thus when decoding the time we must work backwards from the minute pulse, but when decoding the DUT1, work forwards from the minute. @chapter(DESIGN STUDY) Having become familiar with the characteristics of the MSF signal which is to be decoded the problem of designing the necessary equipment is tackled. Rather than adopt one particular solution to the problem it is prudent to examine the configuration options available, always remembering that the overall requirement of the system is to provide the decoded data to an APM system and the EUCSD local area network. All the options considered therefore use the APM system specification as a starting point. @section(Configuration Options) Three possible design options are considered and each of the possible configurations is described below. None of the options are ideal and the advantages and disadvantages of each are given for the design ideas presented, the final choice has been selected after considerable thought and although not perfect it does include most of the desired functions. @subsection(Microprocessor, Bus Master) The most complex design idea considered is based on the assumption that the MSF clock will be a network server on the ethernet and so it need not be attached to any master processor. The configuration would be a two board system, an ethernet board and the clock board. The clock board would have its own processor and interface to the ethernet board through the local bus. This requires that whatever processor is chosen would have to emulate the 68000 bus protocol to some extent to allow interfacing with the ethernet board. It is also very complex both in hardware and software where a simple operating system would have to be written to cope with the ethernet access. If no external memory is required the APM system bus could be ignored to help simplify the hardware. Briefly some of the pros and cons: @begin(itemize) Complex in both hardware and software. Why bother re-inventing the wheel? The control processor board of the APM can cope with the ethernet and is more flexible. The board is incompatible with the standard APM configuration and there is no possibility of the board becoming part of a standard APM as it requires its own ethernet board. Additionally future expansion to allow a master processor to access the board would not be possible. The software development would be considerable. A lot of time would have to be spent on the lower levels of the system. eg. ether read/write routines, I/O routines, etc. The problem of actually mounting and developing software for the system would be problematic and there would be no debugging tools or any aids. @end(itemize) @subsection(Microprocessor, Bus Slave) The second option is to make the board a slave to the standard APM control processor board, the choice of bus (local 68000 or EUCSD bus) would be a matter of taste, for simplicity the local bus could be selected, for versatility the system EUCSD bus chosen. The arrangement here is to have a simple (8 bit) processor on the clock board which would decode the incoming MSF time transmission, test its validity against parity bits and for invalid dates (eg, 31@+ November), then present the time in an easily readable format. Points observed about this option: @begin(itemize) Simple hardware, the processor could decoded the incoming signal using interrupt driven software to build up a picture of the transmitted data over one complete minute. Compatible with standard APM system. The board can attach to any APM system via whatever bus was selected, the EUCSD would be preferable but the local bus would be simpler. Flexible, because of the software nature of the decoding the choice of what data to decode is pretty arbitrary and also allows for the future inclusion of more information in the MSF time transmission. Releases the APM control processor from all of the decoding, all that is left is for some communication protocol between the clock's time register and the APM, this would be through some semaphore mechanism. @end(itemize) @subsection(Discrete Logic) The final configuration considered is one of a completely hardware orientated dump decoder. This would consist of some timing device which would be synchronised with the incoming MSF signal, on minute detection the fast code would be shifted into a register which could be subsequently read by the APM control processor. The slow code signal is not ideally suited to decoding in hardware because of the time span it occupies, the dual level coding of some data and the comparatively large memory that would be required to hold the data for the approaching minute. The best place for this would be somewhere on the 68000 local bus. The observed points on this configuration are: @begin(itemize) Complex hardware. All decoding and processor communication would have to be built out of hardware. Synchronisation problem. There would be problems finding the start of each minute, and therefore the fast code, more hardware complexity would be involved. Fixed decoding properties. Because of the hardware nature of the device once the range of MSF data to be decoded has been selected it would be complex to change this. Master processor is left with some decoding, parity and validity checking which should really be done before it is passed to the control processor. @end(itemize) @section(Final Specification) After considering each of the above design ideas a final specification of the MSF Clock Board is proposed. As stated this is something of a compromise though it does appear to be the best option. A block diagram of this system is illustrated in figure 3-1 below. The decoder will comprise a EUCSD bus interface for connection to the APM system and a Z80 microprocessor for the decoding. The choice of Z80 is for two reasons, firstly it runs at a comparatively fast clock rate (in comparison with alternative 8 bit processors) and will therefore be capable of rapid real time sampling of serial input signals. Secondly the physical architecture of the processor is such that interfacing with peripherals, and the EUCSD bus, is a simple design process. @blankspace(4 inches) @begin(verbatim) @centre<@ux(Figure 3-1: System hardware block diagram.)> @end(verbatim) The board has its own on board memory selectable between EPROM and static RAM, up to 12Kbytes is allowed for in 2K blocks. For booting purposes the first 2K must be EPROM. Also on the board is a simple LED display device, up to six hexadecimal digits being displayable. Normally this would display the time, but it proves invaluable when developing software and debugging. The MSF time code signal derived from the radio receiver is tristate buffered as a memory mapped serial port to the Z80 where it will be decoded into a human (or machine) readable format by software. An LED indicator is tied directly to the serial input port from the receiver and indicates the state of the 60KHz carrier, under normal operation this will pulse off for a brief period at one second intervals. The bus interface has a bank of switches to select the high order 16 bits of address which select the clock decoder board, the low order 14 bits, plus the data strobes after encoding, will be mapped directly onto the Z80 address bus. Thus any APM master processor can access any or all of the clock boards local memory. It is through such a shared memory mechanism that the transfer of information takes place. An LED indicator is provided in accordance with existing APM boards which gives a visual indication of board selection. This specification for the hardware falls short of the first proposed option of a master which could sit with an ethernet board on the network. However this design does allow for flexibility and compatibility with any existing APM. It releases the master processor from any decoding itself and can therefore be placed into a filestore APM without significant modification to the filestore software. Should it be wanted as a separate network server then the the control processor need only concern itself with the ethernet communications, the time being available in a selection of formats. It is likely that such a server would not be dedicated solely to the MSF clock but would also be responsible for other services, indeed it is an unnecessary expense to allocate a whole APM system to the task of providing this one service. The EUCSD bus has been selected over the 68000 local bus as it allows greater flexibility and is a 'better' solution to the interface problem. The local 68000 bus is easier from a design point of view but is control processor dependant, using the EUCSD bus allows for any master processor and not specifically a M68000 device. It also permits access to all of the Z80 address space, had the APM local bus been chosen there would have been a restriction to about 16 select memory locations. The only unfortunate side effect is the inability to generate an interrupt from the EUCSD bus, the local bus at least allowed levels 4 to 7 to be generated easily (although the chosen level would have had to share with another device). The current implementation of the APM control processor does allow generation of an interrupt from the system bus, but requires that the generating device become the bus master and write into a control register. This requires more complex bus control logic and would have demanded a bus arbiter, the ability to interrupt the control processor board is therefore not available with this hardware configuration. @section(MSF 60KHz Radio Receiver) The MSF transmitted data has to be demodulated from the 60KHz carrier before the digital decoding can take place. Some thought went into the radio receiver to do this. It was hoped that the receiver might be built along side the decoder on the same eurocard that would fit into the APM, however it was quickly realised that this was going to be problematic, and not a wise proposition. The main problem within the whole environment of the machine halls is that of radio interference generated by all the computer hardware, this is vividly illustrated by switching on a radio and listening to all the noise in the radio spectrum. It was concluded that placing a radio receiver inside an APM was just asking for trouble. Another equally large problem was one of reliability and alignment, the ZAP wiring method is good enough for digital signals, however with analogue signals, and passive components it was felt that ZAPing a radio receiver was not possible. Therefore the APM MSF radio receiver will be sited some distance from the decoder, probably near a south facing window to give it the best chance of detecting the 60KHz signal. The connection to the decoder will be through a simple 3 way cable carrying power, ground and the demodulated digital time code. This also avoids the need for a length of co-axial cable and standard @w(RS 232) type cable is all that will be required. The main work for the MSF clock decoder is to be concentrated on the digital hardware design and the necessary software to decode and present the time to the APM system, it was felt that the radio receiver was best purchased either complete or as a 'kit of parts'. The radio receiver design used by the REWBICHRON@+(5) design is available commercially as a kit of parts and is very cheap, thus this was chosen for the prototype implementation. This simplifies the receiver problem and only leaves the actually construction and alignment to be done, time can then be devoted to the actual decoder. @chapter(HARDWARE DESIGN DESCRIPTION) This chapter describes the hardware design of the final working MSF clock decoder board. The original design had some hardware bugs that were discovered during the testing of the board, where the cure involved a change to the design the differences between the original and corrected version are outlined. A full explanation of these bugs follows in the chapter on hardware construction. It is felt that the description of the design is more useful where it concentrates on the final implementation, rather than the original, this avoids confusion should more decoder boards wish to be build sometime in the future. The following description is split into two sections which neatly divide the design. The first concerns the interface to the EUCSD back bus of the APM system, buffering and transfer protocol, the second area concerns the Z80 CPU and its related memory and I/O. Circuit diagrams are in Appendix A and full details of APM bus transfer protocols can be found in the APM Working Documents@+(8)@comment(WORKING) Theoretical validation of the design primarily involves a timing analysis of the data transfer on the EUCSD bus, this is covered below and is followed by a suggested procedure to test a constructed board. The final area of design which must be considered is that of software. The nature of the system is such that the majority of the work in decoding the MSF signal is to be done in software, because of this it is necessary to consider some software design together with the hardware, such that certain requirements like generating interrupts at precise intervals can be supported. @section(EUCSD Bus Interface) This section describes the interface between the Z80 microprocessor and the APM system EUCSD bus. A brief description of the bus lines used in the interface is shown in figure 4-1. @begin(verbatim, need 30 lines) CO0L CO1L CO2L Data strobes indicating which CO3L data lines contain valid data AD2L These are mapped directly onto the Z80 address bus, -AD15L The lowest two bits are derived from data strobes. AD16L These are used to determine whether the board has -AD31L been selected, used in conjunction with TRQL DA00L -DA07L DA10L -DA17L DA20L -DA27L Using data strobe lines one DA30L of these data blocks will be -DA37L mapped onto the Z80 data bus R/WL read/write line determines transfer direction ERRL error line asserted if not byte transfer TACL Transfer acknowledge asserted on completion TRQL Transfer request RSTL Master Reset line PFLL System power failure indication @centre<@ux(Figure 4-1: Lines used on the EUCSD bus.)> @end(verbatim) All APM system bus lines are buffered before use on the Z80 board, additionally where the Z80 board drives the system bus, these lines are either tristate buffered (for data and address lines) or connected through open collector drivers (for the control lines), this is in line with the specification in the APM Working Documents@+(8)@comment(Working). Data lines are buffered through 74LS245 bidirectional tristate buffers, and address lines through 74LS240's these are inverting devices which brings the APM bus negative logic into line with the Z80's positive logic for addresses. Board selection is determined by comparing the upper 16 address lines from the system bus with the address selected on the rotary hex switches, 74F521's or 25LS2521 devices perform such an equal too comparison. The output from this is used to drive the Z80 bus request line, and an LED indicator. In the original design a simple state machine was included between the 'board selected' line and the Z80 bus request, such that the Z80's bus could not be released unless the APM system bus ATML indivisible transfer line was also negated. This suffered from noise hazards and as explained in a later chapter was removed from the design. The Z80 can only transfer data of 8 bits in width, thus only byte transfers can be permitted over the APM system bus. To ensure that this is the case the APM data strobe lines (CO0L..CO3L) are examined to check that one and only one is asserted at any one time. A small section of discrete logic provides this function returning an error signal and the derived lower two address lines (AD0L, AD1L) which the APM system bus does not provide. The truth table for this circuit element is in figure 4-2 and is based on the boolean equation: @begin(verbatim) @centre<(A&B)&(C!!D) ! (C&D)&(A!!B)> @end(verbatim) Where A..D represent CO0L..CO3L. If the result indicates that the transfer is of byte width then the tristate buffers can be enabled, and data transfer commenced when the Z80 is ready, alternatively the error is enabled such that the APM ERRL line will be asserted to indicate a bus transfer error. The Z80 bus acknowledge signal arrives some time after all the above has completed, this is used to enable the appropriate data byte from the data strobes (having been validated) and to enable the APM address lines onto the Z80 bus. Alternatively if an invalid transfer request was made (non byte width) then the data and address lines are not enabled, rather a signal is prepared for the assertion of the ERRL error line. @begin(verbatim) CO?L ___ ___ _______ _______ @ux(Data OK) 3210 0+1 2+3 0x1 2x3 vd1.vd2 vd3.vd4 vd5.vd6 AD0L AD1L -------------------------------------------------------- 0000 1 1 0 0 1 1 0 0001 0 1 1 0 1 0 1 1 1 0010 0 1 1 0 1 0 1 0 1 0011 0 1 0 0 1 1 0 0100 1 0 0 1 0 1 1 1 0 0101 0 0 1 1 1 1 0 0110 0 0 1 1 1 1 0 0111 0 0 0 1 1 1 0 1000 1 0 0 1 0 1 1 0 0 1001 0 0 1 1 1 1 0 1010 0 0 1 1 1 1 0 1011 0 0 0 1 1 1 0 1100 1 0 0 0 1 1 0 1101 0 0 1 0 1 1 0 1110 0 0 1 0 1 1 0 1111 0 0 0 0 1 1 0 @centre<@ux(Figure 4-2: Truth table for data strobe decoding.)> @end(verbatim) The Z80 bus acknowledge signal is also gated with the APM transfer request line to enable the transfer acknowledge sequence of events, thus only if the APM system is still in its memory cycle does an acknowledgement occur. This is used to start the timer components and to immediately assert the ERRL error line if required. The TACL transfer acknowledgement is asserted after a suitable time delay to ensure that the data lines have stabilised (for a read cycle) or have been read by the local memory (for a write cycle). This time delay is derived from the outputs of two D-type flip flops gated such that both outputs must assert to drive the TACL line. These flip flops are clocked on the Z80 3.2768MHz clock and an inversion of it, this ensures that the TACL line will be asserted not sooner that 150nS after the data transfer was enabled, and in the worst case not later than 300nS. A diagram of the transitions for this circuit is illustrated in figure 4-3. Note that this assumes that the memory devices used on the Z80 board have access times of the order of 150nS. @blankspace(3 inches) @begin(verbatim) @centre<@ux(Figure 4-3: Transfer acknowledge timing.)> @end(verbatim) The TACL signal generated by this circuit is used to ensure negation (and therefore latching of any data being written) of the local bus write enable signal. Thus data is latched into the memory simultaneously with acknowledging the transfer to the APM system. This was a feature not in the original design where the latching of data was handled by the master processor which initiated the transfer negating the write enable line. However this was found to be unreliable as data lines returned tristate @i(before) it had been latched. @section(Z80 Microprocessor) The MSF Clock board processor section is based around a standard Z80A microprocessor chip clocked at exactly 3.2768 MHz. This frequency is derived from a packaged crystal oscillator module which can drive up to 10 TTL loads. As a timebase for the microprocessor, to aid in decoding the incoming MSF signal and to allow it to accurately maintain the correct time during signal failure, the Z80 is interrupted at 200Hz frequency (every 5mS). This is derived from the 3.2768Mhz crystal by dividing by 2@m(14), this explains the choice of clock frequency for the Z80. This clocks an edge triggered D-type flip flop, D held high such that every clock pulse sets Q and resets Q', Q' is input to the Z80 interrupt request line. As part of the interrupt acknowledge sequence the Z80 input/output request line is asserted, this is used to clear the flip flop, thus causing Q' to go high and so clearing the interrupt. A total of 16K of address space is decoded on board, using a 3 to 8 decoder (74LS138) this is split into 8 * 2K sections. In the prototype the first six sections were assigned to EPROM/RAM devices to cover for the system memory requirements, the final software implementation does not require such a large store so the final design allows for three memory chips, this still allowing for expansion. TMS 2516 eproms (or single power rail 2716) are used which are pin compatible with the 6116 cmos ram chips, with only the write enable line requiring jumper selection. Any combination of eprom/ram in multiples of 2K is permitted, however the first block should always be eprom for initial power up booting purposes. The remaining two slots are allocated to the 6 digit LED display driver device, and a simple binary input port. The LED display driver (74C917) can directly drive each segment of the display through current limiting resistors (330R calculated), but because of the current drive required the multiplexing of each digit has to be driven through transistors. A suitable transistor pack could not be found, so six NPN transistors were mounted by hand onto a DIL header as an alternative. The 74C917 display driver device is strictly speaking write only, but reading from it is possible but will return meaningless data. The last device is a simple tri-state buffer to allow input from up to 4 binary sources. The first bit of the channel is fixed to be the serial input from the MSF receiver head, this is coupled to the buffer through a low pass filter network which removes any possible high frequency interference and is tied to an LED indicator. The second bit is tied to the reset enable switch to allow software to sense whether the APM system reset line has been tied to the Z80 reset, this allows a warning to be issued if required. The remaining two bits are held high by pull up resistors, but are also connected to a DIL switch to allow some manual option selection. The function of these bits are undefined by the hardware and are only relevant when the software demands them. Power on reset is provided by a simple RC charge path which resets the Z80 on initial power application. This is necessary to put the system into a known state at initial startup and requires that the first block of memory be eprom as indicated above. Also provided is the ability for the Z80 reset line to be connected through to the APM system reset line by manual switch selection. This may or may not be desirable depending on the situation in which the decoder board will be used, but the facility is provided. There is NO MANUAL RESET provided on the board, this is deliberate and avoids stray fingers causing any damage, resetting the board should be done under known conditions and preferably via software. A further provision is for the APM system power fail indication line to be tied, again by manual switch selection, to the Z80 non maskable interrupt. A feature which might make use of this facility is that of battery backed RAM to remember the last known time, or real time clock to keep the time up to date, where these could be initialised only upon impending power fail. This facility is not provided in the current implementation but such devices could be piggybacked onto a RAM socket. Power to the MSF receiver head is derived from the APM system bus, but is passed through a current limiting resistor and another LC low pass filter, again to avoid any interference appearing on the power rails. The receiver power is reduced to 4.8 Volts which is in line with the specification of the chosen MSF receiver, although this is not critical. @section(Timing Analysis) Below a simple analysis of the timing aspects of the bus transfer between the APM control processor and the Z80 local memory is considered. Because the local memory has to be shared with the control processor the Z80 must release the bus when the APM master processor wishes to initiate a transfer, thus a bus request must be made of the Z80. The critical part of the whole timing sequence is the time taken for the Z80 to release its bus to the APM control processor, the transfer must be completed within 2000nS or the APM system bus watchdog (or arbiter) will indicate a bus error. The following calculations for the Z80 timing are derived from the Mostek Z80 technical manuals@+(9)@comment(Mostek). Figure 4-4 illustrates the sequence of events. @blankspace(3 inches) @begin(verbatim) @centre<@ux(Figure 4-4: Bus transfer timing.)> @end(verbatim) With a 3.2768 MHz signal the clock period is approximately 300nS though the Z80 accesses memory in cycles of in average 4 T states in length, these are known as M states. The Z80 tests for bus request during the last T state of an M cycle and will then release the bus after it has completed its memory access cycle. If the bus request comes near the start of an M state it could take up to 1200 nS for the bus to become available and bus acknowledgement to be asserted, the minimum time being 300nS. By this time all the data valid decoding has been done and so the acknowledge causes the APM data transfer information to be enabled onto the Z80 data bus. As described above the Z80 bus acknowledge signal is also used to enable the ERRL error line and the timing circuit for the TACL signal. This timing circuit causes a delay of between 150nS and 300nS depending upon where in the clock cycle the flip flop inputs are asserted, after this time the TACL line is asserted on the APM system bus. Thus the total time for a transfer to be acknowledged is a worst case of 1500nS. It is extremely unlikely that more than the 2000nS permitted occurs. When the control processor negates TRQL the bus is returned into the control of the Z80, one clock period later the bus acknowledge is negated and all buffers return to tristate, TACL is released and the transfer operation is complete. The control processor and the Z80 may continue. This takes about 300nS and so the total turn around time for a byte transfer has a worst case maximum time of about 1800nS approximately. @section(Testing) Before completing the hardware design description it is worth considering the problem of testing a constructed board. Below a suggested test sequence is outlined for testing the hardware once it is ready to be populated with chips and installed in an APM system. Circuit diagrams are in the appendix for cross reference. Firstly the clock circuit should be assembled and checked, 3.2768 Mhz should appear at the clock input to the Z80 and 200 Hz at the input to the D-type flip flop. The power up reset section should be assembled next together with the input port, the LED display driver and a simple program in EPROM to drive the LED display. The Z80 bus request line must be held high to prevent the Z80 releasing is bus and the program should be observed to be working. The position of the DIL switches should be able to be sensed by the software also. The bus interface section can now be assembled (select address 16_00F8XXXX on the rotary switches) and by removing the Z80 to disable the processor and pulling its bus acknowledge line high the transfer can be checked. Removing the bus watchdog allows the action to be frozen when the board is addressed by the control processor, the data valid checking circuit can then be checked. The remainder of the interface circuit can be assembled and the processor re-enabled, using a Digital Analysis System the Z80 bus and transfer lines can be monitored to check that data transfer it working correctly. When an attempt to access the board in Word or Long Word mode is made a bus error (event 0) should occur. The Z80 interrupt acknowledge sequence can now be checked, ensuring that the D-type flip flop is reset. To ensure correct operation of the memory a program should write all 256 possible values into each location and read back again to check that no corruption occurs. Finally the socket for the MSF radio receiver should be checked for power and ground voltage levels. If a problem occurs during the testing then the circuit diagrams should be consulted, the ESDL and ZAPing checked and the problem should be able to be traced to a simple wiring error or faulty chip. @section(Requirements for Software) When designing hardware the use that will be made of the system has to be considered, in this case the application is mind was to decode the MSF time signal and present it, decoded, to the APM system. Before finalising the design therefore the following requirements had been defined and met to ensure that the task of the software was not hindered by any hardware limitations. 1) The software would be required to work in @i(real time) sampling a serial input port, performing calculations and making decisions. Thus two necessities are identified: A reasonably fast microprocessor, and some form of simple serial input. 2) An accurate time base would be required for two purposes, firstly to allow periodic sampling of the input data and secondly to permit a free running clock to be provided to update the time between minutes and during a failure of the MSF signal. This identified the need to use a high frequency crystal oscillator which would primarily be divided down to a convenient frequency to interrupt the microprocessor but would also be suitable for driving the microprocessor itself. Thus the frequency of 3.2768MHz was arrived at and a packaged unit used to ensure greater accuracy. 3) A mechanism for communication with the APM system would be required for the transfer of data and software. This requirement is satisfied by designing the Z80 decoder board as a slave on the APM system bus and providing an area of shared memory which both processors can access. The final requirement of the system is that is makes the MSF data decoded available to the EUCSD local area network. Because of the nature of the design developed this is an area which has to be provided by the control processor of an APM system. To make this task easier for a system which might already be heavily loaded (filestores for example) the software which is provided on the Z80 decoder board will already decode the data into several formats suitable for most applications, from human readable strings to machine readable numeric variables. @chapter(HARDWARE CONSTRUCTION) The previous chapter discussed the design developed and the requirements for its software, the following sections describe the process of implementing this design on paper to a working system. This process follows three distinct paths, firstly the design developed as a circuit diagram must be translated into a format suitable for processing by the available hardware development tools, the ESDL design suite. Secondly, after processing by the ESDL suite, the resulting net list is constructed. This followed the usual department method of ZAP wiring the circuit onto extended double sized eurocards. Finally the resulting board must be tested in an APM system, this is where the first problems were encountered and these are detailed below. As indicated previously the MSF radio receiver was bought in as a kit of parts, the process that was followed in constructing and aligning this device is outlined below, and the initial, though not unexpected, problems encountered explained. Construction of the hardware was started in the third week of the second term as planned, the components having been ordered two weeks previously. The intervening time was occupied by Electrical Engineering Examinations. @section(ESDL and ZAPing) The circuit diagrams produced were translated into the Elementary Structural Description Language, ESDL@+(10)@comment(ESDL). This uses a high level textual format to describe the elements of a circuit and can then be processed to produce a net list and layout for constructing the design. The source ESDL description is included in Appendix B and a full list of components required is listed in Appendix C. The circuit was constructed on a double size extended eurocard, first by soldering in all the IC sockets, decoupling capacitors, and edge connectors, then by using the net list the circuit was wired up. The ZAP wiring method was used as it provides a useful prototyping medium, yet is also suitable for a limited production run. In addition it produces a low profile board, unlike similar speedwire or wire wrap systems. @section(Testing) For testing the suggested procedure outlined above was followed, the board being populated gradually as required and the signals monitored with an oscilloscope or the Tektronix Digital Analysis System. By disabling the bus watchdog, and ensuring that the board did not signal a transfer acknowledge, it was possible to test that all the logic was working as predicted. The first section of the design to be tested was the EUCSD bus buffering and control. This is a very simple control design as it only required to act as a slave on the bus. What it did have to do however was check that the board was being accessed in byte mode only, an attempt to address a word or long word is signalled as a bus error. Correct operation of the data strobe decoding was verified and the data bus buffering checked to ensure that only ever one byte (out of the four in a long word) is enabled onto the local bus. The board select logic was verified and the decoding of the lower two address bits from the data strobes checked. In order to fully test the bus transfer cycle the Z80 microprocessor and the board clock had to be present, so the rest of the board was populated with its components. Correct operation of the Z80 processor requires that there is a program running, a simple program which setup the processors vital functions (stack pointer, interrupts, etc) was therefore written and placed in ROM such that the Z80 would be active, the program merely looped doing nothing, on interrupts it branched and returned without any function. Using the Tektronix DAS the processors signals were checked and at a local level appeared to function correctly. The interrupt signal was functioning as predicted. @subsection(Fault Diagnosis and Amendments) As stated in the previous chapter the original hardware design constructed was not immune from bugs, that chapter concentrated on the design of the corrected hardware. Below the bugs discovered, the causes in the original design are described, and the cures implemented outlined. @subheading(Noise and Hazards) The first problem to appear was one of unreliable bus transfer between the APM control processor and the Z80 local memory, in the short term this appeared to be explained by noisy signal levels on the EUCSD bus, however the problem was in fact more complex. It is best explained by first considering how the bus transfer sequence was handled by the Z80 board. A bus transfer is initiated by the APM control processor as defined by the bus protocol@+(8)@comment(Working) and at its simplest level involves asserting the transfer request line, TRQL, on detection of this signal the clock board does a bus request on the Z80 which after its current bus cycle is complete releases its bus to tri-state and acknowledges the bus request. The EUCSD bus is then enabled onto the local bus and the transfer takes place, this transfer is acknowledged as complete when the slave (the Z80 board) asserts transfer acknowledge, TACL. Normally on completion the Z80 would then regain its bus for local processing, however it is desirable to hold the Z80s bus if the control processor had initiated an indivisible bus transfer, (Eg. Read-Modify-Write) this form of transfer is indicated by the ATML line on the EUCSD bus. My original design employed a simple asynchronous state machine to hold the Z80s bus while ATML was asserted, and this was where the problems arose. Asynchronous state machines by their nature are affected by noise or spikes on the signal lines, such that even a small glitch can get amplified through the machine. It is such a problem that afflicted the original design. What was happening was that the Z80 bus was being requested as normal, however a glitch on the bus signal lines caused the state machine output to temporarily negate, this was detected by the Z80 as an indication that it could have its bus back. However the Z80 had already acknowledged release of its bus which the state machine had noted, this signal then negated. The overall result was oscillation between the state machine and the Z80 bus request/acknowledge. To cure this problem an attempt was made to reduce the noise levels on the signal inputs to the state machine by decoupling them to ground with small value capacitors. This failed to reduce the glitches sufficiently to cure the problem entirely. In the long run the naive approach was taken and the entire state machine disabled, such that the Z80 bus request was made from the board selected line only. This had the unfortunate side effect of preventing the true indivisible bus transfer, and therefore precludes the use of the control processors semaphore operations. However it is felt that this was not to great a loss as the Z80 did not support an indivisible cycle itself and more elaborate semaphore mechanisms would have to be used anyway. The removal of the state machine however did solve that bus transfer problem. @subheading(Bus Cycle Timing) The second problem with the bus transfer was that the APM control processor could not write to the Z80 boards local RAM memory, an attempt to do so resulted in garbage being written and not valid data. The problem was made worse in that valid data could be written to the LED display controller and appear on the LED displays. Further the Z80 could write to the RAM with no problems. Initial thoughts were that it might perhaps be a slow RAM chip that was responsible (6116 devices are used), however the problem was not cured by simply replacing the chip. Closer examination of the signal lines to the chips was made, and using an oscilloscope triggered on either the local clock, or the chip select line, the activity of the data transfer could be monitored. At first all seemed to be in order, however it appeared that the chip select line negated before the write enable line. This was suspected as being something to do with the problem, but mentioning it to some of the department staff indicated that the write enable line should be checked to see that it negated before the data became invalid. This was done and indeed the data bus was found to be returning tri-state before the write enable was negated, the time period involved was of the order of 40 nano seconds, long enough for the RAM chips to latch invalid data. The problem here turned out not to be one of gate delays or noise, but rather a problem with the design of the bus transfer acknowledge circuit. What had been done was to simply enable the EUCSD bus R\WL line onto the local bus write enable line directly. This line is negated by the control processor at the end of a bus transfer. Closer reading of the protocol does specify that the transfer should not be acknowledged by a slave until all data is stable. What was happening was that the data was being latched into the RAM by the control processor, where in fact it should have been latched locally before acknowledging the transfer. This was done by the addition of an inverter and one NOR gate which ensured that the latching was done when the transfer was acknowledged and not when the control processor terminated the transfer. This solved all the problems with the hardware which now operates correctly as a slave in any APM system. @section(MSF Receiver Alignment) As the radio receiver was bought as a kit of parts the construction and alignment followed the suggested procedure in the accompanying literature, attached in Appendix D. No problems were experienced with the construction of the radio receiver, all the components being supplied and fitting the PCB correctly. When aligning the R/F characteristics of the receiver it was not possible to use a frequency counter as suggested in the literature as the amplitude of the signal to be calibrated was below the minimum sensitivity of the available counter. An oscilloscope was used therefore to set the oscillators and monitor the voltage levels as required. @subsection(Reception Problems) The receiver appeared to be functioning correctly when the test signals were monitored with the oscilloscope, however there were problems receiving any MSF data signals. This, the inability to receive an error free signal, became the most significant problem which held up the development of the MSF clock system for some time. After unsuccessful attempts at receiving the time signal in various locations within the machine halls the radio, plus a power supply unit, were taken to a south facing room on level 6 of JCMB in the hope that the additional height and remoteness from any electrical interference would help matters. After some minor adjustments to the receivers controls the LED indicator started to pulse positively once per second, with the occasional double pulse, as expected. A pencil and paper attempt at decoding the signal 'by observation' proved that indeed the MSF signal was being received (the time was early one Friday evening). @chapter(SOFTWARE DEVELOPMENT) The previous chapters have concentrated on the development work with a bias towards the hardware aspect, the other side of the project, the software, is now considered. With the hardware working by the latter half of the second term effort was switched to concentrate on familiarisation with the Z80 from a software aspect. The immediate goal was to produce a very simple program, using interrupts, to demonstrate the correct operation of the system. This was tackled by producing a simple counter, incremented on each interrupt, and displayed on the LED digits. All programs were to be written in Z80 assembler, not by choice rather by necessity as there was no high level language compiler available for the Z80. Even if there were such a compiler it is likely that it would have required certain run time library routines to be available, and unlikely to allow flexible handling of interrupts. The assembler used is one local to the Computer Science department and available on the APM systems. @section(Program Development) The immediate lesson learned from the above exercise was the need for some way of downloading software into the Z80 board for execution. Previously each new version was assembled and then blown into an EPROM for testing, this being rather time consuming and wasteful. To solve this problem firmware was written to reside permanently in EPROM on the Z80 board, and all development software would be downloaded into RAM for execution. This firmware was developed and working in a fairly polished form by the end of the second term. The features which it offered were designed to facilitate program development, providing such functions as downloading and execution of software, interrupt management so the program need not worry about enabling or disabling and jump vectors. Additionally routines were provided to read the input port, write to the LED display and communicate with the APM. To help with debugging a primitive ability to examine the Z80 processor registers was allowed but this could only return the registers contents at the last interrupt (every 5mS) as no single stepping hardware had been provided. It was within this environment that the first components of the final software was developed, and it is this final software that will be discussed. @subsection(Communication with Control Processor) The problem of inter process communication was considered as far back as the initial design stages and was resolved by making the Z80 memory space addressable through the APM system bus. This shared memory mechanism is the only communication route between the Z80 and the APM master processor, as such both processors must agree on some form of transfer protocol, and both must know the exact locations to be used. Additionally the APM master processor is constrained by the hardware to always addressing the memory as byte width transfers and so extra care is required when writing applications software. The communication protocol used in the development firmware is the same as that in the final MSF software package except that different memory locations are used and the format is more relevant to the application. The protocol and data format used in the MSF software is described below. The additional areas used by the development firmware were for simple byte length unidirectional transfers and did not employ any lockout mechanism necessary for larger data blocks. @subheading(Lockout and Semaphores) With two independent processors active simultaneously it is possible that both will wish to access the same block of data at the same time. This is fine if both processors wish to read the data, however should one wish to write to the data block while the other reads, then the situation could occur where the reading processor finds data which is in the middle of being updated. such a situation requires some form of semaphore operations to ensure that only one processor can access a given data block at any one time. The form of lockout used must be agreed before hand and known to both processors. The problem of lockout is similar to many problems found in operating system design and it was for such an application that the solution used here was developed. Known as "Peterson's Solution" it is the simplest of the known algorithms and uses only three variables. It is best described by the simple example code below. @begin(verbatim) @u(begin) @u(integer) c1:=1, c2:=1, turn:=1; @u(parbegin) process1: @u(begin) A1: c1:=0; turn:=2; L1: @u(if) c2=0 @u(and) turn=2 @u(then) @u(goto) L1; {Critical section} c1:=1; @u(goto) A1; @u(end) process2: @u(begin) A2: c2:=0; turn:=1; L2: @u(if) c1=0 @u(and) turn=1 @u(then) @u(goto) L2; {Critical section} c2:=1; @u(goto) A2; @u(end) @u(parend) @u(end) @end(verbatim) @section(MSF Clock Software) Following the development of suitable firmware the desired function of the system was considered again, that of acquiring and decoding the MSF time signal and maintaining a real time clock. This problem was split into two separate functions, the real time clock, and the acquisition and decoding of the MSF signal. The envisaged situation was that the clock should be completely independent of the MSF signal, but that its internal registers would be set by the decoder upon accurate error free reception of the signal. This approach has the immediate advantage of allowing two separate programs to be written and tested which can later be amalgamated. This time information must then be presented to the APM system in some fashion, and so a third presentation module is added to complete the overall system. The component parts of the software is shown in figure 6-1, the major components enclosed within dotted lines and the paths of communication shown as arrows. Below each of the major blocks are briefly described. @subsection(Internal Time Keeping) The central component of the system is the real time clock maintained in software. This clock is updated once every 200@+(th) of a second when the processor is interrupted, the internal clock registers are then updated once every 100@+(th) of a second. These registers range in span from hundreds of seconds up to century and each is incremented as required. The clock can be set by hand by writing into these registers, though this should really only be done by the Z80, knowing that it is not currently updating them. The default time (At power on say) is 1@+(st) January 1985 and will increment from this until the registers are set otherwise. @blankspace(4 inches) @begin(verbatim) @centre<@ux(Figure 6-1: Software block diagram.)> @end(verbatim) @subsection(MSF Data Acquisition) The diagram indicates how the Acquisition and decoding of the data is split into its component parts. The first module is called every 5mS under interrupt control and samples the state of the signal which will either be @i(high) or @i(low). By using a simple state machine a count is built up of the number of samples that the input has been in the same state, on a transition this count is saved in a buffer and a new count started for the new state. The state machine has four states, as in figure 6-2, so that some noise suppression is affected, a transition only being registered if it remains in the new state for at least two samples. On a high to low transition the next module of the decoding software is called. @blankspace(3 inches) @begin(verbatim) @centre<@ux(Figure 6-2: Noise Suppression state machine.)> @end(verbatim) The data that has been built up in the buffer is examined on each falling transition, usually once per second. The last 8 seconds are examined first to look for the framing code 2_01111110 which indicates that the minute has just arrived. If this code is not found then the routine exits, otherwise the rest of the data acquired is examined from second 17 to 51 plus the parity bits on the second level with the framing code. When deciding what the last to transitions represented they are checked to ensure that the sum of the two periods (@i) lie within 10 to 20% of the number of samples expected in one minute. A threshold value is compared against the low period and if greater then the result is '0', if less then '1'. The data for each of the six fields plus parity are shifted into temporary registers, these registers being marked as bad if the above check failed. Having now acquired the data and decoded it into the six BCD values the parity of each is checked against the four parity bits received, this checks that no single bit errors occurred in the data but cannot detect double errors or permit the correction of single errors. If this check fails then the data is effectively discarded and the routines return, if it passes however then the data which is still in BCD format is converted into decimal, further check being made for illegal BCD digits (A..F). Finally the new time is checked for integrity and validity, for example the day of month must lie within the range of days permitted for the given month so 31@+(st) June would be rejected, special care is taken over February. If the time is considered valid then the temporary registers are copied into the clocks internal register set and a copy of the new time made to the common area so that the APM master processor can find out when the time was last updated. Because of the problems experienced in receiving the MSF time signal the above algorithm was developed with a simulated signal. Using the IMP language software was developed which provided a stream of pulses, each representing a sample 5mS appart. This was fed into the state machine routine, again written in IMP, and the above algorithms tested for correct operation. Once the MSF signal was received reliably this IMP program was translated into Z80 assembler. This simulation proved to be a useful exercise as few problems were experienced when developing the Z80 software and as a result probably took considerably less time than it might have. @subsection(Presentation) The final area of the system software is the presentation of the time information to the main APM system. As already stated the communication medium was one of shared memory at known locations in store. Peterson's solution to the semaphore problem is used to control the access and the available information is as in the record formats below. Note the additional 'null' element of each record, this is necessary to ensure that the string variables start on an even word boundary which is necessary for compatibility with the APM IMP and PASCAL compilers. @subheading(Record Formats) @begin(verbatim, linewidth 7.5 inches) @u @u time fm (@u control1, control2, turn, null, hundred, second, minute, hour, day of week, day of month, month, year, century, BST) @u @u compact time fm (@u control1, control2, turn, @u (21) time) @u @u full time fm (@u control1, control2, turn, null, @u (55) time) @u @u last update fm (@u control1, control2, turn, null, year, month, day of month, day of week, hour, minute) @newpage @@16_XXXX0800 @u(record) (time fm) A @@16_XXXX080E @u(record) (compact time fm) B @@16_XXXX0828 @u(record) (full time fm) C @@16_XXXX0864 @u(record) (last update fm) D @end(verbatim) 'XXXX' is the address selected by the rotary hex switches on the front of the Z80 decoder board, currently these have been set to '00F8' and it is likely that this will remain so. @i(Time Fm) contains the raw time as known by the clock board, essentially this is just a copy of the clock's internal register set. The @i(day of week) element ranges from 0..6 (0 = Sunday) and @i(BST) is 1 in summer and 0 for GMT, the other fields contain the values that would be expected. @i(Last Update Fm) is compatible with the time format but contains less information, the time being updated on every minute. @i(Compact Time Fm) and @i(Full Time Fm) present the time in a human readable format decoded from the internal registers by the Z80, this is to remove as much pressure on the host APM as possible, when reading the strings always ensure that it is copied a byte at a time. An example output from each of there records might be: @begin(verbatim) Full Time: Thursday 30th May 1985 19:36:16.58 BST Compact Time: 30/05/85 19:36:16.58 Raw Time: 1 19 85 30 4 19 36 16 58 Last Update: 19 85 30 4 19 27 @end(verbatim) @subheading(Access Protocol) When the APM wishes to access these records it must first indicate its desire to do so by grabbing the semaphore for the appropriate record. Peterson's solution is used and the following code indicates how a master processor should operate on the control fields of the record. @begin(verbatim) R_Control2 = 0 R_Turn = 255 @u(while) R_Control1=0 @u(and) R_Turn@r[#]0 @u(cycle) {Could (should!) employ some timeout mechanism} @u(repeat) {We now have access to record 'R'} {Copy it and release semaphore} @end(verbatim) @newpage When the master has finished reading the information from the record it should release the semaphore with the simple operation of: @begin(verbatim) R_Control2 = 255 @end(verbatim) Note that the master processor should always be reading from the record, although there is nothing to prevent writing to it, it is meaningless to do so as the Z80 never reads them. Also it is advisable to copy the record into a local copy and then operate on it, rather than use the shared copy, thus the semaphore can be released as quickly as possible. The master processor @u(MUST) release the semaphore, if it does not then the Z80 processor will hang when it next attempts to grab it (which it does every 100@+ of a second) and the system will stop. An arrangement to prevent this could be added to the Z80 software by employing a time out mechanism when attempting to grab a semaphore and on time out a controlled reset performed. Such a time out mechanism has been used in the server software in the filestore where it is vital that the filestore does not hang! The current version times out after 50 attempts at grabbing the semaphore after which it releases its attempt and sends an error message back to the user. @chapter(INTERFACING to EUCSD LOCAL AREA NETWORK) The successful completion of the main project goals allowed an expansion of the original requirements to include interfacing the system as a service to the EUCSD local area network. There are two considerations here, firstly where should the system be located (as a new server, within existing filestore, etc) and secondly what information should be made available and how should it be presented. @section(Server Machine) After ruling out the option of a dedicated APM acting solely as an MSF time signal server two possible locations for the decoder board were considered. The obvious housing is in one of the existing filestore APMs, however this is open to argument as some consider that the filestore should be just that and nothing more. The alternative solution is to house the board in any ordinary APM which can be used for any normal purposes, but which has a background job listening for a request on the ethernet for the time, this becomes a 'hidden' server. In the end both systems were tried. @subheading(A hidden server) The first server was developed within a standard APM system, this exercise being useful as it allowed the safe development of the ether transfer mechanisms and the Z80@m(#$)Control processor communication. The task of the server was to await a request from a user and then copy the time records from the clock decoder into a local buffer then sending the buffer contents back. The development server was used to discover how the information might best be presented to a user and the results progressed from a simple string being returned to the final record formats presented above. To allow this server to run in parallel with any normal user programs the mechanism by which a waiting job can be awoken by an incoming ether packet was used. The APM system software can be told that a routine exists at a particular address in store, and that this routine is to be called when a packet arrives on a selected port. The routine must be careful to return with all the processor registers unaffected and must not call any external routines as this might affect the correct operation of a user's program. For these reasons the server software was written in 68000 assembler, the module being preloaded into the APM when booting. @subheading(A filestore server) When investigating the possibility of using one of the existing filestores as a server two options were available. The first was to use the mechanism for special files, known as $:files, the second was to provide an additional 'port 0' facility. Special files are files that are known to the filestore software but which are not physically stored on the disk, they are created only as required, an example being $:UNOS which returns a list of currently logged on users. The proposal here was to provide an additional special file, $:MSF for example, which would return the contents of the MSF decoder board's records. The second alternative, a new port 0 facility, would operate in a similar fashion as the 'hidden' server, a user sends a byte to the filestore's port 0 identifying the facility required and awaits for the reply. In terms of modifications to the existing filestore software both are equally simple, requiring the inclusion of a service routine to acquire the information from the decoder board plus the addition of a couple of lines of code to the appropriate section of the existing software. However from an end users point of view it is far simpler to request the information as a port 0 facility than as a $:file which requires that the user be logged on to the server filestore. Thus the final installation is as a new port 0 facility. The routine which has been included in the filestore software is attached in appendix F, it follows the protocol defined above to grab the semaphores and copy the data from the decoder board, returning the information concatenated into a string which can then be forwarded to the user over the ethernet. @section(User Access to MSF Time) Together with developing the server software consideration was given to how the data should be presented to an application program in a users environment. It is always possible for a program to interact directly with the server and this is simply a case of writing an ether packet to port 0 of the server. This packet should contain only one byte which identifies the facility required, the MSF time facility being selected with the number 11. The server then returns the time information which is the contents of all the decoder's records. It is preferable however for there to be a standard routine which could request and receive the time and present it to an applications program in a user friendly format. Such a routine has been written and exists as an include file for IMP programs, this is included in appendix G. This routine requires only one parameter, the network address of the MSF server machine (this is currently filestore 'BRAVO' (15)) and returns the time as a record with the following elements, it is recommended that this routine be used whenever possible. @begin(verbatim, need 8) @u format time fm (@u hundred, second, minute, hour, day of week, day of month, month, year, century, BST) @u format msf fm (@u state, @u (time fm) current time, @u (time fm) last updated, @u (21) compact time, @u (55) full time) @end(verbatim) Note that this routine should be called once only and the information copied into a local record from where each element can be removed as required. If this is not done then the program could end up requesting the time from the server for each element as it is read by the program. This is inefficient and could return unpredictable results where the time is updated half way through reading all the elements, as well as putting a strain on the server. This routine has now been incorporated into the system command TOD (Time Of Day) which returns the full MSF time by default, parameter options allow selection of the format printed and the last updated time can also be read. @chapter(PERFORMANCE and OBSERVATIONS) It is appropriate now to comment on the project as a whole, and to look at the performance of the finished product. Some observations on the MSF signal have been made now that the system is up and running and this is followed by brief comments on how the system might progress. @section(MSF signal) Throughout the life of this project the largest problem has been the reception of the MSF time signal and although the current situation works satisfactorily there is room for improvement. Currently the receiver is located in the technicians workshop at the top of its south facing window, a cable leads from there, under the floor tiles, to filestore 'BRAVO' where the decoder board is currently housed. The choice of this location is more one of convenience than its suitability for the reception of the MSF signal. Periods of erratic behaviour have been observed, sometimes several hours in length, when it is impossible to decode valid data. More suitable sites would be ones remote from any computer hardware interference and facing south, height being an additional benefit. Such sites were found when searching for a suitable location for the radio receiver but in the short term are not being used. The problem with these locations is the distance from the server machine as long cables could affect the condition of the signal as seen by the processor, it is the proximity of the current location that makes the current site attractive. @subheading(Time setting & Accuracy) A problem with an error prone signal, or one with ill defined transitions is that of precisely setting the internal clock registers having detected and decoded the information correctly. The problem is that the first second of of every minute contains the fast code transmission, this starts to appear 25mS after the falling edge which defined the minute. If the signal is noisy, and the cable length is long, and the radio is not as finely tuned as it might be, then the transitions become ill defined such that what was meant to be a 25mS gap becomes much less. As part of the data acquisition algorithm used a noise suppression system requires that transitions must remain in the new state for at least 10mS for it to register, thus it is possible (and has been observed to occur) that the decoding software does not see the falling pulse defining the minute until after (or within) the fast code transmission. The clock might then be set up to 330mS slow. When the Z80 clock has to run for long periods without being updated from the MSF signal then the accuracy of the clock is dependent on the quality of the crystal oscillator. The current oscillator is a hermetically sealed unit of 3.2678 Mhz which was chosen so that there would be as little human error involved when setting up the system. However the implementation which is now in service has been observed to run fast when not updated for long periods, the deviation being of the order of a couple of seconds in twelve hours, this could be corrected by obtaining a higher tolerance oscillator or increasing the frequency of the source and using a larger divider. @section(Concluding Thoughts) For future development of the system it might be worthwhile making some modifications to the decoder software, the following items being worth considering. The communication protocol between the APM master processor and the Z80 require that a semaphore be grabbed, currently the server software times out if it cannot gain this after a while, this should also be the case for the Z80. Upon a time out (which should never occur) the clock system could attempt some form of recovery to get the communication going again. The second addition is a tightening up of the validity checks which are made to the data before the clock registers are set, the culprit here is that the parity bits only allow the detection of one bit errors in each block. Consider the case where the current year is 1985, but two errors occurred which flipped two bits to turn 85 into 01, (BCD representation is used). The current software concludes that this is valid, deduces the century to be 20 and sets the year to 2001, again this has been observed. An additional check could adopt the policy that the new time must be within a certain time span of the old time, and be incremental before setting the registers. Finally for completeness it would be nice to decode the DUT1 information, this being ignored by the current software. This would require a slightly different decoding technique which would work forward from the minute pulse and search for double pulses, the additional complexity sould not be that high as the structure of the existing software permits easy expansion. @chapter(CONCLUSIONS) This report has presented in a more or less chronological order the effort put into completing the project as defined. Work was started early in the first term and as a result was completed satisfactorily early in the third term, this enabling the system to be interfaced to the network as an expansion to the project. Three problems hindered the development work, two hardware bugs with the design which took some time to fix, and the problem of aligning the radio and receiving the MSF time signal reliably. This latter problem was the greatest stumbling block, at one point it appeared that the signal would have to be simulated to allow testing. This did however encourage the simulation of the signal and decoding it in the high level language IMP to develop the acquisition and decoding algorithm, this proved to be an invaluable exercise and made the transition to Z80 assembler all that easier. Fortunately the problems with reception were overcome by moving to an interference free area and so permitted successful completion of the project. The sources of all software developed can be found in the username CLOCK on filestore 'BRAVO'. @newpage @unnumbered(ACKNOWLEDGEMENTS) I am grateful to all those people who helped me throughout this last year at Edinburgh, special thanks go to the following for all their comments and suggestions related to this project. John Butler, as my supervisor who guided me through the project and liaisoning between myself and other staff members. George Ross & Rainer Thonnes, without whose help and co-operation the MSF time information might never have appeared as a network service. Peter Lindsay & Rainer Thonnes, for their help when debugging the hardware problems. @blankspace(1.5 inches) @begin(text, facecode S, spacing 1.5) This report was prepared using the EMAS implementation of the SCRIBE document production system and printed on a Xerox X2700 laser printer. Diagrams, where not otherwise credited, were prepared using the DRAW graphic design package. All software was developed on the Edinburgh University Computer Science Department's Advanced Personal Machine. @end(text) @newpage @unnumbered(BIBLIOGRAPHY) @begin(enumerate) BIH: @i