I tried building it on Ubuntu, if you follow the instructions the SDL library include files will end up in a directory called SDL so you have to include SDL/SDL.h and even then the build fails with lots of SDL related definitions missing (SDL_Window for instance).
That's because you really should be doing
sudo apt-get install libsdl2-dev
#include <SDL2/SDL.h>
make
http://www.freevintagegames.com/MAME/invaders.php
After downloading you'll have to rename the files because the names will all be uppercase:
cd inv1
mv INVADERS.E invaders.e
mv INVADERS.F invaders.f
mv INVADERS.G invaders.g
mv INVADERS.H invaders.h
cd ..
./bin/si78c
- bracket your ifs and place the starting { on the same line as if/while, or one day you'll sit there staring at the screen for 8 hours trying to figure out why your code no longer works due to an accidentally deleted line.
So:
while (num < 64)
{
int has = SDL_PollEvent(&event_buffer[num]);
if (!has) break;
num++;
}
while (num < 64) {
if (SDL_PollEvent(&event_buffer[num])) {
break;
}
num++;
}
This is some rather strange advice. That and the rewrite dropped a '!'.
CFLAGS := [other flags...] $(shell sdl2-config --cflags)
LDFLAGS := [other flags...] $(shell sdl2-config --libs)
You would but it's worth keeping in mind this implementation is constrained by closely following the structure and logic of the original. It's like writing C but being told exactly what state you have to maintain (and where), down to the bit, in advance. It really is a 'hardware simulator' where the spec and input handed to you is the sequence of memory states (and a few other bits) of the original machine.
The C version also loses a few lines here and there for function prototypes and structured control flow.
Handwritten 8085 can be quite compact in some places due to sharing code fragments. It's a bit like self ROP.
int has = SDL_PollEvent(&event_buffer[num]);
if (!has) ...
if (SDL_PollEvent(&event_buffer[num])) ...
Particularly handy in the Visual Studio debugger when working with C#.
That kind of feedback is gold.
I have updated the README with the correct Ubuntu package details.
I think the issue with the includes is likely to do with having both SDL1 and 2 installed, and the slightly dirty way I am pulling in the header (so it works on Mac too).
I will have a bit of a think about how best to resolve that issue, likely needs some ifdefing.
Not necessarily if the C code is trying to reproduce, in detail, all of the externally visible effects of the original assembly language.
> In the early eighties you would have found the Space Invaders cabinet in an arcade right next to the pinball machines. So a "tilt" switch, like you would find in a pinball machine, would not have seemed as strange as it does today. If you shake, slap, or otherwise physically abuse an SI cabinet you will get a TILT message and your game will end.
It seems like a weird sort of reflex action to put a tilt sensor in a video game, though. Maybe they were just worried about frustrated players damaging the equipment?
Those tilt sensitivity is common in computer games, although in some computer pinball games there is no penalty for bumping the table too much.
(Of course, Space Invaders is not a pinball game and so physically attacking it is not legitimate.)
Also, get an HTTPS certificate friend, it's 2019. Dreamhost provides LE certs literally for free.
Because for GIF playback no need any video player plug-in in browser.
HTTPS is unnecessary for this site.
And do what? I'm using (latest stable) FF but nothing in the right click menu seems to allow me to control playback.
> HTTPS is unnecessary for this site.
A: HTTPS prevents your website from being defaced
B: I care about protecting the privacy of which websites and web pages I visit - even if you don't
C: The website hosts the author's PGP key
The Great Cannon enjoys your continued support.
https://cybersecurity.att.com/blogs/labs-research/the-great-...
This is a bit of a love letter to Space Invaders, and video games in general.
I started working on this as a simple emulation project, to rekindle my own passion in low level video game hacking, but then realized with a bit of care I could take it further.
So, this is not a simple clone of the game, but rather a painstaking recreation of the source code in clean, readable C code.
I wanted to make something nice that would last a while, as a tribute to the original, and hopefully function a bit like a rosetta stone for future audiences.
Enjoy.
Well spotted, it looks like you are right. A quick glance here https://computerarcheology.com/Arcade/SpaceInvaders/Code.htm...
and here
https://www.fontzip.com/apple-ii-screen-typeface
Shows a distinct similarity.
(my usual disclaimer: I'm not asking this passive aggressively, I'm genuinely interested in the answer to this).
The project works exactly as the original and recreates the memory state byte for byte, so like the original it has different tasks running at once that are reading and writing to shared memory. Rust's borrow check exists to prevent this sort of thing, because it is so hard to do it correctly or prove it is correct once you have done it. So to use rust, the author would have needed to either totally re-architect Space Invaders, or write the whole thing in ugly, non-idiomatic rust.
Rust simply doesn't let you do the things assembly and C programmers did all the time in 1978 (and with the complexity of our software now and the extra computing power, that's usually for the better). C, on the other hand, has at times been described as "portable assembly," which makes it a good choice for someone wanting to stay true to the original program flow.
Every language has a problem that it is good at solving, and some languages express the underlying idea more clearly than others. In this case, the author has done a bang-up job picking a common, everyday language to solve the problem.
How long did it take you? How did you verify the memory accuracy? It sounds like you co-simulated your implementation with the emulation?
Quoting Wikipedia:
"... around 1999 Christian Pinder developed Elite: The New Kind as a modern PC port of the original BBC Micro version. He achieved a faithful port by reverse-engineering the original assembly written BBC Micro version and recreating a platform neutral C code variant from it, but at David Braben's request this version was withdrawn from distribution in 2003. In September 2014, on Elite's 30th birthday, Ian Bell blessed Elite: The New Kind and re-released it for free on his website. Since then, Elite: The New Kind is also distributed again in version 1.1 by Christian Pinder; a source code mirror is hosted on GitHub."
How hard would it be to port the sound as well?
si78c is faithfully sending all the right bits to the right port, but the hardware component would have to be emulated to get it going.
The relevant code could most likely be borrowed from MAME.
https://github.com/mamedev/mame/blob/master/src/devices/soun...
Emulates the TI SN76477 sound chip.
BTW, in case anyone tries to build it on Ubuntu 14.04 x86 with gcc, you'd need `-std=gnu99 -D_GNU_SOURCE` flags, otherwise it barks about stack_t in ucontext.
Could this be done for Galaga? That’s my personal favorite.
https://github.com/neiderm/arcade/
Don't know if it's finished though - Galaga would be about 10 times harder to do than this project.
First I thought "oh I must have implemented an instruction wrong". So I re-checked all the instructions, read through the Intel 8080 programming manual multiple times. I did find a few errors related to the carry flag, but fixing them didn't change anything.
I then started to actually debug the game code. This was significantly harder than I'd expected. Since the game was in assembly, it was not obvious what each instruction did. What I had to do was pretty much annotate each and every instruction, along with all the memory locations. E.g. address 0xABCD is for player score, 0xCDEF is for player position, instruction X is for drawing the bunker, etc.
It was truly a pain, but it paid off. So the game had an interrupt handler registered to the display refresh signal. And I finally realized the game was constantly interrupted when it was not supposed to. Turns out I had forgotten to disable the signal when entering the handler.
I fixed it, and it ran perfectly.
I have always dreamed of building a classic ROM to C transpiler for native, portable, future-proof(ish) binary builds (just like this).
Not accessible where HTTPS is required here is a mirror that has SSL https://archive.is/E6y37
Why not SDL1.x? It would be more portable,
What about Symbian support?[0]