In 1993, IBM PCs & clones were a significant but not dominant fraction of the home computer market. They were saddled with the stigma of boring business machines. Lacking Apple Macintosh’s polish, unable to match Apple II’s software library, and missing Commodore’s audio/visual capabilities. The Amiga was the default platform of choice for impressive demos, but some demoscene hackers saw the PC’s potential to blow some minds. [Future Crew] was such a team, and their Second Reality accomplished exactly that. People who remember and interested in a trip back in time should take [Fabien Sanglard]’s tour of Second Reality source code.
We recently covered another impressive PC demo executed in just 256 bytes, for which several commenters were thankful the author shared how it was done. Source for demos aren’t necessarily released: the primary objective being to put on a show, and some authors want to keep a few tricks secret. [Future Crew] didn’t release source for Second Reality until 20th anniversary of its premiere, by which time it was difficult to run on a modern PC. Technically it is supported by DOSBox but rife with glitches, as Second Reality uses so many nonstandard tricks. The easiest way to revisit nostalgia is via video captures posted to YouTube (one embedded below the break.)
A PC from 1993 is primitive by modern standards. It was well before the age of GPUs. In fact before any floating point hardware was commonplace: Intel’s 80387 math co-processor was a separate add-on to the 80386 CPU. With the kind of hardware at our disposal today it can be hard to understand what a technical achievement Second Reality was. But PC users of the time understood, sharing it and dropping jaws well beyond the demoscene community. Its spread was as close to “going viral” as possible when “high speed data” was anything faster than 2400 baud.
Many members of [Future Crew] went on to make impact elsewhere in the industry, and their influence spread far and wide. But PC graphics wasn’t done blowing minds in 1993 just yet… December 10th of that year would see the public shareware release of a little thing called Doom.
Continue reading “Under The Hood Of Second Reality, PC Demoscene Landmark”
“Revision” is probably the Olympics of the demoscene. The world’s best tiny graphics coders assemble, show off their works, and learn new tricks to pack as much awesome into as few bytes as possible or make unheard-of effects on limited hardware. And of course, there’s a competition. Winning this year’s 256-byte (byte!) competition, and then taking the overall crowd favorite award, was [HellMood]’s Memories.
If you watch it in the live-stream from Revision, you’ll hear the crowd going (virtually) wild, and the announcer losing his grip and gasping for words. It’s that amazing. Not only are more effects put into 28 bytes than we thought possible, but there’s a full generative MIDI score to go with it. What?!?
But almost as amazing is [HellMood]’s generous writeup of how he pulled it off. If you’re at all interested in demos, minimal graphics effects, or just plain old sweet hacks, you have your weekend’s reading laid out for you. [HellMood] has all of his references and influences linked in as well. You’re about to go down a very deep rabbit hole.
Continue reading “A Jaw-Dropping Demo In Only 256 Bytes”
They say that in order to understand recursion, you must first understand recursion. Once you master that concept, you might decide that it’s time to write your own compiler that can compile itself as a fun side project. According to [Warren] aka [DoctorWkt], who documented every step of writing this C compiler from scratch, a true compiler will be able to do that.
Some of the goals for the project included self-compiling, focusing on a real hardware platform, practicality, and simplicity. [Warren] outlines a lot of the theory of compilers as well, including all the lexical, grammar, and semantic analysis and then the final translation into assembly language, but really focuses on making this compiler one for practical use rather than just a theoretical implementation. He focuses on Intel x86-64 and 32-bit ARM platforms too, which are widely available.
This project is a long read and very thoroughly documented at around 100,000 words, so if you’ve ever been interested in compilers this is a great place to start. There are a lot of other great compiler tools floating around too, like the Compiler Explorer which shows you generated code as you write in a higher level language.
One of the core lessons any physics student will come to realize is that the more you know about physics, the less intuitive it seems. Take the nature of light, for example. Is it a wave? A particle? Both? Neither? Whatever the answer to the question, scientists are at least able to exploit some of its characteristics, like its ability to bend and bounce off of obstacles. This camera, for example, is able to image a room without a direct light-of-sight as a result.
The process works by pointing a camera through an opening in the room and then strobing a laser at the exposed wall. The laser light bounces off of the wall, into the room, off of the objects on the hidden side of the room, and then back to the camera. This concept isn’t new, but the interesting thing that this group has done is lift the curtain on the image processing underpinnings. Before, the process required a research team and often the backing of the university, but this project shows off the technique using just a few lines of code.
This project’s page documents everything extensively, including all of the algorithms used for reconstructing an image of the room. And by the way, it’s not a simple 2D image, but a 3D model that the camera can capture. So there should be some good information for anyone working in the 3D modeling world as well.
Thanks to [Chris] for the tip!
There was a time when microprocessors were slow and expensive devices that needed piles of support chips to run, so engineers came up with ingenious tricks using extra hardware preprocessing inputs to avoid having to create more code. It would be common to find a few logic gates, a comparator, or even the ubiquitous 555 timer doing a little bit of work to take some load away from the computer, and engineers learned to use these components as a matter of course.
The nice thing is that many of these great hardware hacks have been built into modern microcontrollers through the years. The problem is you know to know about them. Brett Smith’s newly published Hackaday Superconference talk, “Why Do It The Hard Way?”, aims to demystify the helpful hardware lurking in microcontrollers.
Join us below for a deeper dive and the embedded video of this talk. Supercon is the Ultimate Hardware con — don’t miss your chance to attend this year, November 15-17 in Pasadena, CA.
Continue reading “Brett Smith Makes Your Life Easier With Hidden Microcontroller Features”
The readability of your code can make the difference between your project being a joy to work on, or an absolute headache. This goes double when collaborating with others. Having easily parsed code reduces your cognitive load and makes solving problems easier. To try and help with this, [PTS93] developed the Stator library to make certain common tasks simpler to read.
The aim of the library is to get rid of piles of state tracking variables and endless if/else statements – hence the name. It’s designed primarily for the Arduino IDE but doesn’t have any dependencies on the API, so can be used in other C++ environments. It comes with a variety of neat tools for common jobs, such as reading an analog sensor with hysteresis around a trigger point, as well as easy ways to track state changes across multiple variables. By using basic English terms instead of condition checks and mathematical operators, it can make things more readable and easier to follow.
The power of the Arduino platform has always been in its easy to use libraries that make everything easier, from interfacing LCDs to working with Amazon Dash buttons.
It’s entirely possible to do your coding in vim or emacs, hammering out hotkeys to drive the interface and bring your code to life. While working in such a way has its charms, it can be confronting to new coders, and that’s before even considering trying to understand command line compiler settings. The greenhorn coder may find themselves more at home in the warm embrace of an IDE, and [morrows_end] has now built one for those working with AVR assembly code.
The IDE goes by the name of Simple AVR IDE, or savr_ide for short. Programmed in C++ with the FLTK widget library, [morrows_end] has tested it on Windows XP, but notes that it should successfully compile for Linux, Unix, and even MacOS too.
All the basic features are there – there’s syntax highlighting, as well as integration with the AVRA assembler and AVRDUDE for programming chips. It’s a tool that could make taking the leap into assembly code just that little bit easier. For another taste of bare metal coding, check out [Ben Jojo]’s discussion of x86 bootloaders.