ROMization

When mass-producing a mask-ROM version after developing using a flash memory version, will some kind of code be written to areas not used by programs?

Yes.
Some values are read if data is read from an unused area due to a bug.
If an used area where no code has been generated is read, the value read when debugging and that read from a mask-ROM version may be different.
If the program operation depends on the value read from this area, the operations with the mask-ROM version is deferent from those at the step of debugging.
Since this situation must be avoided, it is necessary to use the same value as the fill value for areas outside the code area, so that the operations with the mask-ROM version are the same as those at the step of debugging.
To prevent problems that can occur after ordering mask-ROM version production, we also recommend using the -U option to specify an evaluation when filling.

I am trying to fill the unused area between the end of the program and the last ROM address with a particular data.
But an error occurs when the DB pseudo instruction is used as follows.

    DB ( 7FFFH - !$ )

Unfortunately, that pseudo instruction cannot be used as the assembler stage.
Instead, the object converter is equipped with a special function that fills unused areas with a specified code.
Use this function (-U option) to fill unused areas with any specified code.

Ordinarily, when ordering a mask-ROM version, we recommend using this function to fill unused areas.
For details, see the description of the object converter in the operation user's manual.

I plan to use the uPD78F0034 as the flash memory version for development, and use the uPD780021 as the mask-ROM version for mass production.
The memory size is to be changed using the IMS register. Under this conditions, when the uPD78F0034 is selected for the device file, the RAM memory mapping differs from that in the uPD780021.
In such cases, how should the device file be selected?

When developing a program for a mask-ROM version using a flash memory version, be sure to use the device file for the mask-ROM version.
In addition, set the value of the IMS register according to the target mask ROM version (set to 42H in this case).
For the example in the question, use the device file for the uPD780021.

When using a flash memory version for development and then mass-producing a mask ROM version, is there any problem with leaving the setup instructions for the IMS register?

No, that should not pose any problems.
Since mask-ROM versions do not contain an IMS register, the operation will not be affected even if a setup instruction for the IMS register is set.

When developing with a flash memory version, is there any problem if the IMS register is set so as to specify a memory size different from that in the final target mask-ROM version (i.e., using the initial value for the IMS register setting)?
The program size is small enough to fit within the mask ROM version's ROM area.

Even if there is no problem in areas that are explicitly noted in the program, operations could vary in certain unanticipated situations, such as if a memory area that did not exist in the mask-ROM version is accessed.
Although it would not pose any problem if the program is completely unable to generate such operations, we generally do not recommend it.

Such settings may affect the operations when using an external expansion memory.
We do not guarantee the operations in this case, since we have not tested the devices for prohibited settings.
We recommend setting the IMS register according to the target mask-ROM version.

When the ROM size of the flash memory version for development is the same with that of the mask-ROM version for production, is it possible to use the IMS register with the initial value?

Yes. There is no problem using the IMS register with the initial value in this case.

When is the -R option of the object converter necessary and how does it work?

When outputting the objects whose address are determined by the linker, the -R option is used to sort them according to the address order.
In the ROM ordering system, it is checked whether the objects requested by the customer are sorted in the address order.
If they are not sorted in the address order, it is regarded as an error and the processing is not accepted.
The -R option is thus provided to solve this problem.

Is mask-ROM version production ordering acceptable even if the -R option is not specified?

There is no problem if the objects are sorted in the address order by change.
But this is uncertain, and therefore the -R option must be specified.