Puzzling Out An 80s Puzzle Toy

June 29, 2016 by Gerrit Coetzee 15 Comments

[Ido Gendel] looks back a time in the 80s when kids would learn by answering the questions to quizzes on their “TOMY Teacher,” or, “Sears Quiz-A-Tron”. There’s a bit of a conundrum with this toy. How did it know which answers were correct. Chip memory of any kind wasn’t the kind of thing you’d sweep into the dust bin if you had extras like it is now; it was expensive.

To use the toy, the child would place the notebook in the plastic frame on the device. They’d open the page with the quiz they would like to take. Printed in the upper left hand corner were three colored squares. There was a matching set of colored buttons on the device. They’d press the corresponding buttons in order from top to bottom and then the machine would magically know which answers on the quiz were correct.

[Ido] wondered how the machine handled this information. Was there an internal table for all 27 possible codes? Did it generate the answer table somehow? He sat down with a spreadsheet filled with the notebook code on the left and the corresponding correct answers on the right. Next he stared at the numbers.

He eventually determined that there was a pattern. The machine was using the colored squares as the input for a function that determined what the answers were. A table would have only taken up 68 bytes, but with one 80s chip on board, sounds to play, and lights to switch on and off, the machine needed all the free space it could get.

Learn To Program With Literate Programming

June 6, 2016 by Gerrit Coetzee 72 Comments

My heyday in programming was about five years ago, and I’ve really let my skills fade. I started finding myself making excuses for my lack of ability. I’d tackle harder ways to work around problems just so I wouldn’t have to code. Worst of all, I’d find myself shelving projects because I no longer enjoyed coding enough to do that portion. So I decided to put in the time and get back up to speed.

Normally, I’d get back into programming out of necessity. I’d go on a coding binge, read a lot of documentation, and cut and paste a lot of code. It works, but I’d end up with a really mixed understanding of what I did to get the working code. This time I wanted to structure my learning so I’d end up with a more, well, structured understanding.

However, there’s a problem. Programming books are universally boring. I own a really big pile of them, and that’s after I gave a bunch away. It’s not really the fault of the writer; it’s an awkward subject to teach. It usually starts off by torturing the reader with a chapter or two of painfully basic concepts with just enough arcana sprinkled in to massage a migraine into existence. Typically they also like to mention that the arcana will be demystified in another chapter. The next step is to make you play typist and transcribe a big block of code with new and interesting bits into an editor and run it. Presumably, the act of typing along leaves the reader with such a burning curiosity that the next seventeen pages of dry monologue about the thirteen lines of code are transformed into riveting prose within the reader’s mind. Maybe a structured understanding just isn’t worth it.

I wanted to find a new way to study programming. One where I could interact with the example code as I typed it. I wanted to end up with a full understanding before I pressed that run button for the first time, not after.

When I first read about literate programming, my very first instinct said: “nope, not doing that.” Donald Knuth, who is no small name in computing, proposes a new way of doing things in his Literate Programming. Rather than writing the code in the order the compiler likes to see it, write the code in the order you’d like to think about it along with a constant narrative about your thoughts while you’re developing it. The method by which he’d like people to achieve this feat is with the extensive use of macros. So, for example, a literate program would start with a section like this:

Continue reading “Learn To Program With Literate Programming” →

Open Robots With Open Roberta

May 11, 2016 by Elliot Williams 11 Comments

Kids, and Hackaday editors, love robots! The Open Roberta project (OR) takes advantage of this to teach kids about programming. And while the main focus is building a robot programming language that works for teaching grade-school and high-school kids, it’s also a part of a large open source robotics ecosystem that brings a lot more to the table than you might think. We talked with some folks at Google, one of the projects’ sponsors, about where the project is and where it’s going.

Building a robot can be very simple — assembling pre-configured parts or building something small, quick, and cute — or it can be an endeavour that takes years of sweat and tears. Either way, the skills involved in building the ‘bot aren’t necessarily the same as those it takes to program the firmware that drives it, and then eventually the higher-level software that makes it functional and easy to drive.

OR, as an educational project, makes it very, very easy for kids to start off programming robots, but it’s expandable as the user gets more experienced. And since everything is open source, it’s part of a whole ecosystem that makes it even more valuable. We think it’s worth a look (along with something significantly more complex like ROS) if you’re playing around with robotics.

System Architecture

Open Roberta is the user-facing middleware in a chain of software and firmware bits that make a robot work in a classroom environment. For the students, everything runs inside a browser. OR provides a webserver, robot programming interface and language, and then converts the output of the students’ programs to something that can be used with the robots’ firmware. The robots that are used in classrooms are mostly based on the Lego Mindstorms EV3 platform because it’s easy to put something together in short order. (But if you don’t have an EV3, don’t despair and read on!)

