Entropy Out Loud

Keep your ears open :)

The First Mattari - Thoughs on a Simple 6502 Computer

| Comments

First off, after a rather nasty flu-induced hiatus, I’m glad to say that I’m back! Work on Mattari continues!

(incidentally, I’ll also be finishing off my mini-series on immersive audio in games with part 3, soon)

Today I want to talk about my initial thoughts on the Mattari and how I’ll proceed with the project. This is my first hardware design on this scale, so while I know a lot of theory…. you know the saying about theory and practice!

Virtually Surrounded Part 2 - When 7.1 Isn’t 7.1

| Comments

I started writing this post and then threw the original out when I realised I’d rambled on for far too long :)

So in my last post, I said that this post would be about the various 7.1 headset solutions that I tried. However, that’s just a long story that leads to a much more useful lesson that I’ve decided to comment on just by itself.

Don’t Believe 7.1 When You Read It

The one piece of advice I can give to anyone looking for a 7.1 headset is this: MAKE SURE IT GIVES YOU A TRUE 7.1 DEVICE.

Virtually Surrounded - Trials of an Immersive Audio Junkie (Part 1)

| Comments

Lately I’ve been on a quest to find a good virtual surround sound solution for headphones. It’s an interesting topic and those that know me know that I’ve had a thing for audio stuff since, well, forever. I probably own too many headphones at this point.

In this series, I want to cover where immersive gaming audio is at now and what I’ve found on my quest to find the perfect immersive audio solution. It’s my humble opinion that if you’re a first-person-shooter player and you’re not playing your game over headphones with good virtual surround, you’re really missing out.

In this part I’m going to give a quick overview of where we’re at and what the (somewhat depressing) status quo is right now; in the following parts I’ll be giving my impressions on all the virtual surround solutions I’ve tried and the pitfalls I’ve encountered, in the hope that others don’t have to encounter the same surprises.

To not litter the posts with references, I’ll include a ‘Further Reading’ section at the end of each one with links to more in-depth stuff.

So, let’s begin :)

From Here to Console - Step 1

| Comments

So, where is all this hardware stuff going?

Well, I want to build my own console! Nothing too fancy, but something in the realm of what the SNES was capable of…. eventually. There’s certainly a long way to go, but the journey is going to be a fun one!

So, I’ve never done anything like this and when thinking how to approach it, I come back to – simple steps first. With that in mind, my plan is to build up several different ‘consoles’, each getting progressively more complex. For each project, I’ll do both a hardware design and some software to run on it to demonstrate; the software has to be an actually playable game, no matter how simple (not just a tech demo).

The MATTAR-1

For my first attempt, I’m aiming for something simple. How though, do you actually do this?

At the most basic level, we need a CPU and we need some stuff for it to talk to. Some of that is going to be memory, some will be RAM and some will be ROM. It also needs to be able to talk to other things (peripherals) such as displays, lights, buttons, controller inputs and eventually storage like an SD card.

My first go is going to be simple. Goals:

Hardware

  • It needs to have a CPU (I’ve chosen the 6502).
  • It needs to be able to use CPU code to print out some numbers and/or letters on the seven-segment display.
  • It needs to be able to read the pushbuttons and the position of the switches.

Software

The console will run GUESS THAT NUMBER! That’s right, is the number higher or lower?!?! You will have to be the judge in this riveting game.

Seriously though, I’ll flesh out the details of that game later, but that is the basic idea :)

Why the 6502?

It’s a simple CPU that has a special place for me as I grew up with the venerable Commodore 64. It’s got a simple interface and looks simple to program for. I’ve done some 6502 assembler in the past, but really only quickly played with it.

How to stay updated

Watch this blog :) I’ll be putting out videos and blog entries and I’m also going to put my code & docs up on GitHub for others to use as an example or to improve.

So with that, stay tuned for more soon :)

7 Segments of Awesome!

| Comments

It is done!

Well, at least, part one is.

Take a look:

Finally after some time digging into VHDL I got my 7-segment display driver working :) My ultimate goal is to make a small game console with my own sprite core and using one of the open processor cores that’s available. I had an issue with fast clocks that you’ll see in the second part of the video. After watching my own video I actually think I’m starting to understand why the digits are repeated. Need to dig a bit more but I think it’s to do with how fast I’m updating the cathode (segment) inputs. Similar segments are commonly wired across all 8 digits and I think I’m unintentionally doing PWM with the sped-up clock such that I end up lighting up all intended digits simultaneously as there’d be some kind of voltage on the CA-CG outputs going to the cathodes. Still not 100% sure if that’s right; any comments welcomed :) Check out more at: http://blog.entropyoutloud.net

So, this turned out pretty interesting to do as I thought it might have. After spending some time reading the earlier mentioned VHDL books and some more time in Vivado, my segments finally light up, scan and show BCD input as decimal digits.

There was one interesting problem that I ran into; driving the display very quickly off of the board clock resulted in some odd behaviour that wasn’t (still isn’t totally) clear to me given the algorithm.

