I started a design using a binary counter driving an EEPROM, but about half way through it the station bought a DVI(?) digital timebase corrector and it had basically the same thing fully developed.
Almost exactly my experience with TTL! Almost all of the necessary engineering had already been done by the time I got involved with TTL in the late 1960s into the 1970s. No way I could compete in price or time-to-build with commercial off-the-shelf (COTS) equipment. It had to be a one-of-kind project. And some really spiffy LSI TTL was becoming available that further simplified the engineering required to complete a project. The icing on the cake was the arrival of the Intel line of microprocessors. I was late getting involved with that too... another "super technician" in our lab had discovered the 4004, and other processors from Motorola and others, and was busy experimenting with them. He even bought a
KIM-1 computer with his own out-of-pocket money!
But being a little higher on the food chain, I held out for a modular Intel 8080 minicomputer-style system using rack-mounted card modules: one card for the CPU, one card for the clock generator and bus controller, one card for each kilobyte of RAM, another card for serial I/O... yada, yada, yada. IIRC, the company I bought all this stuff from was named Control Logic, but I cannot find a trace of them today. Control Logic is a common enough name though, so they may have gone out of business or were absorbed by another company.
Our electronics lab supported the University of Dayton Research Institute as well as every department and school on campus. Across the hall from our lab was a surface analysis lab, my first introduction to that particular science. It initially had an hemispherical electron spectrometer used with a monochromatic x-ray generator to analyze the surface chemical structure of samples in vacuum. It seemed to take forever (hours) to scan through the range of photoelectrically emitted electron energies to identify and quantify each chemical species, in the meantime recording on a linear chart recorder the response from an electron multiplier that detected electrons of a specific energy that made their way through the hemispherical analyzer. The chart recorder ran at a constant strip-chart speed that was not in any way coherent with the slowly changing waveform that determined the analyzer energy window. It was therefore difficult to accurately interpret the results.
So, realizing the power of expensive minicomputers, and the potential power of inexpensive microprocessors, I proposed to "upgrade" their ESCA (Electron Spectroscopy for Chemical Analysis) system to allow automagical sweeping of analyzer energy selection and storage of digital count data from the electron multiplier detector. There were multi-channel analyzers available that could do the same thing, essentially a memory matrix into which the number in a binary counter could be transferred to sequential memory locations and then "read out" as vertical deflections on a CRT screen, but these were expensive. And interfacing the digitally stored information to a mainframe computer was a daunting task.
The lure of being able to build something on the cheap that would free up hundreds of man-hours spent baby-sitting the ESCA was irresistible. I got the go-ahead to proceed, using the Control Logic card chassis as the basis for my very first embedded microprocessor application.
Only thing was... I didn't know Jack about how to program a microprocessor. Or how much RAM was "enough" or even how to download and store a program in RAM. Long story short: we had to eventually purchase an Intel Microprocessor Development System (MDS) to finish the project, and hire a grad student to program the Control Logic box. Not that I didn't learn a lot. I signed up for, and passed, a course in IBM 360 Assembly Language Programming, figuring it would help me understand how to program the Intel 8080. Well, not so much, but it was enough to convince me I did not want to pursue a degree in computer science. But I did purchase, and for awhile used, a paper-tape based Editor, Assembler, and Loader for the Control Logic system.
We used an ancient ASR-33 Teletype machine to punch and read paper tape, interfaced to the Control Logic chassis through a 20 mA serial current loop. So the drill was this: Read in the editor from paper tape. I had built a tape boot-loader that read its small program from a Hollerith card inserted in a static card reader. The card was multi-punched manually, in binary, from hand-assembled 8080 instructions, each 12-bit column on the 80 column card representing one byte of data... in effect an 80 byte paper ROM. More than enough memory for a paper-tape boot-loader.
Next, use the Editor, now loaded into RAM, to write an assembly language program. Punch the ASCII representation of this source program onto paper tape. Read in the Assembler program, replacing the Editor program, and create a relocatable binary object file from the source file paper tape. Punch out the relocatable binary object file on paper tape. Finally, read in the Loader program, specify a starting address, and create a loadable hex object file from the relocatable binary object file. Punch out this absolute binary object file on paper tape. Finally, using the Hollerith card bootstrap reader program, load the binary object file into RAM and see if your program works.
On a really good day, this design cycle (not including subsequent program test and debugging) took about an hour. The Intel MDS with its floppy disk drives and CRT screen editor shortened it to just a few minutes, not including the time it took to burn an erased EPROM, addressed in high-memory, that we finally used for program storage. Pretty primitive by today's standards, but cutting-edge technology for our little lab in the 1970s. Not to mention we had a hell of lot of fun.
By this time I had designed and had manufactured locally some sixteen static memory boards, each with one kilobyte of static RAM. I didn't know how to use dynamic RAM at that time, but sixteen kilobytes of RAM out of a 64 kB addressable memory space just seemed like a lot of memory to me at the time. The sponsor of the project asked me how much memory we would need, and off the top of my head I told him sixteen kilobytes should be more than enough. Even using 16-bit counters for the photo-electron count data would still leave 8 kB for data storage. By then I knew about EPROMs and figured we would use a few of those for program storage. We were going to display the stored counts on an x-y addressable CRT, but not a raster-scanned CRT. That came years later after I had graduated and was hired by a company heavily into digital image processing. It was amazing how rapidly raster scanning replaced vector displays. Many of our customers resisted this transition, but there was never any doubt (at least in my mind) that high-resolution raster displays would eventually replace all vector CRT displays. Today, I doubt you can find a
vector CRT display anywhere.
Your comment about binary counter-addressed EEPROMs brought back some memories. I hooked up an A/D converter to the sine-bar drive mechanism of a Czerny-Turner Monochrometer to obtain wavelength information. The A/D converter output then addressed a static RAM array, into which the user had downloaded transmission information as a function of wavelength for the monochrometer. This data was used with a Burr-Brown hybrid multiplying four-quadrant D/A to linearize the response of a photo-multiplier tube that "looked" at the monochrometer output.
