Just before Christmas, I had a kind offer from the folks at PCBWay to work on a small maker project. I saw this as a great opportunity to experiment with some new tech and designed a new board around the Microchip SAMD21G microcontroller.

I’ve always wanted to build a ‘Tamagotchi’-type device, so I designed a simple development board the size of a standard playing card with an 8x8 LED matrix and some capacitative-touch buttons. I knocked my design up in KiCAD in a couple of hours:

and uploaded the files to the PCB website.

Not long afterwards I got these beauties in the post:

I’d also asked for a solder paste stencil. I was a little bit lazy and just added a comment for it to be made the same size as the board and the guys at PCBWay did it for me which was really great. The boards were really good quality - I poked at them with my multimeter to check continuity and everything was fine.

The black soldermask looks so good on bare PCBs.

Using some old PCBs from another project, I taped the stencil down to my workbench:

and applied the paste. I think my paste might be a little bit old but it still looks good. I’d really like to get a little USB microscope so I can take proper solder paste glamour shots!

I then very patiently placed most of the components - I don’t have any RGB LEDs or coin cell holders so I left those off. This is easily the highest component count I’ve assembled so far and it went really well. I was paranoid about the LEDs being the right way around so I check every single one out of the reel-strip!

After blasting it with my hot air gun, I think it looks pretty good:

.

I can power the board via the USB connector whilst I’m developing and I can add the RGBs to it later once I’ve got the matrix working.

My main goal with this board is to build up my Arm MCU development toolchain so getting some code up and running is the next step!

All of the KiCAD files are available in my BattleBeasts Repository - BattleBeasts is supposed to be the name of the Tamigotchi-type game I’m making!

My new boards arrived!

This week I have been mostly soldering my new Glyph console together.

Glyph

New boards arrived for the Glyph this week. This was my first attempt at designing a fully surface mount board. Probably the most challenging part, and the bit I was most worried about was the display. I had to make a custom footprint for the ribbon cable and was a bit nervous about how well it would reflow with a hot air gun.

Turns out, I probably shouldn’t use hot air for soldering these ribbon cables. I had a lot of issues where the solder just seemed to pool together under the ribbon, shorting a bunch of pins together. After I retried with a soldering iron, it worked fine.

Another issue I had was with the 20MHz crystal. Turns out I was actually sent a 3.3M ohm resistor in a package that was roughly the same size as the crystal. Because I’d only used the big oval through-hole crystals before, I didn’t realise. I had to use my Emergency Clock sketch on a dusty Arduino in order to recover the clock fuses so I could run it with the 8Mhz internal oscillator.

I’ve since been able to replace the resistor with a proper 20MHz crystal and now it works! Technically I’m overclocking the ATMega1284P because it is only supposed to run at 20MHz with 5v and I’m running at 3.3v but it seems to be ok.

I posted a Twitter thread with lots of photos of the build process.

Case

I tried making a basic case for the Spike but I struggled because it ended up being a giant game of “move this hole left half a millimeter”, “does that fit around that capacitor?”, “move that hole over a bit”.

This time I was clever. I designed the board outline in OpenSCAD and at the same time I defined areas where all the components could go:

Then I imported the resulting .dxf file onto one of the user layers in KiCAD:

This allowed me to place components in known areas so that when I made a case, I’d know where to make voids.

The basic case is just 2 slices of acrylic cut on a laser cutter and screwed together with nylon bolts, but with the OpenSCAD files I made as a base, I could make a nice 3D printed one too in the future.

Argon

Argon is the first game I’ve ported to the Glyph. It works really well and looks great on the 1.3” OLED.

I made the little LEDs brighten as the ships weapon gets hotter. I’d like to add a few more effects to that too - maybe a glow or flash when it overheats and stops shooting.

I’d also like to expand the game element to include some bosses and the dreaded music.

What’s next?

So, next I want to create some more games and port over all the Spike games I made. I also want to try and get my Isometric demo working to see if the extra 4MHz of processing makes much difference to the performance.

I want to make a better case that encloses the battery a bit better too.

Animation

I wanted to spend some time working on a sprite animation ‘engine’ for Spike. I have a game that already has the sprite data for simple walk animations, Spore, but I’ve never actually coded them in.

Spore

Annoyingly, I haven’t worked on Spore for a while, which meant it was about 3 versions of the hardware library behind and wasn’t using the tilemap library at all. At first I thought it would be a fairly simple change to switch it over.

It wasn’t. I think I spent about 6 or 7 hours in total refactoring various bits of it. I updated it to use the new structure I developed on Asteroids, and then improved on in Argon (and just realised I need to port back into Asteroids) ::rolleyes::.

So after a weekend of work, I’m back where I started, but I’m in a better position overall.

BattleBeasts

I rewrote my scaling code to be a generic nearest-neighbour function so I can make whatever stuff I want bigger. I’ll probably move it out into a new library at some point.

Glyph-ISP

I spent some time earlier this week reworking the board for my USB-ISP thing to put all the components on the top and add a nice logo. I sent it off to the fab too, so hopefully that will be on its way soon.

What’s next?

So I think this coming week I want to try and work on the animation thing in Spore and I’m hoping the boards for the Glyph will arrive too. I still need to order the SMD components for that because I only have through-hole in my component boxes!

Glyph Handheld Game Console

The current iteration is the GLYPH. In this version I’ve moved entirely to surface mount components, including the screen. I’ve also dispensed with the cartridge idea for now in order to simplify the device overall and reduce the component cost (the PCB connector was around £5, which made it the second most expensive component after the screen!). Getting rid of the OLED breakout board also allowed me to use a larger display without changing the overall size of the console.

I think the Glyph will likely be the final name, although I do have some plans to change some of the things under the hood. At some point I’d like to include a USB controller that allows games to be flashed as a Mass Storage class USB device. Currently the USB port is only used for charging.

