KIL opcodes and such

[tepples]

VirtuaNSF just increments the PC on an illegal opcode

If VirtuaNES uses the same 6502 core, Puzznic will shake. Puzznic uses $89 $00, which is BIT #$00 on 65C02 and NOP #$00 on 6502. Here's an object-detect:

Code: Select all

; The code
  CLC
  .byte $89
  SEC
  BCS fail

; How a conforming 6502 emulator sees it
  CLC
  SKB #$38
  BCS fail

; How a conforming 65C02 emulator sees it
  CLC
  BIT #$38  ; BIT modifies NVZ, but not C
  BCS fail

; How VirtuaNES might see it
  CLC
  NOP
  SEC
  BCS fail

I'm talking about someone running a homebrew ROM here.

I thought modern consoles didn't support sideloading. How would the developer of an emulator that runs on a modern video game console get the emulator past the console's digital signature validation in the first place?

Edit conflict 1 while trying to post this reply:

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

Are you referring to bug reports by users of a ROM to the ROM's author, or bug reports by users of an emulator to the emulator's author? Because how failure to submit them or failure to handle them differs between the two simulations. Or should I explain fully for both situations?

Furthermore, there are lots of popular emulators that have long been abandoned

And there are lots of popular web browsers that have long been abandoned, such as Internet Explorer for Windows XP. IE/XP hasn't had any substantial updates for five years since XP went into extended support.

Let me sum up: Should ROM developers go out of their way to support NESticle?

Edit conflict 2: I will double post because mikaelmoizt's comment is unrelated.

[tepples]

@mikaelmoizt In some of my productions, you'll see the carry flag used to switch on which button was pressed.

Code: Select all

  lda new_keys  ; each bit here represents a button pressed this frame but not the previous
  lsr a
  bcc not_right
  ; omitted: handle right press
  rts
not_right:
  lsr a
  bcc not_left
  ; omitted: handle left press
  rts
not_left:
  ; etc.

[rainwarrior]

Let me sum up: Should ROM developers go out of their way to support NESticle?

There are plenty of modern systems that don't require licensing, e.g. Android, but this also includes any cracked system that people like to run homebrew on. I've run NES emulators on PC, Mac, Linux, DOS, Android, PS3, XBox, and PS1, personally (probably a few more I'm forgetting). People will run an NES emulator on just about anything that will support it. I don't know why you keep trying to restrict this to "modern" or "licensed" or "legal" or things that are currently under development. NES emulation is largely illegal, and the majority of it is done with non-commercial software.

What is out of your way?

In my view, using an illegal opcode is an optimization of either space or speed, and it comes at a small expense of portability and possibly code readability/maintainability. In most cases, I consider an act of optimization to be out of my way. Writing straightforward, simple code is what I prefer to keep in my way. The thing is, if you've sacrificed anything for size/space that you don't actually need in the end, it's been a net loss for you. This is why I suggested a few posts back that I would normally save optimizations like this for the end of the project when I am already sure I need them. In very specific cases, you need what these opcodes provide, but in the majority of cases you do not.

NES emulation in particular has a wider range of well-used emulators than any other system. Wide compatibility is difficult, and yes, I definitely think it's worth avoiding illegal opcodes for this sake. NESticle is an unfair example because it's not well-used, but there are definitely cases in ones that are (I pointed out two in NSF players). I'd have to do a large survey to find out which, and I'm not prepared to do so, but you seem to be taking a position that none of them matter for ideological reasons, I guess. I think they do matter, because people are using them.

I also think people should improve their emulators and get the proper support for these opcodes in, but I like to treat that as a separate issue.

If VirtuaNES uses the same 6502 core

VirtuaNSF does not use the same CPU (or APU) code as VirtuaNES, or at least, doesn't appear to. I tried looking at the VirtuaNES source to gain insight into VirtuaNSF at one point, but it became clear it was pointless because they didn't match at all for what I was testing.

[Drag]

I agree that emulators should support the undocumented opcodes (especially since the NES only used the one 6502 revision throughout its lifespan), but I think games doing opcode checks is a bit unnecessary. Of course, I also think using the undocumented opcodes in the first place is unnecessary, so I'm biased.

[Kasumi]

I haven't yet used such opcodes, only because I fear some revision of NES somewhere doesn't do what's expected with them.

This is still really sexy.

I probably should start using them. My game optimizes for speed to nearly every extreme, sacrificing readability and code size for it. My excuse for not using these isn't that great.

More on topic, I definitely liked the explanations of the KIL opcodes. Especially this post. I was aware of why the illegal/undocumented/what-have-you opcodes are usually combinations of other ones, but that was neat to read.

[zzo38]

Let me sum up: Should ROM developers go out of their way to support NESticle?

If they want to check for (or even workaround) incorrect implementations, they can if they want to, but I think it should not be necessary. At least I prefer to write the program such that it is designed for a "correct implementation of the Famicom VM" (of which the RF Famicom, and several mapper ASICs (even those used only on NES), are mostly what is defining it (and are considered as a correct implementation); I also consider that unofficial opcodes were not a part of the "Famicom VM" until the Super Famicom and SNES came out; some things do actually have undefined behavior though, such as unstable opcodes). (I do the same with Z-machine programs, although in this case very few programs that implement the Z-machine actually do it correctly even for the required subset. Therefore, it isn't specific to NES/Famicom programming at all!)

I haven't yet used such opcodes, only because I fear some revision of NES somewhere doesn't do what's expected with them.

I don't think any official revisions of NES or Famicom is, although I would believe that any that don't are probably incorrect implementations.

I probably should start using them. My game optimizes for speed to nearly every extreme, sacrificing readability and code size for it. My excuse for not using these isn't that great.

I agree (although they can sometimes help improve size as well as (or instead of) speed). Use comments if you need to; after all they don't affect it at runtime!