Samstag, 17. September 2016


Flash player is requires for this post!
Back in 2009 I had a blog about flash game development. After taking it offline I've got some requests to put some content back online. Today I found a backup of the blog and some posts still seem to be interessting to me. So I'll repost some of them here. This is one of them.

This is no informative post, but I like mandelbrot :-)


Flash player is requires for this post!
Back in 2009 I had a blog about flash game development. After taking it offline I've got some requests to put some content back online. Today I found a backup of the blog and some posts still seem to be interessting to me. So I'll repost some of them here. This is one of them.

You can reload the page to see different effects.

Some weeks ago I needed some eye candy for my latest game. The easiest way was to put some plasma in the background. But mostly plasma algorithms generate a repetitive pattern and i wanted a better one.

I found this post in david's blog:

Unfortunatley this program is written in blitzmax, a language I don't know at all. But the syntax is easy to understand, so it took just some hours to port it.
I have added one nice feature. You can define how many lines are calculated by render circle. So you can screw down the fps of the plasma effect and use the CPU for what you really want to do.

p.s.: My favourite line of code in this project is

if ( ubyte[plasma_id] & 128 )
                            ubyte[plasma_id] =  (~ubyte[plasma_id])&0x7F;

It's a very good example of the power of bit operation.

The flash version is from 2010.
In the meanwhile I wrote a javascript version too:
(Drag the mouse to animate and rotate color.)
Interactive Plasma written in java script.

rendering ISO-tiles with blender

Back in 2009 I had a blog about flash game development. After taking it offline I've got some requests to put some content back online. Today I found a backup of the blog and some posts still seem to be interessting to me. So I'll repost some of them here. This is one of them.

For a project I am planning I want to render iso tiles with blender. After some research with google and in some blender forums, I just found no satisfying solutions. So I had to build up something myself. First let's consider the situation in an iso game to get some cornerstones for our system to work efficiently.

1. Buildings and landscape tiles need to be rendered from four directions.
2. Creatures need to be rendered from four or eight directions depending on the game design.

This leads to a render scene with eight cameras.

3. We need a system to synchronize all properties, positions and angles of all cameras. This makes the perspective of an object stays the same if we use the images of a different camera in the game.

That leads to a system where:
- all eight cameras are looking exactly at the same point.
- all eight cameras are at the same distance of the focus point. So, their positions are building a circle around the the focus point with an angle of 45 degrees between each camera.
- all eight cameras have exactly the same properties, like focal distance, ...

I am not an expert in blender, so it took me some hours to build up a system providing all that points.

How does it work:

1. I created an empty at {0,0,0} and named it "camTarget". This is the focus point.
2. I created a circle at {0,0,10} and named it "camCircle.001".
3. I created a camera and named it "cam.001". To this camera I added two constraints.
   a) a FollowPath to "camCircle.001".
   b) a TrackTo to camTarget.

4. I repeated these steps eight times, where I duplicated the camera with ALT+D to secure all cameras will have the same properties.
5. Each camCircle is rotated +45 degrees.

6. I added an empty and named it "camRing" all camCircles are child object of this empty.
7. I added an empty and named it "camAll" camRing and camTarget are child objects of this empty.

8. I locked some properties to allow the three empty just to move along the z axis.

That's it.

To change the perspective you can drag camTarget and camRing. To lift the whole system without changing the perspective you can drag camAll.


Blitting - The art of fast Pixel drawing

Back in 2009 I had a blog about flash game development. After taking it offline I've got some requests to put some content back online. Today I found a backup of the blog and some posts still seem to be interessting to me. So I'll repost some of them here. This is one of them.

To display objects on screen in flash games Movieclips or Sprites are used very often. Sure this is the easiest way to handle it and if there are not much objects this is OK. But when performance comes in play there is a much better way to display objects - blitting. Blitting reduces the overhead of managing display objects in the flash player and allows you to use the saved CPU power to display more objects or to use it where you really need it.


Blitting stands for BLock Image Transfer and describes a technique of drawing pixels on screen. The idea is quite simple. Instead of creating tons of MovieClips we create one Bitmap and paint all objects on it. So the flash player has just to manage one object. With flash 8 (I think) the BitmapData object was introduced. This object allows direct access of pixel data in images. And this is what we are going to do.

