The Data Memory Map

The following image has been extracted from the datasheet of the PIC16F648A, as it’s the PIC we are currently using as ‘main brain’.

It’s main task (and the one that’s currently being coded) is to solve a given sudoku. In order to solve a sudoku, we need to store it’s data into memory. That’s what I’ll cover on this post.

As you can see, the data memory map is divided into 4 banks.

The GPRs (General Purpose Registers) are basically where you can store whatever you want to. There are three groups of GPRs (banks 0-2).
Positions 70h-7Fh are globally accessible (which means they can be accessed no matter which block you are currently at), so they are great for ‘global variables’.

So yea, 3 groups of GPRs (not taking 70h-7Fh into consideration):

• Bank 0: 20h-6Fh
• Bank 1: A0h-EFh
• Bank 2: 120h-16Fh

A sudoku is composed of 81 cells (9 rows and 9 columns). Each of these cells can have a value ranging from 1 to 9 (or it could be still unknown if it’s not been solved).

We are going to store columns 1-3 at bank 0, columns 4-6 at bank 1 and columns 7-9 at bank 2.
That means 27 (81/3) cells per bank.

Now, what to store per cell? We are going to do it like this:
2 bytes per cell.

First byte: each bit (let’s name them from 1 to 8) will indicate if that given number can be (or is) the value of that cell.
Second byte: first bit will indicate if number 9 can be (or is) the value of that cell, and the other 7 bits will be used for other purposes (such as a flag indicating if that number has a sure value [aka one and only one of the previous bits equals 1], a flag indicating if it has removed its sure value as possible from the rest of the cells of its column/row/zone already, etc.).

So, for example, if a cell has a value of 3, its corresponding 2 bytes in memory will look like:

0010 0000 0XXX XXXX (X at the flags, since you don’t care about their values =P)

If a cell had a value of 9, it would look like:

0000 0000 1XXX XXXX

And so on. Also, if a cell is unknown (aka it wasn’t one of those whose value they give you at a start):

1111 1111 1XXX XXXX

So, there are 3 banks with GPRs, three columns of the sudoku will be stored at each, and each cell of the sudoku takes 2 bytes.

This means that we will need 2 bytes * 3 columns * 9 cells = 54 bytes for sudoku data at each memory bank.
We will use:

• Bank 0: Positions 20h-55h
• Bank 1: Positions A0h-D5h
• Bank 2: Positions 120h-155h

The GPRs that the sudoku itself won’t cover will be used to store temporal values (‘variables’).

So, basically, that’s how it’ll be organized. More to come!

Hello PICs!

We are going to use PIC microcontrollers to control our robot, and we are going to program them in assembly (yay for low-level coolness and total control!).

We plan to use a PIC16F648A (256 bytes of RAM for us to use, not much, just for it to be more exciting) as the main brain. It would be in charge of solving the sudoku and controlling (asking for information, and receiving information from) other, smaller PICs (12F675).

We had our first meeting (the trigeeks at my basement!) last Sunday, and since then we’ve started working harder!

Now I’m going to show you some videos so you can see some of what we have been doing. Follow the links (click on the videos) for a more detailed description of what’s going on in them.

Our very first test with a PIC (we had never used one before!):

Dealing with 7-segment displays:

And finally, our current masterpiece in terms of hardware. A first prototype of the colour sensor that will be used to detect different pieces (1-9). Also, note that here we have two PICs working together. =)

trigeekz was born today!

minolo3ds, jacano and me founded trigeekz today. We are the guys behind this Guitar Hero III bot (yes, I have to write a few posts about it here, I just didn’t have time.. yet).

Just three geeky friends who like working on cool projects (current one: Sudoku Solving Robot). ^_^

By the way, there should be some juicy posts about the robot soon. We have been doing some stuff… just don’t be impatient. =D

Movement: Decision taken

We are going to use the system they used in the checkers bot I mentioned a few posts ago.

Guitar Hero: Aerosmith

Heh, it’ll appear on June. Looking great in my opinion, can’t wait.

In case you didn’t know. I’m a Guitar Hero freak. =P

Mitnick

Download it here!

After finishing Hell’s Gate, I really didn’t want to get into a big project again (not without some time to “rest”). And this is one of the little things I made in that time.

Released on December 2005, Mitnick is quite a simple minigame in which you use W to speed up, always move towards the mouse pointer, and use mouse left button to shoot and mouse right button to throw “ultra-bombs”.

