Thanks for all the feedback!
Unfortunately, I only have very limited time to post in the forum. But as there seems to be some interest in the motivation for this lecture, let me give you some background information and let me explain a bit about the idea behind this course.
The course is not a prank, but has some serious educational intentions.
I am not an expert in robotics. I am a professor of computer science and software engineering. Before I assumed my position as Pforzheim University, I worked as a senior software developer in the R&D departments of several large EDA companies and was mainly concerned with devising algorithms and implementing them.
At Pforzheim University, I teach all sorts of computer science and programming classes, ranging from introductory courses to advanced lectures on algorithms and data structures and design patterns. When it comes to learning how to program a computer, I am convinced that nothing is more boring than doing text-in / text-out programming exercises (like I think so many of us suffered from in our own programming classes). That is the reasons why I started to use (educational) robots as a means of making programming exercises more interesting and more fun. The students actually see what their code does when a robot moves or crashes into an obstacle. So the “robot programming” class is a class about advanced programming techniques and general programming concepts, illustrated by using such techniques to control autonomous robots.
At the beginning of this spring term, in March 2016, I had the problem that most of the robots which are usually used in this course had to undergo maintenance and so would not be available. Thinking about a good alternative coincided with my father sending me my old Vectrex device which he had discovered in the vaults of my parent’s home. When I was a kid, I played for hours, and the Vectrex was one of the main reasons why I became interested in programming and later on studied computer science, because I wanted to understand how these games worked and why in the end the computer always won.
So when the packet arrived, I enjoyed being a kid again for an evening, playing my old cartridges that came along with my Vectrex. The same night I decided to do what I had dreamt about as a child: to write my own Vectrex game and run it on the real machine. By that time, I had no idea about the details of how to do this, by I vaguely knew that homebrewed games for the Vectrex existed. I started some research on the internet and soon realized that this would take much longer than I could afford in my free time.
The solution was easy: do this as part of one of my lectures :-)
This also solved my problem with the non-available robots. Instead of using robots for the programming exercises, we now use the Vectrex. The students’ task is to design and implement their own retro video game, using an emulator for development and testing, and the promise is to see the result run on a real Vectrex arcade machine from the golden days of the dawn of the computer era.
This proved to be a big motivation for the students.
In the lectures, I focus on advanced hardware oriented C programming, as well as on techniques, algorithms and data structures for game development. We also cover the details of how a compiler works and how C is translated into assembly language. The important part here is that we explore general concepts, e.g. how C function parameters are passed via stack frames, or how global and local C variables are treated completely different on assembly level, Or how constant and non-constant C variables results in completely different things on assembly level.
These aspects and concepts are machine independent. However, of course we also deal with the Vectrex specific stuff, i.e. the MC6809 processor, the Vectrex memory layout, bios etc. The Vectrex bios is small and decent enough to be understood completely (well, almost…), so this a nice example to see in detail how a piece of software and an operating system interact and work together.
Furthermore, emphasis is laid on designing computationally efficient (meaning fast) algorithms and memory efficient algorithms (using as few memory as possible). Both is really important on a small system like the Vectrex, as you can imagine, if you want your game to be complex but to run smoothly at the same time. If one programs directly in assembly language, then these things are obvious. But if one uses a high level language like C, it is not that obvious which of the many ways to write the same thing in C is the most efficient.
Today, on modern machines, most programmers do not really care if their programs use more memory than would be necessary, or if the computations take longer than necessary, as today’s machines have abundant memory and processors are so fast, that a few additional machine cycles do not seem to matter.
As someone here so nicely put it, today every dummy can click together a java app without really needing any deep knowledge about programming. As I experienced, many of today’s software developers are proficient in programming in a high level programming language, but lack a deeper understanding of what code is actually generated by the compiler and of what conceptually happens on the processor level (let alone have some basic knowledge of assembly language).
However, all these things get really important when it comes to game development on the Vectrex. Or, to put in a modern context, when it comes to programming embedded systems with limited resources.
So, in essence, for me the Vectrex project is a way to disguise that I am teaching the students some relevant and up-to-date hardcore programming skills, while making it look like fun :-)
