C23 Programming For Everyone

Here’s a history quiz: What architecture did the first C++ compiler target? Of course, it is a trick question. The original C++ — known then as C with classes — compiler wrote out standard C code that you then compiled for whatever your target was. This has a lot of advantages since C compilers are everywhere. Now we are seeing a similar approach to bring C23 to the world with Cake. Cake can translate C23 or other versions to C99 which you can then compile with normal compilers.

While the old C++ compiler, cfront, needed special steps to compile (since it was built using C++), you can build cake for Windows or Linux easily. However, it can also be built with emscripten and you can try it yourself in your web browser.

Continue reading “C23 Programming For Everyone”

The Big List Of Naughty Strings Helps Find Those User Input Problems

Any software that accepts user input must take some effort to sanitize incoming data, lest unexpected and unwelcome things happen. Here to make that easier is the Big List of Naughty Strings, an evolving list of edge cases, unusual characters, script-injection fragments, and all-around nonstandard stuff aimed at QA testers, developers, and the curious. It’s a big list that has grown over the years, and every piece of it is still (technically) just a string.

These strings have a high probability of surfacing any problems with handling user input. They won’t necessarily break anything, but they may cause unexpected things to happen and help point out any issues that need fixing. After all, many attacks hinge on being able to send unexpected inputs that don’t get properly sanitized.

Finding bad inputs is not always entirely straightforward, but at least the Big List of Naughty Strings is available in a variety of formats to make it easy to use. [Max Woolf] has been maintaining the list for years, but if you haven’t heard of it yet and think it might come in useful, now’s the time to give it a look. Now you can help ensure your system can handle things like someone registering a company named ; DROP TABLE “COMPANIES”;– LTD.

Diff Tool Knows What You Mean

We will admit to not being particularly artistic, but we do remember an art teacher telling us that sometimes it is better to draw what isn’t there instead of what’s there — a concept known as negative space. [Wilfred] makes a similar point when explaining his “fantastic diff” tool called, appropriately, difftastic. He points out that when comparing two programs, the goal isn’t so much to determine what changed, but rather what stayed the same. The more you can identify as the same, the less you have to show as a change.

The tool compares source code in a smart way, assisted by tree-sitter which has many different languages already parsed, at least well enough for this purpose. According to [Wilfred’s] post the tool supports 44 different languages ranging from bash and YAML, Verilog to VHDL, and C++ to Rust, among others.

Continue reading “Diff Tool Knows What You Mean”

KittyOS: Writing A Toy OS For The ATmega168 From Scratch

Writing an operating system for a computing platform is one of those non-trivial tasks few people actually need to do, regardless of whether it’s for a small microcontroller or a larger general-purpose computer. Many of us spend a large amount of our time working on producing robust code for embedded systems, occasionally diving deeper into the abstraction when we’re stuck on a problem. Quite often this work is sitting on top of an RTOS, which we consider a solved problem. [Jonathan Diamond] had picked up a fair bit of knowledge of some of the low-level AVR black magic, as well as some details of how operating systems work internally, and so decided to have a crack a building a toy operating system called KittyOS, for the learning experience alone.

[Jonathan] hastens to add that this is not a practical OS, but a learning platform that needs a few more bells and whistles added to be useful. Aimed at the 8-bit AVR ATmega168 with its mere 16kB of flash and 1kB of SRAM, the diminutive chip can still perform more than well enough to host the rudimentary OS — up to four application tasks, and some basic system call support.

Already, KittyOS sports preemptive multitasking, with prioritization and support for applications written in C. Hardware support is a bit limited, with just serial I/O and a spot of GPIO, but that’s more than enough for a demonstrator. Applications can be loaded into any of the four available slots, with per-slot run state control, using the Python-based host interface. The post is a long one, with an absolute ton of the gory details we love around these parts, and we’re very glad [Jonathan] took the time to make a proper write-up as well as a demonstration video, which can be found after the break.

Continue reading “KittyOS: Writing A Toy OS For The ATmega168 From Scratch”

Choose Your Own Vector Map

There are adults out there driving who were born after Google Earth came out. Potentially distressing facts aside, those who were around to remember the magic of scrolling in and out with infinite levels of detail was an experience that burned into our brains. Perhaps still curious 21 years later, [Craig Kochis] dove into how vector maps work by implementing one himself.

Some standard helper functions convert latitude and longitude into Mercator coordinates (x and y coordinates on the screen). He used WebGL to draw a canvas, making the whole thing interactive on the webpage itself. The camera position and zoom level stored as a matrix that is used to transform the map projection. By grabbing polygons that describe the shape of various borders and then converting those polygons into triangles with earcut, [Craig] has a part of a country rendered to a screen. Continue reading “Choose Your Own Vector Map”

Recreating DOOM On A Homebrew 8-Bit CPU

[James Sharman] has been working away on a 8-bit CPU of his own design. Naturally, with his computing device largely functional, the obvious question was asked: can it run DOOM? [James’] latest video explores this question, showing just how close he was able to get.

[James’] 8-bit pipelined CPU also has its own UART, VGA adapter, and sound adapter all built up on discrete components on various PCBs. There’s also a custom interface for a SNES controller as an input device. However, it’s fundamentally well below the specs that DOOM originally required at launch. His 8-bit CPU runs at just 4 MHz, with 64 KB of RAM. This compares poorly to the 32-bit, 33 MHz Intel 386 chips and 4 MB of RAM originally recommended to run the game.

In lieu of running the real thing, [James] demonstrated the limitations of his machine by coding his own demo, nicknamed Doomed. It’s able to average 19 fps video output at a resolution of 80×60, and consists of over 5,000 lines of hand-written assembly code. Fundamentally, it’s a basic 3D engine not dissimilar to Wolfenstein 3D, though without any actual gaming interactions involved.

[James] could have simply stated the machine won’t run DOOM. However, trying to get something similar up and running was a useful learning experience, and in his own words, highly satisfying. This attitude of pushing on in the face of adversity is what propels many other DOOM porting efforts.

Continue reading “Recreating DOOM On A Homebrew 8-Bit CPU”

Self-Hosted Pi Pico Development

Older readers and those with an interest in retrocomputing may remember the days when a computer might well have booted into a BASIC interpreter. It was simultaneously a general purpose device that could run any software it would load, and also a development environment. Not something that can be said for today’s development boards which typically require a host computer on which to write code. Have we lost something along the way? Perhaps an answer to that question can be found in [lurk101]’s self-hosted development environment for the Raspberry Pi Pico.

It presents itself as a shell, with a flash file system, a port of the vi editor, and a C compiler. We might think of vi as being more at home on a UNIX-derived system, but in this case it’s a port of the vi included in BusyBox. Meanwhile the compiler comes from amacc project.

Of course, this still requires a terminal of some type which in practice will mean a host computer. But the feat is nevertheless an interesting one, and we can see that it might not be impossible given the Pico’s surprising versatility to being some of the terminal features onto the chip itself.

It’s worth noting that this isn’t the first attempt we’ve seen to put a command line interface on a development board.