5'th Sept 2008,
It shouldn't be all that hard to make a fake Intellidge (AKA ink chip).
Unless you are making ink carts this is pretty pointless.
In general read only ink chips are more useful and actually a lot easier to do.
I've heard from people saying they were working on a chip emulator and such but never heard the result or seen anyone publish anything.
There is also scope for variations on the theme such as write-once chips or chips which are usually un-writable but can be reprogrammed if need be.
The term "program" has a double meaning here. For a genuine Intellidge the meaning is clear - it means to write data into the 32 byte (eeprom) storage which stores the ink levels and other information. Perhaps the term "rewrite" is better.
For some but not all fake chips "reprogram" can mean to program firmware into a micro-controller such as a tiny-AVR.
In future I will try to remember to use the words "rewrite" and "reprogram" as appropriate.
|This is a PCB I literally had lying around. It is overkill for making a fake ink chip but I have bigger plans for it. The code I write should be trivial to convert to a less powerful AVR if required. If I really planned to put my "chip" onto a cartridge then I would have to use a smaller micro but that isn't what I want to do.
I added an extra LED since taking the PCB photo. This will help me debug the code.
I've already modified my "spoofer" program because it may have some reusable code and uploaded it.
The micro starts ok and I can flash the LEDs to show all is well so far.
I also reprogrammed the mega-8 fuses from the default setting to select 8 Mhz internal RC clock and BOD on. This *should* allow the micro to boot fast enough to be operational a few hundred microsecond after power on. The standard boot takes milliseconds and this is too slow.
|This is the data I captured in 2002 using a micro as an el-cheapo logic analyzer. These are my names for the signals because I didn't know the epson names at the time. The sync line could also be thought of as a positive chip enable - it doesn't make any difference.
Enlarge the above signal capture image if you want to understand what I am trying to do.
The printer controls power and all the signals shown. However the data line shown on the bottom trace is bi-directional.
The only signal I need to generate is on the data line during the read part of a transaction.
The data line is always driven by the printer up to the fifth data bit (counting from one) and reverses direction if the chip is being read.
The chip only drives the data line if the three bits of ID match the chip ID and the read/write bit is low.
Multiple chips share the serial buss(es) and in the case of the 2100P there are two serial busses which use the same sync and clock lines.
Zero is not a valid ID because only one serial buss is used at a time and the unused idle (low) line would cause chip ID zero to dump data onto that line causing buss contention (ie both ends acting as drivers at the same time).
The code is basically working. My reader reads my mega-8 circuit correctly.
I also need to test partial reads and multiple reads with power remaining on between reads to different chip IDs.
First test in the printer is a no-go.
I can think of a few possible reasons why it doesn't work and will have to work through them.
I'm hooking into the mother board signals.
Plugging the real chip module into my connector works.
I wrote the extra code the make the fakechip write-able. It is working in the reader but the mega-8 eeprom writing is a little slow. I can only write at about 900 bits/sec, this may be fast enough but maybe not. If this is a problem I may have to go to a different micro. I may be able to work around it for my internally mounted "chips".
A cartridge mounted fake will need to use a different micro anyway for space reasons.
Some progress. The printer won't recognize the chip when it is set up as "black" but it will write to it to increment the counter in the second byte.
Strangely it will recognize it when it contains lite-cyan data - I've hard-coded the ID to "one" (the black ID) and it is recognized as a black chip. I'll have to ponder this for a while.
Still not totally sure what is going on but I can make my fake chip work reliably by using fast inline code with no EEPROM access and by not having the low bytes zeroed.
I have some experimenting to do to work out where the timing is critical but it is bed time so it will have to wait.
I suspect that either the data clock is faster than I expected or the printer is not sampling the data line when I think it should.
A logic analyzer would be a help.
I ordered a USB logic analyzer from Saleae.com today - I guess it'll take a week or two to get here.
12'th - The new toy has been sent so I'd expect it next week. If I don't solve my current problem tonight I'll probably wait till the analyzer arrives.
I tried powering the faker from the printer's internal 3V3 supply. Still no go for the light cyan. It clearly isn't a problem with booting time.
|A slower data capture showing the printer reading all 7 chip. We are only seeing one of the two data lines which is why we see no data for four of the chips
Referring back to the crude logic captures I did in 2002 give me a clue. Sometimes the printer has a delay between sync going high and the clock starting, sometimes it doesn't this may be causing my code to miss the first clock edge.
Added firmware code to use the second data line - still no joy at getting anything but black to register in the printer.
I've stared at this code for far too long. I thought I'd found the bug several times but still no go. The printer is incrementing the third byte of the eeprom data which means it must be able to both read and write to it.
The logic analyzer has been in the country for several days now. I should have it for the weekend but I'm pretty busy with other things.
|The mega-8 chip emulator having its pulse taken.
I picked up the logic analyzer this afternoon and the first capture has a huge amount of information and confirmed my suspicion that the printer reads my chip, write to it and attempts to read it back again and this fails.
|A slower data capture showing the printer trying to access all 7 chips.
If you click the above image you can see the chip access at printer start-up. You can see 9 chip accesses taken about a quarter of a second.
However the sync line sometimes makes a false start and goes low again. Also the power usually goes off between accesses but not always. You can see activity on data line A in the fifth access as my chip is being read. Next access the clock slows down when the chip is being written too. However there is no data in the next access as the chip is read again - this is the problem I need to track down.
|A zoomed in view to show the printer reading my fake chip.
Zooming in to the period when my chip is read (about 10.5 ms) we notice the clock isn't constant and is interrupted twice. This is not a problem for a synchronous transmission. We can also see the sync makes a false start, goes low then high again. My AVR software is coping with it.
|Zoomed in more to show more detail of the first few bytes being read reading my fake chip.
Zooming is some more we can see the timing is greater detail.
We can't trust the analyzer to show the power up delay because we don't know the rise time. The analyzer may see the power pin rise above threshold long before the micro has enough voltage. This isn't a problem because I can easily use a digital output on the micro to show the micro has booted.
If the above capture - power up to sync up is 31uS in reality it is probably less but it doesn't matter if we missed the edge. They way my code works as long as the micro is ready a little before the clock rises all should be well.
Power up to clock reads as 107uS.
The program lights the LED at the beginning of the send data routine and we can see the LED drive goes up 5uS after the fourth positive clock edge.
It usually take 2uS for my micro the raise the data line after a negative clock edge and 3uS to drop it. However when a eeprom read needs to be performed it is slower - like about 7uS. This is still fast enough to have data stable for the rising edge when I'd expect the bit is sampled. These delay could be shortened but it would be a waste of effort.
You can see I wasn't kidding about needs to boot quickly.
The serial clock is normally about 29 Khz. When the chip is written to, the clock slows to under 300hz so the mega-8 eeprom write time is not an issue as long as there is enough delay at the end of the sequence.
|This is where the printer finishes writing the data and starts reading the chip again.
Here I see a huge problem. The printer doesn't wait after writing the data. It is possible the write sequence doesn't end on a byte boundary and the last few clock cycles are just to add a delay - I doubt it but I have to check.
If the chip write does end on a byte boundary. That is if the printer send a multiple of eight bit of data (not counting to 4 bit for ID etc) then the chip will have performed and eeprom write which requires about 8mS to complete.
By attempting to read the chip again we either abort the write or are unable to read.
Time to read the data sheet again...
The datasheet says "If a write operation is in progress, it is neither possible to read the EEPROM, nor to change the EEAR
This explains the problem and also possibly why the black ID works.
After the printer writes to the chip (the mega8) the chip is unable to access eeprom. The ChipID is in a register and doesn't need to be re-read from eeprom so it should still enter the send-data-to-printer routine but the LED indicates other wise. It isn't clear exactly what happen if you attempt to read eeprom while a write is in progress.
In the mega8 I can work around this problem but I'm not sure how people have done it in tiny12 etc which don't have ram. It is possible they don't program the last byte which is sent to the eeprom.
The printer is sending 32 bits ie 4 bytes but the fourth byte rarely changes.
The logic analyzer session for this event can be downloaded here ltcyanok.logicsession (12.23 KB)
You can view it by downloading the software from saleae.com - the software is free and lets you test drive in simulator mode. Simulator mode does allow saved session to be loaded.
I accidentally created a read only chip and it works fine.
Later I ripped out the eeprom writing routines and all is still good (well not really but it looked that way).
Later something is still wrong.
My RO chip only worked sometimes.
I think it depends on what the printer remembers having written to it. I've gone back to plan A which was the modify the W/R chip code so the last data byte is not written to EEPROM thus preventing the problem I had yesterday.
The code is kind of ugly but it works. My fake chip is recognized both at printer power up and after a cartridge change sequence. This is hardly a comprehensive test but about all I can do for now.
The printer doesn't seem too fussy about the data the chips send to it. By sending the same data (black) to all the requests on data line A I can fool the printer into thinking it has Black, LC and LM chips fitted.
With only a couple of bytes being written I could probably forget about reprogramming the eeprom altogether and remember the changes the printer made in RAM or even registers (in the case of the tiny chips).
By sending the black data (or any other colour) data to the requests on data line B as well I can get all the error LEDs out except one - light black.
No idea why at this stage.
As soon as I did this the printer said OK and did an ink charge cycle.
So the main goal is achieved. I can run the printer without any chips on the cartridges.
Phase two is the make my emulated chips self reset. With the startup timing so tight I will probably need to use the main 3V supply not the switched supply the chips normally use.
The printer needs more repair work before I can put my chip extermination program to the test.
Hopefully I can get to it in a couple of days.
|A look at the signals now that the emulator is working. You can see 7 pseudo chips being access on two data lines.
The code is working fine but doesn't auto-reset yet and I'm just about "out" of light black. I will write the reset code soon.
Yesterday I blobified the mega8 board so it will resist the abuse it is likely to get over the year few years. By making it external I can continue to work on it or newer versions without exposing the the printer electronics or stressing the many old ribbon cables.
The mega8 is now powered off the main internal 3 volt supply.
|The polymorphed dongle now plugs into the back of the printer. I can also plug the AVR programmer into the dongle to change the firmware.
When it activated the printer was already thinking light black was empty.
The printer didn't accept that the cartridge had been changed and kept lighting the empty light even after hitting the cart change button and power cycling.
Eventually after a long power down (minutes) it seem to take notice and all is well again.
This is a fairly minor inconvenience I can live with every few months.