The wiring of the display and the driving of it is interesting. You drive the cathode inputs to light up the segments you want for a digit. However, there is only one set of cathode inputs and it goes to the same cathodes on every digit. So, for example if you drive the cathode inputs to display a ‘1’, then that input goes to all 8 numbers and if you lit them all up at once you’d see ‘11111111’.

There’s a second input that lets you choose which digits are lit up. So, to create a complete display you need to rapidly scan out one digit at a time. Do it fast enough and the display becomes 8 digits that all look like they’re being lit up at the same time, when they’re actually being rapidly scanned.

In the final version of the circuit, I scan at a rate that gives me 60Hz for each digit and a 1/8th duty cycle. To achieve this I need to use a clock that runs the scan at 480Hz – thus completing a full 8-digit scan at a 60Hz rate.

This is still actually a little slow for my liking – I’d double that scanning rate if I were using this in anything right now (and will double it later for sure). The digits at 60Hz do look a bit unsteady / flickery and a faster rate makes them look more stable.

What was really interesting is what happened when the clock rate went too fast. The initial version of my circuit just used the 100MHz default clock mapped in the Nexys4 constraints file. That means that each digit was only being driven every 80ns (10ns per digit with a 1/8th duty cycle) for a single clock tick.

This lead to two things, one I’m sure about, the other I’m not:

  • The driving time was so short before switching over that the LEDs in the display never come up to full brightness (makes sense).
  • All digits were visible somewhat on all segments (makes less sense).

What I think happened is that the scanning frequency was faster than the fall time of either the signal or of the LED itself. After the first scan, none of the digits shown would ever have time to get fully dim again.

Definitely don’t quote me on this though and if someone knows better, leave a comment!!

Anyway I’ve got a post coming that details where all this is going. Stay tuned :)

Hittin’ the Books

| Comments

Progress on the 7-segment display driver has stalled a little.

VHDL is proving to be a very different experience for me coming from a software engineering background. Not only am I learning VHDL ‘the language’ but intricately tied to that is that what I’m actually doing is hardware design.

So I’ve been reading up on stuff like RTL and trying to wrap my head around the fact that I’m not writing a piece of software but am in fact designing hardware using a methodology that I’m only just starting to scratch the surface of.

(it’s also not helping that I’m getting distracted setting up my electronics workbench, but I digress….)

So now I’m working my way through the awesome book ‘VHDL for Logic Synthesis’; search it out on Amazon (need to figure out how to get a short link to it and I’ll upadte / put it in the next post). It really seems like the kind of concise overview that I’ve been looking for. I atleast now understand the design workflow much better and am getting more familiar with VHDL’s types. So that 7-segment display should be rocking in no time.

I’ve also picked up ‘Circuit Design and Simulation with VHDL, second edition’; it was actually the one I picked up first but the other VHDL book seemed highly recommended and more specific to exactly what I want to dig into right now.

Looking forward to going through the Circuit Design book’s examples once I get the 7-seg out of the way.

There is a big plan for this. More details on that soon :)

The Best Soldering Tutorial Videos I’ve Ever Seen

| Comments

Found these absolutely AWESOME soldering tutorial videos. If you haven’t seen them before, definitely check them out. I love how they give a close view of the soldering process.

PART 2: http://www.youtube.com/watch?v=fYz5nIHH0iY PART 3: http://www.youtube.com/watch?v=b9FC9fAlfQE Dave takes you through everything you need to know to do good quality soldering. Part 1 is all about the tools you might need. A lot of this was already covered in my general lab tools video.
PART 1: http://www.youtube.com/watch?v=J5Sb21qbpEQ PART 3: http://www.youtube.com/watch?v=b9FC9fAlfQE A beginners guide to learning how to hand solder. Remember to watch the first part, which is all about the tools: http://www.youtube.com/watch?v=J5Sb21qbpEQ
PART 1: http://www.youtube.com/watch?v=J5Sb21qbpEQ PART 2: http://www.youtube.com/watch?v=fYz5nIHH0iY Part 3 of the hand soldering tutorial. This time Dave shows you how to drag solder and tack & reflow SMD components, and in particular 0.5mm fine pitch IC’s. Including solder paste and hot air.

I’ve always tried to do the ‘touch the iron on one side, feed the solder in on the other’ and thought I was just really really crap at it, but turns out I’ve always been using one of those conical tips. Definitely gonna give the chisel tips a go now.

Bouncin’ LEDs

| Comments

I present to you…. Bouncin’ LEDs! Xbox One/PS4, eat your heart out!! :)

My second FPGA circuit is a little LED bouncer with selectable speed.

So this circuit was a bit more challenging than the last one and my software instincts lead me astray, something that I’ve heard happens alot to us software devs when starting out in hardware.

Specifically, my first attempt at specifying the state machine that bounces the LEDs was wrong. Even when trying not to, I assumed that it worked like a program with code kind of like this:

process (CLKIN, RESET)
begin
    if (led(0) = '1' or led(15) = '1') then
        bounce_dir <= not bounce_dir;
    end if;

    if (bounce_dir = '0') then
        led_out <= led_out rol 1;
    else
        led_out <= led_out ror 1;
    end if;
    LED <= std_logic_vector(led_out);
