Well actually, back to the more generic type of game scoring device. While RobotSteve gets on with making some rather smashing looking servo controller boards I've been coding yet more for the golf device.

To date we've got

• eeprom driven menus
• up to 4 player support
• Edit player names
• Edit player parameters (handicap and golf tees)
• eeprom driven bitmaps
• Nokia-type joystick support

.
Something to look out for with these Nokia breakout boards is running them at under-voltage.
I left my PP3 (9v) battery connected to the display all night and in the morning the battery was only giving out 7v. This meant - and I've yet to work out why - that only 4.3v was coming out of the voltage regulator, instead of the full 5v (not very regulated then!).
At this voltage, the Nokia screen (which usually requires 5v to drive it) would reset intermittently. This would sometimes also cause the pic micro to reset too. So behaviour was very unpredictable. Also, because of the lower supply voltage, the joystick values did not read true, and the logic to decide which button was pressed did not always work either (with the effect that the menu selector would appear to pick random entries from the list, instead of the one immediately above/below the highlighted entry).

Below is a video showing Nokia development so far.
It shows how eeprom-driven menus can move control onto a new screen (screen refreshing is slow because we're reading bitmap bytes from eeprom at just 400khz, not a the full 20Mhz that the chip can run at) and also how to edit player details.

Once perfected, these techniques can be used as the basis for other game scoring devices - after all, most games involve picking one or more players, entering their names, and providing some extra information (such as handicap/tee preference in golf, maybe boule weight or team position - pointer, shooter, middle - for petanque and so on).

In a break from all the golf coding of recent weeks, a previous project made a welcome reappearance this week - the multiple usb servo controller. Welcome in that it gave us an opportunity to actually complete something and get that warm fuzzy feeling that so often accompanies putting a project to bed!



The hardware development is complete. Data can be sent to the device using a USB connection, and is as easy as copy-and-pasting a list of bytes from the online editor. Below is a video of the test app used to send data to the servo controller board eeprom. You can see the data values and see them being played back in the video above:



A new version of the editor is currently in progress and when complete can be found, along with a whole host of support materials, at www.botbuilder.co.uk.

Work is almost complete on the online golf course editor.
Below is the link to a preview version of the editor.
http://www.scoresure.co.uk/golf/coursedetails.asp?courseid=ABCDEFG&holeno=1

Meanwhile, the first golf-oriented menu and bitmap has found its way onto the Nokia screen. Here is the main menu for Score Sure Golf Pro:

Work on the Nokia 6610 display and joystick continues at quite a pace and with the eeprom-drive menu code complete, it's time to get down to the nitty gritty of actually (re)building our ScoreSure Golf Pro digital scorecard device.

One of the planned features of the device is to download golf course data from the website www.scoresure.co.uk. This means putting it up there in the first place! Which means not only an online editor, but some method of recalling and displaying the golf course information - Adobe Flash seemed a perfect choice for this, and it is anticipated that the golf part of the website will be a mixture of HTML/XML/Ajax/Javascript and Flash.

http://www.scoresure.co.uk/golf/coursedetails.asp?courseid=ABCDEFG&holeno=1

The golf course hole information has been recreated using the course guide booklet and scorecards, available from the golf shop and online.

...especially when they're attached to a Nokia 6610 breakout board. This little fella provides 4-axis input (plus a "fire" button) using a single input pin. It's quite clever really, but simply uses a load of resistors, to change the input voltage depending upon which direction has been pressed.
Put the input from the miniature joystick on the Arduino Nokia board onto pin A0 of a PIC microcontroller and read the input values.



The Oshonsoft PIC18 the command for reading an analogue input is:

Adcin 0, joystickvalue

This takes the input from analogue channel zero (in our case, PORTA.0) and writes it to the variable "joystickvalue".
During testing, with an open connection (joystick centred, no movements made) the joystick value wavered between 169-170. At first this seems odd, but looking at the schematic datasheet we can see that the reference voltage from the joystick is between 0v and 3.3v.

Taking the average value of 170, and given that we're storing this data into a byte variable, we can see that (170/255)*5v = 3.3v.
So it all makes sense again - with no joystick movement, we expect to receive 3.3v from the joystick onto our analogue pin. And the value 170 does indeed represent a 3.3v signal when our PIC is powered by a 5v supply.

A simple routine was put together to write the value of the joystick input onto the Nokia screen. The following was determined:



This translates quite nicely into a simple subroutine for any project that uses this board. The routine waits for the joystick to be moved, stores the direction into a variable then waits for the joystick to be released again.
The routine can be called from anywhere in the program, though it might work quite nicely if called from a timer interrupt, since the user input is stored until the microcontroller is free to process it.

Dim joystickvalue as Byte
Dim jstick(5) as Byte
Dim buttonpressed As Byte

jstick(1) = 126 'right
jstick(2) = 88 'up
jstick(3) = 60 'down
jstick(4) = 26 'fire
jstick(5) = 4 'left

---

getbuttonpress:
  'single input ADC for joystick press
  Adcin 0, joystickvalue

  'compare current joystick value to stored values
  'at rest returns 172-168, first value is 120-122 for "right"

  If joystickvalue < 140 Then
    For i = 0 To 4
      If joystickvalue < jstick(i) Then
        buttonpressed = i
      Endif
    Next i

    'debounce the button press
    WaitMs 1
    Adcin 0, joystickvalue
    If joystickvalue < 140 Then
      'wait for the button to be released
      While joystickvalue < 140
        'keep sampling the joystick to see whether it's been released
        Adcin 0, joystickvalue
      Wend
    Else
      buttonpressed = 0
    Endif

  Else
    buttonpressed = 0
  Endif

Return

---

One thing that quickly comes to light when working with the Nokia 6610 display - it has no libraries of its own to use: that means that you have to hand-code pretty much everything for it, including making your own fonts and writing your own bitmap display routines.
This means that your code bloats up pretty quickly.

In fact, to demonstrate using bitmaps, drawing strings of text, and including USB support (in order to send commands to the display to test different combinations of things) our code is already a whopping 9.4kb in size.
That leaves around 15kb of space for actually coding that the device should do (on a 18F2455 chip anyway). So almost half of the available program space is taken up with libraries for controlling the display! (ok, it also includes a routine for reading/writing to eeprom, but that it itself is only a few hundred bytes big!)

In fact, forgetting about the eeprom routines could be quite a mistake - instead of hard-coding menu data into the program memory (which strings to display and in which order) it makes a lot of sense to put these strings into external memory.
This offers two distinct advantages: firstly, you're not filling all your program space with strings of characters that make up the menus (you can just use a double-byte word to keep track of the eeprom address that contains the string to draw for each menu item). Secondly, it means porting your device to another language (it's wishful thinking, but there's a massive European market for electronic golf scorecards too) is a relatively painless task: simply update the strings held in eeprom using an external app and your original device code does not need to keep being amended and recompiled. Interesting idea....

Taking this idea a step further, instead of just storing strings in memory, I've decided to store the entire menu structure in eeprom.
The block diagram looks something like this:

• Each menu begins with a title
• C = count the number of items in this menu
• X/Y = position on screen this menu should be displayed at
• goto = pointer to eeprom address of the next menu to be displayed

The "variable" C has two functions:
The upper three bits are flags to tell us:

• Clear the entire screen before drawing this menu?
• Remove this menu after selecting an item?
• (reserved)

The remaining lower bits contain the value (1-31) telling us the number of items in the list.

The variable "goto" has some special/reserved values:
0 = do nothing when any item in this menu is selected
65535 (0xffff) = go into edit mode when any item in this menu is selected

"Edit mode" puts the device into a special state, where each character of the menu item can be highlighted and changed, individually. This means that, for example, player names can be put into a menu (so that a player can be selected) but at the same time, player details can be updated (e.g. change the letters of a players name).

If the variable "goto" has a valid value (i.e. a number between 1-65534) then this is the eeprom memory address containing the next menu. The current menu is cleared from screen (if necessary) and the new menu is drawn.

Here's a sample menu, converted to a byte array and written to eeprom

84, 105, 116, 108, 101, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 12, 20, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 52, 0, 0, 0, 0, 0, 0, 0, 0, 0

You'll see how the first byte is 84 (ascii 84=letter T), followed by 105 (ascii 105=i) and so on, spelling out the word "Title" and some padding bytes. The values 4,12,20 are the C,X and Y values, followed by the next line item in the menu: ascii 77=letter M, ascii 101=letter e (and so on, spelling out "Menu item 1").
Here's the resulting menu, drawn on the Nokia 6610 screen:

There have been some exciting developments with our Score Sure Golf Pro game scoring device recently: namely that we've managed to get a full-colour Nokia 6610 128x128 display working with a PIC18F2455!

What does that mean?
For our ScoreSure range of devices, it means the hunt for a stable, decent screen is finally over! It also means the whole thing will fit into a much smaller enclosure, making it much more "pocket-friendly" and therefore more likely to gain acceptance. There were concerns, after seeing the original device actually working on a 128x64 mono glcd, that it might be getting a bit big and bulky. Of course, it also means we now how a full-colour display (although it'll still mainly be used as a mono device, due to memory/storage constraints!) but the odd splash of colour here and there won't go amiss!

It also means that there's now a library of PIC-based functions available for drawing bitmaps, writing text/displaying fonts AND creating menus. Readers of earlier posts will see that we've already had monochrome bitmaps displayed - the bug that stopped rending the image properly came from the VB app used to convert the image into a sequence of bytes and NOT the PIC rendering code (so the list of bytes you see in that example cause a white line to appear under the golfers feet).



Using the work done with an earlier GLCD the Nokia 6610 can also display strings of text. Unlike mono GLCD displays, where a vertical "slice" of 8 pixels for each character is sent in a single byte, the Nokia 6610 uses a single byte PER pixel. So that means breaking each character down into 5 vertical slices, then looping through each byte, and checking the status of each bit in the byte.
If the bit is set, the value for the "foreground" colour is sent - if the bit is not set or zero, the value for the background colour is sent to the display.
Thus strings of text are always drawn inside a box and you need to match the box background colour with the background colour of the display to avoid having big stripes of colour all over the screen.

To make our display more readable on the Nokia 6610, the fonts have been redesigned. Each is still 5x8 pixels, but this time a single pixel spacing remains at the bottom of each character. The character height has also increased by a pixel.
Below is a screenshot of how the characters were drawn using a homemade VB app to convert pixels into byte-slices:



The fact that strings are drawn inside boxes can be exploited for drawing menus.
By setting the background colour to one different to the colour of the display, when a string of text is drawn, it appears to be inside a coloured box. It is easy to imagine that a simple "if" statement can be used when rendering a menu to decide whether to use the default background colour (black/white) or the highlight colour (red) when drawing a string of text on the screen.
When the menu bar needs to be moved, the string of text that is highlighted is simply drawn again, this time using the default background colour.

The characters were redrawn and deliberately centred vertically inside each 5x8 grid (as best could be achieved) so that when drawn using a different background colour, they did not appear off-centre.

Here's a screenshot of the output acheived using these fonts: