## Lights out!

After spending hours playing Primrose, I decided to code a little board game using GGI during a week-end. I don’t remember how but I ended on the Lights Out wikipedia page.

The gameplay is quite simple. You have a 5×5 board with tiles randomly switched on. Well not really randomly because it’s frustrating to have an unsolvable board ;). Your goal is to switch all the tiles off by pressing them. The problem is that when you press a tile, the four adjacent tiles are toggled on or off (see it as an xor).

And voila! It’s a very basic implementation. It features simple graphics, no text nor title screen…

Damn, 9 months since last post… It’s not as if I had nothing to say. It’s quite the opposite in fact. So now the question is… Where to start?

## Fireballs of fire!

EEK! 6 months !

It’s not that I had nothing to write. On the contrary, I have a lot to post. I just didn’t found the time to write… Erm.. Let’s go with a 7 months old stuff.

While working on the tracker, I wanted to add some kind of “live” mode. The user could choose which sequence to play, modify it, control volume, add an effect etc… So I came with the idea to associate a command to a key combo.

Combos are detected by walking down a tree. Each time a button is pressed, we look at the current node and check if one of its children is associated to this button. If that’s the case, this child becomes the new current node. Otherwise there’s no matching combo and we reset the current node to the tree root. If the button pressed didn’t not changed for a certain amount of time (timeout), we check there’s a child corresponding to the current button. This way, we can detect combo containing a sequence like “press A button during t seconds”.

Let’s look at a simple example.

Mkit will successively return : DOWNDOWN+RIGHTRIGHT0 (aka nothing) – A

We have 0 because when you go from RIGHT to A, there’s a moment when you don’t press any button. And as we check keys every vsync, we necessary get 0 (unless if you are Superman on Redbull).

Consider we want to handle the following combos :

The combo tree is very similar to a lexical tree. A node can have 0 to N children but only one parent.

The tree is store in level-order with the longest path first. This means that you’ll have to be very careful and store node children by their depth. We have for our example :

Root – Down – A – Down+Right – Down+Left – Nothing – Left – Right – A – Nothing – Nothing – Leaf – A – B – Leaf – Leaf

In the current implement, the tree is stored in 2 arrays. The first one contains the index to first child of a node. And the second the key for each node.

```combo_tree : 1, 3, 5, 6, 7, 8, 9, 10, 128 | 2, 11, 12, 128 | 0, 128 | 1
combo_keys: .db 255, JOY_DOWN, JOY_I, JOY_DOWN | JOY_RIGHT, JOY_DOWN | JOY_LEFT
.db 0, JOY_RIGHT, JOY_LEFT, JOY_I, 0, 0, JOY_I, JOY_II```

The root is always at index 0 and we associate the key value 255 to it.
The tree traversal algorithm is very simple. For a given node i, we know that its children are at indices j from combo_tree[i] to combo_tree[i+1]-1. And that we can reach them only if the current key is combo_key[j]. If the bit 7 of a value in the children list is set, this means that we have a transition a leaf. The remaining bits are used as an index to a jump table.
The traversal looks like this:

i // current node index
for(j=combo_tree[i]; jCOMBO_DEFAULT_DELAY in combo.asm). Note that in current code combo_tree, combo_keys and combo_jumpTable are in RAM. So you’ll have to initialize them before-hand.

If you have any question, feel free to leave a comment or go and join the [PCEdev Forum].

Talking about web stuff, I finally updated the gallery. Hurray!

## Micro SDisco

Some months ago, I bought a 4DSystem’s µDRIVE-uSD-G1 (microDRIVE) from Sparkfun. It’s basically a serial module which let you access a microSD memory card (from 512Mb to 2Gig). You may wonder why use an external module as SD cards have a SPI interface? The main reason is … laziness. All file-system operations are performed by the module. So why bother coding fat16 support or whatever? Unfortunately, the current microDRIVE firmware only supports raw access.

Anyway, I wrote a small module for the current firmware. It was implemented as a template in order to support various serial implementations. The serial class must provide the following methods :

• void print(uint8_t)
• int available()

It’d have been better if all the serial implementations derived from a same interface. But as I didn’t want to modify the base Arduino code (and as i said earlier, because I’m lazy), I went for the easy/brutal way. And you’d probably never have more than one microDRIVE. At least you want raid 😀

I tested Arduino‘s HardwareSerial and SoftwareSerial, as long as ladyada’s AFSoftSerial. None of the software implementations work 😐 Only soft read is working (hardware tx was used). As software serial is working for the serial LCD, I think the problem might be the autobaud detection during microDRIVE initialization… Or not…

