KIL opcodes and such

[tepples]

They're just like drugs, they're illegal and they're not cool.

The legality of drugs varies from place to place.

It's hard to just move away from the UN Single Convention on Narcotic Drugs.

Alcohol is legal everywhere.

Not in most of the Muslim world.

when you use illegal/undocumented/unofficial opcodes to noticeably improve your program, you're risking compatibility with clones and such, which might not support said opcodes.

Any more so than when you use 4-screen mirroring?

[tokumaru]

Not in most of the Muslim world.

I knew I should've written "almost everywhere"!

Any more so than when you use 4-screen mirroring?

About the same, I guess. I don't know specifically about NES clones and unofficial opcodes, but I remember people mentioning there were Atari 2600 clones that didn't like them.

[Bregalad]

Yes, I think "unofficial" is definitely the best term. "Illegal" is wrong, but not as wrong as "undoccumented". The usage of them is mostly legacy back when their existance was relatively new (early 80s).

And yes comparing unofficial opcodes to drugs is a bit silly I know. I just felt like doing this.

Like you said programming should be about usefulness and/or efficiency, not about being cool. The unofficial opcodes are not terribly useful, at least I never found myself requiring those. Usually the stable ones just does too much stuff at once to be any useful.

[mikaelmoizt]

After learning some basic (official) opcodes and how to use them you start to wonder why there is no

Code: Select all

BRA ;Branch Always! Could ofcourse be simulated in different ways
PHX
PHY
CPS ; Compare stack pointer
NUA ;Null A..
NUY 
NUX 

I guess I am not the first who had these or similar ideas

[rainwarrior]

There's a lot of instructions I dream of when writing 6502. Most often I want an indexed STX/STY, and an INC for the accumulator. A short jump (your BRA) would be nice for saving a byte.

x86 let you XOR a register with itself, which was the most compact way to load it with 0, just as good as your NUA but more powerful.

[koitsu]

65c02 addresses the lack of inc a, 65816 addresses the desired indexing for stx/sty (but only one addressing mode is supported: directpage,{x|y}). Tellin' you guys, the 65816 spoils you. It's hard to go back to 6502/65c02 once you've used it.

The primary thing I wish 65xxx had were integer multiplication and division opcodes, e.g. imul/idiv on the x86. That's pretty much the only thing I've ever wanted (on 65816), and the SNES/SFC has those memory-mapped registers for such (though they take a while, something like 20 cycles before you get a result?).

Anyway, all that's off-topic...

[Drag]

I see how undocumented opcodes can be useful, but unless I'm doing some kind of demoscene-esque demo, I prefer to code the "correct" way and rely on other tricks instead, especially because I'm more concerned with the code working than I am with saving a byte in a potentially dangerous way.

[Bregalad]

Most often I want an indexed STX/STY

This exists, but only on zero-page.

For branch always, in 80% of the cases there is another flag that you can know it's state and do a "fake" conditional branching (i.e. BCC with carry always = 0, etc..). However, it's very vulnerable to problems with former modification of the code.

Same with INC A, you can often use simply use ADC #$01 or ADC #$00 if you know the state of the carry.

Opcodes I've also been wishing (but that unofficial opcodes doesn't help with unfortunately) : LDX/LDY indexed with the same register, and NEG A.

LDX $blabla,X
LDY $blabla,Y

I don't know what's wrong in indexing with a register, and then scrapping the index with a new value. Apparently, MOSTEC decided it was worthless, but I find myself always doing a

LDA $blabla,X
TAX

