Intellidge Extermination program.
This is the summary of the Intellidge Extermination program - the long versions are Intellidge hacks and MakeaFake.
Yesterday I took great pleasure in removing those evil Intellidges from my printer for good. This has been after years of problems not only with defeating the chips (as I did in 2002) but also electrical problems with the chip contacts. There has also been the added nuisance of not being able to clean the CIS (continuous inking system) properly because you need to keep the chips dry.
The hack is basically to program a single micro-controller (an AVR mega-8) to generate fake signals to fool the printer into thinking it has seven Intellidge enabled ink cartridges fitted.
In 2002 I reverse engineered the protocol used but there were still many unanswered questions that needed to be answered. Not being privy to the printer code the only way to do lots of experiments and also get some better logic analyzer captures.
What I already knew...
Chips do not is any way sense ink level, they are just a non-volatile serial memory device.
The protocol uses a four bit header containing a three bit chip address/ID and a read/write bit. The serial data buss in bi-directional and can change direction after bit number four (counting from one).
The transmission is synchronous with the printer generating the clock and sync/enable signal.
The clock slows down during the chip write sequence.
The chips contain 32 bytes of data with ink level stored in the first byte and other counters in the first few bytes.
The last nibble contained in the chip determines its ID and this can be changed.
There is a 10 character string at the end of the data which in my case says "INKbyEPSON"
Other counters besides ink level are stored at the beginning of the data.
The printer reads the chips on power up, writes to them on power down but also accesses them at other times such as cartridge changes.
The printer does not rewrite all the data, it usually only writes four bytes.
There are two shorted pads on the chip which may be used to detect physical presence of a chip in the socket.
The seven chips are on two separate data lines four on one and three on the other. All other signals and power are common to all seven.
Power is only applied when the chips are accessed.
What I know now (2008)
The ink level is not the only field which needs to be reset. Once the "head shots" count reaches a threshold (probably 32K) the chip is rejected. It takes many cartridges worth of ink before this happens and only the black overflowed in the time I used the printer.
The shorted pads can be ignored. Things might work better if the lines connected to the pads were controlled but the printer can be made to worked without chips in the sockets or the contacts shorted.
The fast serial clock is around 28Khz the slow clock is around 300Hz.
There is around 100uS from chip power being applied to the first chip access.
Read-only chips do not work in my printer. The printer writes to the chips and reads the data back - if the writing didn't succeed the chip is rejected. This could be worked around.
There is no significant delay between writing to the chip and reading it again. This is a huge problem when using AVRs to make fake chips as the EEPROM is not able to be read until the programing completes (around 8 mS for a mega-8). My work around is not to program the last byte (which is unimportant).
Chips must be on the correct serial line. The printer looks for every ID on both lines and if it finds a chip on the wrong line it gets upset.
The chips emulator
I was able to remove all the ink chips by creating an emulator which provided the correct signals to fool the printer into thinking that there were valid chips present.
The micro-controller I used was an AVR mega-8. This might be overkill but having extra resources makes things easier. In particular the M8 has enough EEPROM to provide 32 bytes for each virtual chip.
The emulator is connected directly to the signals on the printer mother board. I simply traced the lines from the chip sockets to the MB using a multimeter.
Six connections need to be made, two are power, one is serial clock, another is a sync or chip enable line and then there are two lines for serial data (for two banks of chips).
The emulator auto-resets the virtual chips whenever it detects that an ink level is approaching empty at power up. Currently I have the threshold set to 90% used.
When this occurs the first 8 bytes of all the virtual chips is cleared. This may not be the best method but I will see how it goes.
The future.My dongle already does everything I need but if there is enough interest I could do another version more suitable for home builders. The mega-8 is a single chip solution, apart from a couple of decoupling caps (.01uF) and the connectors there are no other parts required. The LEDs and associated resistors are a worthwhile extras but not essential.
An emulator based on a DIP version of the mega-8 or some other micro could easily for made without the use of a PCB provided people know which end of a soldering iron is hot and how to use it.
If the chips are preprogrammed there's no need for a programming port either.
The software is currently hard-coded for the 2100p chip arrangement - this can be made more universal.
When used in conjunction with my chip writer shown at Intellidge hacks it should be possible to cover a wide range of printers using the same firmware.
Hacking into a printer motherboard is probably a bit much for the average guy. Clearly there are other hackers out there but I don't know if there are enough interested to continue the project.
I can't debug everyone's systems for them so it would need a few people with a bit of nous to test the emulator on other printers and share the info.
Also I don't know anything about the newer chips. I've seen some hints that they may be the same protocol with the pins re-arranged just to annoy people making and using chip resetters.
I'm happy for amateurs to use my code at no charge (will accept donations). I think commercial users should pay though and this creates a problem in code distribution which I will have to ponder.
I've released the source for a single a ID read/write chip but for now the emulator source is closed.
If there is no interest in the emulator then there is no problem - if there is an interest then I will need to look at either releasing the binary, selling reprogrammed chips or maybe opening the source.
Feb 2009,There has been moderate traffic to this page but very little feedback about this project. I've had one possible offer for help in open sourcing the code. I'm fine with releasing the code but I have other time commitments so I won't be able to do much more more on it myself.