I got the programmer from iMania. Works perfectly. The only thing is I'd like to have a detailed description of jumper configuration. Is that possible?
My main concern is how to supply vpe instead of vpp to the chip (I need 21V) and what are the goldpins beneath A0 pin?

I ended up building my own, but coding it was a real challenge. I found that getting a bit of help with programming assignments from https://essays.edubirdie.com/programming-assignment-help made a big difference. It’s handy for those tricky parts where you need extra guidance. If you’re tackling something complex, a little expert advice can really help you get past those roadblocks.

Nice project, i need a ROM Programmer for myself and i am kind of hopeful on this one. However, in the schematic you connected D0 and D1 of the ROM to Pin 15 and 16 of the MCU/Arduino. Iguess these pins are required for the USB connection to the PC. I guess you can work around that in software, but maybe its a good idea to leave pin 15 and 16 of the arduino open. 

Just a thought.

Yeah, I don't really see any way around that - on the Arduino Uno/328p the only fully available 8 bit port is PORTD (D0->D7) and the performance hit of not using it is that we have to do bit juggling with half of another port for instance.. Reducing speed drastically. 
Setting "PORTD = value" is very fast and we can still use the serial port via USB - just not at the same time. 
At least we won't have to unplug the RUROMP(better acronym pending) to reprogram the Arduino.

Are you using the Arduino Library? If yes, you are probably right. 

But, if you are using plain C, the increase in time per byte is 3 clock cycles. Just shifting out the 16 adress bits will take at least 32 clock cycles. Plus some over head.

In total your performance hit will probably be below 5%.

Lets assume it takes 100 cycles to write one byte to the EPROM. The maximum amount of bytes you can write is 2^16 (all available adresses), then it takes roughly 6.5 million cycles to write all the date. At a clock rate of 16MHz (typical Arduino clock) this takes 0.4 seconds.

I don't think you have a performance issue.

I think you missed the switch to parallel registers - one byte is just load lower address byte, clock, load data byte, clock - and every 256 bytes also a higher address byte clock. Much more efficient - and the goal is also to make it usable on my 1 MHz #65uino  :) 

Ah, right. ^^

In fact thinking a bit about it, muxing address and data on the bus isn't that much more complicated. Instead of the 595s you'd have a couple of latched register chips, and instead of the 595 drive lines you'd have the mux control lines which would be at minimum: data/address, low/high byte, and load.

Thanks you for the input! The idea with using the 595's instead of 590's is "fast" arbitrary address selection and using a single MCU register for data increases data speed and makes it bi-directional. 

What register IC's did you have in mind?

I think the good old 74x573 octal latch will work fine and is cheap enough.

So, muxing by using a single port on the mcu and three registers for data/address?  Or another for control bits, like VEP/VPP enable?
I guess that needs another pin for data bus latch+enable. Hmm. 
That would also require another input register for reading the ROM, right?

You only need a couple of octal latches for the address, similar to the couple of octal shift registers. The data lines of the EPROM can be driven directly by the Arduino. Their state only matters at the time you pulse the program pin. They need to be bidirectional anyway so that you can read back the EPROM, just like in the shift register case. The other lines like program voltage enable are already needed.

Yes, that'll work - about the same amount of pins but should be faster than clocking serially. Especially a lot faster on the 1MHz #65uino 

👍

Additional speedup can be obtained by noting that the upper byte of the address needs to be changed only after 256 bytes of data because only the lower byte of the address changes. So one low address byte load 255/256 of the time.

In practice this is simple. The driving software checks if the upper byte is the same as the last time and doesn't load it if it hasn't changed.

In fact this "caching" could even work for the low byte. Say the EPROM burning protocol does verify after write. For the read-back, there's no need to change the address at all. All this can be encapsulated in a routine in the burning software.

@Ken Yap Yes! That should make it way more efficient. Especially in 6502 assembly on the 65uino.
It's a little bit frustrating the only whole port available on an Arduino Uno footprint is the same port that uses the two lower bits for serial data (PORTD)..
For the 65uino it's easy to swap the software serial pins to use the other port (usually occupied by i2c SLC/SDA) but for an Arduino Uno with hardware serial on port D, I'm not sure what the best solution is. 
Eventually I expect the data for the ROM to come from somewhere off board ;-)

I think it's not so bad if you can arrange to use the same top or bottom nybble of two ports, then in betwen the port writes you do a swap nybble. Anyway the AVR is fast enough. The data is definitely a problem for the Arduino as the onboard RAM isn't enough if one is going to burn the whole 64kB EPROM, so some sort of comms with a host computer will be needed to send a chunk at a time. Or a SD card.

Another idea might be to multiplex the address and data onto one bus from the Arduino, getting the Arduino to write and latch 2 bytes to the address register.

This is an excellent idea. I wonder how much slowdown having the load each address serially imposes on the programming time. I suppose a hobbyist shouldn't mind waiting. I wonder how many more chips would be required to put a counter on the board, then the software would just reset the counter at the beginning then step through each address.