Yet another emulator

[Eric Aos]

Which file do I try to view?

> -----Original Message-----
> From: Mike Pitts [mailto:mpitts at netspeak.com]
> Sent: Friday, April 02, 1999 7:10 AM
> To: 'gmecm at esl.eng.ohio-state.edu'
> Subject: Yet another emulator
> 
> 
> 
> 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
>