As for NEG A (two's complement A), doing this :

EOR #$ff
CLC
ADC #$01

is tedious and wastes 5 bytes (and overwrites the carry) for a very simple operation.

[rainwarrior]

Yes of course there is indexed STX/STY on the zeropage, but obviously that's not what I wish for.

In general I try not to make a habit of assuming the state of a flag, mainly for the reason you mentioned. I need to push things around now and then, and it's easy to lose track of this kind of thing. When I do feel the need, I try to comment it something like: ;clc ; already clear

Most of the code I write might run once or twice per frame at most. Saving two cycles isn't much of an issue. Saving a byte could be, though. As such I would usually reserve the use of illegal opcodes and assumed flags for inner loops and very often called code, or for when I've actually identified a performance problem. The rest of the time I'd rather have code that's easy to read/edit.

Though, illegal opcodes don't really hinder readability, just portability. Would you rather your code run on more obscure emulators that haven't implemented these opcodes, or save a few bytes/cycles? I could go either way on this decision, depending on the situation.

[tepples]

Nestest tests the most useful unofficial opcodes. Avoiding known capabilities of the NES hardware for the sake of compatibility with emulators that don't even pass nestest is like avoiding HTML capabilities for the sake of compatibility with Internet Explorer 8. Everybody who owns a computer running supported Windows is eligible for an upgrade to at least IE 9, and everybody who owns a computer running even the most recently end-of-lifed Windows (that is, Windows XP) still has access to Firefox and Chr...oh wait this isn't Slashdot. Let me just say that any platform with FCEUX should be able to run it, and any platform with support for USB joysticks has FCEUX.

Saving bytes can help a great deal when trying to pack the last few features into NROM, especially if you can find several dozen places where you can LAX or AXS.

[rainwarrior]

Neither VirtuaNSF nor NEZPlug++ supports illegal opcodes and they are two of the most popular NSF players.

I would bet there's more than one popular NES emulator on more obscure targets (e.g. video game consoles, cell phones) that doesn't support them.

I'm not too concerned about Windows users, but even still, when a ROM doesn't run, especially a homebrew, users are very likely to blame the ROM before they blame their emulator.

Sometimes you don't have much of a choice on which emulator to use, and a lot of times the choice is made for other reasons (nicest interface) than accuracy (why aren't we all playing games on nintendulator?).

So, what I'm saying is that if I can spare, say, 150 bytes to avoid the issue, I am likely to do so. Or, more practically, I code first without considering fussy optimizations like this. When I run out of space/performance, then I start considering these tradeoffs. This often leaves me a nice buffer to work with when a project becomes tight near its conclusion, and at this point the design is very stable, so the maintainability issue becomes less important. On the other hand, if it never becomes tight, then it was never an issue and I didn't have to trade anything for it.

[tepples]

VirtuaNSF doesn't support illegal opcodes and it's one of the most popular NSF players.

What does it do when an unofficial opcode is executed, so that it can be detected?

I would bet there's more than one popular NES emulator on more obscure targets (e.g. video game consoles, cell phones) that doesn't support them.

If a publisher has the resources to become a licensed developer for a video game console, it probably has the resources to improve an emulator to support the opcodes that nestest tests. For cell phones, I'm not aware of any that ship with a gamepad, and I had no end of problems trying to control a platformer with a virtual gamepad on my Nexus 7 tablet. Xperia Play is outdated and discontinued.

I'm not too concerned about Windows users, but even still, when a ROM doesn't run, especially a homebrew, users are very likely to blame the ROM before they blame their emulator.

To continue the web JavaScript analogy: "object detection" and other forms of behavior detection are best practice there. A game that uses unofficial opcodes for speed could show a copyright notice for a couple seconds while testing the behavior of the opcodes it uses, but I grant that that doesn't work for space.

Sometimes you don't have much of a choice on which emulator to use, and a lot of times the choice is made for other reasons (nicest interface) than accuracy (why aren't we all playing games on nintendulator?).

Someone who receives a bug report about a game not running on a particular emulator could have the user try running nestest on the same emulator and reporting the bug to the emulator's developer.

But at some point you have to give up. There are emulators that can't run a very simple UNROM, as I discovered in 2006 when I was developing an e-book reader to run on a DVD player.

[rainwarrior]

VirtuaNSF just increments the PC on an illegal opcode, as I recall, but its been a while since I tested it, and it's not open source.

[rainwarrior]

If a publisher has the resources to become a licensed developer for a video game console, it probably has the resources to improve an emulator to support the opcodes that nestest tests.

...

Someone who receives a bug report about a game not running on a particular emulator could have the user try running nestest on the same emulator and reporting the bug to the emulator's developer.

I'm talking about someone running a homebrew ROM here. I think most NES emulators that can run a user's ROMs aren't going to be licensed, and there are plenty of platforms where licensing isn't a requirement either.

Bug reports are good only when:
1. users actually submit them
2. to somebody who will actually do something about them

I love to get bug reports, and I try to submit them when I can, but I think people that do so are in the vast minority, unfortunately. Furthermore, there are lots of popular emulators that have long been abandoned, and there's nobody there to listen to bug reports anyway.

[mikaelmoizt]

LDX $blabla,X
LDY $blabla,Y

I don't know what's wrong in indexing with a register, and then scrapping the index with a new value. Apparently, MOSTEC decided it was worthless ...

Agreed. This would be a nice way of doing things.

Also, it would be nice if I had a set of logical operations to be "non destructive" to acc. and just result in a flag.
But that might only be an unexperienced coder issue

So far, I am forced to do stupid things like this when checking joypad input because A gets changed when ANDed.

Code: Select all

LDA somewhere
TAX
AND #something
BNE go some place
TXA 
AND #something 2
BNE go somewhere else
TXA
AND #something 3
...