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@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 comm...
fred1144