It was another of those frustrating can't-seem-to-get-anything-done-tonight nights at BuildBrighton last night. I took all the wrong gear along (wrong PIC chips to code up for our electronic board game, forgot the clamp for the SOIC programmer, there was no solder left at the space anyway) so left the electronics-y stuff and made another stand for my Army Painter paints.
Thankfully the laser cutter was behaving (though cutting at 15% speed to ensure a good cut is painfully and tediously slow) so I managed to get this knocked up in a pretty short space of time:
The centre hole is for 16mm dowel - 15mm is more common, so edit in Inkscrape as necessary.
Inks and paints together look pretty cool. Now I just need to learn how to use them to paint some decent miniatures!
While we've been putting together double-sided PCBs for our electronically enhanced board game prototype, and painting miniatures for forthcoming publicity shots, it's not been all fun, fun, fun. In between the light being too bad for painting in the evenings, and the latest stuff from Farnell still not having arrived, we've been cranking out some code too. Using - what else, but - Adobe Flash CC?
Here's a quick run-through video of development to date.
It's all looking quite exciting and using this new digitally enhanced method of playing boardgames, we'll be able to offer:
Play over the net with anyone
True hidden movement (so your opponent can't see you setting up your ambush ahead of time)
Have multiple games on the go at once
No tracking hit points, health etc with onboard markers or scraps of paper
No more buckets-of-dice-rolls, long-winded arithmetic or looking up results in tomes and tomes of results tables
Fast, frantic playing pace
Sound effects and atmospheric background music
Obviously the usual caveats are in place - crappy coder art and images "borrowed" from Google Images need to be replaced, interface needs smartening up etc. - but the functionality so far is looking very encouraging...
With a bit of imagination, it's possible to see how the same mechanics could be adjusted for just about any board game type - sports simulator, dungeon adventure, even some of the old classics like Monopoly or chess!
We've been avid users of Oshonsoft's PIC simulator for a long time, here at Nerd Towers - not only one of the best simulators we've seen for Microchip's PIC range, but a great compiler, working with a really easy-to-learn BASIC style language. But as the range of PIC micros has increased, sadly Oshonsoft failed to keep up. Now we're often finding that the best/cheapest PIC from the Microchip product selector can't be programmed using our favourite coding IDE.
A while back we used SourceBoost (C compiler) to write some pretty heavy-duty code (reading SD card data). Since then we've done a few other projects, and each time have leaned pretty heavily on previous examples to set up the fuses on the PIC, just to get a "hello world" blinking LED example.
So here's how to get started coding with Sourceboost C and how to use the datasheets from Microchip to get a simple "hello world" example running...
(we're assuming that SourceBoost is correctly installed, and can compile correct code into a burnable .hex file: there isn't room here to discuss setting up the IDE!)
Firstly, create a new project with source code file
Double click the .c source code file to start editing.
Note that the main system.h file is already included.
At this point, we need to tell the IDE which PIC/microcontroller we're targetting. For this example, we're going to use the 16F722 chip (because some arrived in the post about an hour ago, so why not?)
Behind the scenes, this tells the IDE to include the appropriate header file for the target chip. A quick rummage through the Program Files\SourceBoost\Include folder reveals the .h header file for our 16F722 microcontroller:
Open the header file up in a text editor and you should see a whole load of registers and values that the compiler will recognise as being related to this chip. Often (though be careful of a few gotchas) these match the values given to registers (and bit values) in the datasheet. Quite often. But not always. So it always pays to have the header file as a reference!
Now take a look at the datasheet for the PIC and check out the configuration bits.
Reading microcontroller datasheets is an art in itself. Starting to code from a datasheet is infinitely more difficult than, say, hacking a few lines of Arduino code together, but also gives you complete control of the lower-level workings on the chip. No nice, abstracted libraries here - you're gettingn your hands dirty!
To keep our hardware set-up nice and simple, we're going to run this PIC off it's own internal oscillator, at 16Mhz (so no need for an external crystal or resonator then - just give it some juice and let it run!)
Starting with configuration word number one, we're going to set each bit of the special register CONFIG1 to get the PIC running exactly how we want it. We do this in SourceBoost by using the #prama DATA command. From the header .h file, we can see that SourceBoost has called this register _CONFIG1
We set the _CONFIG1 values by using the bitwise AND operator to join them together.
From the datasheet, we want _DEBUG off, PLL on (to set the clock speed to 16Mhz) brown out reset BOREN disabled, code protection _CP disabled, MCLR tied high (use RE3 as input), power up timer _PWRTE disabled, watch dog timer WDTE disabled, and the fosc (clock source) to be the internal oscillator with no clock out.
This is where the header file comes in really handy.
The SourceBoost C variables and the datasheet names don't always exactly match up. But from our header file, we can see that the combination of config bits we want should read:
(note that some variable names translate back to the same value/register. So it doesn't really matter whether we use _MCLR_DIS or _MCLR_OFF, both have the same value. Likewise for the oscillator selection, _INTRC_OSC_NOCLKOUT and _INTOSCIO both have the same value 0x3FFC)
Configuration word 2 is much similar for this chip.
We simply want to disable all Vcap activity on all pins
And lastly, tell our compiler the clock speed that the device will be running at (to assist with compiling pause/delay macros later on). Hit the build button and if all has gone well, the last line of the report should read "success" followed by "done!"
Right.
Now the PIC should be running under it's own steam when powered up. That's to say, it's using it's own internal oscillator as a clock source, so when it's given power, any code inside the "main" function will get called. So let's write some simple code to get our "hello world" program working:
There we have it - a simple LED blinking program. But we're not quite done just yet.
There are still a few more registers to set up. That's why we have the "initialise" routine. Here at Nerd Towers we just got into the habit of creating an init routine, rather than putting everything inside the main loop. It's just personal preference - that's just how we roll....
Now PICs are awesome devices. They're multi-function and one chip can have hundreds of possible configurations; many have A2D (analogue-to-digital) converters on the input pins, a lot now have capacitive sensing on a lot of the input pins, and almost all can configure their pins as either inputs or outputs (and in some quirky, charlie-plexing programs, sometimes change between the two, or set to high-impedence: neither input nor output!)
So we need to tell the PIC what function we want the pins to take on.
We'll start by setting the input/output direction of the pins, using the TRIS registers:
Back to the datasheet - we've got loads of different ports to configure. Our chip has PORTA, PORTB, PORTC (and even a PORTE) defined on the pins. So we need to set the appropriate registers to define theses.
We're going to make the whole of PORTA (i.e.any pin that is labelled RA.. such as RA0, RA1 etc) an input.
We're going to make the whole of PORTB outputs (it's perfectly acceptable to use a combination of inputs/outputs on a single port - for example, make RB0 an input, RB1 and RB2 an output, RB3 an input and so on)
We're not really bothered about PORTC but for completeness, we'll make it an output too.
A quick check of the header file and we can see the TRIS register variable names:
If we want to make all the pins of PORTA inputs, we need to set the value b11111111 (in the tris register a one represents "input" and a zero represents "output"). To make PORTB outputs, we set the tris register to b00000000. If we wanted to make, say, RB2 an input, and all others outputs, we would use the value b11111011 (or 251 decimal, 0xFB in hex).
Now, it's not really critical for this example, since we're only concerned with outputs, but debugging input pins that don't work properly can be a real nightmare if you've forgotten to turn off the A2D converter module on each bank of input pins.
We just got into the habit of actively disabling analogue on our pins - some chips default to "off" but most chips have the A2D converters "on" at boot-up. To change the analogue settings on a PIC, we need to set the ANSEL registers. Our particular PIC has two sets of A2D, on both PORTA and PORTB.
Back to the header file, and we can see the variable names we need:
So the last thing to do is make our i/o lines all digital and make sure all output pins are turned off:
Build the file, then go digging about in the debug folder (our SourceBoost is set up to create debug versions of the .hex file during testing) and burn the .hex file to your PIC.
After a weekend of painting (and repairing the allotment shed roof) I'm in two minds about Quickshade.
The initial use of it on some Tyranids and Cadian Troopers was very encouraging - it brought out the details beautifully with very little effort, and added a layer of varnish protection over the paintwork.
I've already ruined a couple of miniatures using the anti-shine matt paint outdoors, in the cold, possibly when it was a bit too damp. So this time, I was determined to follow the instructions to the letter, and make sure conditions were perfect for spraying. I made a little spray booth in the kitchen, made sure it wasn't too hot, nor too cold and sprayed from not less than 20cm and not more than 25cm away - in fact, pretty much everything the Army Painter guys said to do.
The result?
More badly powdered, frosty-looking miniatures, complete with crazing effects! In short, a terrible finish and more miniatures destined for the bin.
With this in mind, I've been trying the water-based 100% colour-match strong tone ink. I love the tin of dip idea, but if it's going to create such rubbish looking results, I'll stick with the water-based ones. But they are not quite the 100% colour match claimed on the label:
The model in the centre was coated with the tin of brown gloop, the outer models using the water-based acrylic strong tone. 100% colour match? Not really.
Personally, I think the effect on the robot models using the water-based strong tone looks just right for them. Dirty, grimy, industrial-looking is just right for robots on the battlefield. But there's also a massive dis-colouration, whereas the brown gloop keeps a lot more of the original colour, and a lot of the underlying vibrancy of the colours.
Water-based strong-tone is great for achieving a dirty-looking industrial effect
The dirty grimy look isn't ideal for all miniatures though - these were heavily discoloured using the water-based strong tone. So much, that I had to re-paint the shaded colour with the original base-coat. This has got rid of the nice shaded effect that Quickshade gives, and now looks more like the two-tone light-on-dark painting scheme I was trying to get away from.
There's much discussion online about "frosting" of miniatures. Apparently it's not uncommon when using spray varnish - so far we've not had great results (and at the same time, had some really cool results) using both the brown gloop and the water-based strong tone.
While I really like the effect on the robots using the water-based toner, I think the brown gloop is much better suited to the soliders - if only there were some way of reducing the shine without ruining the figures.
Adding a splash of the water-based anti-shine that came with the Army Painter Mega Set on a previously spoilt Tyranid helped reduce the powdery frosted effect (but did re-introduce a bit of a sheen) so perhaps there's some hope...
The water-based anti-shine also helped restore a little bit of the Cadian Shock Trooper - though many of the details that the Quickshade picked out so well were lost, and large areas (like the helmet and shoulder pads) still had a nasty speckled effect all over them.
Before anti-shine, the details on the miniatures were picked out with sharp constrast but left a high-gloss finish on the miniatures
Anti-shine definitely takes the shine away - but sadly, also the colour vibrancy and model details!
I think I'm going to have to burn through a few more minis to get the combination of shade and anti-shine just right. Word has it that brush-on matt varnish works more consistently than spray. Hopefully this will work, as the original Quickshade had so much promise. I'd love to get back my initial enthusiasm for the Army Painter range!
The other day I took delivery of some Army Painter Quickshade Inks from Ian at www.ibuywargames.co.uk. He's already selling them at 10% less than RRP. With the 10% off voucher from a previous purchase the total cost was just over £11, including delivery!
It's not the cost that matters though, it's how they perform that we're interested in, so I set about trying the inks on a couple of (unfinished) models. I've been painting some soldiers to use in the up-and-coming publicity shots for a game we're working on called Starship Raiders. Originally I was going to use the Games Workshop Cadian Shock Troopers (who look more like "regular" soldiers, than their over-armoured Space Marines) but was advised against using too many GW miniatures in any promotional material. Apparently GW are a bit over-zealous in guarding their "intellectual property" so I'm now using non-branded minis, from a variety of sources.
To really try out these inks, I thought I'd have a go at painting a miniature as quickly as possible. After all, the product is called Quickshade. And the water-based inks means no hanging around for 48 hours waiting for varnish to dry, nor messing about with anti-shine matt varnish.
I took a plastic robot model (from e4m miniatures robot range) and base-coated it quickly with white primer (it was actually too late in the day to be spraying, so I painted the primer and based coat colour on with a brush, but then end result was still a totally white figure). Then I coated the whole thing in Quickshade Dark Tone.
The water-based inks leave a lot of pigment colour on the surface, not just in the creases. In the Army Painter painting guide, they even demonstrate that the ink is heavy heavily pigmented by painting an ork face green by simply applying green ink over a white base coat
Personally, I think the effect is rather impressive, left at that: if ever I had to paint an army of Orksies, I'd just ink them green, and pick out the details like eyes and teeth, and call it finished!
Because of the heavy colouring, our all-white robot quickly became a dull grey:
(this is how quickly I was trying to paint: I just kept hold of one leg of the model and splattered ink over the rest. I'll finish the other leg now the rest of the model has dried!)
The water-based Quickshade is obviously not shiny (like the varnish-based tin of gloop) but it's also not quite as brown, once dried (though the ink does look brown while being applied). This model had a really generous coat of ink.
Once dry, I picked out a few details (the bits on the shoulders, the little bits sticking out of the legs and the visor). Lastly I added a thin line of white back over some of the edges of the armour.
And that's it. Although it's not going to win any awards, I think the model is certainly well-painted enough to earn a place on the gaming board. And given this only took about an hour or so (and admittedly, I've not painted the arms yet) it's quite feasible to have a squad of ten or a dozen robots painted up over a wet weekend - now that the weather's turned, it might come round sooner rather than later.
Now it's time to finish the game board and try to actually play a game on it - with some nicely painted miniatures!
Last night was another BuildBrighton Open Night, which meant loads to do, loads of visitors, plenty of tea and pizza - and relatively little done! That said, we did manage to get our first (and hopefully, only) double-sided PCB ready for testing.
here's the board with most of the pcbs pins soldered in place
on the top side the PCB pins stand about 0.9mm proud of the PCB surface
The through-hole vias are big clumsy PCB pins from Maplin and some of the pads didn't line up perfectly on both sides (though never more than 1mm off, so all the pins did actually hit a trace on the opposite side).
The heads of the pins are proud of the top surface which is a bit of a pain - we're going to have to create a much fatter separator layer, to avoid getting lots of dimples appearing on the top (printed) layer, once assembled. But it should still prove that the PCB at least works (or doesn't, as the case may be) before we send the design off to be manufactured.
the final board, all soldered up and cut to size
adding magnets to the edges of the board
To be honest, Steve did most of the assembly work. He has an eye for detail that means everything is cut and aligned "just so" - far better than I might have left it (copper boards cut with a hammer and joined with string and sellotape).
Soldering the magnets onto the edges was more fiddly than we'd expected.
Firstly, of course, they stick to the tip of the soldering iron! And if you let a magnet get too hot, it starts to break down and stops being so magnetic. And these magnets were mounted into acrylic edges on the board, so as well as stopping the magnets from breaking down, we also had to make sure the plastic didn't melt while the solder was applied!
The final board looks very good and all the pads have been tested for continuity.
Assembly of lots of boards might be problematic with magnets as edge connectors.
Personally, I love the idea of putting two boards edge to edge and they just go "clink!" and join together. But it's fraught with difficulties. If any one of the four magnets is slightly more proud than the others, there's a potential for a break in the continuity of the entire circuit. The magnets will pull the boards together as closely as possible - but if one it further forward than the others, not all magnets might actually touch.
To solve this, future versions will use pin headers and sockets to connect the boards together. This should also make assembly of each board section easier too, as well as make the connections between boards a little more robust.
But this board "works" in that the pads on the top can be bridged with a piece of conductive material, and the continuity traces out to all the correct pins on the microcontroller pads.
Next step is to program up a PIC (we've got some 28 pin 16F722 chips here to try out) and actually send the correct serial data back to a host controller as each pad on the surface is pressed/released.
After a successful evening etching circuit boards at BuildBrighton last night, Steve insisted on issuing a retraction to a statement made earlier this year: creating etching masks for PCBs with a laser cutter can be a quicker and easier than using press-n-peel - especially for enormous great big boards.
So why were we eching A4 sized circuit boards at 10pm last night anyway?
We'd already decided that a custom-made PCB was the way forward with our board game idea - now it was time to prove it!
Using full A4 sheets of press-n-peel was a non-starter: with so much ink on the board, getting a consistent, clean etch would be almost impossible - as a large quantity of toner melts, the entire blue sheet starts to float on a great big puddle of liquid ink, resulting in blurred traces and smudged filled planes with just the tiniest bit of movement during the heat transfer. We've done A5 sized boards before now, using press-n-peel, and may one in three worked well enough to get a clean etch. Trying to effectively make four of these boards in one go just seemed like trouble! So it was time to give lasering another go...
We used the same Halfords Matt Black car paint as before and set the BB laser cutter into action. It took about 30 minutes to fully etch the paint off a full A4 sized copper clad board:
The important step that we'd missed last time, was giving the board a generous wipe over with some white spirit, to clear away the vapourised paint off the exposed copper tracks. Cleaning the board thoroughly before etching allowed the ferric chloride to work much more quickly on the copper. Also unlike last time, we used a PCB etching tank, complete with heated ferric chloride and an aerator (bubbler) to help improve etching times (and remove spent ferric off the surface of the board, without having to constantly dip the board in and out of the brown sludge)
The result was a pretty impressive, super-sized PCB (the edges have yet to be cut to size, but that's a job for once everything else is in place.
We did consider making a double-sided pcb, but lining up two sets of traces on one single board, with so many vias (this board has about 94 vias) seems quite tricky. Normally on a homebrew double-sided board there are three or four places where getting things lined up is critical, so you can use large pages and give yourself a little bit of "wriggle room" should things slip slightly. But because we couldn't be exactly certain of getting the laser to etch the opposite side in exactly the right place on the reverse (and because it takes so long to etch) we decided to make a separate pcb out of much thinner copper board and simply glue it to the underside of this board, once aligned in a few places.
Our thinner copper board wasn't quite A4 sized, so we put two sheets together and made sure the join was nowhere critical in the top layer design. Then it was time to set the laser going and discuss the days events over a brew - it would be another 30 minutes before the next board would be ready!
With the second boards cleaned, and dipped in the ferric chloride, we pretty soon had all our copper etched and ready for drilling.
checking the etch quality by holding the board up to a bright light - any non-etched or badly etched parts would be easily visible.
The question now was whether everything lined up correctly!
The PIC microcontroller sat in the right place and lined up with it's own pads, so things were looking quite promising to begin with...
So now it was time to put the boards together and see if the whole idea actually worked. Obviously drilling the boards separately would be time consuming, so we thought it best to place a couple of pins in opposite corners and get the boards lined up, back to back, then drill through both layers, at the same time, for each pad.
The few locating pins lined up beautifully on both sides of the board (one pin was about 0.5mm out but that's a level of deviation we can work with, on 2mm pads). The boards were pressed firmly together and the pins soldered on the underside.
The resulting board is starting to look very promising indeed.
In the photo you can see the hand drill used. Originally we put a 1mm bit into a Dremel, but this does tend to grab a bit when drilling. Because we don't want even the slighted bit of deviation from the centre of each hole (to give us the best chance of hitting a usable part of the pad on the other side) we resorted to drilling each hole by hand.
With 88 squares (it's an 11" x 8" board) and a few extra power/connector vias, there are a total of 96 vias on this game board. So far we've drilled six. Tomorrow night's BuildBrighton meet-up is going to involve a lot of drilling!
