Gaming In Different Languages

July 7, 2020 by Bryan Cockfield 2 Comments

One of the perks of using older hardware is its comparative simplicity and extensive documentation. After years or decades of users programming on a platform, the amount of knowledge available for it can become extensive. This is certainly the case with the 6502 microprocessor, used in old Apple computers and some video game systems from the ’80s. The extensive amount of resources available make it a prime candidate in exploring various programming languages, and their advantages and disadvantage.

This project looks into those differences using a robot game, which has been programmed four different ways in three languages. [Joey] created the game in Python first and then began to port it to the 65C02, a CMOS variant of the 6502. The first iteration is its assembly language, and then a second iteration with optimized assembly code. From there, he ports it to C and then finally to Forth. Each version of the game is available to play in a browser using an emulator to run the 6502 hardware.

Since the games run in the browser, other tools are available to examine the way the game runs in each language. Registers can be viewed in real time, as well as the values stored in the memory. It’s an interesting look at an old piece of hardware and of its inner workings. For an even deeper dive into the 6502, it’s possible to build a working computer on breadboards using one.

Classic 8-Bit Computing The Atari Way

April 29, 2020 by Bryan Cockfield 9 Comments

In the classic gaming world, even before the NES arrived on the scene, there was no name more ubiquitous than Atari. Their famous 2600 console sold almost as many units as the Nintendo 64, but was released nearly 20 years prior. In many ways, despite making mistakes that led to the video game crash of the early 80s, Atari was the first to make a path in the video game industry. If you want to explore what the era of 8-bit computing was like in the Atari age, a new resource is compiling all kinds of Atari-based projects.

This site has everything, from assembling Atari 8-bit computers based on the 6502 chip, to programming them in BASIC and assembly, to running official and homebrew games on the hardware itself. This was put together by [Jason H. Moore] who grew up around Atari systems and later, their home computers. He even puts his biomedical experience to use here by designing a game for the 2600 called Gene Medic which can be found at the site as well.

If you grew up in the 70s and 80s and are looking for a bit of Atari nostalgia this site is the place to go. It’s even worth a visit from younger folks as well since the 8-bit world is a lot easier to get immersed in and learn the fundamentals of computer science. Of course, if you want to take it the other direction, it’s possible to modify the old Atari to add a few modern conveniences.

Photo via Evan-Amos

PCB Bring-Up Hack Chat

April 14, 2020 by Dan Maloney No comments

Join us on Wednesday, April 15 at noon Pacific for the PCB Bring-Up Hack Chat with Mihir Shah and Liam Cadigan!

The printed circuit design process is pretty unique among manufacturing processes. Chances are pretty good that except for possibly a breadboard prototype, the circuit that sits before you after coming back from assembly has only ever existed in EDA software or perhaps a circuit simulator. Sure, it’s supposed to work, but will it?

You can — and should — do some power-off testing of new boards, but at some point you’re going to have to flip the switch and see what happens. The PCB bring-up process needs to be approached carefully, lest debugging any problems that crop up become more difficult than need be. Mihir and Liam from inspectAR will discuss the bring-up process in depth, offering tips and tricks to make things go as smoothly as possible, as well as demonstrating how the inspectAR platform can fit into that process, especially with teams that are distributed across remote sites. If your board releases the Magic Smoke, you’ll want to know if it’s your design or an assembly issue, and an organized bring-up plan can be a big help.

Note: Liam will be doing a simulcast web demo of inspectAR via Zoom.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 15 at 12:00 PM Pacific time. If time zones have got you down, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

Continue reading “PCB Bring-Up Hack Chat” →

Tony Brooker And Autocode – The First High-level Language

January 2, 2020 by Sven Gregori 32 Comments

The field of computer science has undeniably changed the world for virtually every single person by now. Certainly for you as Hackaday reader, but also for everyone around you, whether they’re working in the field themselves, or are simply enjoying the fruits of convenience it bears. What was once a highly specialized niche field for a few chosen people has since grown into a discipline that not only created one of the biggest industry in modern times, but also revolutionized every other industry, some a few times over.

