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.
[Ido Gendel] was thinking about new and interesting ways to send data between devices, when he realized that the answer was right in his hand. Literally: he decided to try sending data using the mouse pointer. What he came up with was an interesting hack that uses small movements of the mouse pointer to send data at up to 1200bps, or about 150 bytes per second.
The way he did this was very, very clever. He used an Arduino Leonardo that is set to emulate a mouse, working alongside his existing mouse. This setup means that he can use his existing mouse: the system just sees the Arduino as a second mouse, and the pointer just looks a little jerky when you zoom in. That is because the Arduino is just sending tiny movements, each of which is a code that represents a nybble (4 binary bits) of data. By using both a combination of three left-right or up-down movements, he was able to create 16 movements, each of which can encode 4 bits of data. Each of these encoding movements also returns the mouse to its origin point, so the mouse doesn’t mysteriously scroll off the screen when data is being sent.
The Hackaday Prize isn’t exclusively about building things that will help the planet; you can also build things that will enable others to build things to save the planet. [Eric] isn’t saving the world with his commonCode library, but it will make it vastly easier for other people to build the next great Thing.
The idea behind commonCode is the same as shared libraries you’ll find in any desktop application of reasonable size; it provides a common library for AVR microcontrollers to build just about anything. Bit manipulation, an interface for timers, math functions, graphics, I/O, and peripheral drivers are all available in the commonCode library. This makes it easy for the developmentally challenged among us to create whatever project they want.
The commonCode library wasn’t created just for The Hackaday Prize. [Eric] has been tinkering around with AVRs since well before the Arduino existed, and he has dozens of projects in permanent installations. It’s a great way to give back to the community, and the perfect way to allow people to develop their own things to solve whatever problem they have in mind.
We don’t find smartwatches to be supremely usable yet. This one sets a definition for usefulness. The Enigma machine is of course the cipher process used by the Germans during World War II. This Enigma Machine wristwatch is not only functional, but the appearance is modelled after that of the original machine. With the speckled gray/black case and the Enigma badge branding [Asciimation] has done a fine job of mimicking the original feel.
Driving the machine is an Arduino Pro Mini. We’ve seen Arduino Enigma Machines in the past so it’s not surprising to see it again here. The user interface consists of an OLED display at 128×64 resolution, three buttons, with a charging port to the right and on/off switch on the left.
The device is demonstrated after the break. Quite a bit of button presses are used to set up each of the three encoder wheels. But that’s hardly avoidable when you’re not committing to a full keyboard. We’re pretty impressed by the functionality of [Asciimation’s] interface considering it’s hardware simplicity.
This seems perfect for kids that are proving to have an interest in engineering. They learn about ciphers, embedded programming, and mechanical design and crafting (this is a hand-sewn leather wristband). Of course if you build one and start wearing it into the office we won’t judge.