A note on this, the ROM format is the newer one intended to replace the BIN+CFG format. It combines both files.
Yes and no. The .ROM format is the Intellicart / CC3 format. For games with a straightforward memory map, it's sufficient. It has several technical limitations:
- No support for Mattel-style page flipping. Games like World Series Major League Baseball, for example, cannot be represented in .ROM format without modifying the game to use Intellicart bankswitching.
- 2K word address map granularity, with 256-word "fine-address" boundaries within each 2K word span.
- Hard limit at 64K words.
- No support for patching via '[macro]' statements
- No support for config variables, such as 'voice = 1' to instruct emulators to turn on Intellivoice.
On the plus side, .ROM does specify a memory map and basic memory permission information (read/write/bankswitch/narrow); it's limited to the 2K granularity though. It also has some basic CRC checking built in, to detect corrupted files.
At one point, jzIntv switched to only supporting .ROM format. Even AS1600 only really supported .ROM at one point, and only generated .BIN via a "rom2bin" conversion internally, effectively. That limited the assembler output to what was representable as .ROM, including the address map granularity.
Eventually, I added BIN+CFG back to jzIntv because it's ultimately more flexible, and I needed it in order to support playing all games. WSMLB, Go For the Gold, etc. (That was many, many years ago now; pre-2006, at least.) Also, there's cases (admittedly baroque) where you want to be able to assemble stuff with finer granularity than .ROM offered. And, the assembler now supports Mattel-style page flipping, which raises the maximum theoretic ROM size to something like 768K words.
All that said, for most users, .ROM saves a lot of hassles. It's a reasonable default, especially in the context of IntyBASIC SDK. You can always switch to .BIN+CFG later if/when your needs change.