Simplify Microcomputer Software Development by Simulating an EPROM – EDN

I published this back in 1979, when I was building custom micro-based systems for Corning Glass, Seagram’s Distilleries, and Robinson-Nugent. As a lone developer, I could not afford $20K for an Intel In-Circuit Emulator (ICE), so I invented this device to simulate the ROM in a target system by plugging in a ribbon cable reflecting a field of RAM in my S-100 development system. The magazine paid $195 and I was delighted with the layout… but then… about a year later, I found that a company called Pragmatic Designs on the West Coast had apparently lifted the design and was selling it as a product called the DBM-1… it sure looked identical!  As a young pup in Kentucky, I didn’t know how to lay any IP claim to something that I had freely published, but I lost a bit of innocence that day. Still, whaddya gonna do? My whole life is one of building bizarre contraptions and publishing them, and trying to keep them all secret would only make sense if I had manufacturing and marketing capability to back it up. So nothing has really changed… but I still dream of finding a technology-transfer joint-venture partner who can help me extract more than nickels when the occasional bit of gizmology might be widely useful.

by Steven K. Roberts
Cybertronics Inc.
EDN
April 20, 1979

A relatively simple logic circuit termed a RAMport permits development of microcomputer software without the use of costly in-circuit emulation.

Simulating a 2716 EPROM in a RAMport eliminates many of the frustrations inherent in developing dedicated microcomputer software without an in-circuit emulator (such as Intel’s ICE). This 2kx8 field of RAM resides in the host system and is equipped with sufficient gating and control logic to allow its address and data to come from either the host’s bus or an external source. With it, any low-cost S-100-based microcomputer system with reasonably good software support can serve as a host in the development of code for single-board computers, without the need for complex software simulations. (Suitable modifications to the RAMport circuitry described here allow its use with other hosts: Multibus-based systems, for example.) The alternative—buying an emulator-type system—becomes a very costly one by comparison.

Use of the RAMport design approach handles one of the major problems of software development without an in-circuit emulator: lack of sufficient system support. In stand-alone development systems, debugging the evolving code in situ can involve dozens of tiresome trips to the EPROM programmer, and the inflexibility of this stored code makes even simple patches a major pain.

This design also offers some surprisingly convenient additional features. In data-acquisition systems, logic analyzers and other environments in which communications overhead is a burden on a computer, the RAMport can significantly speed data transfer. And in addition to serving as an alternative to the use of emulators for microcomputer development, it’s a generally useful R&D tool. Finally, as a window between two systems, the RAMport constitutes another step toward achieving the distributed intelligence that will characterize the next generation of computers.

A look at RAMport design

The RAMport’s “mode” (Internal or External) is determined by the status of a bit on a host-system output port, which constitutes part of the required support logic. And to make the device as useful as possible, its external interface maps onto a 24-pin DIP header in a pinout that matches the 2716’s—a provision that allows plug compatibility between the RAMport and the EPROM and thus makes the RAMport appear like a 2716 to the system under development.

In normal operation, the header plugs into that system’s single-board computer, and the designer assembles successive revisions of the applications software into the RAMport’s address field. The host system’s debug software is then executed, and with the RAMport switched to External mode, the processor in the system under development suddenly has memory. Use of the debugger then allows patches to be made easily; no EPROM burning is required until the software is “clean.”

In the RAMport version described here (Fig 1), the development system is the Cromemco Z-2D, which uses the S-100 bus structure. The processor boards used in the systems under development are Intel SBC 80/04s, for which a RAMport with a 2k field proves adequate. (Naturally, the concept is easily expandable to allow a larger address space or longer word length.) Two groups of multiplexers, one eight and the other 12 bits wide, select the RAM’s data and address source, respectively.

The section of logic labeled “S-100 Interface,” detailed further in the schematic in Fig 2, handles the timing and other interactions between the RAM and the host-system bus, to which the memory appears (at hex locations C400 to CBFF) like any other block of the address space.   Wait-state selection accommodates slow RAM, although a designer should exercise care not to use parts slower than a 2716. Port 24H is decoded, and the design uses two of its bits: One controls RAMport mode, and the other serves as a utility reset signal to the external hardware.

The entire RAMport circuit fits comfortably on a 5×10-in. card, such as the Vector wire-wrapped prototype board for the S-100 bus shown in Fig 3. The 24-pin DIP adapter in the upper-right corner of that photo is the seat of the ROM-simulator cable; the smaller header below it carries the RESET and some useful miscellaneous lines (system clock, control-port bits, MODE LED, serial in and out, etc.)

Use of the RAMport for software development can proceed in one of two ways. Most directly, a designer can build the system under development in its final form and then develop the program for it in the system’s actual working environment. This is the cleanest approach if the system’s hardware configuration is finalized. However, if the development task includes optimizing hardware interfaces or making changes in the system configuration, the RAMport can function in concert with an intermediate single-board computer. This computer (perhaps built into a box to facilitate its repeated use) can provide I/O lines and other signals on barrier strips (Fig 4).

The intermediate single-board computer is a self-contained μС system, based in this example on the Intel SBC 80/04 and equipped with a 5V/6A power supply (with plenty of +5V left over to accommodate the hardware under test). In use, the barrier strips are wired to interface this μC with the peripheral devices called for by a particular design, and the RAMport cable plugs into the ROM 0 socket on the SBC 80/04. The cable bearing the RESET line plugs into a Molex Connector (J2), and the designer debugs software and hardware simultaneously by manipulating the RAMport’s program content and mode. When the software is correct, the designer burns it into a 2716 (or two 2708s) and then builds the actual developed system, exploiting the distinct advantage of having known good code available.

