It's not like there was a choice -- at that time, you had to do a lot in a small space, with very little in the way of computational power. If you wanted to write a game, you had to do so in assembly. Mind you, games were much simpler then.
And sure, x86 might be easier to understand, but it's not the original PoP. That's what this is about, not just the code.
I happened to be in the office of someone who was doing language translation on the PC version of PoP at the time; He had a copy of the source code for that, and it was C.
That was twenty years ago. I only got a glimpse of one screenful of code, but I remember feeling special for that nonetheless :)
x86 might be easier to understand for someone who happens to know x86, but frankly for someone who doesn't have previous exposure to assembly, I'd be willing to bet it'd be far quicker to pick up the 6502...
Really depends on what you mean by x86. If you're talking 16-bit real mode code, it's pretty straightforward -- C in assembly form, largely. If you're talking pmode code, modern asm, I tend to agree. I hope this rekindles an interest in 6502 asm, though!
I'm an old C64 and Amiga guy - the first time I saw x86 code I was horrified. 16-bit real mode or not, when I finally gave up on my dying Amiga was when I stopped writing assembly as well - x86 assembly was where I drew the line. I didn't want to make that transition.
In other words, I don't agree that 16-bit real mode is much better. Now, mdern x86_64 code is starting to get tolerable, with more orthogonal register, for example. But I'd rather chew off my own hand than be forced to write any large amount of 16 or 32 bit x86 assembly....
Then again, I'm horribly opinionated about programming language syntax...
The x86 is actually fairly straightforward, as long as you don't try messing around with A20-gates, GDTs and legacy modes (i.e. not staying in protected/long mode the OS has given you). It's only when you try to build things such as bootloaders that x86 starts getting nasty. Backwards-compatibility can be quite evil.
It's not that it's complicated. Few assembly languages manages to be all that complicated, at least if you avoid some of the more bizarre addressing modes ...
It's that it's horribly ugly and full of warts.
The biggest issue I have with x86 is not even trying to make things orthogonal (until x86_64, which does a tolerable job cleaning up a lot of the mess).
Some of it could probably be improved simply by ditching the syntax, and renaming stuff and pretending a lot of the rest simply doesn't exist, but you'd be left with something that looks very different from a typical x86 assembly listing..
But some stuff you don't avoid unless you go 64 bit: The registers alone gives me gives me hives, starting with the naming convention, where the M68k for example is straight forward: D0 through D7 = data registers. A0- A7 = address registers. For a lot of things they can even be used entirely interchangeably.
No addressing parts of the registers with special names, or mumbo jumbo restrictions on what can be done with different registers (that was excusable when the 6502 was a viable competitor, but even that followed clear and simple rules (Arithmetic on the accumulator (A), indexing with the X and Y registers) and didn't layer complexity on top of complexity. Bank switching / segments? Nope, we don't clutter the CPU with junk like that. Either you use a memory address or IO lines (or, as it happens, on the 6510 in the C64, IO lines mapped to a memory address).
Maybe I'm just still sore the M68k lost the performance race and I "had to" get a PC.
As you noted, the x86_64 sorted out some of the mess.
Personally, I think a big issue is the whole backwards-compatibility thing. It causes all sorts of nastiness, and a complete overhaul of the architecture is impossible because everything depends on it! (Which is one of the reasons the IA-64 never really became a hit.)
I vote we design our own processors, and write a new kernel to boot. ;)
Um... ARM got assembly "right" three or four separate times at last count (depends if you count thumb and thumb2 as distinct architectures). And I believe they now have three equally "right" (and mutually incompatible) floating point architectures.
Everything has warts (and x86 more than most). But don't pretend that ARM is clean. Or VAX (integer polynomial instructions? Non-IEEE floating point what now?). Or MIPS (A branch delay what? Multiply outputs to a separate register?). Or even 68k (let me puke garbage on your stack, I'll just tell you how much room you need).
As a matter of fact, I agree. The fact that x86 won the consumer market is, IMHO, very much one of those clever-marketing-and-quick-standardization-cases.
So does it use any unofficial opcodes for performance?
(IIRC, the 6502 decoded instructions by bitmasks; say bit 7 meant "load" and bit 6 meant "move" or some such thing. So you could trigger combination instructions that'd still execute in 3 cycles but perform the work of two instructions that'd normally take 6. This might have been 6510-only, but I don't think it was.)
Sadly, the 65C02 used on the //c and //e enhanced converted those to NOPs :-(
I actually had to rewrite some code because of that. I remember the comments in the source code were less than kind towards the engineers responsible. I may even have the listings somewhere.
And sure, x86 might be easier to understand, but it's not the original PoP. That's what this is about, not just the code.