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]
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”
Today (September 13, 2015) is Programmer’s Day — a recognition day that started in Russia, but has been adopted by many countries. While it is great that there is a day recognizing the contribution of programmers to society, the really interesting part is why it is on September 13 (except on leap years).
The leap year part should be a clue. Today is Julian day 256. We’ll guess that anyone reading Hackaday doesn’t need to be told the rest of the story. While it might not be as good of an in-joke as May the 4th (be with you), it is satisfying to know that it isn’t just a random date from the calendar. Now if we could only get the day off as paid vacation…
Continue reading “Happy Programmer’s Day”
If you are a Hackaday reader, it is a good bet that when you were a kid there was some adult who infected you with the madness you have for science, engineering, tinkering, or whatever it is that brings you here. Maybe it was a parent or a teacher. For many of us, it was a local ham radio operator. But it was probably someone who had the passion for this kind of thing and you caught it.
Paying that debt forward can be very rewarding. Schools and youth organizations are always looking for people to share their passions with kids and at the right age and the right school, you could be that one push that moves a kid off a bad path.
Continue reading “Kids and Hacking: Blind Robotics”
We’ve recently noticed two different fonts aimed at programmers, each with a different approach to editor customization. The first, Fira Code, transparently converts common programming digraphs into single characters. For example, <- becomes an arrow and != (or <>) becomes a proper not equal sign. The other font, Hack (can’t argue with the name), aims to make commonly confused characters distinct. For example, the zero glyph has a very distinct appearance from the letter O.
It is pretty easy to understand how Hack works, but Fira seems a mystery at first. Your C++ compiler expects <- not an arrow, right? Fonts support ligatures–sequences of two symbols that run together (like æ). Clever use of these ligatures means that the compiler still sees -> but the screen displays an arrow.
Continue reading “Hack an Editor: Fonts for Programming”
After the release of Mortal Kombat X, [Zachery’s] gaming group wanted to branch out into the fighter genre. They quickly learned that in order to maximize their experience, they would need a better controller than a standard gamepad. A keyboard wasn’t going to cut it either. They wanted a fight stick. These are large controllers that look very much like arcade fighting controls and include a joystick and large buttons. [Zachery’s] group decided to build their own fight stick for use with a PC.
[Zachery] based his build around the TeensyLC, which is a 32 bit development board with an ARM processor. It’s also compatible with Arduino. The original version of his project setup the controller as a HID, essentially emulating a keyboard. This worked for a while until they ran into compatibility issues with some games. [Zachery] learned that his controller was compatible with DirectInput, which has been deprecated. The new thing is Xinput, and it was going to require more work.
Using Xinput meant that [Zachery] could no longer use the generic Microsoft HID driver. Rather than write his own drivers, he decided to emulate the XBOX 360 controller. When the fight stick is plugged into the computer, it shows up as an XBOX 360 controller and Windows easily installs the pre-built driver. To perform the emulation, [Zachery] first had to set the VID and PID of the device to be identical to the XBOX controller. This is what allows the Microsoft driver to recognize the device.
Next, the device descriptor and configuration descriptor had to be added to the Teensy’s firmware. The device descriptor includes information such as USB version, device class, protocol, etc. The configuration descriptor includes additional information about the device configuration. [Zachery] used Microsoft Message Analyzer to pull the configuration descriptor from a real XBOX 360 controller, then used the same data in his own custom controller.
[Zachery] programmed the TeensyLC using the Arduino IDE. He ran into some trouble here because the IDE did not include the correct device type for an Xinput device. [Zachery] had to edit the boards.txt file and add three lines of code in order to add a new hardware device to the IDE’s menu. Several other files also had to be modified to make sure the compiler knew what an Xinput device type was. With all of that out of the way, [Zachery] was finally able to write the code for his controller.
In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!
[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.
Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.
The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.
The modified version of the Optiboot bootloader is available on [Majek]’s Github. If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.
Thanks [Koepel] for the tip!