The importance of writability

The RAMport’s real contribution to the process of microprocessor software development, however, is its writing ability. One of the biggest problems with the ROM-simulator approach (compared with using an emulator) is the invisibility of a single-board computer’s RAM and registers: It’s not possible to write into the ROM field on an unmodified single-board computer. The approach discussed here, though, modifies the single-board computer; it adds a 74LS02 NOR gate in the “kluge area” of the SBC 80/04. One of this gate’s elements then serves to AND together the active-LOW signals WRT and IO/M. The output, which is HIGH when the ROM area is addressed with any kind of write instruction, then connects to the PGM pin (18) on the 2716 socket.

The remainder of the gate package (Fig 5) is used—albeit inefficiently—to generate a LOW simulator without requiring any hardware signal whenever the upper five address bits are LOW; this procedure parallels the normal CHIP SELECT provided on the board but does not include the MEMORY READ condition. The address logic on the RAMport receives the new signal via the auxiliary DIP cable (which also carries RESET and the optional convenience signals) and gates it with A to properly enable the 2102s. Thus, during an external read of the RAM, the original CHIP SELECT enables the output buffers, and during an external write, the newly developed PROM WRITE is gated with the now-inactive CHIP SELECT. This somewhat convoluted approach is necessary to prevent “garbage” from being written into the RAMport when stack operations and other “normal” writes occur in the single-board computer’s RAM space. (Note that the modification just discussed is optional; the RAMport can function as a ROM simulator without requiring any hardware changes in the external system.)

With write capability, the RAMport’s utility increases considerably. From the development system, a designer can direct the 80/04 to copy its registers and important scratchpad contents into its ROM space, which is then returned to Internal mode for examination. Instead of a “mysterious black box” about which the designer must guess, the system under development becomes completely accessible. The designer can even add breakpoints with a simple software patch; the software in the accompanying listing (Fig 6) automates these memory- and register-examination functions.

As noted, aside from performing development tasks, the RAMport helps solve a variety of other design problems. By allowing the swapping of the 2k field of memory between systems, it provides a method of performing a block transfer with an absolute minimum of processor overhead.

In a computer music application, for example, the RAMport presents envelope patterns to the sound-generation portion of a μC system. Repetitive operations such as amplitude-envelope generation and keyboard scanning represent troublesome overhead factors in a real-time music system, usually calling for external hardware. But the envelopes are complex data types (more complex than the basic attack-sustain-decay format) which can change frequently in the midst of a performance. Thus, whenever it’s necessary to redefine the envelope shape for an output channel, the RAMport is placed momentarily into Internal mode. Data goes into it via a fast Z80 block move; then the RAMport returns to External mode. The music system’s DAC-controlling hardware then scans to its heart’s content without the need for synchronization or cycle-stealing with the main processor.

Author’s biography

Steven K Roberts is president of Cybertronics Inc, a microprocessor engineering firm in Louisville, KY. His firm specializes in developing custom industrial-control systems and is beginning to manufacture distributed data-collection systems. Cybertronics also supports Steve’s R&D activities in artificial intelligence, bizarre system architectures and new цР-based products. Freelance writing, music and photography occupy his time outside the business, and he is also building a solar-energy system for his home. Photos for this article are by Douglas Fowley.

NOTE: A decade later, this topic came up in the late Embedded Systems Programming magazine:

WHEN IN ROM
by Ray Duncan
Memory Emulators Revisited

As charter subscribers to Embedded Systems Programming no doubt recall, in the first installment of this column I waxed enthusiastic about the time- and labor-saving properties of ROM/RAM emulators.

These nifty devices, which consist basically of static RAM and some control logic, plug into an embedded system’s ROM or RAM socket and are loaded up over a serial or parallel port from a development system (such as an IBM PC). Thus, one of the most tedious and time-consuming elements of the development cycle, erasing and reprogramming EPROMs, is simply excised from the loop.

That column prompted a number of vendors to send me information about their own memory emulators, which pleased me greatly since that was my goal in the first place. It also earned me a flurry of letters ranging in tone from amused to annoyed, with most (luckily) somewhere in between. The most interesting was written by high-tech nomad Steven K. Roberts, who spends his time bicycling back and forth across the country. The unusual thing about his bicycle is that it carries a cellular telephone, ham radio, speech synthesizer, TV set, oscilloscope, five computers linked by a local area network, and… well, suffice to say, this is no ultralight racing bike. Steve writes:

“I enjoyed your article on ROM/RAM emulation in the premiere issue of the magazine, and agree fully that this is a useful design approach. I have to tell you, however, that it’s not at all new: in 1979, while working on custom micro-based systems for clients, I developed a board called the RAMport to perform exactly this function. I wish I had marketed it… For your entertainment, I’m enclosing my EDN article [“Simplify Microcomputer Software Development by Simulating an EPROM,” April 20,1979, pp. 171-78] on the design, which ran about 10 years ago!”

Steve went on to say that he’s working on a new bike in the San Francisco Bay area, using a 68000 running Forth for real-time control and management of a 32-node resource bus.