For this I'll write the same application one version with MovieClips and a second version with blitting. The application will be very simple. It will create moving objects on screen and as long as a certain FPS count isn't reached flash will add one object. If the FPS count falls to much one object will be removed automatically.

The average number of objects on screen will indicate which version runs at a better performance.

I'll not describe how to create MovieClips, but I'll explain how blitting is done.

First we need the BitmapData object. The BitmapData object represents the content of a Bitmap object. It gives us direct access on pixel basis. Additionally we need a Bitmap object. This object represents the display object we can add to stage, we also link our bitmapData object to it. This is the way our pixels comes on screen.

======================== AS3-Source code:begin
import flash.display.BitmapData;
import flash.display.Bitmap;
var screenData:BitmapData = new BitmapData(640,480,true,0x00000);
var screen:Bitmap = new Bitmap(screenData);
======================== AS3-Source code:end

The BitmapData object offers different ways to manipulate its pixel content. The fastest was to bring something to it is the function copyPixels. With this functions we can transfer pixel data from one BitmapData object to another one. We also can determine the position where pixels will appear. For this we need an additional BitmapData object holding the data we want to show on screen. To do this we are simply drawing a MovieClip on it.

======================== AS3-Source code:begin
import flash.display.MovieClip;
var mc:MovieClip = new Unit(); // Unit is the MovieClip in the Library
var objectData:BitmapData = new Bitmapdata(42,42,true,0x000000);
objectData.draw(mc)// this draws mc to objectData
======================== AS3-Source code:end
Technically this is all we need to do.
X and Y describes the point where objectData is drawn in screenData.

For more information about BitmapData object follow this link:

 demofile using MovieClips: Demo with Movieclip
 demofile using blitting: Demo with blitting
 Here you can download the source of the demo files: Source code for demo files

Donnerstag, 2. Juni 2016

The second life of a Casio DH-100

More than a year ago I have got a casio DH-100 on Ebay. Unfortunately it was totally disappointing after getting it.

  • Soldering joints were made unprofessionally.
  • The cover of the battery slot was missing.
  • Flex cables had to be replaced.
  • And the worst thing was, someone has removed the pressure sensor.

Technically the description on ebay was correct, saying "it's just working with breath mode turned off". But I am sure the seller wanted to make buyers believe it's just a small problem that's fixed by replacing a capacitor. However, after some emails I have got the cover for the battery slot.

In the next step I did some general clean up of bad soldering like this one and replacing a flex cable with the cable of a floppy disc drive.

I shorted the legs as much as I could and fixed some dry soldering joints.

The Pressure sonsor

Now there was the biggest problem left, the missing pressure sensor. I found a technical manual that explains the sensor quite well. It's a moving iron core in a coil but it doesn't say anything about the number of loops, length or diameter of the coil or the core. The breath is moving the core which is changing the inpedance of the coil. This change is converted into an analog signal for the CPU.

I tried to contact some service center for those devices to get photos or any information they can provide but I didn't get anything. For the next year the casio was laying around and nothing happened.

Last week I felt it was time for a plan b. I thought I could start playing round with some coils, but this seemed very unprofessional to me and didn't look very promising. So I checked my bench for helping stuff and found a picaxe m20 and a mpx5010. I knew the impedance of the coil is converted into a directed current and the CPU is reading it with an ADC. So my plan was to use the pressure sensor and the picaxe to simulate this analog signal. Of course the m20 didn't have an DAC to create the analog signal. But I remembered an old friend of mine. He created an DAC on the LPT-Port of his 386. This was in the in the early 90s, where sound cards were not the standard. There goes a waving hand to albert for showing off ;-) On Google I found the covox speech thing. The m20 offered enough output pins to build an 8 bit DAC and so I had everything what I needed. Find the schematic at the end of the post.

sensor electronic for EWI

Writing the software took 2 days. It was my first picaxe project and for this I had to learn how to code it. The tricky part was to scale the air pressure to values that are understood by the original CPU.