The fascinating part about all this is the relatively short time span it took to get here, and with that the privilege to live in an era where some of the pioneers and innovators, the proverbial giants whose shoulders every one of us is standing on, are still among us. Sadly, one of them, [Tony Brooker], a pioneer of the early programming language concept known as Autocode, passed away in November. Reaching the remarkable age of 94, the truly sad part however is that this might be the first time you hear his name, and there’s a fair chance you never heard of Autocode either.

But Autocode was probably the first high-level computer language, and as such played a fundamental role in the development of whatever you’re coding in today. So to honor the memory of [Tony Brooker], let’s remember the work he did with Autocode, and the leap in computer science history that it represented.

Continue reading “Tony Brooker And Autocode – The First High-level Language” →

These Tips Make Assembling A Few Hundred PCBs Easier

September 12, 2019 by Donald Papp 7 Comments

There are a few common lessons that get repeated by anyone who takes on the task of assembling a few hundred PCBs, but there are also unique insights to be had. [DominoTree] shared his takeaways after making a couple hundred electronic badges for DEFCON 26 (that’s the one before the one that just wrapped up, if anyone’s keeping track.) [DominoTree] assembled over 200 Telephreak badges and by the end of it he had quite a list of improvements he wished he had made during the design phase.

Some tips are clearly sensible, such as adding proper debug and programming interfaces, or baking an efficient test cycle into the firmware. Others are not quite so obvious, for example “add a few holes to your board.” Holes can be useful in unexpected ways and cost essentially zero. Even if the board isn’t going to be mounted to anything, a few holes can provide a way to attach jigs or other hardware like test fixtures.

[DominoTree] ended up having to attach multiple jumper wires to reprogram boards after assembly, and assures us that “doing this a bunch of times really sucked.”

Other advice is more generic but no less important, as with “eliminate as many steps as possible.” Almost anything adds up to a significant chunk of time when repeated hundreds of times. To the basement hacker, something such as pre-cut and pre-tinned wires might seem like a shameful indulgence. But cutting, stripping, tinning, then hand-soldering a wire adds up to significant time and effort by iteration number four hundred (that’s two power wires per badge) even if one isn’t staring down a looming deadline.

[DominoTree] also followed up with additional advice on making assembly easier. Our own [Brian Benchoff] has also shared his observations on the experience of developing and assembling a large number of Hackaday Superconference badges, including what it took to keep things moving along when inevitable problems surfaced.

You don’t need to be making batches of hundreds for these lessons to pay off, so keep them in mind and practice them on your next project.

Debug Superpowers Bring An STM32 Back From The Dead

August 26, 2019 by Kerry Scharfglass 5 Comments

When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead” →

Examine Source Code To Assembly Mapping With PenguinTrace

May 9, 2019 by Ted Yapo 23 Comments

C-programmers who don’t have a mental model of what’s going on underneath their thin veneer of abstraction above assembly code are destined for trouble. In order to provide a convenient way to understand what C-code gets compiled to and how it runs on the machine, [Alex Beharrell] has created penguinTrace, a program which allows you to see what instructions your code compiles to, and examine how it executes.

While you can get somewhat similar functionality out of standard debuggers, penguinTrace was purpose-built to facilitate exploration of how the whole process works. You can single-step through the instructions your code compiled to, examine variables, and look at the stack — the usual debugger stuff — but structured more for exploration and learning than full-on debugging. Based on our experiences when we learned low-level programming, anything that can help novices build that all-important mental picture of what’s going on underneath is a good thing. But, since it was written with a secondary purpose of learning how debuggers themselves work, it’s a great opportunity for exploring that space, too.

The UI harnesses CodeMirror to provide a browser-based interface, and is configurable to use Clang or GCC for compilation. It supports AMD64/X86-64 and AArch64 architectures, and will run on Windows using WSL: if you’ve got a PC running Linux, a Raspberry Pi, or a Windows box, you’re good to go. The code is AGPL-licensed and available on GitHub. So, if you want to gain a better understanding of what happens when you compile and run “hello, world,” grab a copy and start exploring.

This isn’t the only way to debug, though – we previously featured an application that allows a type of debugging for the Arduino platform.