Nothing out of the ordinary if it wasn’t because the game is an OSG (One Script Game). For those users of Game Maker that will ring a bell. If not, it’s a game where the .gm6 (.gmk, or .whatever other versions of GM use) only contains a script, an object and a room. The room only contains an instance of the object. And the object only contains an event: Draw. The event only contains one action: execute script (guess what script it executes? Right, the only one it contains).

So yeah, it was more fun to program than to play. That’s why you can download both the executable version and the editable version here, to let you take a look at the (1075 lines of) code.

It was my first OSG, and I learnt quite a lot in the process of making it. I made a better OSG some time later. That is Sivor, and I’ll post about that one soon. =)

Download it here!

Movement and design

Just some thoughts.

Our robot needs to be able to move both on the x axis and the y axis in order to be able to go through the whole board. It would optimally be able to move diagonally but it’s not required.

It could either be sort of an independent vehicle that moves on the board (1), or it could move over the board, suspended on some structure (2).

(1) Would require cells to be quite separate, so that the robot can move among them without touching/moving them. Diagonal movement isn’t that simple to achieve. Actually, having both horizontal and vertical movement isn’t that easy to achieve either… you either need some sort of wheels that can change the direction they are facing, or have both wheels pointing horizontally and vertically, and activate only the ones needed… not too fond on that.

(2) Sort of the same system they use on these things.
A friend of mine made a checkers bot some time ago, and he used that scheme, you can take a look at his robot (youtube video) here.

Option (2) is the one I will vote for. =P
(Note how it uses electromagnets to pick pieces, too. Our robot should behave similarly in that aspect aswell.)

Harder than we expected?

It’s taking us a bit to get started.

We first thought about using Lego NXT, but oh well, we don’t really have direct access to one (even though they have some at the University but hmm…) and they are expensive, way too expensive for our limited budget. =P

So now we are going to try to go the cheap way. That means using microcontrollers (I personally hadn’t used one before, and neither had my friends…).

We found some sort of good introduction tutorial for Atmel ATtiny2313, and there’s where we’ll start. Soon (quite a few exams arriving, oh no!).

So what problems will we have to face? Many. Some of them are:

• Movement
• Piece detection
• Piece picking and dropping

About movement, well, we want it to be able to move both on the x and y axis, so that it can easily go through the entire board (first for an analysis of which pieces are given as initial data, and then to pick and drop the appropiate pieces on the adequate locations).

Piece detection? We want the robot to know what number the piece below it represents. We are thinking about using cromatic sensors.

Piece picking and dropping: we could have the robot physically grab pieces, or we could use an electromagnet.

I’ll elaborate more on those topics in future posts.

It’s cool that we are finding some support. Actually, whenever we tell someone about the project, they want to help. Guess it’s a charismatic robot, ours (at least in our imagination, wahey!). But really, there are a couple of guys that will be of great help, I’m sure. ^^

Hell’s Gate

Download it here!

So I thought I’d write a bit about the games I’ve made in the past, and this sounded like a good way to begin.

Hell’s Gate is, I would say, the first “real” game I made. I had obviously made smaller game-ish experiments before, but nothing I would want to show here. ^_^

Platform/adventure/action game.
Let’s show a couple of screenshots first:

Released on August 2005, so it’s old. Actually, now that I look at it, it kind of sucks. But oh well, it was a real accomplishment at the time, and I was really proud of it.

You control three soldiers, and must take them through a few levels (around thirty) visiting the jungle, mountains and even Hell! Each soldier has some unique skills that should make him needed at some point =P.

It was made by the SpanishGM’s clan, formed at the GMClans, and whose leader was me. I’ve got to thank jmgandalf (the spriter behind Hell’s Gate, and old friend of mine) for his dedication to the project. Without him it would have not been possible. Many others helped making the game, but those you can check in the in-game credits. =)

So yeah, it should take around ah hour and a half to beat, and comes with tutorials and minigames. Nothing too fancy, but hopefully not too shitty either. The result of around 8 months of work. It was made using Game Maker 6.0.

We got quite good reviews at the time, scoring 8.0 at the GMG, and we got 2nd at the GMClans competition it was made for. Not bad for a first try!

Download it here!

Guitar Hero II contest!

Hoho! There’s a GH II contest in my city in a few weeks. Needless to say, I’ve already signed up. I had never played GH II before (well okay, I had played Guitar hero 80s) but I do play GH III a lot.

So yeah, I got a copy of GH II and have started training. Wish me good luck! (I’ll need it)