EFIDynoTuning Forum

I haven't been able to find any schematics or really anything more than a mention of the Son-of-EECSucka hardware anywhere so far. The 74HC373 latch chip is tri-state capable but the design I'm using right now has its OE/ pin1 simply grounded. Thank you again for your input I'll do some more looking at this. This design not tri-stating the way it is now is probably why the pull-down resistors are so fiddly. I think the SUCKIT program has the LPT outputs (PD0-PD7) only jumping back and forth between 0 and 255. I don't think it's giving any address info to the EEC just strobing the data out of it into nibbles read by the status register of the LPT port and using the control port to change the bank select lines. My intentions are to move on to more modern tactics but for now I'm trying to learn by available examples and original thoughts from the beginning or near to it.

***Correction*** I realized after writing about the tri-stating up above it’s not the 74HC373 latch chip that needs to tri-state for the MBUS it the 74LS157 mux chip that is connected to the MBUS MB0-MB7. I’ll look to see what can be done with that.

I have a couple Rasbery pi Pico units I will start messing with eventually and they have some state machines built in with programmable I/O that may come in handy, plus they can clock to I think like 225Mhz.
***correction*** Dual ARM Cortex-M0+ @ 133MHz still impressive.

I'm having a lot of fun borderline obsessing over this lately.

Thank you
J.W.S.

wwhite wrote: ↑2022 Dec 08, 21:18

efloth wrote: ↑2022 Dec 08, 07:17 It would be cool to do a uv erase like this: https://youtu.be/_sSuzDg4ntA

That's how we did it in the early 90s.
I follow that youtuber, The software he uses looks like the programmer has configurable pins. That is what would be needed to program a stock Ford EEPROM. The programming/write pin that takes 12-15V is on the middle of the chip, pin 18 or something. Most EEPROMS its on the beginning or end of chip pins, like 0/1 or 23/24 or 27/28, something like that.

Anyways, UV erasing the EPROM should result in a read of all 0xFF's, chip bits all 1. When it is written it writes 0s.
It's all about testing and succeeding!

I stumbled across this recently. I'm sure some of you have seen it as it's flaoting around. has some info on eprom programming.

https://drive.google.com/file/d/1ypPYhu ... p=drivesdk