In a very real way, Pong started the video game revolution. You wouldn’t have thought so at the time, with its simple gameplay, rudimentary controls, some very low-end sounds, and a cannibalized TV for a display, but the legendarily stuffed coinboxes tell the tale. Fast forward 50 years or so, and Pong has been largely reduced to a programmer’s exercise to see how few lines of code can stand in for what [Ted Dabney] and [Allan Alcorn] accomplished. But now even that’s too much, as OpenAI Codex can generate a playable Pong from just a few prompts, at least most of the time. Continue reading “Let Machine Learning Code An Infinite Variety Of Pong Games”→
It’s fair to say that among the new product launches we see all the time, anything new from the folks at Raspberry Pi claims our attention. It’s not that their signature Linux single-board computers (SBCs) are necessarily the best or the fastest hardware on paper, but that they’re the ones with meaningful decade-plus support. Add to that their RP2040 microcontroller and its associated Pico boards, and they’re the one to watch.
Today we’ve got news of a new Pi, not a general purpose computer, but useful nevertheless. The Raspberry Pi Debug Probe is a small RP2040-based board that provides a SWD interface for debugging any ARM microcontroller as well as a more generic USB to UART interface.
The article sums up nicely what this board does — it’s for bare metal ARM coders, and it uses ARM’s built-in debugging infrastructure. It’s something that away from Hackaday we’ve seen friends using the 2040 for as one of the few readily available chips in the shortage, and it’s thus extremely convenient to have readily available as a product.
So if you’re a high level programmer it’s not essential, but if you’re really getting down to the nuts-and-bolts of an ARM microcontroller then you’ll want one of these. Of course, it’s by no means the first SWD interface we’ve seen, here’s one using an ESP32.
An article on the history of EPROMs in the Soviet Union by [Vladimir Yakovlev] over at The CPU Shack Museum caught our attention. It is part one of a series on the topic, and walks you through the earliest Soviet EPROMs families.
Early EPROM programmer using punched paper tape (Intel, Electronics Magazine 1971)
The first of which, from the 1970s, is the K505RR1 developed and manufactured in Kyiv, equivalent to the first-generation Intel 1702A. It could hold 2048 bits, organized as 256×8, and offered a whopping 20 reprogramming cycles and data retention of 5000 hours.
The narrative proceeds to introduce several subsequent generations, design facilities, manufacturing techniques, and representative chip examples. A few tidbits — unlike Western EPROMs, the Soviets managed to put quartz windows in plastic packages (see the KP573 family).
In addition to the common gray or white, they also used different terracotta colored ceramic packages. An odd ceramic flat-pack EPROM is shown, and also some EPROMs whose dies have been painted over and re-badged as OTP chips.
Intel began producing EPROMs in 1971 as reported by the inventor, Intel’s Dov Frohman-Bentchkowsky, in Electronics Magazine’s 10 May edition (pg 91). We learned, amongst other things, that the 1701 did not have a quartz window, but could still be erased by exposure to X-rays. A friendly word of warning — browsing electronics advertisements from 50 years ago can easily consume your entire morning.
Once the package is sealed, information can still be erased by exposing it to X radiation in excess of 5×104 rads, a dose which is easily attainable with commercial X-ray generators.
It’s been at least a couple of months since we’ve seen a different 3D modeling language project, so here’s [Lukasz Janyst] with GhostSCAD: a take on creating OpenSCAD models, using the Go language as the front end, bringing all the delights this modern modular language has to offer (and a few of its own idiosyncrasies.) As [Lukasz] says in the blog, from a programmer’s viewpoint, openSCAD has a number of failings that make it not necessarily hard, just kinda annoying to work with, due to the way the geometry tree works. The OpenSCAD way of working ends up with the programmer requiring knowledge of the internal workings of sub-modules, in order to work at the top level (assembly) which is not an ideal situation from a code reuse perspective.
A programmer would describe this problem as “abstraction leakage” and it doesn’t make modular, reusable coding easy to do without a lot of extra work. [Lukasz] says regarding the example GhostSCAD project, that some parts were modeled in a way that knowledge was needed of some mounting points of sub-modules, but those sub-modules had no way to expose this information to the outside world. GhostSCAD enables the programmer to define parts that expose specific parameters to the world that can be queried, for example, to produce a joining part, or an exploded assembly diagram. These properties can be interpreted without the querying module having any knowledge of the internal structure of the thing it’s working with. GhostSCAD provides a Java3D-like API for defining the geometry tree, which may be familiar to some.
In the early days of C, you’d occasionally see someone — probably a former Pascal programmer — write something like this:
#define BEGIN {
#define END }
This would usually initiate complaints about abusing the preprocessor and generally being anti-C. Surely no modern language would permit such things, right? Perhaps not. Consider [Tushar Sadhwani] who wanted to create a classic C-style for loop inside of Python. He did it, and the journey is perhaps more interesting than the result.
First, you can’t just transport straight C for loops into Python. There has to be some concession to Python syntax. The initial attempt was clever but not clever enough. However, the disassembly of the Python code was telling. The second attempt, however, was particularly interesting.
That attempt used an odd feature to examine the interpreter’s tree structure for the code and then modify it. This is sort of like a very painful C preprocessor but more powerful. That version works although it is pretty convoluted.
Ironically, [Tushar] then set up a third attempt after seeing code that tries to replace Python indentation with braces using a codec. In Python-speak, a codec lets you convert different text encodings. However, you can do other things than text encoding conversion. This is closest in spirit to the C preprocessor method. You can wade through the source code ahead of processing and make whichever changes you see fit.
Is any of this really useful? Probably not as it is. But you never know when you might need to do something exotic and one of these techniques could save the day. You probably couldn’t get away with some of this on MicroPython, of course. Your mileage may vary depending on where you find your Python running — like the Web.
There’s nothing new about a Pi camera module as they’ve been available for years in both official and third party forms, so to be noteworthy the new one has to offer something a bit special. It uses a 12 megapixel sensor, and is available both in autofocus and wide angle versions in both standard and NoIR variants. Wide angle and autofocus modules may be new in the official cameras, but these are both things which have been on the third-party market for years.
So if an autofocus camera module for your Pi isn’t that new, what can we bring to a review that isn’t simply exclaiming over the small things? Perhaps it’s better instead to view the new camera in the context of the state of the Pi camera ecosystem, and what better way to do that than to turn a Pi and some modules into a usable camera! Continue reading “Do You Need The Raspberry Pi Camera Module V3?”→
For the proper retro gaming aesthetic, plenty of gamers look to old CRT displays. Older games can look better on these displays because the original programmers took their visual characteristics into account. Finding a CRT from the 90s or early 2000s is one option, but an even better option is a broadcast video monitor (BVM) which were extremely high quality CRTs with some other features, like the ability to install a Wii straight to an expansion port on the monitor itself (Nitter).
These monitors were, as their name implies, made for broadcast TV productions. As such, they don’t have the typical video connections that might be found on a consumer unit. Instead, they used modular cards to interface with the monitor. Thanks to an open design for cards made for Sony monitors, [ShankMods] was able to make one for the Wii by “trimming” away the unnecessary parts of the console’s PCB and mapping its video and audio outputs to the slot connector.
While the Wii might not be everyone’s idea of retro, it was still a console that came out when plenty of people still had CRTs as their primary home television. It isn’t as necessary to have a CRT for a Wii as some of the older consoles, but it was very easily adaptable to this single-board design. If you don’t have a CRT and still want the CRT feel, there are ways of retrofitting a more modern display to get this effect, though.
coding easy to do without a lot of extra work. [Lukasz] says regarding the 
