"Fake" FF opcode vs a real one

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
tucna
Posts: 2
Joined: Fri Jul 08, 2022 12:52 pm
Contact:

"Fake" FF opcode vs a real one

Post by tucna »

Hello guys,

I am working on NES emulator and I ran into a problem today. During a test using one of the testing ROMs (registers.nes if interested) I noticed weird usage of opcode FF. I assume that author meant it as "nothing" but that raises questions:

1) How should I know that FF in the program does not stand for ISC {ABX}? (illegal opcode)
2) If the FF really is there just to fill up a space, why not to use NOP? (I understand that answer to this can be "it is a personal choice of the author so I do not know" but I am asking just in case there is a good reason behind it in general).

Image

You can see that FF is there for PRG-ROM.
Last edited by tucna on Sat Jul 09, 2022 7:15 am, edited 1 time in total.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Fake FF opcode vs a real one

Post by Quietust »

tucna wrote: Fri Jul 08, 2022 1:11 pm 1) How should I know that FF in the program does not stand for ISC {ABX}? (illegal opcode)
It's not an instruction until the program counter ends up pointing at it. If your emulator somehow is trying to execute that block of 0xFFs as code, then you're doing something wrong.
tucna wrote: Fri Jul 08, 2022 1:11 pm 2) If the FF really is there just to fill up a space, why not to use NOP? (I understand that answer to this can be "it is a personal choice of the author so I do not know" but I am asking just in case there is a good reason behind it in general).
Probably because most people don't remember that the opcode for NOP is 0xEA, and it's common practice to fill unused space with 0xFF if you're going to write it onto an EPROM (because "erased" EPROMs are filled with 0xFF and you can presumably save time by not having to write any data to the bytes you aren't using).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
tucna
Posts: 2
Joined: Fri Jul 08, 2022 12:52 pm
Contact:

Re: Fake FF opcode vs a real one

Post by tucna »

Thank you for the information and explanation, things are clear now.
Quietust wrote: Fri Jul 08, 2022 1:38 pm It's not an instruction until the program counter ends up pointing at it. If your emulator somehow is trying to execute that block of 0xFFs as code, then you're doing something wrong.
Actually, my emulator is not trying to execute this. I wrote dissembler for debug purposes and made in the way that everything in PRG-ROM is understood as a program code. This led to a situation where shown disassembly really did not fit with the things which were executed.

So I guess I should not expect that only program is there and make more clever disassembly of it based on a program counter (and actually reachable places) instead of an attempt to disassemble everything between $8000 - $FFFF expecting all of it are instructions.
Last edited by tucna on Sat Jul 09, 2022 4:10 am, edited 1 time in total.
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 569
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: Fake FF opcode vs a real one

Post by Jarhmander »

Not only a ROM can be partially full, there can be data intermingled with instructions, usually after a flow control instruction (jsr, rts, jmp etc) so the data won't be executed by the CPU. It is common to embed lookup tables alongside routines. And of course, usually well separated of the code, there's level and music data as well as data for enemies etc.
((λ (x) (x x)) (λ (x) (x x)))
User avatar
tucna
Posts: 2
Joined: Fri Jul 08, 2022 12:52 pm
Contact:

Re: Fake FF opcode vs a real one

Post by tucna »

That makes sense. Thank you.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: "Fake" FF opcode vs a real one

Post by aquasnake »

0xff is used to fill unused ROM space.

Why not use 0x0 or NOP to fill in?

Because 0xff is ignored for programmer writing, all bytes are 0xff after erasure, so it can be skipped directly. If it is other data, it takes time to write.


In this way, filling 0xff has the significance of shortening programming time and improving production efficiency


The cfg file of cc65 can specify to fill byte data.

I usually use 0xff, and sometimes use RTS(0x60) to fill with
Post Reply