end process;

So, the code looks pretty simple right? If the lit up LED is at either edge of the strip, reverse the bounce direction. Then just shift the LED output value in the appropriate direction (it’s a binary output that looks like “0000000000000001”).

Except, not.

The LEDs would get stuck oscillating between either edge. See, there’s an implicit assumption of sequence in that code; assigning to bounce_dir and then assuming that the value the next if-block would see is the new one.

However these are signal flows, this isn’t a program executed by a CPU and everything is concurrent. I’m still wrapping my head around it, to the point where my explanation here is probably a little off. In the case above, bounce_dir is a register which doesn’t get the new value until the next clock edge. Connections, not statements (or something, I’m happy to be corrected!).

My final code looked like this, FYI:

process (CLKIN, RESET)
begin
    if rising_edge(CLKIN) then
        if (RESET = '1') then
            led_out <= "0000000000000010";
            bounce_dir <= '0';
            bouncing <= '0';
        elsif (led_out(0) = '1') then
            bounce_dir <= not bounce_dir;
            led_out <= led_out rol 1;
        elsif (led_out(15) = '1') then
            bounce_dir <= not bounce_dir;
            led_out <= led_out ror 1;
        else
            if (bounce_dir = '0') then
                led_out <= led_out rol 1;
            else
                led_out <= led_out ror 1;
            end if;
        end if;
    end if;
    LED <= std_logic_vector(led_out);
end process;

So, in the code above, the circuit lives in one of four states: reset, changing direction to the right, changing direction to the left or moving in whatever direction is specified by bounce_dir.

(oh; I see now I never use that ‘bouncing’ variable, it was a leftover from an earlier attempt at something).

So there you have it. Need to keep practicing and should probably read some more language focused stuff on VHDL now that I atleast have my bearings enough.

Next step: Get a BCD value entered in with the switches displaying on the 7-segment display, then extend that circuit to get a binary value from the switches displaying on the 7-segment display.

Oh; my post on the tools and thoughts and stuff is coming, probably in a few days. I need to get iSim working first.

New Beginnings in FPGA-land!

| Comments

So…. haven’t updated this blog in awhile. Now however, I have lots more free time :)

So with this time, I’ve decided to do something I’ve been wanting to do for awhile; dig into hardware and FPGAs. I got myself a nice Digilent Nexys4 development board with the goal of creating my own 16-bit-style videogame console (think Super NES on steroids…. hopefully).

Of course, there’s a long way to go – until a few days ago I’d only read some VHDL (I’m going with VHDL) and never actually written it.

However we now have…. LEDs! They even respond to a switch and everything! Check it out:

My first VHDL on a Nexys4 board. This after a day of wrestling with the tools to get them to work on Windows 8.1. Using Vivado 2013.4, seems like a nice UI so far and I’m getting the hang of things. Had to use IMPACT to program the board as the built-in Vivado hardware server refused to see the board (even though the release notes/docs say that it should be supported). Oh well. Pretty excited to get into this stuff. My hope is to build a 16-bit classic game console :)

Can’t be far from there to a full game console, can it?? ;)

Will post more soon with some initial thoughts on the tools and some more LED action.

Why I’m Getting Back Into Comp Sci

| Comments

I love solving problems.

Awhile ago (actually, in my last post) I mentioned that I was doing a Programming Languages course on Coursera. It’s continued to go great. We’ve moved on from using Standard ML of New Jersey to using Racket, which I particularly like since the Lisp-y family of languages really appeals to me;
partly because they’re just different from what I use day-to-day.

This week’s homework is about building a programming language. We’re just building the syntax tree interpreter, skipping past all the parsing stuff.
So you just take an AST and run through it with a nice recursive definition. It’s pleasingly elegant. It’s so much more intellectually fun than what I’m doing in my “day job” at the moment.

(here comes the normal ‘enterprise’ rant haha)

It’s the difference between solving problems and gluing things together. When I’m tinkering around with my programming languages, or writing generative music in ChucK (soon to be Extempore when I get around to it), I feel like I’m creating something new to explore. Something will happen that I haven’t seen before. You wouldn’t think that writing an interpreter and generating music would have a lot in common, but somehow they do. There’s a satisfaction to writing your own little piece of code that does it’s own little thing. You start off with an unsolved puzzle and then it’s solved in a neat package.
You’ve taken thoughts from your head and made them real in the machine. You create something.

Particularly when generating music, there’s a great feedback loop that you often get into where something that your code does surprises you. That’s when you go from “writing out steps to solve a problem” to “creating something that almost has a life of it’s own”.

So what made me think of all this? I really don’t know :) I’ve been tasked to write a plugin-type thing at work. It’s one of those big enterprise-y software things where you write a lot of boilerplate code to solve a problem that’s been solved a million times before and you wonder why you need all this boilerplate. For a split second it reminded me of a time when I thought that the software profession wasn’t for me, that it just wasn’t stimulating anymore.

Luckily it doesn’t take much more than a music scale, or a game, or even an abstract syntax-tree interpreter to remind me why I love doing what I do so much.