There are some points to be considered:

  1. The sensor has a pressure range from 0 to 10 kpa.
  2. The actual pressure in the instrument never goes that high. I guess it ends at 3-4 kpa. The instrument isn't a closed chamber, the player is blowing thru it. So there is just a small rise in pressure inside the air channel.
  3. The ADC of the original CPU takes 0 to 5 volts.
  4. The Software in the original CPU just processes values from about 0.5 volts to 1.5 volts.

Sheme of pressure conversion for orig. CPU

On the output side of my module there are two key parameters. The minimum and the maximum output level. The more critical one is the minimum level. If it is too high the horn blows constantly. To be able to adjust this value I added two keys to increase or decrease it. The maximum output level is hard coded and has to be adjusted in the source code(config file). The next key parameter is the relation between the max output level and the max input level. This relation is auto adjusting. The software takes the maximum measured input pressure for the maximum possible value. That means after turning the device on it has to be blown once to adjust your pressure sensor. On the other hand if it is blown too hard the full volume is hardly reached in normal play. So there needs to be a way to reset the auto adjusting mechanism. This is done by pressing both buttons at the same time. To distinguish no breath and normal air pressure there is a minimum sensor pressure that has to be reached to generate any output, otherwise the horn would blow because normal air pressure pushes the sensor.

These are all config values for the software:
  • minimum output level
  • maximum output level
  • minimum sensor data

Connecing the main board

The main board is connected at 3 points. On one hand to get VCC and GRND. On the other hand to feed the original CPU with the pressure signal.

connection points to the main board
analog input pins on the original cpu
The analog signal from the sensor goes to 2 analog input pins of the original CPU. First I disconnected them from the main board(I am not sure if this is necassary) and connected both to the output pin of my DAC.

That's it - on the bread board it was working like a charm!

The last task was to put everything back into the case.
Luckily there is enough space in the case

In the case of the instrument there is enough space to add the pressure sensor and the chip.
The pressure sensor sits next to the speaker
The board sits next to the main board


Userinterface of the device

To the user panel I added two buttons and a 3-Pin-Connector to be able to upload a new firmware to my picaxe.


Please excuse the quality, I had to draw it with Illustrator :-)

For the DAC I used 10 and 20 KOhm resistors
The capacitor has 100 microFarad
SIN = serial in
SOUT = serial out
The MPX5010 is not connected directly. There are some elements used. Please see the manual of your exact chip. On google I found projects connecting them directly, but the manual shows a very small circuit that is recomended.

I made one Failure in this project

I connected the resistors in the wrong order to the output pins of the m20. For this I had to add an option to reverse the bit order of the output data. The schematics below shows my wrong version.

Finally, it's working

Here you can see the output signal on the oscilloscope

Final thoughts

I designed everything to be independent from the casio device. So I made a general module that could be interesting for other projects too.
The original device is working with moving mass. This replacement is working with a pressure sensitive chip. I can't compare them, but I guess the replacement is reacting faster and better to pressure changes.
Firstly using the picaxe looked a bit over engineered to me, but there are some parameters to adjust. And doing this in software is much easier than in analog circuits.
Having the picaxe and the software opens a door to effects that can be build into it.


Finally,  yes my casio DH-100 is now working again and now it's time to learn to play it :-)

PICEWI on GitHub

PROJECT UPDATE 2016-08-27 - Picaxe - Floating serial in

In this project i had serial in of the picaxe floating. This made it stop working randomly.
Please check page 31 of the picaxe-PDF get serial in grounded.

Update 2017-07-22 original pressure sensor

I have got a second DH-100 on ebay for some bugs. It just had a death capacitor, so rapairing it was a question of minutes :-) Now I can compare the original sensor to my own build. I tried both and I can say my rebuild with a modern sensor is much more sensitive and easier to play.

Sonntag, 17. Januar 2016

How to reset the toner chip of a CLP-510, or learning I2C with Arduino

Some weeks ago I have got a laser printer Samsung CLP-510 for free. It replaced my old laser printer with an damaged transfer belt(At this point I didn't know I just refilled the wrong toner what caused the bad printing quality, but that's another story). Of course it didn't take long till I got the message of empty cartridges.

