Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
“If you haven’t tested it, it doesn’t work”
When I started this blog, I intended to write about more than displays and include some of my personal IC history. Today’s story is about Derek Roskell of Texas Instrument’s who led the UK-based design teams I worked with between 1979 and 1997 on a number of the most complex I.C.s done up to that point including the 9995 16-bit CPU, 34010 and 34020 Graphics CPU’s, and the extremely complex 320C80 and 320C82 image processors with a 32-bit RISC CPU and 4 (C80) and 2 (C82) advanced DSP processors on one chip. Every one of these designs quickly went from first silicon to product.
Having one successful design after the other may not seem so special in today’s era of logic synthesis and all the other computer tools, but back in 1979 we drew logic on paper and transistors on sheets of frosted Mylar plastic with color pencils that then were then digitized by hand. We then printed out large “composites” plots on giant flat-bed pen plotters (with each layer of the I.C. in a different color) and then verified all the circuitry by hand and eye (thank goodness by the mid 1980’s we got computer schematic verification).
In those days it all could go very wrong and it did for a 16-bit CPU call the 9940 and a spinoff version the 9985 that were design in Houston Texas in 1977-1978. It went so bad that the both the 9940 and 9985 were never fully functional, causing the designer to be discredited (whether at fault or not) and many people to leave.
In the wake of the 9940/9985 disaster, in 1979 management pick me, the young hotshot only 1.5 years out of college, to lead the architecture and logic design of a new CPU, the TMS9995, to replace the failed TMS9985. There was one hitch, they wanted to use a TI design group in Bedford England. So after some preliminary work, I packed up for a 6 month assignment in Bedford where I first met Derek Roskell.
To say Derek is a self-deprecating is a gross understatement. The U.S. managers at TI at the time were more the self-assertive, aggressive, “shoot from the hip,” cut corners (which resulted in the 9940/9985 debacle) and generally didn’t take well to Derek’s “English working class” (said with great affection) style with the all too frequent laugh at the “wrong” time.
When I first met Derek he was this “funny old guy” who at had worked on “ancient” TTL technology. He was around 40 and seem like an old man in a world of engineers in their 20’s and early 30’s who he led. As it turned out, Derek was the steady hand that guided a number of brilliant people who worked under him. He made sure my “brilliant” architecture and logic design actually worked. You don’t have one successful design after another, particularly back then, by accident.
Upper management was always pressuring to get thing done faster which could only be accomplished by cutting corners. They called Bedford a “country club” for resisting the pressure. Derek was willing to take the heat and do things the “right way” because he understood the consequences of cutting corners.
For most engineers fun part of engineering is doing the original design work. That is the “creative stuff” and the stuff that gets you noticed. Also most engineers have big egos and think, “of course what I designed works.” But when you are designing these massive I.C.’s with hundreds of thousand and later millions of transistors, even if 99.99% of the design is correct, there will be a hopeless number errors to debug and correct. Most of what it takes to make sure a design works is the tedious process of “verification.”
A couple of months back I had a small reunion in Bedford with some friends from the old days including Derek. Everyone remembered Derek for one thing he constantly chided the designers with, “If you haven’t tested it, it doesn’t work.” Pretty good advice.
Epilog
TI, like most companies today, in their search for “shareholder value” closed the large Bedford UK site around 1995 but still kept Bedford MOS designers who had so many proven successes and moved them to a rental building Northhampton. Through the years TI kept “consolidating/downsizing” and finally 2011 it shut down the last vestiges of their design operation in England and losing a number of extremely talented (and by then) senior people.
Below is a picture taken of the design team in Bedford that worked with me on the 320C80.
A nice read, Karl, very enjoyable. I remember one guy from TI Bedford, named (if I remember correctly) Colin Hinson. Maybe the name is familiar to him. IIRC, he designed Teletext decoder chip-sets, but he was a digital wizard. He told me that at one point there were a lot of TI-99/4As knocking around in Bedford. He had one at home, and he was annoyed at the 4A’s ‘crazy’ architecture, where they shoe-horned a 16-bit TMS9900 onto a board that was intended to take the ill-fated TMS9940. He showed me a 4A mother board that he had “fixed”. He had actually taken a TMS9995, mounted on a 9900-sized PCB, with a few PALs/GALs on it and a clock crystal. The TMS9900 was removed from the mother board, a socket fitted, and the board (which had long pins on it) was plugged in in its place! It worked like a champ, and was a good four times faster than the TMS9900!
Thanks for the memories!
Mark,
Thanks for the kind words. You may know my first device with TI was the TMS9918 which was the display chip for the 99/4A (as well as Colecovision and Japan’s MSX computer). TI was working on a lower cost (but much faster) 99/2 and a higher end 99/8 computer based on the 9995 but neither product made to market before TI pulled the plug on the Home Computer. The TI home computer architecture was terrible with the 9900 retrofitted into the 9985. In addition I was told that everything when through GPL originally “Games Programming Language” but later changed to the more politically correct with management “Graphics Programming Language”.
GPL was in essence the opcodes for a custom CPU that the home computer group wanted to design but got nix’ed. The GPL interpreter ran out of the fastest local memory (the instructions in high speed ROM with 256 bytes of local data RAM), but the programs with the GPL codes were stored in the 9918’s DRAM. It was a terribly slow process to fetch GPL from the 9918’s DRAM, interpret them into 9900 assembly, and then execute an instruction. The whole process was inherently very slow and made the 9900 look bad. When you ran Basic on the 99/4A, it first was translated in GPL and then converted into 9900 assembly code.
TMS9918 was also used in Sega first home console (SG-1000) and later served as a base to design their own 8/16-bit consoles VDP (Master System, Game Gear, Genesis). It seems like they were designed by japanese companies (NEC initially then Yamaha) and it’s surprising how they kept your initial design (CPU interface, Sprite pre-processing, Pattern nametables,…) pretty much intact, only with expanded capacity (more access cycles, more planes, more sprites,…) or additional features (DMA circuitry, CPU write FIFO, color RAM,…).
I know it has been a long time but do you have some insight about Sega’s VDP design or maybe some interesting stories from that time ?
Thanks for the trip down memory lane. The 9918 was used on all kinds of products including the Colecovision and The MSX Computer in Japan. The MSX computer was a product of ASCII Microsoft (sort of Microsoft Japan but run rather independently as I remember it — yes, kind of a strange relationship, the got in early on the Microsoft bandwagon). The head of ASCII Microsoft was pushing for a more advance 9918 for a new version of the MSX computer and this lead to Yamaha developing their “Z80” version of an upgraded VDP. My guess is that they wanted it to be compatible so all the old software would run on the new computers.
A TI we were developing a Super VDP (I had moved on to the TMS340 family so a different group of people worked on it). They tried to do too much “tricky circuitry” on the Super VDP and as I remember it, the device had fairly massive circuitry problems so the program got cancelled. The feature set was very similar to the Yamaha chip, probably no accident as the ASCII Microsoft was talking to all the companies. Strangely in spite of all the patent litigation that TI was pursuing at the time, I don’t remember them ever litigating the 9918 Patent (for the patent see http://www.google.com/patents/US4243984) in spite of there being several register level clones.
I never had any contact that I can remember with Sega. I know Nintendo was a software developer for Colecovision and had Donkey Kong on Coleco and Sega had ZAXXON (a semi-flight simulator version of their arcade game). The sense I get is that after Coleco went bankrupt due to the failed Adam computer, that Nintendo and Sega decided to develop their own platforms and since they were already programming on the Coleco with the 9918 so they went with an upgraded 9918 architecture.
Pete Macourek and I did all the digital processing architecture on the 9918 (Pete had been at TI a couple of years and I was brand new). Everything in the display was pretty well driven by available memory cycles. We just didn’t have enough memory cycles to do a full simple bitmap AND have Sprites. Remember the 9918 was the first low cost display device to ever directly interface to DRAM which gave us a comparatively large amount of memory but the access was slow. As I remember it they wanted something like 8 sprites and we could not afford it and there were not enough memory cycles available. It was Pete and I that came up with “Sprite Pre-processing” With pre-processing we only fetched the sprites’s vertical address and size information (magnification and whether it was 16×16 or 32×32) from DRAM and see if it would be on the line and when we got to 5 we stopped (the so call 5th sprite number, but we didn’t have the memory cycles or hardware to display the 5th sprie). We only had enough memory cycles to fetch 32 vertical values and size values so we had 32. Basically for about the hardware budget of 5 sprites anywhere, we figured out how to put 32 sprites on the screen but only 4 on one line.
One of my early accomplishments (the 9918 was my first design after leaving college) was to figure out the DRAM interface, the DRAM In/Out buffer turnaround time was too slow which is why we multiplexed data out over the address lines and had separate data-in lines. The idea of using DRAM’s was not mine, but I figured out how to make it work (I still have the hand drawn diagram I drew up). My working with DRAMs in 1977 on the 9918 taught me how difficult it was to interface with DRAMs and eventually led to my pushing for and helping architect the first the Synchronous DRAM (see our early SDRAM patent at http://www.google.com/patents/US5390149) that found it way into every computer.
Karl
Karl, Great article and great information, I always appreciated the time and patients you gave me on the projects we worked on, thank you.
dc
As Mark says, a nice read Karl. It brought back a lot of memories as I was the person tasked with writing software for what was then a non-existant processor (TMS9995) to run on a set of video graphic boards. The idea was that I should add in addition to the video functions, a set of routines which tested every op-code in the micro-code. My memory of running this on the ’95 when it arrived was that the only problems were something to do with things being reversed somewhere. The final ’95 ran very well on the video cards which I think were used by the Royal Navy. After that project I went back to Teletext design (one of which used a ’95) but also had the job of 9900 family support.
C.H.
Very nice article Karl, the MOS design team were a fine bunch of lads, though they did have the tendency to group together and talk shop at the parties i threw for them! It was shame when Manton Lane closed down and even more when Northampton was let go.
-Mick
Karl, thanks for this post read by me rather belatedly as it filled in a few gaps in my memory!
I joined TI Bedford in 1976 and left in 1979. I was Senior Product Engineer for the 9990 family and the AMPL development system during that period. My early days were absolutely fabulous after joining from ICL, but the latter years were completely marred by so many irate customers who had designs based on the disastrous and non-delivered TMS9940 and 9985. I left 1979 to be Sales Director for Motorola’s 68000 family which had its own set of issues! Funnily enough I then joined Microsoft and the problems really started! Chris
Chris,
Yes the mess up with the 9940/9985 was awful and led to my becoming the lead CPU architect of he TMS9995 and my living in Bedford for 6 months at the start of the design. The 9995 was the replacement for the 9985 which was supposed to go in the Home Computer. The 9985 was really a terrible design and I (only 1.5 years out of college) was able to figure out how to make it a lot faster using fewer transistors. After the collapse of the 9940/9985 the home computer retrofitted the 9900 into the 99/4. The next generation of Home Computers (the 99/2 and the 99/8) were supposed to use the 9995 but the whole program collapse before they made it to market.
While I lived in the US, from 1979 through about 1996 I worked with TIL MOS Design in Bedford (and later North Hampton) on the 9995, 34010, 34020, 320C80, and 320C82 plus we started another media processor chip that didn’t go to market. I still have a very special place in my heart for Bedford and try to get back there at least every couple of years.
[…] https://www.kguttag.com/2013/08/10/if-you-havent-tested-it-it-doesnt-work/ […]
Gosh this takes me back to being a summer intern at Bedford in 1979 working on the TMS9985. I remember admiring the skill of designers who could insert extra transistors for missing inverters by hand in the middle of dense completed layouts.
Other fun ‘problems’ included the failed Spice runs caused by all the zeros being entered in as the letter O.
That said, my only positive contribution was spotting the one of the -Ve internal power supplies only used a half-wave rectifier and that adding a inverted clock feed and a few more diode-transistors would reduce the size of the massive on-chip smoothing capacitor.
I don’t miss having to check transistor dimensions by hand with a ruler – 0.4 by 0.6 sticks in my mind to this day!
However, I had a cracking time at Manton Lane, Bedford and really enjoyed working with a great bunch of talented people.
Thanks for the comments. In 1979 the device would have been called the TMS9985A as it was a replacement for the failed 9985 for the TI Home computer. Later the part number was changed to the 9995.
For about 15 of my 20 years at TI, I worked with the team in Bedford (later moved to North Hampton) and lived in Bedford twice, each time for about 6 months. I go back to Bedford every year or two and get together with some of the old team members as it has very fond memories for me.
Karl, do you know any of the backstory behind the TMS9995 and TMS9918 in the Tomy Tutor (or Tomy Pyuuta in Japan)? The architecture of the Tutor is very simple compared to the 4A, but it also used the same 16K of DRAM/VRAM on the basic console. The logic was sparse compared to the /4A. Some folks have disassembled parts of the BASIC ROM and found the tokens for XB and a lot of the assembly routines were *identical* to TI BASIC. https://atariage.com/forums/topic/312283-tomy-tutor-rom-community-attempt-to-disassemble-the-system-rom/
I imagine that if TI would have designed the /4A like the Tutor, it could have saved a fortune… Or maybe it did share the design with Tomy. The cartridge pinout is 85% the same. They have a -5V for GROM that wasn’t used at the cartridge port. The same VDP and CPU family – same source and tokens in XB, cartridge headers are somewhat the same format….
I didn’t know about the Tomy Tutor, but I wished I did as I worked on both devices (I think the only person that did for any length of time).
The TMS9995 was supposed to be used in future generations of the Home computer, and the 99/8 and 99/2 both were prototyped using the 9994 by the time the home computer program was canceled. Originally the home computer group wanted their own custom CPU to use their Games Programming Language (later called Graphics Programming Languages for company political reasons). Still, upper management told them they had to use the 9985, a variant of the 9940 16-bit CPU with EPROM. The 9940 had massive design problems, which eventually led to the abandonment of the 9985 (the short version of a long story). When it became clear the 9985 was going to be seriously delayed, the Mome Computer group redesigned the Home Computer to use the 9900 with 256 bytes of 16-bit wide SRAM. Then an external 8-bit interface more or less emulated the 9985, which was to have 256 bytes of on-chip SRAM. After the success of the 9918 design, I was given the assignment to lead the architecture and logic design of the 9985A in Bedford England, which was later renamed the 9995. So the original reason for the 9995 was as Home Computer cost reduction.