Yet another emulator
Mike Pitts
mpitts at netspeak.com
Fri Apr 2 15:10:12 GMT 1999
See what you guys think of this one. It does 2764
to 27512 and from the sounds of it, it may be byte
pokeable with a simple software change.
BTW: 2732 can be done with your own adapter if you
are so inclined.
http://www.emi.net/~mpitts/PROM-EMU.ZIP
-Mike
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
PROM Emulator (C) Copyright Mika Iisakkila & Marko Winblad 1991-93
Distribution document Jan 10, 1993
CONTENTS
------------------------------------------------------------------------
1.....Copyright & related stuff
2.....Why?
3.....The hardware
4.....The software
5.....Construction tips
6.....List of files
1 COPYRIGHT
------------------------------------------------------------------------
This PROM emulator and all the files listed in section 6 are copyrighted
by Mika Iisakkila. They are based on work by me, with some invaluable
help from Marko Winblad. Any commercial exploitation of this schematic
or other files included in this archive is prohibited. You can use the
emulator in developing commercial software, though.
Otherwise, you are free to do whatever you want with this archive and
give it away to anyone who is interested. If you modify it or use any
ideas from it, it would be nice if you gave appropriate credit to the
original authors or whoever might have worked on it after us and
before you. I'm doing this for the fame, not for the money :-)
There are no warrantees and I won't consider myself responsible if you
kill your dog with this emulator. However, it works great for me.
All comments, questions and suggestions are welcome.
E-mail: iisakkil at vipunen.hut.fi
2 WHY?
------------------------------------------------------------------------
Why would you want to build a PROM emulator? If you have written 1500
lines of assembly and driven 15 miles and back to a friend to get it
burned on an EPROM, only to find out that the program doesn't work at
all, you know why. That's what happened to me. Even if you do have an
eprommer, constantly replacing a 28-pin IC in your system and erasing
old chips to get new ones to program quickly becomes tedious. I needed
only the one frustrating event to convince myself that I needed an
emulator to get rid of all this.
There have been numerous PROM emulator circuits in magazines. Usually
they work well, but have a major drawback - you still have to have that
stupid eprommer and/or you still have to detach them from the target
system during programming. This design comes around that problem - it
is loaded from a PC parallel printer port at a typical rate of 5-10
secs / 64 kbytes, while it is still sitting in the target system,
which is still powered on.
The ease of this approach opens new possibilities for embedded software
development. You can recompile your program and have it running in the
target in less than 10 seconds. It is very easy and quick to add a
statement to wiggle a port pin if you want to know if your program
reaches that point in the software. This way you can just use a logic
pen or a scope for debugging problems that typically would be better
suited for an expensive in-circuit CPU emulator or a logic analyzer.
If you have an ICE and don't mind being married with that particular
processor or if you are able to write perfect code on the first try,
this emulator is not for you. However, I have probably saved days of
EPROM burning & and erasing time during the last year - time that is
better used for actual development.
You can of course buy an emulator from a commercial supplier, but they
are very expensive and not for the hobbyist. The price for this emulator
should stay well below $50, if you don't count your time.
Now that I've let out enough steam, let's get into business.
3 THE HARDWARE
------------------------------------------------------------------------
[This description will always refer to the PC parallel port. However,
you can use any system with 8+3 Centronics compatible data and handshake
lines for loading if you write your own software]
In short, the idea of the emulator is to replace the PROM with static
RAM, in which the contents can be loaded in some way or another. This
design lets you load the software while the emulator is connected into
the target system, and therefore we need 3-state buffers to disconnect
the RAM from the target bus (PROM socket) during loading. The actual
loading is done from an 8-bit parallel port. The data is written in
3 byte chunks (2 for address and 1 for the corresponding data byte)
into a 3 byte deep / 8 bit wide shift register. After that, the loading
software uses one of the parallel port handshake lines to pulse the
/WR line of the RAM, and we're done with that byte. After all bytes
have been loaded, another handshake line disables the shift registers
and enables the bus buffers, and the target system is ready to go after
a reset.
The buffers are implemented with 74hc541 octal 3-state line drivers,
and their enable lines are controlled by the INIT line from the
parallel port (D5 is controlled by the /CE and /OE lines from the
ROM socket). The same line (after inverting) controls the 3-state
outputs of the shift register, which is constructed from octal
D type flip flops 74hc574. Data is written into the shift register by
pulsing the STROBE line, as usual. This will write the new data byte
into D6 and move the old bytes forward into D7 and D8. D11 (hex
schmitt-trigger inverter) provides both inversions and buffering
for the handshake lines. D9 and D8 implement some additional logic
for controlling the type of PROM to be emulated (selected with S2)
and putting the RAMs into stand-by mode when the emulator is not
being written or read (low power consumption and long data retention
even without supply power). SELECT line from the parallel port
is used to pulse the RAM /WR line after the desired address and its
data has been written into the shift register.
The led is optional and will light when the loading software takes
control of the emulator. S2a (and S1) write-protect the emulator when
opened. Otherwise you can't boot the PC without corrupting data in the
emulator, because the BIOS messes with the parallel ports during boot.
The other three switches in S2 select the type of PROM to be emulated.
All three switches open is 27512, b closed is 27256, b&c closed is
27128 and all three closed is 2764. 2764 needs also an adapter because
of the different pin-out (24 pins, 28 for the others)
The pull-up resistors from ID0-7 belong to a typical Centronics
implementation and are needed to interface the TTL outputs of the port
with the CMOS inputs of D6. The series resistors are there to protect
D6 from excessive currents, because any high levels from the port will
bleed through the ESD protection diodes in D6's inputs into the supply
line of the entire emulator if the target system is powered down.
The PC parallel port has TTL outputs, and one high level data bit can
source more than enough current to keep the emulator powered forever.
This is why V1 is used - otherwise the current would flow through the
poor D6 into the entire target system, possibly damaging D6. V1 is a
schottky diode to keep the forward voltage drop as small as possible.
There are also two pins designated RESET and /RESET. They give you
active-high and active-low reset signals for your target system,
if you don't have a watchdog circuit to kick it up after loading (the
target will inevitably crash during loading, because the emulator
effectively disappears from its address space).
Parts list
D1,D2 55256,62256 or any generic 32kx8 static RAM (see below)
D3,D4,D5 74hc541
D6,D7,D8 74hc574
D9 74hc00
D10 74hc08
D11 74hc14
J1 PC parallel port connector (D25)
J2 PROM to be emulated
H1 red led
V1 BAT42 or any smallish schottky diode
C1-C7 100n ceramic (supply bypass caps for the IC's)
C8 22u/10V tantalum
R1,R3,R22-R25 100k - 1M (see below)
R19-R21 4.7k
R26 330 ohm
pullups from ID0-ID7 4.7k
series resistors between ID0-7 and D6 470 ohm
S2 4 x on-off DIP switch
S1 on-off switch (optional for ease of use)
The required speed of the RAMs depends on how fast PROMs you need to
emulate. The glue logic in the emulator adds around 50ns of delay.
In practice, it's difficult to find RAMs slower than 100ns nowadays,
which would still make the emulator the equivalent of a 150ns PROM.
I have 85ns RAMs.
If the pull-up resistors are large, the data will stay longer in the
emulator after it has been disconnected from both the target system and
the PC. If you don't need this capability, use 100k which will allow for
better noise immunity.
4 THE SOFTWARE
------------------------------------------------------------------------
The software should be rather self-explanatory. It is able to load
files in the following formats:
- straight binary data (with optional offset for loading)
- Intel-Standard hex format
- Motorola hex format (not tested)
The software is written for Turbo C 2.0, but should be trivial to port
to other compilers. Later Borland compilers should work right out of the
box. Microsoft C will require slight modifications in some functions
(outportb() is called something else, maybe MK_FP() macro too).
The program will try to measure the approximate speed of the computer it
is running on and adapt the delay loops for writing into the emulator.
Unfortunately this is not a very clever implementation and I've only
tested it with the computers I have owned (286-12, 386DX-33 and 486DX-50).
The measurement function may also get confused if you run it in a Windows
dos box (although this works fine after you find an adequate constant).
Because of all this, the default delay is made overly pessimistic
and you may get the loading much faster by experimenting, especially
if the cable from the PC to the emulator is not longer than 2 feet.
Try reporting the default constant outside Windows with emu -t and
specifying at least that on the command line, if you use the software
under Windows. I have reliable loading at 0.2 sec / kbyte rate with
a one meter ribbon cable.
5 CONSTRUCTION TIPS
------------------------------------------------------------------------
The schematic may seem to have a lot of wires, and it does. It's probably
not feasible to design a single-sided PCB for it and it's definitely not
suited as an introduction to digital electronics. I made my prototype
on a Veroboard with jumper wires. It's not that hard, as hc574 has a nice
flow-through pin-out (so does hc541, but the chips that they connect to
don't). Wire-wrap should be a breeze, if you're careful. You can put the
RAMs on top of each other, just separating the few pins that don't connect
in parallel. You can also just omit one of them (D1) if you won't need
more than 32kB emulation (you can still emulate a 27512, the upper half
just doesn't work). The connector on the right of the schematic can be
omitted, it was originally meant to facilitate serial loading of two
emulators from a single port.
For reference, the emulator can be implemented on a two-sided PCB
with SMD components on both sides and a size of 38 x 57 mm (the width
is the same as the length of a 28-pin CERDIP package). I have one
such de Luxe system that I use every day. We decided not to
release the PCB plots (at this point anyway) because it still needs some
work. With mandatory through plating and 0.2mm trace widths, it's also
way beyond the precision one can reach at the home lab (or at a
low-quality PCB manufacturer, for that matter).
Good luck if you decide to build one and let me know what you think of it!
Mika Iisakkila
iisakkil at vipunen.hut.fi
6 LIST OF FILES
------------------------------------------------------------------------
emulator.doc You're reading it
emu.exe Loading program DOS executable
emu.h Definitions
emu.c Main program
hex.c Hex -> binary converters
load.c Loading routines
makefile Makefile (no kidding)
emu.sch PCAD schematic
emu.hgl HP-GL plot of schematic
emu.eps Postscript plot of schematic
The PS file is encapsulated postscript, but it worked for me by just
dumping it to an Apple LaserWriter from a Unix machine. If you can't
print or view any of these formats directly, get the PrintGL program
from some ftp archive. It is a DOS program and will convert the
HP-GL file into next to any printer format. hpgl2ps and Ghostscript
might also help you if you're stuck with Unix (hah).
All files are copyrighted by Mika Iisakkila (iisakkil at vipunen.hut.fi),
with conditions for distribution given in emulator.doc.
--end
More information about the Gmecm
mailing list