Well, we all know it's not the problem to refill the catridges, but to make the printer believe you have done it. It's about resetting the counter chip on each catridge. Google brought some old articles with broken links to DOS programs and a Raspberry project. Because we are not makers when consuming other peoples work and because of christmas vacation and spare time, I desided to play with it. On top of that it gave me the opportunity to settle two tasks I had in mind for a long time, but never had an opportunity for it. Firstly I wanted to work with the I2C-Bus and secondly I wanted to have a serial monitor with a command history.

My plan was to write an arduino sketch to read and write the chips and a serial monitor which allows to dump the chip content to a file and to write it back.

For all visiters really wanting to refill the CLP-510 I cover the whole process.

1. Open cover


First of all we need to remove 4 screws to open the cover of the chip and the refill opening .
Remove 1 screw from the ride side of the catridge(On the foto the catridge is upside down.).

Remove 4 screws from the bottom side of the catridge.


 2. Refill powder


Next to the chip you can see the round opening. You have to remove the cap with pliers.

Pull the rubber cap to remove it. Hold it with pliers at the rim.
After removing the cap, refill the catridge and put the cap back on the catridge to close it. Be carefull and don't breath this ;-) Finally put the cover back on the catridge and fix it with the 4 screws.

That was the boring part, but now it's getting interessting.

3.Connecting the Chip to the arduino


On the circuit board you find three connection points marked as SDA-CRUM, DGND and SCL_CRUM. It didn't take long to find out this is about I2C and this is where arduino and the wire library comes into play.

Connecting the chip to the arduino is really simple, it just takes two pull-up resistors and some wires.

Pull up the pins SDA and SCL to 3.3 V power source. I am using an Arduino Mega where SCL is port 21 and SDA is port 20. Than connect SDL_CRUM from the toner chip to SDL from the Arduino and SDA_CRUM from the toner chip to SDA to the Arduine. And finally connect DGND from the toner chip to GND from the Arduino. That's it. You don't have to remove the chip from the tomer catridge, I just had one laying round and it's more comfortable to take pictures from it.

We have connected the chip to the Arduino and now we can start to communicate with it.

4. Finding devices on a I2C bus


I never used the wire library before and I was surprised by the small number of methods it has.
On Wikipedia I read each device on a I2C-Bus has it's own 7-bit address and to communicate with it you have to know this address. So firstly I wrote a function to scan for devices on the bus. My idea was to try to read from each possible address and to listen for answers. This worked excelently I found the chip at the first try.


 5. Dumping the chip


This is the point I was excited about and why I did all this. Reading the whole chip and check if received data makes sense in any way. I wrote a dump function which takes the device address and the number of bytes to read. The output is formated as usally. On the left block there is a hex dump and on the right side there is the ascii representation of the data.

Oh boy, I am so glad! I saw "SAMSUNG", "CLP510" and something, that could be a production date "2006.03". This was a real success.

6. Finding the Page counter


Somewhere in this dump there must be the number of pages that has been printed with this catridge. To find the position I printed a page and did a second dump. Comparing these two dumps showed all changing positions when the printer counts pages. There are three position of them. In the next step I printed a configuration report of the printer and luckily it says how many pages has been printed with each catridge. This is a helpful information because now I know what to look for.

Et voila! One of these three positions contained exactly a number from the report.
The printer configuration report shows the page count of each catridge

Dump of the magenta catrigde showing the page counter marked


7. Resetting the counter


Till now I worked with the serial monitor from the arduino IDE. But now I needed something to write the chip content to a file and to write it back to the chip. This is the main reason, why I wrote my own serial monitor. After writing the basic functionality like connectiing to the arduino, sending a string and receiving the response, I started to add the functionality for the dump file.

Writing the dump file back to the chip is done byte by byte and the commands to manipulate a small number of memory positions could have been done by hand without dumping the whole file. This made my serial monitor not nesasary anymore for this small project. But, hey, it was nearly finished at this point and dumping a file can be helpful for other projects too, so of course, I finished it anyway. :-)

Setting the red marked bytes to 00 resets the page counter.

For this project I wrote a Serial monitor which is some kind of a I2C-Console when used with a special Arduino sketch and I want to share it with you. So I uploaded all sources to my Git-Repository.

In one of the next post, I'll demonstrate the capabilities and functions of the tores console.



Serial monitor:
Arduino sketch:

Sonntag, 3. Januar 2016


Just found out, I am a member since 2007. So it's probably time for some posts.