{"id":3172,"date":"2011-10-31T12:57:55","date_gmt":"2011-10-31T12:57:55","guid":{"rendered":"http:\/\/www.polymathperspective.com\/?p=3172"},"modified":"2019-07-08T17:20:42","modified_gmt":"2019-07-08T17:20:42","slug":"brian-flint-using-eproms-and-pics-part-1","status":"publish","type":"post","link":"https:\/\/polymathperspective.com\/?p=3172","title":{"rendered":"Brian Flint: Using EPROMs and PICs (Part 1)"},"content":{"rendered":"

After briefly encountering EPROM processors when working for Sinclair Research Ltd in Cambridge, hardware electronics designer, Brian Flint, began using the processors to solve design problems, later using PIC devices for similar purposes. He explains how he found practical, and occasionally unique, ways to exploit both the EPROM and the PIC, and discusses their relative pros and cons.<\/strong><\/p>\n

\"\"

Brian’s box of EPROMs. The label covers the light hole to prevent accidental data loss<\/p><\/div>\n

The acronym EPROM stands for Erasable Programmable Read Only Memory, and refers to a memory chip used in electronics from the early 1970s onwards. EPROM memory chips have an advantage over standard microchips, in that they can be removed from their sockets and programmed to act as Read Only Memory devices. It is also possible to wipe their memory of data \u2013 by shining ultraviolet light through a tiny hole on the top for a certain length of time \u2013 so that they are can be programmed afresh. This characteristic enables engineers to update their program data whenever necessary.<\/p>\n

Brian Flint, who worked at Sinclair Radionics Ltd from 1971 to 1979 and then at Sinclair Research Ltd as project leader for the hardware design aspect of the ZX80 and ZX81 home computers, first encountered EPROMs during his Sinclair days. But it was as chief design engineer for video duplication specialists, Dwight Cavendish Ltd, that he began incorporating them into his design hardware. He explains when and how he became familiar with the technology.<\/p>\n

\u201c<\/strong>I became aware of EPROMs when they first came out, I suppose, in the early 1970s, but I think my first experience with them was when I was programming some memory devices at Sinclair. We had an EPROM in the ZX80, although for the production models it was probably replaced by a standard ROM, which you can\u2019t reprogram, but I can\u2019t quite remember.<\/p>\n

\u201cWhenever the ZX80 program was changed the EPROM also had to change because it contained the program. The microprocessor in the ZX80 ran off of the program so the most convenient thing was to put the code in an EPROM because you can reprogram them. If you changed anything \u2013 if there was a bug fixed \u2013 it would mean a new EPROM or update. I didn\u2019t write code then, so some software person would release the update and I would make sure the ZX80 I was testing had the latest version. I must have had a master and copied the program from that but I can\u2019t really remember much about it now.\u201d<\/p>\n

It was a few years later, while working for Dwight Cavendish Ltd in St Neots, that Brian encountered a problem which he decided would be best solved by using EPROM processors.<\/p>\n

\u201cWhen I was at Dwight Cavendish we were using an infrared remote control to operate multiple domestic VCRs,\u201d Brian recalls. \u201cWe were breaking open remote control handsets, taking the boards out and putting them into this little box. Then if we hit the record button on the control panel, it would effectively close the switch contracts and trigger record on this board. The board would then generate the record signal electrically, and we would take that electric signal and spread it over to lots of infrared transmitter diodes which controlled the rest of the VCRs.<\/p>\n

\u201cThe problem was that customers had many different makes of VCR. There was Sanyo, Panasonic, Akai, Sony \u2013 all sorts of different makes \u2013 and some VCRs from the same manufacturer had different codes and hand units. We continually had to break remotes open and trace out their circuits to work out how to wire them into our interface, and it was getting impossible because it was not easy to connect to some of these things.<\/p>\n

\u201cSo I thought what we needed to do was decode the signal that came out of the hand units and generate it ourselves with a little program. To make that possible we needed some means of storing all the different manufacturer\u2019s codes. It is the same sort of thing you get with a universal hand unit that you can buy now, which can be programmed with all the different manufacturers\u2019 codes. So basically I was doing that.<\/p>\n

\u201cSo I would get hold of a hand unit, press the various buttons on it and use an infrared light sensor to catch the signal and work out what all the timing parameters were. I would measure the time pulses and I had a little code that I wrote that would recreate that signal.<\/p>\n

\u201cEventually we were sending customers an interface with a little switch on it and we gave instructions to switch it to Position 1 for Sony, 2 for Panasonic, 3 for Akai, or something like that.<\/p>\n

\u201cSo there was a need to solve a problem and that forced us to make this little board. That was mainly to control VCRs, but once I\u2019d got the program working for that I expanded into writing code to do other things. Once you\u2019d got the knack of how to do it you can expand it to all sorts of areas.\u201d<\/p>\n

<\/div><\/div><\/div>
\"\"

A promotional picture taken of Brian during his Dwight Cavendish days<\/p><\/div>\n

Method and Equipment<\/strong><\/p>\n

Before Brian could start working with ERPOMs he needed to get hold of the necessary equipment to program them. The device he chose was a Dataman S4 handheld programmer. The device, which is about the size of a large pocket calculator and originally shipped with a 95-page manual, is equipped with a ZIF (Zero Insertion Force) socket and accompanying lever for attaching the EPROM that is to be programmed, 48 soft keys and a small, four-line, 80-character, LCD display. The user can either enter their code using the on-board keypad, or connect the S4 to a computer using an RS232 cable and download their program data from the computer.<\/p>\n

Brian explains a little more about how he worked with the device.<\/p>\n

\u201cI would write the code in what\u2019s called assembler language, and I would assemble it, if you like, in my head. When I say I\u2019d do it in my head I mean I would write it out using a pencil and paper! Then I\u2019d then convert that into what is called the object<\/em> code, which is a lot of hexadecimal figures; so I would work out what the hexadecimal code was for each line and hand-punch the numbers into my Dataman S4 programmer using its mini keyboard.<\/p>\n

\u201cI mostly did it that way, rather than use an assembler on a computer, because the programs weren\u2019t all that big and you could enter many hundreds of lines of code in a few hours. Then I would stick a blank EPROM in, burn it and then test it.<\/p>\n

\u201cThe S4 was about \u00a3500, I think, and I bought it through work. I could spend that sort of money for R&D purposes and didn\u2019t have to ask permission. Of course, when I started using the Dataman in the early 1980s, if you wanted to buy a computer they\u2019d cost about \u00a31200, which was a considerable amount in those days as the cost of living has gone up by about three-and-a-half times since then. Plus you would have to get all the software to go with it to do what you needed, and there was the learning curve too \u2013 you had to learn all this other stuff and get it all working together.<\/p>\n

\u201cWhen you got hold of a little Dataman, on the other hand, all you needed to do was read the instruction book, work out what you wanted to do and get on with it. You ended up with the same product whether you used a Dataman or a computer; it was just a means of creating the code, that\u2019s all. You could even download code to it from a computer rather than type it in using the little keyboard.\u201d<\/p>\n

When Brian began working with EPROMs, he had had no formal training in software code programming, although he had learnt a little bit about it over the years. He first dabbled with code when working for Sinclair Research in King\u2019s Parade, Cambridge, just after Clive Sinclair started up his new business which would soon produce the Sinclair ZX80, ZX81 and Spectrum computers.<\/p>\n

\u201cI\u2019d been fiddling around with a little bit of code when I was at Sinclair Research,\u201d recalls Brian, \u201cusing the Science of Cambridge MK14 board. The MK14 was something that Chris Curry had been working on but he\u2019d moved out to set up Acorn by then. At the time we moved into King\u2019s Parade, Sinclair Research hadn\u2019t made anything, but there were customer returns of the MK14 so I was fixing them. While I was doing that I\u2019d fiddle around with them \u2013 program them \u2013 and learnt a bit. I was just messing around with code for my own amusement, really.<\/p>\n

\u201cThe purpose of the MK14 board was to be an educational thing. If you wanted to make a digit flash on and off, for example, you could use the MK14 to write a little routine to make that happen. It had a little display on it and you could enter some data in hexadecimal form, I think, and get it to do some silly little routines \u2013 little simple things.\u201d<\/p>\n

<\/div><\/div><\/div>
\"\"

Dataman S4 EPROM programmer. Thanks to Daniel Smith at Dataman for providing this image<\/p><\/div>\n

Getting Started<\/strong><\/p>\n

Before Brian could start writing code for his Dwight Cavendish projects, he first had to select the most suitable EPROM to program, and there were a number of products to choose from. He explains what he used and how things progressed from there on.<\/p>\n

\u201cI had to choose the processor and the one I picked was an Intel 8032 8-bit microprocessor, I think. I simply chose that one because it was supposed to be good. So I got a book on how to write the assembler language for it, worked out how the memory was organised and what the various basic instructions were.<\/p>\n

\u201cWhen I\u2019d read that through I started applying the problem I had to it. Once you have an objective to aim for, it is odd how very quickly you find you can do something. If you are just aimlessly messing around you will only go so far. But once you have a specific task in mind, within a matter of weeks, or maybe less, you can get something up and working. You might have do a little bit of debugging and further work on it but you\u2019d be amazed how fast you progress.<\/p>\n

\u201cThere are different assembler languages for each microprocessor. It\u2019s like Heinz 57 varieties \u2013 they\u2019ve all got different ways of doing things \u2013 but there are a lot of things they have in common too. There was a paper-back book I bought back in the 1970s, all about how microprocessors work, which I\u2019d read through, and that really gave an insight into it all. You\u2019ve just got to learn how microprocessors work and become acquainted with software to a certain level.<\/p>\n

\u201cUltimately the processor runs off of noughts and ones, but you start off with writing things down in a semi-English way. If you wanted it to load a value into a memory location you might actually use the word Load<\/em> and then you have some way of identifying the memory location. Then you\u2019d tell it to move to the next memory location. You might want to load the memory contents at that address into the accumulator, so there would be an instruction for that. So you look up the hexadecimal conversion for that type of load from that type of memory place. Then there is an instruction which loads the accumulator into memory and that will be slightly different.<\/p>\n

\u201cThe instruction book gave you an example and you\u2019d just follow that. You very quickly learn what they are because you are using them all the time and eventually you learn all the codes off by heart.\u201d<\/p>\n

Divide and Conquer <\/strong><\/p>\n

Brian explains how he decoded the signals sent by the infrared VCR hand controls and the method he used to deal with that data when creating code for the EPROM.<\/p>\n

\u201cWhat I did for the remote control code was devise what you might call an algorithm, or at least a way of splitting up these infrared pulses. I think I was using multiples of 50 microseconds. I would measure the width of a pulse, which was the length of time the infrared transmitter would be lighting up for. Then I would calculate how many times 50 microseconds went into it. So if the pulse was one millisecond there would be 20 lots of 50 microseconds going into it. I would enter 20 into a data table, or rather the hexadecimal value for 20, and I\u2019d build up this table of data.<\/p>\n

\u201cThe program would basically run through, get a value and say to itself, \u2018I\u2019ve got to light the infrared beam for 20 lots of 50 microseconds.\u2019 There would be a little loop that counted 20 lots and then switched the LED on. After that it would get to the next one and say \u2018Oh, I\u2019ve got to switch it off for this amount of time.\u2019 So I had a little system I worked out for measuring times.<\/p>\n

\u201cIt would know when it had got to the end of the table because there would be some marker. There might be more pulses in one type of system than another, in which case when it got to the end there would be some code that told it to repeat the whole lot again. For example, the instruction would tell it to repeat five times, or something like that, even though the user pressed the button once.<\/p>\n

\u201cAnd in the code there would be a switch that pointed to the beginning of the relevant data table relating to the particular operation or VCR. There were codes for stop, rewind, play, fast forward, eject and I\u2019d worked them all out and had them sitting in a certain position relative to one another in a table.<\/p>\n

\u201cA good part of the EPROM was storing data while another part of it was actually running the code. So the code would reside in one part of the EPROM, the program in another.<\/p>\n

\u201cIt was all pretty simple in a way. Once you had worked something out in your head you could write a little program for it which wasn\u2019t terribly difficult.\u201d<\/p>\n

Now that most of us are accustomed to viewing data on a large monitor screen, it is hard to imagine how engineers managed to check code for errors on a screen as small as that of the S4. Of course, there were ways, as Brian explains.<\/p>\n

\u201cYou are making errors all the time but if something doesn\u2019t work you can spot it. Debugging software can be done in different ways. You can make the code run a little way through and then deliberately stop, and if it continuously crashes in that section you know roughly where there is a problem. But if it can run that bit of the code you know the section is fine.<\/p>\n

\u201cOr you can enter some code so that when it gets to a certain point it flashes a little LED on and off and then you can visually check that the LED is flashing. So you do little tests and develop tricks to find out if it is running so far and find out if it manages one bit but misses another.<\/p>\n

\u201cYou can also test a lot of things by looking at the signal on an oscilloscope to see if the waveforms looked more or less right. You know what you are after.\u201d<\/p>\n

<\/div><\/div><\/div>
\"\"

It is always useful to label chips<\/p><\/div>\n

EPROMs in Action<\/strong><\/p>\n

Once Brian realized that EPROMs were a great way to solve certain electronic design problems, he began using them more and more. By working in this way, the software and hardware were being developed in unison, and this meant that the use of both technologies was optimised. Brian describes how his work with EPROMs progressed.<\/p>\n

\u201cWhat happened was the entire product range of the company became microprocessor based rather than just logic, so I started putting microprocessors into everything. I\u2019d usually have one unit communicating with another via a RS232-type control system.<\/p>\n

\u201cRS232 is a protocol for sending 8-bit word data. It\u2019s a standard way of formatting data and you can put it into a dumb terminal, as we call it, so it will read the data up on screen so you can debug it easily. So in our video duplication systems, for example, we had lots of interconnected VCRs and I\u2019d be using that communication system to connect them. As well as RS232, I also used I\u00b2C, which is another serial communication format, devised by Philips. It communicates in both directions up one wire, so it is bi-directional and doesn\u2019t have a separate clock.<\/p>\n

\u201cIn practice, you have something that sends out a signal over I\u00b2C and when it has finished sending out that stream, it sits and waits for a reply. When the reply comes in it sends again. So using that system connected devices can communicate with each another and send information.<\/p>\n

\u201cUltimately all the products, up to a very sophisticated level, were done like that. To do automatic quality control I had a load of boards communicating with a PC, which was controlling the video machines. I was reading signals off of VCRs, doing an A-D conversion, sending it to a computer which would draw pictures of the RF signal and audio levels and that was all being stored in a Microsoft Access database. It could test up to 1000 tapes an hour automatically.<\/p>\n

\u201cIn a system there might be 10 to 15 different products all with different codes in them, all communicating with each other and with a PC, using a high-ish rate of data transfer. That\u2019s what it all led up to after eight or 10 years of progress.\u201d<\/p>\n

The video duplication systems made by Dwight Cavendish were installed in countries all over the world, which meant that Brian was often flying abroad to sort out installation issues and oversee product updates. On such occasions, he found it very helpful to be able to reprogram EPROMs on site using the eminently portable Dataman S4. He recalls the time he was working at Fuji Magnetics in Germany, where a system involving Sony VCRs needed on-site tuning.<\/p>\n

\u201cThat was a semi-automatic system for video duplication. It was controlling these one-inch tape machines via an RS424 remote control. I didn\u2019t have one of those exact VCR models in the lab at work to test my code with, so I tested it on another machine that had a similar sort of protocol. Using that I wrote the basic code but wasn\u2019t certain if it would fully work with the model Fuji Magnetics were using because there are always differences between machines and they can respond slightly differently. For example, there was a Sony protocol that controlled Sony machines, but the individual models have different response times and supplementary control signals. We could control our Sony VCR in a certain way but another machine, which is reeling big one-inch tapes around, will have slightly different dynamics.<\/p>\n

\u201cMost of it had been tested but there were some slight unknowns and I didn\u2019t know how it would work until the system was connected up to the machines they were using. When I got out there I found that most of what I had done was working but there were some little hitches and I had to try and figure it out on the spot and then write some code there and then, which I managed to do.<\/p>\n

\u201cI took some blank EPROMs with me but when I had used those up I needed them wiped clean so that I could reprogram them, and Fuji Magnetics happened to have an ultraviolet box which could wipe the contents.<\/p>\n

\u201cI also took the Dataman with me and all my code, which was hand-written on sheets of paper and just kept in a folder. I always liked to have a master code to refer back to so I had a lead pencil with a rubber on the end and anything that got changed I would rub out on the master sheets and re-write in so that I could see exactly what I\u2019d done. I was constantly buying Papermate non-stop pencils with a rubber on the end \u2013 I couldn\u2019t exist without one of those!\u201d TF<\/em><\/p>\n

<\/div><\/div><\/div>
\"\"

One of Brian’s working drawings, showing lots of rubbing out<\/p><\/div>\n

Part 2 of Using EPROMs and PICs can be found here: Part 2<\/a>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"

[…]<\/p>\n","protected":false},"author":1,"featured_media":2403,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[71],"tags":[],"_links":{"self":[{"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/posts\/3172"}],"collection":[{"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3172"}],"version-history":[{"count":3,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/posts\/3172\/revisions"}],"predecessor-version":[{"id":3745,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/posts\/3172\/revisions\/3745"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=\/wp\/v2\/media\/2403"}],"wp:attachment":[{"href":"https:\/\/polymathperspective.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/polymathperspective.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}