Be careful! There’s a bug in the rev1 firmware. The internal memory address is not incremented to the next sector block after a write operation. It was corrected in the rev2.

## MazinSer LCD

Woohoo!

I just got my hands on a 20×4 serial LCD from Sparkfun. It’s basically a standard LCD with a little PIC based serial TTL interface board plugged on it.

10 lines of code and 3 wires later, I had a wonderful “Hello world” displayed on screen. The only problem is that I was using pin 1 (TX) which is shared with the serial USB interface. So when the sketch is uploaded, it’s also sent to the SerLCD. And you end up with garbage on screen. Hopefully, Arduino comes with a soft serial class. It lets you use custom pins for serial communication. The only downside it that it can only run at 4800 baud or 9600 baud.
Next serial fun : 4DSystem’s µDRIVE-uSD-G1.

Here’s the result!

The mandatory piece of code.

```#include <softwareSerial.h>

#define SERLCD_CMD                  0xFE

#define SERLCD_CLEAR                0x01
#define SERLCD_MOVE1_R              0x14
#define SERLCD_MOVE1_L              0x10
#define SERLCD_SCROLL_R             0x1C
#define SERLCD_SCROLL_L             0x18
#define SERLCD_DISP_ON              0x0C
#define SERLCD_DISP_OFF             0x08
#define SERLCD_UNDERLINE_CURSOR_ON  0x0E
#define SERLCD_UNDERLINE_CURSOR_OFF 0x0C
#define SERLCD_SET_CURSOR_POS       0x80
#define SERLCD_CURSOR_OFF           0x0C

#define rxPin 6
#define txPin 7

void setup()
{
char *str = "BlockoS! :)";
char *cursor;

SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);

pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);

mySerial.begin(9600);

mySerial.print(SERLCD_CMD, BYTE);
mySerial.print(SERLCD_CLEAR, BYTE);

mySerial.print(SERLCD_CMD, BYTE);

for(cursor=str; *cursor!='\0'; ++cursor)
{
mySerial.print(*cursor, BYTE);
}
}

void loop()
{
/* Nothing */
}```

## IPS delivery (part 3)

Happy new year!

Just after Christmas, Tomaitheous released Bubblegum Crash patch. Yeepee!

As it’s an IPS patch, I tried to patch the rom with the wonderful ips patcher. Unfortunately, it was unable to patch it. I had a nice “Record offset is out of file bound.” error.
All was IPSProcessRecord function fault. First, I considered the file offset to be out of bound if it was superior or equal to the file size. But if you are appending data to a file, the offset is equal to the file size. Second, I never updated the patched file size. So If we keep appending data to a rom, the bound test will fail.

Anyway! Everything is fixed now. And I was able to successfully apply the patch. So go grab the latest version here:

And as usual, feel free to contact me or leave a comment if you have any request or problem.

## IPS delivery (part 2)

Here it is! The gtk version of the ips patcher I wrote earlier.
It’s based on GTK. And I use Glade to create the interface.

I thought I’d have to implement zillions of callbacks but in the all I had to to is attach the IPS structure to the main window, implement a callback and add a thread.

This was also the occasion to clean up and simplify the IPS code.

Here are the mandatory screenshots!

• Main window :

• Error window (it’s a little too big in my opinion 🙂 ) :

• Success window :

## IPS delivery

Today I wanted to try the translation of Metal Max Returns. This game looks really cool. As I’m super lazy, I ran the windows version of snes9x through wine. I haven’t tested the 64bit version yet. I realized that there’s no IPS patcher under linux. So once again I had to run a win32 IPS patcher (arkana ips) using wine.

I was wondering where there wasn’t any IPS patcher under linux… Maybe the IPS format is a real mess. In fact it’s the total opposite. It’s really simple.

I coded my own patcher in less than 2 hours (including testing). Here’s the quick non-documented code :

Here’s how you use it :
`Usage : ips-patch ipsfile inputrom [outputrom]`
ipsfile is the filename of the IPS patch to apply.
inputrom is the filename of the rom to patch.
outputrom is the filename of the patched rom. It’s an optional argument. If you don’t specify it, the input rom will be saved in inputrom.sav and then overwritten.

I’ll try to add some GUI later if I have enough motivation 🙂

## Double Bit Dragon

