Very integrated solution for 1991. Now days there are muuuuch easier ways to do this but the theory remains exactly the same.

I plan on making an ROM emulator for my Z80 build. Its going to be an SPI EEPROM and STM32F103 with a simple drag'n drop hex programming interface. Will make writing a monitor, porting CP/M and more sooooo much easier.

Using an Teensy Arduino to emulate the RAM & ROM for a z80

http://labs.domipheus.com/blog/teensy-z80-part-1-intro-memory-serial-io-and-display/

Very clever mechanical design! 

Thanks, danjovic!

Are you planning to release more details?

The design should be still DIY-able, as not only 16C54 is still manufactured, but there is FLASH replacement PIC16F54.

I don't think that it's DIY-able, at least without modifications. Even then, I wonder how many hackers need EPROM emulator now. But I've found the source file and added it as the attachment, more as the relict.

there is a lot of people resurrecting old tech and building "new old tech", like Z80 computers or TTL CPUs. I personally thought of building the EPROM emulator for a long time, as swapping parallel EPROMs is annoying

I took a look at the source and I believe it can be modified for new tools with no big effort, I'll try it. Schematics is traceable from sources and block diagram you entered here. It looks to expect expect special software on PC side to send the data, but I believe it is doable, I can somehow understand the comments.

If nothing else, we all will have conserved this brilliant UART RX routine for future :-)

Good luck and thanks!

Here's the version of source file, with comments translated to English. Attached.

I have found the source file for PC software (attached also), which I wrote in assembly language. I don't remember anythig about it, but as far as I can see, it takes binary file and adds only the checksum after every 256 bytes, and sends all that to the serial port. It also supports several switches in command line:

syntax: EMUL [[path] filename[.ext]] [/type] [/n] [/R|/D|/E|/F|/?]
type = [27]16|32|64|128|256|512|010|101
R = Reset pulse 0.5 sec
D = Disable target (reset on)
n = COM port (1|2|3|4)
E = Enable target (reset off)
F = Clear emulator (all FFs)
? = this message
default .ext=.BIN

...if there's anything that I can do, please let me know!

Right now I got the source of emulator to build in newest MPLABX under Linux. I think it is magical how one can reuse sources from 1991, 25 years later under totally different tools and platform. I needed to make slight touches to the source, like changing name of one label (error, seems to be reserved word) and consequently all goto references.

Huh, 8086 asm is over my head.

Now some random thought, correct me if I'm wrong, please:

As I looked at the PIC sources, it looks like it expects 1024 bytes long blocks, in 256 bytes long subblocks, each with single byte of simple checksum. So, to write two 1024 blocks it should look like 

<Command 03>

<Command 64><Command 09>

<Byte0> <Byte1> <Byte2>...<Byte254><Byte255><Checksum>

<Byte256>...<Byte511> <Checksum>

<Byte512>...<Byte767> <Checksum>

<Byte768> <Byte1022>... <Byte1023><Checksum>
<Command 65><Command 09>
<Byte 1024> <Byte 1025> .... etc the same as for first block
<Command 04>

then perhaps <command 1> to reset the target?
Checksum is just simple sum of all 256 bytes, overflow ignored?
To transfer 1024 bytes - do I need to transfer 1 (command 09) + 257 (for each subblock 256+checksum) * 4 bytes = 1029 bytes?

I reviewed the protocol, so now I remember some steps. For all EPROMS with less than 128K memory, it writes 0xFFs to all unused blocks, so that the active block is at the top of the virtual EPROM. It's because all unused (highest) address pins are actually high, but now I think that it would be much better if it filled all unused areas with the same contents, instead of writing 0xFFs. So the reading would be always correct, independently of all the unused address pins.

Another thing that I noticed is that every command arrives in two bytes: first true, and then negative. If not so, an error is generated. Checksum is, of course, simple sum of 256 bytes mod 256 (ignores bits 8-15) and it takes only one byte.
If error is detected, it holds RESET pin active and waits for another separator, which is silence in RS232 signal, longer than 700 ms. So the pause in a kind of transfer terminator.
I think that in your protocol is an error. All commands with bit 6 set (64...127) are just for skipping (and writing 0xFFs to) memory region which starts at 0x0000 and ends just before the byte where the active block starts. For EPROM 27512 (which is 64K) the active block starts at 0x8000, for 27256 at 0xC000, for 27127 at 0xE000 and so on. So commands 16, 32, 64, 128, 256, 512, 101 and 010 ("27" prefix is optional and makes no difference) should be sent only once, at the beginning.
I know, the protocol is unnecessary complicated, now I would do it in a more convenient way. I am sorry that I didn't find the protocol description, but those listings are all I have now.