It's a Casio FX502P in pretty much perfect cosmetic condition. Unfortunately the display isn't. It's not displaying anything very well at all. It's attempt at displaying Pi shows how bad the LCD is:
Once I opened it up, the problem was immediately obvious. It was battery leakage again. It's not very obvious in this photo but the batteries have leaked in the area of the battery contacts (which are remarkably clean) and the LCD.
The LCD is fortunately connected with zebra strips on this calculator, not heat seal:
This meant that I could dismantle the display and clean it. I also cleaned the tracks that had had leakage on them. the solder resist was loose so I removed it on any affected tracks. You can see that tracks I've cleaned are missing their resist and appear gold in this photo:
Once re-assembled, the LCD is working perfectly. It's got good contrast and the filter is completely free of scratches. It's the best example of a FX502P I've got.
The Casio CP-10 is a neat calculator that has a thermal printer attached. The calculator also has a built-in clock and can do useful tasks such as printing this month's calendar. The date range is also useful as it ends in 2099. The printer is a small mechanism that take standard 38mm thermal paper. I found out that the mechanism is the same one that the FP-12 printer uses. This is a small printer that is designed to attach to a variety of calculators and pocket computers.
I bought a CP-10 to see if I could re-use the printer mechanism instead of the receipt printers that I have bought off ebay in the past. They are relatively expensive (over £20) whereas the CP-10 can be had for half the price, if the CP-10 is listed as non-working. Unfortunately the CP-10 has a NiCd battery pack, as the printer mechanism take a fair current when running and the pack is used to supply that. This means that a lot of CP-10s have suffered battery leakage and failed. This is what had happened to my example. After a brief attempt to revive it I cut off the printer mechanism and attached a blue pill and some extra circuitry.
There's seven transistors, one for each thermal element, and one transistor that drives the motor. There's an input for the home position switch as well. The mechanism has a tachometer output that gives a series of pulses as a magnet rotates near a coil. The magnet is attached to the motor, so this arrangement gives a reading of the motor speed. The pulse may also be used for dot timing. Unfortunately my mechanism seems to have a broken tachometer output. The coil reads 25M resistance, which is a bit high for a coil of wire. (I have since bought a second CP-10, this one shows signs of life and its coil reads 82R, so is much healthier). After trying my own tacho circuit, then copying the CP-10 circuit, then building a higher gain circuit with an op-amp I decided that the tacho output wasn't reliable enough to use. This may not be too much of a problem if the motor is run off a stable supply as the speed of the motor should be fixed. I should be able to time the motor moving from home position back to home position and scale the dot timings appropriately if need be.
The output from my working CP-10 is like this:
That's the calendar printout from the CP-10. The FP-12 has a print width of 20 characters, the CP-10 also seems to have a print width of 20 characters.
My first attempt at printing was a little more basic than a calculator. I turned the motor on and fired one element of the print head repeatedly:
This is a start, at least I'm getting dots. The motor drive also performs line feeds and the dots show that. The horizontal dots are the feed across the paper. the sloping dots are where the head is returning and the paper is being fed. After some work with the code, including adding a font table and using the input from the home switch, this is the output:
This is a test printout that is printing the parameters of the code that printed that section. I am also using 20 characters as the width here, simply because the mechanism is set up for it. There's a row at the top of the characters that is faint, I think this is to do with the ground wiring I have used.
There is also an interesting effect which is best shown in the lines of asterisks. They are darker on the right hand side of the line. I'm pretty sure this is down to the heating of the printhead as elements are turned on. Every time a dot is printed, the printhead warms up a bit. This means that to get an equivalent dot, you don't need to turn the element on quite as long the next time. In the printout above, I have a parameter called 'DEC_PERIOD' which controls part of my correction for this thermal heating effect. You can see that the second from bottom section has a DEC_PERIOD of 1 and the asterisks are darker to the right hand side of the line. The section above it has a DEC_PERIOD of 2 and the asterisks are printed more evenly. The correction code counts the number of elements that have fired, accumulates those counts and uses them to create a 'temperature' for the printhead. The DEC_PERIOD value controls the cooling of the printhead. This does lead to a working correction as can be seen above.
I think the CP-10 code must also be doing something similar, as the calendar printouts above show an even darkness across all the lines.
The CP-10 must also be correcting for supply voltage variations. It runs off four NiCd cells which will present a range of voltages to the motor and hence different speeds of printing. I have attached my working CP-10 to a power supply and varied the voltage. The time to print a line definitely changes, but the characters printed remain in the correct positions. The printout is fainter when the voltage is lower. The code could be using the tachometer signals from the mechanism. I can't do this but I could measure the time taken to print a blank line and use that to adjust the dot timings. Interestingly it appears that the CP-10 does print one blank line after it is powered on. I wonder if that is a timing line and the CP-10 is doing what I will probably have to do if I want to correct for voltage?
Next step? probably a PCB. But do I use a blue pill or STM32 chip? Given the size of the mechanism, a blue pill is a bit on the big side, so I think a chip would be better. The only problem is that there is quite a shortage of STM32s at the moment. I've got a few so that is probably OK.
It decoded the frequencies that the FA-1 sent to a cassette recorder and wrote the data to an SD card attached to an Arduino Due. I had to use a Due as it was the only combination of clock frequency and RAM that could keep up with the data stream coming out of the FA-1.
The advantage of using this approach was that the cassette interface was a well-known format and fairly easy to decode. The disadvantage is the bulk of the final package. To get the data onto the tiny little SD card you need the FA-1 cradle and the gadget. A few weeks ago I suddenly realised that I could cut down on a lot of the hardware needed by attaching a gadget to the expansion port on the top of the FX-502P. This would involve interacting with the protocol that goes over the expansion port, but that shouldn't be a problem. There's a lot of detail here about the expansion port of the FX-602P and FX-700P.
As a base for a prototype I used the Sharp PC-G850 gadget, using the Blue Pill processor and the OLED display. The expansion port signals are attached to the 11 pin Sharp interface connector on the gadget using a cable.
The protocol that the expansion port uses is a bit odd. It seems to be the bus that the processor in the calculator uses to talk to the LCD controller. It has a single bi-directional serial data line, a chip select, a command/data control line and a clock for the serial data. The data packets are of variable length, which makes it a bit hard to decode. Most packets are 6 bits long, there is one two bit packet and a 16 bit long data packet (holding an RS232 type character format that encodes a single byte of data. The clock edge that the data is latched on is different for transmitted and received data. And the data is inverted logic (0 is 3V and 1 is 0V, not forgetting that the calculator uses 3V as it's 'GND' and -3V as its VDD).
Once the signal levels are sorted (use 0 and 3V to power the STM32, invert data to get levels that match the known commands for the FX-602P) the data and clock can be fed to GPIO lines on the STM32, The bus runs at around 200kHz, so there's not a lot of time to process the packets. It is not feasible to have any delays so I run the decoding code purely in interrupts (one on the SP or clock line and one on the CE signal). The timing is so tight that initially I had problems with the serial port disabling interrupts (I presume that is what it was, disabling serial IO removed the problem), those problems went away with later code, but I can still disable the serial port access when packets are received.
The data that is sent and received is held in a RAM buffer, there is no time for access of the SD card, so the RAM buffer is stored and loaded from SD card when needed.
After quite a lot of reverse engineering of the interface (the FX-502P is not quite the same as the FX-602P) including capturing traces of communication between the calculator and an FA-1 adapter, I got some working code that could both send and receive data files from the calculator.
This gives a gateway between the calculator and the outside world. The calculator has a limited number of ways to send information over the interface. It can send or receive a single number (this is the quickest transfer), it can send or receive all memories
At this point the prototype was limiting the code as there isn't sufficient flash memory on a Blue Pill (STM32F103C8) to implement the features I wanted to add. The basic idea had been proven with the prototype, time to move on to a better platform. For that I chose the STM32F103RE device. Or, more accurately I chose the 64 pin QFP package. The STM32F103 family has nice pin compatible genetics, so several devices of different capacities will fit onto a particular footprint. Using the 64 pin QFP I can got up to 1M of flash and 96K of RAM down to 16K of flash and 6K of RAM. There's also a lot of GPIO on this package, way more than I need for this gadget.
It has a small 0.96" OLED display, an SD card module and a programming header that uses an STLINk V2. It also has a serial data header with TX and RX, and a header with 8 GPIOs on it (and power):
The PCB plugs into the connector on the top of the calculator. Optionally the PCB can supply power to the calculator, or it can run off batteries, there's a jumper for that. It's the red one.
I have also used a USB socket breakout board for the USB connection, which supplies poiwer for the PCB and also provides a serial connection. I use a breakout board as the USB sockets have a habit of ripping off the PCBs and taking tracks with them. This way the tracks are on a disposable PCB, not the more valuable one. I've already replaced the USB socket and breakout board on the is PCB...
The code is based on the Arduino platform, so it can connect to the serial monitor of the IDE.
What can it do? Well, it can save and load programs and memories to and from the SD card, that's the basic function. It also uses several 'special' values to do other things. Things like displaying programs on the OLED display:
With GPIO lines you can interface any I2C device, such as a real time clock. This is the STM32 displaying time in a display mode set up by the 502, using a DS3231 RTC module:
You can also read the time (and date) into calculator memories:
Of course, it is useful to be able to print things out now and again. Interfacing a simple thermal printer isn't difficult. The one I used accepts serial data so I attached it to the serial data header .The calculator can set up a print flag that sends programs and memories to the printer as well as SD card.
This printer does require a 2A supply, so can't run off the USB direct from the PCB.
There was a printer that attached to the FX-502P, but it used magic metallised paper which is pretty much impossible to find these days, so a thermal paper option is a nice alternative. See here for more magic metallised paper experiments:
As well as the RTC, I've attached a sensor module and an accelerometer, but haven't done much with them other than read registers. There's also a text mode where the calculator has a text screen that it can place ASCII text on, and a graphics screen that it can place pixels on.
More information on these videos.
The gadget should work perfectly fine with an FX-501P, as it's the same code and hardware in the calculator as shown in this video:
The FX-602P and FX-601P use the same interface but a slightly different command set. It should be possible to get it to work, though, with some changes to the firmware on the gadget.
The FX-702P tantalisingly uses the same connector as the 502/602 series calculators, and the same command set as the FX-602P, but unfortunately uses 5V signalling rather than the 3V of the 502/602. The pins used on the STM32 for the calculator interface are 5V tolerant, but there's a couple of issues. The first is that the STM32 should be able to sense the 5V logic levels correctly, but may have trouble driving 5V levels due to 5V tolerant pins still driving at 3V3. The second issue is that the data line is bi-directional and the 5V tolerance on STM32 devices only works when it is configured as an input. I have serial resistors on the calculator interface lines, which might help, but if there's a time when driving the interface that I drive the data line as an output and the calculator does the same then there could be problems. I may try this in the future, as it may work.
Thursday, 24 December 2020
Casio CQ-1 Recreation Information
Until I tidy up the github repository, here's some snippets relating to the Casio CQ-1 recreation.
The first PCB is really a prototype as well, it just fits in the case better than the first prototype.
It was a weird machine, I suppose, but it was a clock, and a stopwatch, and a calculator, which makes it pretty useful. And the calculator could tell you what day of the week any date was (well, in it's date range). It could calculate the number of days between two dates. And it was an alarm clock.
Not so long ago the batteries leaked and the CQ-1 was binned. This was a shame and I decided to get hold of another one, so bought one on ebay. This didn't turn out too well, as the device would only start up if I held my finger on one of the clock oscillator pins. I tried simulating a finger with various components, but the little chip seemed only happy with my finger. I never found out why, so I bought another CQ-1, hoping to either get enough bits to fix my original CQ-1 or get a unit I could fix. That didn't work out too well either, as it was utterly dead, and no amount of fingering could get it going again. Aargh!. Third unit and this time all was well. It calculated dates and the stopwatch worked.
At least all was well until I came to use it after a day or two and the AA battery was flat. Aaargh! again. This CQ-1 has a strange fault where the supply that powers the VFD display seems to power up repeatedly even when the unit is off, and that eventually flattens the battery.
So, I decided to have a go at designing a replacement for the CQ-1 main PCB. This is the one that has the circuitry on it. This is a partially stripped PCB:
It attaches to a keyboard PCB which has one of the AA battery connections on it. The wire tabs connect to two 1.5V watch batteries that power the clock circuit.
The first attempt at recreation is this:
There's a prototyping PCB (one of Mike Harrison's prototyping boards) with all the circuitry to create the voltages to run the ARM processor (3V3)and the higher voltage needed to run the VFD segments and digits (about 23V). The filament drive is conveniently 3V3 (ac). The PCB is attached to the front half of a CQ-1 which provides the switches and keys. All this circuitry runs off a single AA battery, or USB. As batteries are an evil that has to be tolerated, I did consider running this off just USB, but decided that it was too limiting. i didn't want to use the original CQ-1 PSU as I've never seen one, and USB is just so convenient. I haven't carried over the silver oxide batteries that run the clock, instead the RTC chip runs directly off the battery. It is a low power chip so that's not a problem. If there's 3V3 then it runs off that too, so you can plug a USB cable in when changing the AA battery.
This is a close up of the prototype PCB.
There's a blue pill providing an ARM processor, programmed with an ST-LINK. There's two dc-dc converters, one to go from 1V5 to 3V3 and one to go from 3V3 to 23V (-ish). The 23V supply is switchable from the processor and turns the display on and off. The VFD is driven from a MAX6921 chip which has a serial connection to the processor. The timekeeping is provided by an MCP7940 chip with it's own crystal. This is attached over I2C to the processor. i took a VFD tube from a donor CQ-1 and that is used as the display. The beeper is also from a CQ-1. Due to the STM32F103C8 on the blue pill not having enough GPIOs to handle all this hardware and scan the keypad, a GPIO expander is used on this PCB to provide more GPIOs. This is accessed using I2C.
Of course, this doesn't fit in the original case, so a V2.0 PCB has been created that does:
This is basically the same circuit, but the dc-dc converters are now in component form on the PCB, and the GPIO expander has been dropped as a larger STM32 chip with more GPIOs has been used. This is capable of all the IO and keypad scanning. It also has more flash and RAM (512K of flash and 64K of RAM). As the STM32F103 chips are all very compatible there are a few options for flash and RAM simply by fitting a different variant of the chip.
I've also added the connections for an OLED display on this PCB so if the CQ-1 VFD is broken then you can use a dot matrix OLED display. The 23V dc-dc converter can be left out if the OLED is used, as well.
Here's the first populated PCB in a case:
It fits nicely, the wires coming out are the ST-LINK programmer wires. The USB power goes in through the battery cover latch hole which I filed out so the USB socket was accessible. The circuit should run off a single AA battery as well (the prototype did, but I've not tested the new PCB yet). I'll need to print a connector for the positive terminal of the battery, the negative is a spring on the keypad PCB.
Here's the front side of the PCB:
Again the beeper and VFD tube are from a CQ-1. The keypad PCB is mounted using 0.1" plug and socket connectors, the spacing was perfect, even though the original CQ-1 uses copper strips held together with plastic.
The PCB needs a modification as I got one signal wrong, the keypad connector is out by 0.1" for five connections, the 23V dc-dc converter inductor whistles, and the mounting hole for the beeper is too small, but other than that I'm very happy with it. It fits the case well.
There's a few things left to do. The display is a bit dim, which is probably the 23V dc-dc converter needing to be 26V or so. There's a lot of code to write if this is going to be the same as a CQ-1 but there's a rudimentary stopwatch and integer-only calculator, together with a clock you can't set, but writing the code is the fun bit...
See it working here:
Some pictures of it operating:
The USB cable that is powering it and the programming wires that come off a header on the PCB:
And displaying some characters that the original just can't manage:
Wednesday, 26 February 2020
Bus Sniffing Replacement Display for Fx702p
I've had bad experiences with heat seal connectors in the past (Casio PB220) and wasn't very happy to find that a broken Casio fx-702p had a heat seal connection from its main PCB to the LCD. The display wasn't working and when I had a look at the connector it had broken tracks. After buying some conductive paint (water based carbon), I had a go at repairing the tracks. This was going well until I pulled the LCD end of the connector ribbon at one side and the connections to the LCD just ripped off. The ease with which this happened might have been a clue as to why the fixes I was doing with paint didn't seem to be affecting the bad display at all. It looks like the LCD connections were dodgy as well. Fixing the LCD end of the connections is not something I think I will have much success at, so I ripped the entire connector off.
This made repairing the device out of the question at the moment as I have no way to connect the LCD to the PCB. After a bit of thought I wondered about attaching a totally different display to the LCD connections and get display output that way. This is theoretically possible, but as the LCD signals are multi-level (essentially analogue) and there are a lot of them (dozens) it would be difficult to capture the data needed to rebuild the display. The decoding of the signals isn't trivial either.
So I had a bit of a think and decided that an easier way to get a display would be to attach a sniffer to the bus that the processor uses to talk to the display controllers. Then I could capture the data going to the display controllers and put that on an external display. The fx702p would not have it's original display but at least I'd be able to use it. Then I thought about what else was on the bus and it got even better. The RAM chips that give the 702p its memory are also on the bus, so I could snoop reads and writes to the RAM and have an idea about what the programs stored in the RAM looked like. And any other data in there. This was looking feasible and interesting.
After some wiring
I had a logic analyser attached to the bus and I managed to capture bus traffic:
This actually shows the message that the 702p displays at power on. The bus is four bit, though, so you only get nibbles displayed, and the 702p doesn't use ASCII for it's characters. The values starting 1 5 in the photo are the sequence:
1 5 4 4 0 4 3 4 8 5 F 0 F 4
If you turn these into bytes (reversing each pair of nibbles) you get:
51 44 40 43 58 0F 4F
If you check out a 702p character set map (such as this one http://www.pisi.com.pl/piotr433/fx702cod.png) you will see that these character decode like this:
51 R
44 E
40 A
43 D
58 Y
0F (space)
4F P
This is obviously the start of the 'READY P0' message that is displayed at power on.
Interestingly, this appears to be data sent to the display controller. When the CE lines for the RAM chips are examined, there appears to be no access to the RAM chips at all at start up. It looks like initialisation of the memory is done within the internal memory of the processor.
The next step was to use a logic analyser to decode as much of the display data as I could and then display it on the LCD. The final sketch uses interrupts to handle the bus accesses to the two display controllers and the main loop of the code to display the data.
My logic analyser has a slow 9600 baud connection for dumping traces, so using it to capture bus traces was time consuming when I was transferring the data from the analyser to a PC. Because of this I created a build option for the sketch that captured traces very similar to my logic analyser trcaes in the ISR. These traces are then decoded by the main loop and the data is displayed from them. This leads to a fairly large (2 or 3 seconds) delay before data from the ISR is displaye don the LCD, and also sometimes causes a trace buffer overflow and loss of cycles. It's a lot faster when looking at bus cycles, though, as the serial port runs at 2Mbps. In normal ISR mode I also dump display data over the serial port so whatever is displayed on the 702p is available as a serial data stream.
There's a video showing it working and some description here:
The connections inside the fx702p require some fiddly soldering, but several signals can be taken from test pads, which is easier than soldering to an IC pin (which some signals have to come from).
I connected the signals to the blue pill using a milled PCB which makes the wiring much simpler than point to point. The physical layout of the board and components was for ease of debug and there are logic analyser connectors which aren't necessary any more. The whole thing could probably be designed to be much more compact.
The fx702p is normally powered by two 2032 button cells, which poses a problem as that can give a maximum of 6V when fully charged. The blue pill is a 3V3 device with 5V tolerant inputs. I therefore power the fx702p from the 5V supply of the blue pill and make sure that all signals from the calculator are going to 5V tolerant pins. This keeps the signals from the fx702p within safe levels. The calculator seems to run it's circuitry at the battery supply voltage, there's no regulator.
The latest incarnation of the display uses a milled PCB to simplify the signal connection from the calculator to the processor.
The arrangement could be shrunk down, this PCB was a breakout board and has connectors for logic analyser signals, and was definitely not designed to be compact. I don't think the new electronics would fit into the case of the fx702p very easily, and I haven't seen a display that would fit in the space left by the old one. A better layout could be done though, and I may do that now I have the code and hardware essentially working.
Some sample displays. This is the power on display:
The 8 BB is part of a debug display of the annunciator data.
This is the MODE 1 display:
And this is a calculation ready to be evaluated:
There's some extra annunciators on that last display
Saturday, 11 January 2020
More Magic Metallised Paper Experiments
I've been trying to make paper that works in the Casio FP-10 printer. See the previous post for attempts one to six:
Anyway, I was watching an episode of Wheeler Dealers and Edd mentioned that you use a conductive spray primer before you spot weld, sometimes. That was interesting as I had been looking for conductive spray paint. A quick google and it appeared that yes, this primer was indeed conductive due to either zinc or copper in the spray. Not only that but it as available at a local auto supply shop.
One trip to the shop later and I had a can of pretty expensive zinc spray paint. It was no problem to then spray a sheet of A4 paper:
When dry the surface is similar to the magic paper, and even shines up a bit if you rub the surface:
Unfortunately, even though I did measure some conductivity when drying, the paint seemed to not be conductive when dry. I did a couple of sheets with varying numbers of layers and ran some test strips through the printer:
As you can see, it's a bit messy and clogged the print head as the final product is quite thick. It also didn't work.
Attempt 6b
I then had an idea about testing the paper. I set up a PSU with 15V on it and attached one wire to the paper then dragged the other wire across the paper. This gave me an idea whether the paper would spark erode or not. The real Casio paper worked fine (as expected), but the only paper from my tests that worked was the 'gilded' aluminium one. Here's some scribbles I made, which are spark eroded. The black you can see is some paint I sprayed under the aluminium, just like the real paper.
Even though this manual test worked, it didn't print in the FP-10.
Saturday, 7 December 2019
Magic Metal Paper
In the seventies, Casio created the FP-10 printer for the fx-602p.
It could also be used on other calculators like the fx-502p and fx-702p. Like the ZX Spectrum printer it was a spark printer that used metallised paper. This paper is no longer available, at least anywhere I can find. I managed to get a printer for a reasonable price, and it came with one roll of paper. The paper appears to be a layer of metal at the front (aluminium I assume), then a black layer of some kind and then a paper backing. The rolls are very narrow and only a couple of metres or so long. I only have one roll of paper so I decided to see if I could make some paper to use on the printer.
I measured the paper and got a figure of around 3 to 6 ohms per square (very rough measure).
That's a printout from an fx502p, which doesn't ordinarily have any real alphanumeric capability, but the printout does. The printout is very clear.
Attempt One
Aluminium foil. I tried aluminium foil in the printer. This didn't work as the foil doesn't have the physical strength to get driven through the mechanism.
Attempt Two
Stiffen it up. I glued foil to paper to try to give it a bit of stiffness. This also didn't work. The foil tore and I suspect there was no electrical contact between the foil and the metal plate at the front that forms a circuit between the paper and the electronics.
Attempt Three
Try to find conductive paint to spray on some paper. There are conductive paints but they are very very expensive and I didn't try those. I also inquired about silver spray paint that looked like it was conductive. There's no metal in it apparently and it is not conductive.
Attempt Four
I find that there is a conductive paper available. It's called 'teledeltos' and it is used for science experiments and I believe was also used in fax machines many years ago. I bought some (not cheap) and it arrived as a large roll. It appears to be totally unsuitable as it is carbon based and the conductive side of the paper is the wrong side to work in the printer. The resistance of this paper is probably too high anyway at 2000-3000 ohms.
The black side is conductive, but you'd want to print on the white, non conductive side to get contrast. I tried scraping some of the white off so there's contact with the metal plate on the front of the printer, but no sparks at all.
Attempt Five
I tried shiny aluminiumized paper based on a plastic sheet backing. This was conductive on one side but again wouldn't print.
Attempt Six
This involved aluminium 'gilding' foil. This is very thin foil that you can glue to paper (or other surfaces). It results in a shiny silvery effect. I used spray glue to attach the foil to paper as it will not adhere on it's own.
When I measured the gilded paper I got a figure around 0-1 ohms so this is much more in the ball park of the original paper. When I cut strips and ran them through the printer, there were some sparks, but not enough to get a printout.
I'm not sure why not as the resistance seems similar to the original paper. The texture is different though, with the original paper a grey matt surface and the gilded paper much shinier.
Here's a selection of papers that I tried:
That's gilded paper on the left, shiny aluminiumized paper in the middle and the magic original paper on the right.
I also cut some original paper at a shallow angle so the layers become more apparent:
You can see the backing layer of paper, then a black layer and finally the aluminium on top. The black provides a contrast after the metal has been sparked away, I think.
Conclusion
There must be some magic employed in the original paper. It's not just that it is conductive, as none of these conductive 'papers' worked at all. The things I can think of are maybe:
The resistance of the paper is critical to operation. None of the resistances were exactly what the original paper showed, either much higher or slightly lower.
The texture of the paper is important. The original paper has a distinctive matt finish. If you scratch it with your fingernail then you get a metallic shine, so there's aluminium there.
The thickness of the paper is critical. I doubt the papers I made are exactly the same thickness as the original.
The printer has been finely tuned to print on just the original paper. maybe it can be re-tuned to print on other 'papers'.
I'm not sure what to do next. I may have a look inside the printer and see if there's some clues in there.
Posts
