10
\$\begingroup\$

Regarding this suggested crack, do I have to accept it as valid?

The code there is not valid 6502 machine code because it uses an opcode that doesn't exist (and won't work / crash on CMOS variants of the 6502 processor family). But it works correctly on all NMOS variants, and there wasn't ever an unmodified C64 shipped with a CMOS processor. So it will in practice only crash on systems like the C64 DTV (first generation) or a C64 equipped with a "turbo" extension like the SuperCPU that includes a CMOS processor.

  • Reject it: It isn't valid 6502 code any more, will crash on an "accelerated" C64 and some emulated systems, and if a crack like this would be allowed, 6502 code targetting the C64 could often be "trivially" cracked.

  • Accept it: The code targets the C64 and will work correctly on any real machine that wasn't modified/extended. As "undefined behavior" is explicitly allowed here as long as the actual behavior is the expected one, this is a valid crack.

So, what do you think? Do you have additional arguments for accepting/rejecting this crack?

\$\endgroup\$
2
  • 4
    \$\begingroup\$ I wasn't trying to "cheat" with my crack. It ran in the same online emulator that you had used for your demo, so I figured it was okay. I understand that where/how you code on your system doesn't necessarily match what you put as the example "try it online" (it doesn't for me on my TIOs). I see that meta agrees that it is okay to keep the answer up, but I will take down my crack answer. It will break the link in your question, so if you want to pull anything from it, you can now before I take it down. \$\endgroup\$
    – Jo.
    Commented Nov 16, 2017 at 2:23
  • 3
    \$\begingroup\$ @Jo. I don't want to be unfair, that's why I asked. Given the answers here, the crack is valid, so keep it! The only real machine I know about that doesn't execute your code is the 1st gen C64-DTV, which is arguably not a C64. Otherwise, problems are only expected with some emulators. It's my fault not to think about illegal opcodes in the first place and explicitly forbidding them. Because there are some of these opcodes doing exactly the same as the "legal" ones, it defeats the purpose (you can find any amount of changes), but again, that's a lesson I learned here :) \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 7:02

4 Answers 4

Reset to default
15
\$\begingroup\$

Yes

By the definition of programming languages on this site, programming languages are defined by the implementation. So as long as there exists a machine that can run that machine code and return correct result, it is valid.

However, for that particular case, you can specify that "Intended crack doesn't use invalid opcode". If the OP (Stewie Griffin) or the community accept it (the cops can specify conditions on crack) for Cops and Robbers questions, the crack is invalid, otherwise the best you can say is "cracked, not intended solution".

Alternatively, if there is any 6502 machine emulator that doesn't accept that submission you can specify that particular emulator (before posting the answer, for example: write the language name as "6502 machine (accelerated C64)"), then the submission will be invalid.

\$\endgroup\$
14
\$\begingroup\$

It depends.

If I understand it correctly:

  • The opcode is illegal in the language specification. This doesn't matter.
  • The opcode works on certain platforms, but doesn't work on other platforms.

Therefore, the question is:

  • Did you specify the platform in your post? Does the crack fail on that platform?

If you can answer "yes" to both, then the crack is invalid. If not, then tough luck :)

\$\endgroup\$
1
\$\begingroup\$

Yes - it's been done for years.

Some of the first golfers (known then as "programmers", or sometimes "hackers") would use invalid opcodes to make their programs faster and take up less space (two things almost synonymous, ignoring the algorithm and loop unrolling). I won't go into details about the benefits and widespread use of such undocumented opcodes - you can read more here.

Banning this golfing technique would be akin to banning closures in a language where they were an emergent feature-not-bug of the original implementation, and an unofficial clean-room reimplementation from the language documentation didn't support them.

\$\endgroup\$
10
  • \$\begingroup\$ If there's too much jargon in the second paragraph, I'll elaborate. \$\endgroup\$
    – wizzwizz4
    Commented Nov 15, 2017 at 20:52
  • \$\begingroup\$ I'm not so sure about this answer. 1.) This wasn't a code-golf challenge but cops&robbers where the robber must give an equivalent program with a given distance. If the code is valid 6502 machine code, I expected the robber's code has to be as well -- the twist here is that there's no unmodified C64 version that doesn't execute these illegal codes, they all used an NMOS version. 2.) The illegal opcodes were never intentional in the 6502 processors, just "random" effects of the chip design -- a modern CPU would trap/break on any illegal opcode just as the CMOS 6502 chips do. [...] \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 8:16
  • \$\begingroup\$ [...] 3.) even back then, code size vs speed was often a trade-off and only sometimes, the shorter code was also the faster one. -- But still, also given the other answers, I agree the crack is valid, because when targeting the C64, illegal NMOS 6502 opcodes will work in 6502 machine code. \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 8:19
  • \$\begingroup\$ @FelixPalmen 3) Where the algorithm remains the same, undocumented opcodes are often faster than a several-instruction snippet with the same or similar effect. Using these opcodes gives you more flexibility. \$\endgroup\$
    – wizzwizz4
    Commented Nov 16, 2017 at 16:41
  • \$\begingroup\$ 1) It wasn't just used in golfing - for timing purposes code sometimes had to have a specific length (e.g. when doing raw I/O with the floppy drive). 2) My second paragraph addresses that. And whilst being unintended, they were clearly known about by the designers whilst they were creating the chip; it just didn't matter what happened with the other three 01110xxx opcodes so long as 01110001, 01110010, 01110011, 01110100 and 01110110 worked. \$\endgroup\$
    – wizzwizz4
    Commented Nov 16, 2017 at 16:45
  • \$\begingroup\$ yes, as a micro-optimization, this is often true. I was just objecting your statement "faster and take up less space (two things almost synonymous back then)". Not really ;) I've seen code for plotting a pixel in the strange bitmap organization of the VIC-II that sacrifices around 100 bytes just to save a few cycles (which makes sense when every higher-level drawing routine calls this for every pixel) \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 16:45
  • \$\begingroup\$ @FelixPalmen Hence "almost". Micro-optimisations were king once a program had got to a certain point... but I'll clarify. \$\endgroup\$
    – wizzwizz4
    Commented Nov 16, 2017 at 16:47
  • \$\begingroup\$ regarding 2), the point is your comparison to "an emergent feature-not-bug of the original implementation" which doesn't apply to the chip design. Special functions of illegal opcodes were never intended, the chip designers just didn't care. Furthermore, the "crack" in question uses an opcode that's just an unintended duplication of a "real" opcode. \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 16:48
  • \$\begingroup\$ @FelixPalmen I thought that "it's a bug, not a feature" would suggest that the designer didn't intend it to exist but didn't try to fix it. \$\endgroup\$
    – wizzwizz4
    Commented Nov 16, 2017 at 16:50
  • 1
    \$\begingroup\$ Yes, that sums it up. With the later CMOS design, they eliminated all "undefined behavior" of the chip. But these chips were never put into a stock C64, only in turbo boards and the like. --- bottom line, I agree illegal opcodes must be allowed in machine code submissions targeting the C64 (or other machines where it's known and reliable what the illegal opcodes do). With the cops&robbers challenge here, using an illegal opcode kind of feels like a "loophole", but I see now that I should have closed that before submitting my cop post. \$\endgroup\$
    – Felix Palmen
    Commented Nov 16, 2017 at 16:52
-1
\$\begingroup\$

Fairly often, the original game itself used undocumented opcodes. Sometimes even outside the protection check, for exactly th esame reason of saving bytes.

So they are fair game for c64 cracks. 100%.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .