It’s a simple fact that most programs created for the personal computer involve the same methods of interaction, almost regardless of purpose. Word processors, graphics utilities, even games – the vast majority of interaction is performed through a keyboard and mouse. However, sometimes it can be fun to experiment with alternative technologies for users to interact with code – Paper Programs is an exciting way to do just that.
It’s a system that creates a very tactile way of interacting with a program – by moving the page around or placing different pages next to each other, programs can interact in various ways. The system is setup for collaboration as well, allowing users to edit code directly in the browser.
The project reminds us of earlier works on DIY multitouch screens, but with a greater focus on direct engagement with the underlying code. What other unique ways exist to interact with code? Let us know in the comments.
While schools have been using robots to educate students in the art of science and engineering for decades now, not every school or teacher can afford to put one of these robots in the hands of their students. For that reason, it’s important to not only improve the robots themselves, but to help drive the costs down to make them more accessible. The CodiBot does this well, and comes in with a price tag well under $100.
The robot itself comes pre-assembled, and while it might seem like students would miss out on actually building the robot, the goal of the robot is to teach coding skills primarily. Some things do need to be connected though, such as the Arduino and other wires, but from there its easy to program the robot to do any number of tasks such as obstacle avoidance and maze navigation. The robot can be programmed using drag-and-drop block programming (similar to Scratch) but can also be programmed the same way any other Arduino can be.
With such a high feature count and low price tag, this might be the key to getting more students exposed to programming in a more exciting and accessible way than is currently available. Of course, if you have a little bit more cash lying around your school, there are some other options available to you as well.
3D printers are great for creating static objects, but if you’re clever, it’s possible to print functional devices. If you’re absolutely brilliant you can go far beyond that, which is the case here. This door handle with a key-code lock does it all with 3D printing using mechanism designs that look like alien technology. This is just one application of a much more interesting mechanical digital logic they’re developing (PDF).
Working from the [Hasso-Plattner-Institut], the research team is focusing on metamaterials as mechanisms in and of themselves. The crux of this lock is a series of bistable springs that — if the correct code is entered — will trigger in series to unlock the door. The project builds on the grid of shearing cells seen in the door handle we featured last year. It happens quickly in the video, but the intricate cascade of the handle unlocking is a treat to witness.
It’s a fascinating show of mechanical design. The common elements of digital electronics are all present: set or unset bits, logic gates, propagation issues, the whole works. But there are added challenges in this system, like the need for special cells that can turn the logic chain by 90 degrees and split the signal into more than one part.
This signal splitting is seen in the upper right (bifurcation) and leads into what is in effect an amplifier. The locking bolt must be moved twice the distance of a normal cell, so a dual-cell input is necessary to offset the loss of force from the incoming smaller cells. Cognitively we understand this, but we’re still trying to gain an intuitive sense of the amplifer mechanism.
One thing’s for sure, the overall concept is far cooler than this admittedly awesome door lock mechanism. The paper is worth your time for a deep dive. It mentions their design editor software. You can play with it online but we don’t think it’s been updated to include the new logic cells yet.
Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips. Amongst other hardware, Java Grinder supports the Commodore 64, which uses a variant of the 6502 CPU. [Michael Kohn] realized the Atari 2600 shares this processor, and figured he’d get started on making Java Grinder work with the Atari by expanding on the C64 work done by [Joe Davisson]. Together, they brought Java to the Atari 2600 and made a game along the way.
According to [Michael], parts of the project were easy, as some Java routines compile down into as little as 1 or 2 instructions on the 6502. Other parts were harder, like dealing with the graphics subsystem, and modifying Java Grinder to output 8-bit bytecode to fit into the Atari’s tiny 4K ROM limit. Even with this tweak, they still couldn’t fit in a game and title screen. In the end they relied on bank switching to get the job done. [Joe]’s game is pretty solid fare for the Atari 2600 — blocky graphics and bleepy sounds — and they’ve uploaded it to the page so you can try it yourself in an emulator.
At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430. Video after the break.
We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.
[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?
When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.
So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.
Print is dead, so we put a skull on it. That’s the philosophy behind the 2015 Hackaday Omnibus, the printed collection of the best Hackaday has to offer.
We have a few ideas of where we would like to take the print edition of Hackaday. Mad magazine-style fold-ins are on the list, specifically a fold-in style schematic that does two completely different things. Remember when records were included as a magazine insert? Those are called flexi-discs, and there’s exactly one company that still does it. All of these and more are plans for the future, and for the 2015 Hackaday Omnibus, we chose to include something we’re all very familiar with: a puzzle. This is no ordinary puzzle – even we don’t know what the solution is.
A few months ago, a strange account popped up on hackaday.io. Whoever is behind this count is based in Bielefeld, Germany – a place that doesn’t exist. They are somehow related to the Berenstain / Berenstein Bears dimensional rift, and they may be responsible for giving Cap’n Crunch only three rank insignia on his uniform. There is something very, very strange about this account. Since August, a black and white image of static, 98 pixels wide and 518 pixels tall has sat on this account profile. The Illuminati has given us enough clues, but until now, no one has managed to crack the code.
The hackaday illuminati included one additional piece of information with their encoded static image: a 12×12 pixel bitmap. When this bitmap was XORed with the main image, symbols appeared. In total, there are only seven unique symbols in the image. These symbols seem to be stolen from the Fez alphabet, but there are some significant differences. These symbols are rotated multiples of 90 degrees, and are surrounded by a one pixel border that is either black or white (we’re calling the border a ‘sign’ bit). In total, these seven symbols arranged in four different rotations with two different signs yields forty unique variations of a symbol in the decoded image. At this point, it should be noted 7*2*4 = 56.
As of now, cracking the illuminati’s cyphered machinations has hit a roadblock. There’s a dead image file on the illuminati’s profile. Until that image is rehosted, there is no way to progress any further. That’s not going to stop people from trying, though: the chat channels on hackaday.io have been buzzing about the newly decrypted images. Hopefully, with time, someone will figure out what it all means.