When the 4D Systems display first arrived in the mail, I assumed it would be like any other touch display – get the library and start coding/debugging and maybe get stuff painted on the screen before dinner. So I installed the IDE and driver, got everything talking and then…it happened. There, on my computer screen, were the words that simply could not exist – “doesn’t require any coding at all”.
I took a step back, blinked and adjusted my glasses. The words were still there. I tapped the side of the monitor to make sure the words hadn’t somehow jumbled themselves together into such an impossible statement. But the words remained… doesn’t.require.any.coding.at.all.
Continue reading “Making Embedded GUI’s Without Code”
While it may not look like much, the image above is a piece of the original email where [Ken Thompson] described what would become the implementation of UTF-8. At the dawn of the computer age in America, when we were still using teletype machines, encoding the English language was all we worried about. Programmers standardized on the ASCII character set, but there was no room for all of the characters used in other languages. To enable real-time worldwide communication, we needed something better. There were many proposals, but the one submitted by [Ken Thompson] and [Rob ‘Commander’ Pike] was the one accepted, quite possibly because of what a beautiful hack it is.
[Tom Scott] did an excellent job of describing the UTF-8. Why he chose to explain it in the middle of a busy cafe is beyond us, but his enthusiasm was definitely up to the task. In the video (which is embedded after the break) he quickly shows the simplicity and genius of ASCII. He then explains the challenge of supporting so many character sets, and why UTF-8 made so much sense.
We considered making this a Retrotechtacular, but the consensus is that understanding how UTF-8 came about is useful for modern hackers and coders. If you’re interested in learning more, there are tons of links in this Reddit post, including a link to the original email.
Continue reading “UTF-8 – “The most elegant hack””
A few weeks ago we featured the McHck project (pronounced McHack), a $5 Cortex M4 based platform which can be directly plugged into one’s computer. Recently, [Simon] announced that he made a firmware allowing a McHck to behave as a SWD adapter and also detailed his flashing rig.
Therefore, those who’d want to build their own McHck would only need to borrow an SWD programmer once to get started. When the first platform has been programmed with the SWD firmware, it can be used to flash and debug applications on the second McHck. Consequently, the microcontroller flashing rig [Simon] designed (shown in the picture above) is based on this. The few core elements are a TQFP48 ZIF programming socket, a push button and two LEDs. Simply push the Kinetis in the programming socket, close it and press the button. Success of the operation is indicated by the two LEDs. [Simon] used the Ragel State Machine Compiler to generate his flashing program and all the code he made can be downloaded from his github.
If you missed the original McHck post now’s your chance to go back and see what it is all about.
This week we’re taking another departure from the ordinarily campy videos featured in the Retrotechtacular section. This time around the video is only two years old, but the subject matter is from the early 1980’s. [David Crane], designer of Pitfall for the Atari 2600 gave a talk at the 2011 Game Developer’s Conference. His 38-minute presentation rounds up to a full hour with the Q&A afterwards. It’s a bit dry to start, but he hits his stride about half way through and it’s chock-full of juicy morsels about the way things used to be.
[David] wrote the game for Activision, a company that was started after game designers left Atari having been told they were no more important than assembly line workers that assembled the actual cartridges. We wonder if any heads rolled at Atari once Pitfall had spent 64-weeks as the number one worldwide selling game?
This was a developer’s panel so you can bet the video below digs deep into coding challenges. Frame buffer? No way! The 2600 could only pump out 160 pixels at once; a single TV scan line. The programs were hopelessly synced with the TV refresh rate, and were even limited on how many things could be drawn within a single scan line. For us the most interesting part is near the end when [David] describes how the set of game screens are nothing more than a pseudo-random number generator with a carefully chosen seed. But then again, the recollection of hand optimizating the code to fit a 6k game on a 4k ROM is equally compelling.
If you like this you should take a look at an effort to fix coding glitches in Atari games.
Continue reading “Retrotechtacular: How I wrote Pitfall for the Atari 2600”
Gather ’round children, we’re about to hear a story about the good old days. Except that this is really more of a horror story of what it used to be like as a code monkey. [John Graham-Cumming] shares his experience programming a 6502-based KIM-1 machine back in 1985. Simple, right? The caveat being that there was no assembler or hardware for loading the finished code!
The machine in question was a label application tool for a production line. You know, product goes in bottle, label gets slapped on the side. But the slapping needed to be perfect because consumers shy away from packaging that looks shoddy. Computer control would end up being far superior than the mechanical means the factory had been using because it simplifies the ability to adjust calibration and other parameters. [John] started from square one by interfacing the KIM-1 with the existing hardware. It has a hex keyboard which is how the program was entered into the device. But first he wrote the software on sheets of notebook paper like the one seen above. It includes his hand assembled code, which was then typed in on the keypad. Kind of makes you appreciate all the tools you take for granted (like Eclipse), huh?
Upgrading a desktop with a diamond cutting wheel
[Michail] needed a new graphics card. The only problem was his motherboard didn’t have any free PCI-E x16 slots available. Unable to find a PCI-E x1 card, he did what any of us would do and broke out the Dremel. Yes, he got it working, but don’t do this unless you know what you’re doing.
[Steve] recently got a Galaxy S3 and was looking for something to do with his old phone. It’s got WiFi, it’s got a camera, and with a free app, [Steve] now has an IP Webcam. Neat way to recycle a phone.
This is now bookmarked
We’re not much for plugging other blogs, but Math ∩ Programming – that’s intersection, remember – is really cool. Apparently it has been around for a little more than a year and already there are quite a few really cool posts. How to use cellular automaton to generate caves in video games and facial recognition through Eigenvalues are amazingly in depth, and show the theory behind some really cool techniques. Very, very cool.
Troll Physics: now wireless!
Remember [Fredzislaw100], the guy who puzzled the Internet with impossible circuits? He’s back again, this time with wireless LEDs. We’re guessing something similar to an induction charging system in the battery clip, wirelessly coupled to something under the paper, and that is wirelessly coupled to the LEDs. Your guess will probably be better than ours, though.
Not shown: Captain Obvious, Major Major
Pv2 [Zachary Ricks] of the U.S. Army thought we would get a kick out of the last name of one of the guys in his company. Yes, it’s ‘Hackaday,’ and yes, it’s a real surname. Here’s the full pic [Zach] sent in. Apparently it’s a name along the lines of ‘Holiday.’ Honestly, we had no idea this was a real surname, but we’re thinking Private Hackaday could use a care package or two (dozen).
Anyone up for sending a few hacker friendly (for [Zach] and a few other guys) care packages? Even socks or books or Oreos would make for an awesome care package. Email me if you want the mailing address.
Imagine you’re stuck on a desert island, hundreds of miles away from the nearest person, and you finally have time to finish that project you’re working on. You have a single microcontroller, but you’re lacking a computer and you need to program an ATtiny13. How do you do it? [androidruberoid] figured out how to manually flash a microcontroller (Russian, surprisingly good translation) using just three switches and a lot of patience.
[androidruberoid]’s ATtiny13 – like nearly all Atmel microcontrollers – are programmed using an SPI interface. This interface requires four signals: SCK, a data clock, MOSI, the data line from master to slave, MISO, data from slave to master, and RESET. By connecting these data lines to buttons, [androidruberoid] is able to manually key in new firmware one byte at a time.
This technique of manually programming bits relies on the fact that there is no minimum speed for an SPI interface. In the video after the break, you can see [androidruberoid] manually programming an ATtiny13 with a simple program. It only lights up an LED, but with enough patience he could key in a simple ‘blink a LED’ program.
Continue reading “Programming a microcontroller one bit at a time”