In my quest for demo effects I’m studying zoom. 2 days ago while looking at the code for right shifting signed bytes, I realized that this technique can be used to “double” a byte.

Here’s a little schema showing byte “doubling”:

 b0 b1 b2 b3 b4 b5 b6 b7

 b0 b0 b1 b1 b2 b2 b3 b3 b4 b4 b5 b5 b6 b6 b7 b7

How can signed byte bit right shifting can help us?
Signed numbers are represented in two’s complement. I won’t explain it here. But when you are shifting a negative value to the right the most significant bit is replaced by 0. However this bit is always 1 for negative values. A way to solve this issue is to use the right bit rotation instruction (ROR) instead of the right bit shift instruction (LSR). ROR shifts the bits on position to the right. The carry flag is shifted to bit 7 and the bit 0 is shifted to the carry flag. We must copy the value of the 7th bit to the carry flag. We’ll use the CMP for this. The carry flag is set if the value in the accumulator is equal or greater to the compared value. So comparing the accumulator to #\$80 (128) will do the trick.

We’ll use this technique to “double” the bits. First we shit the source byte to the right. The least significant bit will be in the carry flag. Then we rotate the accumulator to the right. The carry flag is then shifted to the 7th bit of the accumulator. We compare the accumulator to #\$08. The carry flag is now equal to the 7th bit of A. Rotate the accumulator to the right one more time. Et voila! 🙂

This macro reads a bit from the source byte and adds it twice to the destination.

```doubleBit .macro
lsr <__src
ror A
cmp #\$80
ror A
.endm
```

And finally here’s the code to “double” a 8 pixels long line. You’ll have to repeat it for each lines. If you want to double a tile on pc-engine you’ll have to call this of code for each “line” (32 times).

```    cla

doubleBit    ; bit 0
doubleBit    ; bit 1
doubleBit    ; bit 2
doubleBit    ; bit 3
sta <__dest

doubleBit    ; bit 4
doubleBit    ; bit 5
doubleBit    ; bit 6
doubleBit    ; bit 7
sta <__dest+1
```

We now have the basis to make a complete zoom-in routine! 🙂

## Dataflash Gordon

Last month I ordered some DataFlash (AT45DB161D) chips from Sparkfun. The AT45DB161D is a flash memory with SPI interface. It’s able to store up to 16Mbits of data.
With the DataFlash library for the Arduino in one hand and a solder iron in the other, I was ready to test the beast. Unfortunately the chip is an 8 pin SOIC. So I had to solder it on a SOIC-to-DIP pcb. Luckily Sparkfun (again) was selling an 8-Pin SOIC to DIP Adapter. With my legendary bad luck, I realized afterward that the SOIC connectors were too small. I had to bend them a little 😐 The soldering was a massacre…
Anyway, after what seemed to be an hour (in fact it was only 5 minutes) I was finally over with the whole mess. I plugged the DataFlash to the breadboard and connected it to the Arduino (important note : it was an old NG revision). I had to make a simple circuit to convert the 5V output from the Arduino to 3.3V. After a bunch of attempts which ended in burning a 3.3V voltage regulator, I run the test program.
And … Nothing happened. I was getting a bunch of 0000 and FFFF. And the result was the same even if the chip wasn’t connected to the Arduino.
To make things short after destroying another DataFlash (I broke the pins) and hazardous code experiments, it appeared that the old revision of the Arduino NG had problems with SPI.
This was a good excuse to buy the new Diecimila Arduino board 🙂 The 9V output was changed for a 3.3V one. I didn’t need my dummy circuit anymore. I also bought a bunch of 8pin SOIC to DIP pcbs from ebay (larger than the Sparkfun ones). The soldering work was easier this time and everything was setup for testing in less than 10 minutes. I uploaded the test program to the board…

Miracle, it worked!

The Arduino DataFlash library was written for the B revision. A lot of things changed from the B to the D revision of the DataFlash. This was a call to write a new library. Unfortunately the on I wrote is specific to the AT45DB161D. It only supports standard page size (528 bytes) and all the security commands are unimplemented. I first need to get extra chips before working on it as these commands can brick the DataFlash.

You can grab the AT45DB161D library for the Arduino here :

You’ll have to put those files in \$ARDUINO/lib/targets/libraries/at45db161d (\$ARDUINO being the name of you arduino directory).

[Documentation] (Doxygen rules)

[Example code]

Now, I have to find out how to interface the Arduino board to the pcengine. I think I’m up again for a month of painful experiments 🙂