I would also like to migrate to an ARM-based MCU at some point, which was originally why I had the interchangeable cartridges on the Spike, but added more complexity to the build than I wanted to manage.

This week I completed designing the new board and sent it off to be fabricated.

Glyph-ISP

As noted above, I want to include USB Mass Storage programming on the Glyph. I didn’t want to add a bunch of components to the board before I knew what I was actually doing so I started designing a standalone programmer based on the ATMega16u4 controller. I realised creating the 3D image of it for this post that I need to move the components that are on the back onto the front and make the board a little bit bigger because it looks weird and awkward with a few capacitors sticking out the back! So that’ll go back to the drawing board before I send it off to the Fab.

Games

I did a huge rework of the way I structure the code in my games. I learnt how to use VPATH in makefiles so I can have just 1 copy of my library for the Spike hardware. Y’know, how things should be done.

I made a title screen for a new game concept - it’s awful, but less awful than usual, and I was quite pleased with it. The game uses a cool trick to generate random ‘beasts’ to train and battle. It’s a cross between Tamagotchi and Pokemon, or something. I haven’t really gotten very far.

As far as games go, I’m building quite the library of almost finished games. Currently in progress are: BattleBeasts, Lamplight and Spore, although that last one is a little neglected lately.

Previously I wrote about the Mage. I’ve been very busy since then, but terrible at writing about it here.

After playing around with the Mage for a while, I realised that the limits of the ATTiny85 were a lot harder to work with than I was expecting. 8Kb of program space got eaten up by maps and tile data really fast. Even simple game mechanics took way more code space than I expected.

I needed a new microcontroller.

I pretty much ‘completed’ the “Mage Game” RPG demo but it didn’t look anything like I had imagined once I ran out of space for new areas. I also had to abandon my idea of randomly generating dungeon maps because I just couldn’t fit it into the 512bytes of RAM.

And so I decided to find a new microcontroller.

It was a lot harder than I expected. Obviously I needed something with more resources. My problem was that if I was redesigning the whole thing I should probably use something a little more modern. I wanted to use something with an ARM M0 core but I have no experience with working with those and don’t have the tools to program them. So I thought about using the ATMega1284p but because I wanted something small, and I was intimidated by the the SMD packaged version I felt like I was stuck. I kept oscillating between learning a whole new ecosystem and sticking with something I was comfortable with.

One of the things I’d wanted to do was store games on an SD card so I could swap them in and out at will. It occurred to me that for the cost of an SD card I could pretty much have a whole microcontroller AND solve my problem of which one to choose by not having to choose at all!

I reworked the whole concept to move the microcontroller off onto a separate ‘cartridge’ (I call them Shards, because I can). The screen, buttons, battery & speaker could all sit on one board and the Shard could plug in to make it work. It took a couple of iterations to get right; finding the right connector took some searching and I even had to make my own custom PCB footprint for it.

Most importantly: it works. I am currently using an ATMega1284p, I had a go at soldering the SMD version by hand and only messed the first one up a little bit (the second one worked first time!). Once I’ve reached its limits, I can make a new Shard with whatever flavour of ARM I like on it and simply plug it in!

I’ve been working on a tribute to the Alien Breed game from the Amiga as my first proper Spike game:

And actually since I made this video I’ve done a lot more work on it, but that’s for another post.

Repositories

Spike main board and shards

Spike Game Template

Spore - top-down shooter

What’s next?

I need to port the Mage Game over to Spike (and think of a proper name).

I’m not completely satisfied with the Spike part (and I’ve gone off the name a bit since I made it :().

I am completely over clicky tactile buttons. I’ve found some alternatives that I’m going to try in a new revision at some point.

I’m not sure about the screen breakout board - it’s been fantastic for prototyping and development because it just plugs in, but I think working with a bare panel might make it look more ‘professional’.

I originally connected the battery to the Shard connector with the view that I might need it for something, but I took it off in an earlier version that used a different connector with fewer pins because I didn’t have enough. I wish I’d put it back in when I changed the connector so I could use it to monitor the battery level.

Surface mount all the things. I need to buy new tools for that though, so I’m going to hold off on that.

SOUND! Sound is a huge thorn in my side for this project and I desperately wish I knew someone who could help. I can make simple tones using PWM and because they use timers, they use virtually no CPU time. Music, polyphony and sound effects are completely beyond my capability. The few tries I have made to make a wavetable synth on this hardware have failed or at best used pretty much the entire processor bandwidth just to make a simple noise. I think I need a discrete sound device, which feels like a whole other project on its own.

All that said, pretty much this whole project was far beyond my understanding when I started, so there’s hope.

The lost variant

When I redesigned the Mage I wanted to include a colour screen. The first version of Spike had a 128x128 Colour OLED display. I had the boards made and assembled one. I had some trouble getting the screen to initialise at first, eventually it worked though and I wrote a program to quickly fill the screen with a colour, simply starting at 0 and adding 1 each frame.

With not-very-optimal code I managed 4 frames per second. I was really disappointed. I worked out that with some code optimisation and reworking the Shard to use hardware SPI instead of bitbanging, I might get it as far as 12fps. Even using hardware SPI though, the processor would have been working flat out to do it. The current version does use hardware SPI and I’m thinking about trying a 96x64 colour OLED at some point, but for now I’m happy with the monochrome version although I’d like it a little larger.

The colour version still exists in a branch of the main repo, but it’s no longer actively developed.

I’ve been working on a new project. Mage is a handheld gaming device based on the ATTiny85.

My intention is to write a lot more about it over the coming weeks - I learnt A LOT whilst making this, and it’s still a long way from finished. I want to make sure I document as much as I can.

You can read about the details in the Dev Log