This book is awesome for anyone who lived those days.
"the PDS assembler could only handle source files up to a certain size so the more you commented your work the less room you had for the actual game code itself"
And that is why, 25 years on, I still use hard tabs rather than spaces.
I got into the habit on the Amstrad CPC using the Maxam assembler. 40k was the limit for a source file and some of the stuff I did, like a UK-wide route-planning program (think an enormously primitive version of Autoroute), seriously pushed that.
Having hard tabs, rather than eight spaces, was a major memory saving, while still retaining readable code. Well, as readable as Z80 ever got. Haven't managed to wean myself off them since...
By all means use hard tabs to your taste, but if it would help anything to use spaces, why not configure the editor to handle that for you and forget about whether you are emitting ASCII 9?
Reminds me of trick from the Commodore BASIC days, where you could use "?" as a replacement for "PRINT" to save a whopping 4 bytes. Seems silly now, but back then it made all the difference.
Don't know about Commodore BASIC, but in Locomotive BASIC on the Amstrad CPC, "?" was just a text-entry convenience rather than a memory-saver. BASIC was stored tokenised, so "?" was one byte same as "PRINT" (in fact, I think it was the same byte).
You are correct. In fact, Commodore Basic had more of these shortcuts which allowed you to type in Basic commands really quickly. If you LISTed the code all shortcuts were changed to their correct command names. Kind of stenographic coding. Never saw anything like that later on with the 'modern' programming languages.. Maybe someone should bring this approach back :)
In Commodore BASIC, the PRINT command is tokenized and stored as a single byte $99 - see this wiki: http://www.c64-wiki.com/index.php?title=BASIC_token
When you use "?", this gets stored as the same token $99 as well. When you LIST the program then, you see PRINT.
PDS also wished you Merry Christmas if the date was December 25.
I coveted it an unhealthy amount whilst being stuck with various machine code monitors on the C64 itself, eventually later having the money to upgrade to an assembler. Of course then there was a whole other class of memory problems as most of them hooked BASIC to work so you were quite limited in the length of programs; everyone became very good at manually laying out blocks to memory and disc.
I just read the whole thing and it was definitely worth it! If you like these kind of coder memoirs (especially if you like Masters of Doom) then this will be right up your alley. Plus I'm an R-Type fan so that's an added bonus.
As I was reading it I couldn't help but feel a bit of regret. It was in 1991 on a visit with my dad to LA that I got my first computer (a TRS-80 Model III) along with a book on programming in BASIC. I didn't know what I was doing, but I wanted the computer to do the stuff I saw on War Games and Explorers. I got pretty far but it wasn't until 1996 or so that I really got into the swing of "serious" programming in C and C++. Growing up in Dallas, TX I didn't have the first clue where I might find people interested in this stuff. Until sophomore year in college it was really just me. I find that I regret not having lived in a place where I could have "gotten into the scene" early. This is even more ironic considering that my idol at the time (and arguably today as well), John Carmack, worked less than 5 miles from my house!
From reading this, it appears the only reason we had any decent 8-bit games at all was due to professional pride and heroic effort on the part of the bedroom programmers employed! He was largely left to his own devices (but given a tight deadline).
Bittersweet moment in the book - the photo of some suit accepting the "best game" award for his game. They never even bothered to tell him he had won...
"My original plan was to self-publish this book and put it up for sale - at a purely nominal price of course (ahem) - and maybe make a few pounds from the thing but there's a part of me that finds this idea just wrong"
There is nothing wrong with making a few pounds from such an interesting story. I'm sure there is more people around like me who actually find a pity not being able to easily purchase a physical copy of this book. I actually find quite convenient to pay for not having to print it ( I mean book printing ) myself. And I actually love to have physical books too, specially this sort of books :)
This is a fantastic read, brings back many memorys of my youth. One thing I was thinking about was the undisclosed multiface backup hack that was mentioned. I believe this could have been done using the Z80 shadow registers, which was a copy of all the Z80 registers in a seperate bank and had to be switched to in by code. If these were used instead via in game switching the multiface 1 would not be able to switch to the shadow registers, it would just copy the main registers, so storing a key in the shawdow register would defeat the multiface 1.
One of the best games ever and an unbelievable ZX Spectrum port.
I still remember holding and reading the box cover from the shops to my home.
And, shameless plug, this is what I did for my summer vacation project: "R-Type Real Time Memory Visualisation" ZX Spectrum http://zaf.io/page-3o.html#p139
Same here. The ZX manual that came with a list of Z80 opcodes was how I learnt assembly/machine code programming. I lived in a real backwaters, and getting the ZX Spectrum as a gift from a distant uncle changed my life.
Had no other books, no community, absolutely no other resources to learn anything. But the ZX and its manuals got me to where I could write machine code programs without even looking up the opcodes.
When I visited the Centre for Computing History (http://www.computinghistory.org.uk/) I noticed that as well as having games for their collection of 1980s home computers, they also had developer tools. Having read about Ian Bogost's "A Slow Year" (for the Atari 2600) it occurred to me that making new games for old machines using "period instruments" might be an interesting exercise. What I had in mind was games that would never have been written at the time, but that would have been technically feasible.
That's as far as the idea got because, er, I'm not a games programmer. As close as I got to an actual idea was that perhaps it would be possible to write a Tetris clone for the ZX Spectrum. Can anybody think of something better?
This looks like a great read. It must have been challenging to do a decent arcade conversion for the 8 bit home computers. The spectrum was probably slower than the z80 sound cpu in the arcade board.
I remember that the Spectrum version of the game was very good, with full colours (perhaps thanks to very fast 8-pixel jumps), as well as the arcade machine it was based on.
The author writes in the book exactly how he managed to contol the colors: the shapes that scroll pixel by pixel never mix with anything of different color horizontally. The things that move freely move in 8 pixel jumps. Magic.
I remember these two and the Amiga versions (A500, Amiga CD). He played it with a symphonic orchestra too.
But yeah, out of these I think the Amiga/C64 title screen tune is the best, and then the first level (by Whittaker, basically the same tune across versions).
Does anyone else see the logo image moving in a weird way? like when you are not exactly looking at it, it feels like animating, like those fancy optical illusions.
(sorry for being off-topic but this is bothering me)
"the PDS assembler could only handle source files up to a certain size so the more you commented your work the less room you had for the actual game code itself"