4 ms·

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 wr

by daeken 15y ago

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.

vidarh 15y ago
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...
- daeken 15y ago
  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!
  - deleted 15y ago
    [deleted]
  - vidarh 15y ago
    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...
    - inoop 15y ago
      Amigaaaaaaaaaaaaaaaaaaaaaaaaaaa!
      - inoop 15y ago
        To those that didn't get the reference: http://www.youtube.com/watch?v=GMATCbC0g3I http://www.youtube.com/watch?v=GMATCbC0g3I :)
        plaes 15y ago
        European demoscene is virtually unknown for the rest of the world :(
- hobin 15y ago
  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.
  - gaius 15y ago
    Right, but compare it to ARM, VAX, MIPS or even 68k. There are plenty of people who got assembly "right"; Intel isn't one of them. Not by a long shot.
    - hobin 15y ago
      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.
    - ajross 15y ago
      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).
  - vidarh 15y ago
    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.
beagle3 15y ago
Actually .. 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 :)
jaylevitt 15y ago
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.)
- to3m 15y ago
  "How MOS 6502 Illegal Opcodes really work": http://www.pagetable.com/?p=39 http://www.pagetable.com/?p=39
- rbanffy 15y ago
  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.

by daeken 15y ago

vidarh 15y ago

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...

daeken 15y ago
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!
- deleted 15y ago
  [deleted]
- vidarh 15y ago
  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...
  - inoop 15y ago
    Amigaaaaaaaaaaaaaaaaaaaaaaaaaaa!
    - inoop 15y ago
      To those that didn't get the reference: http://www.youtube.com/watch?v=GMATCbC0g3I http://www.youtube.com/watch?v=GMATCbC0g3I :)
      - plaes 15y ago
        European demoscene is virtually unknown for the rest of the world :(
hobin 15y ago
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.
- gaius 15y ago
  Right, but compare it to ARM, VAX, MIPS or even 68k. There are plenty of people who got assembly "right"; Intel isn't one of them. Not by a long shot.
  - hobin 15y ago
    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.
  - ajross 15y ago
    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).
- vidarh 15y ago
  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.

beagle3 15y ago

Actually .. 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 :)

jaylevitt 15y ago

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.)

to3m 15y ago
"How MOS 6502 Illegal Opcodes really work": http://www.pagetable.com/?p=39 http://www.pagetable.com/?p=39
rbanffy 15y ago
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.