The emphasis is on ease of entry for the students and the teachers supervising the class. Everything runs in a browser, so there’s nothing to install on the client side. The students connect to a server that directs the robots, communicating with the robots’ own operating system, and uploading the students’ programs.

Continue reading “Open Robots With Open Roberta” →

Continuing The Dialog: “It’s Time Software People And Mechanical People Had A Talk”

April 11, 2016 by Gerrit Coetzee 59 Comments

A while back I wrote a piece titled, “It’s Time the Software People and Mechanical People Sat Down and Had a Talk“. It was mostly a reaction to what I believe to be a growing problem in the hacker community. Bad mechanical designs get passed on by what is essentially digital word of mouth. A sort of mythology grows around these bad designs, and they start to separate from science. Rather than combat this, people tend to defend them much like one would defend a favorite band or a painting. This comes out of various ignorance, which were covered in more detail in the original article.

There was an excellent discussion in the comments, which reaffirmed why I like writing for Hackaday so much. You guys seriously rock. After reading through the comments and thinking about it, some of my views have changed. Some have stayed the same.

It has nothing to do with software guys.

I definitely made a cognitive error. I think a lot of people who get into hardware hacking from the hobby world have a beginning in software. It makes sense, they’re already reading blogs like this one. Maybe they buy an Arduino and start messing around. It’s not long before they buy a 3D printer, and then naturally want to contribute back.

Since a larger portion of amateur mechanical designers come from software, it would make sense that when I had a bad interaction with someone over a design critique, they would be end up coming at it from a software perspective. So with a sample size too small, that didn’t fully take into account my positive interactions along with the negative ones, I made a false generalization. Sorry. When I sat down to think about it, I could easily have written an article titled, “It’s time the amateur mechanical designers and the professionals had a talk.” with the same point at the end.

Though, the part about hardware costs still applies.

I started out rather aggressively by stating that software people don’t understand the cost of physical things. I would, change that to: “anyone who hasn’t designed a physical product from napkin to market doesn’t understand the cost of things.”

Continue reading “Continuing The Dialog: “It’s Time Software People And Mechanical People Had A Talk”” →

It’s Time The Software People And Mechanical People Sat Down And Had A Talk.

March 7, 2016 by Gerrit Coetzee 131 Comments

With the advances in rapid prototyping, there’s been a huge influx of people in the physical realm of hacking. While my overall view of this development is positive, I’ve noticed a schism forming in the community. I’m going to have to call a group out. I think it stems from a fundamental refusal of software folks to change their ways of thinking to some of the real aspects of working in the physical realm, so-to-speak. The problem, I think, comes down to three things: dismissal of cost, favoring modularity over understanding, and a resulting insistence that there’s nothing to learn.

Continue reading “It’s Time The Software People And Mechanical People Sat Down And Had A Talk.” →

Test Drive Your New Programming Font

January 21, 2016 by Gerrit Coetzee 43 Comments

After hour and hours spent in front of a terminal or IDE, a user begins to build a list of infuriating little things. That one pop-up box that happens every time you press that button by mistake. The noise the software makes when the compile fails. Or the horrible reality that your code just crashed because there wasn’t enough difference between uppercase ‘O’ and a zero. In comes the programming font.

The typical way to find a programming font is to troll forums for a user with a similar problem and see if they have a workable solution. [Koen Lageveen] went out and found nearly all of the free programming fonts out there and compiled a list. He then took one more step and wrote a web app that lets you test them out. Hopefully this will help those in the very real struggle for the perfect programming font. You can try out the tool for yourself, and if you really like it [Koen] has all the code up for it on his GitHub.

[via Hacker News]

Bespoke, Artisanal, Hand Made Executables

October 12, 2015 by Brian Benchoff 69 Comments

Programmers and software engineers will always use the latest development environments, the trendiest frameworks, and languages they learned only 21 days ago. What if this weren’t the case? What if developers put care into their craft and wrote programs with an old world charm? What if Windows executables were made with the same patience as artisanal firewood, or free range granola? [Steve] has done it. He’s forging a path into the wilds of truly hand crafted executables.

The simplest executable you could run on a Windows box is just a simple .COM file. This is an extremely simple file format that just contains code and data loaded into 0100h, and a jump to another point in the code. The DOS .EXE file format is slightly more complicated, but not by much. [Steve]’s goal was to build a proper Windows executable without a compiler, assembler, linker, or anything else.

Continue reading “Bespoke, Artisanal, Hand Made Executables” →