I have to say I was also surprised but I did post the picture of the attempt to boot using Lightning and the pin 20 tap. I was even more surprised when moving to pin 2 of U12 allowed it to boot. However moving to pin2 did pickup the 0-7 decode but corrupted the full $fc0000 decode and worked with intermittent crashes when the machine warmed. So when I went to Exxos's board it worked flawlessly but I attribute this to the way he generates the entire decode signal. He creates the entire decode from scratch off the bus signals and doesn't leverage the processed decode that originates from the glue and is additionally processed to make a u9/u10 decode. I suspect the EPE is slow needing a faster decode signal. For normal eproms I suspect the Lightning decode signal works fine. My effort was getting the EPE working since I find its capability advantageous and wanted to have working units. Since I want to continue to use the Lightning card I will most likely generate my own decode to drive EPE and put the Lightning back in. Maybe I should have said the EPE was slow since the Lightning uses the standard method of creating a 0-7,$fc0000, and $e00000 decode.czietz wrote: ↑Sun Feb 09, 2020 11:33 amTo be honest, I rather doubt that. When just passing ROM2 through (for booting or for access to the 0xFC0000 - 0xFEFFFF address range), the Lightning ST adds about 7 ns delay. When decoding a ROM access by itself (to 0xE00000 - 0xE7FFFF), the Lightning ST chip select output becomes low within 8 ns of the falling edge on /AS. These delays are small enough even for slow EPROMs.
I guess bottom line is I have no idea why the EPE and Lightning don't work together at this point in my mega but its an easy solution for me to use what works together.