Here we go again 
3/ If your Rom is placed on bank 0 and 1. It call at 4015h into second bank of you ROM. Here is C3 52 41. This jump on herself. This configuration is the only one that can work on real cartridge but any rom is use this configuration.
The ROM I made is using that configuration, so there is at least one ROM using that configuration
Also, your explanation is not right. When the ROM is on pages 0 and 1, the boot address is #4010. At #4010 there is a rutine that waits for a key, beeps and loops.
Until today I am right my method can execute all Roms. It is based only on header and file size.
Someday if a person wants do a Rom not supported by loaders I advise a other method more efficient like the method used for "INK - Exxon Surfing" because otherwise a simple update will do work the Rom.
If you need updates, patches or any other trick, means what I'm trying to explain: it is not possible to be 100% sure about where the ROM is located, mirrored or other hardware related features without information of the real hardware.
INK is an example. It is not a MegaROM, but can't work as a "normal" non MegaROM.
There are other ROMs, like Sofia, Cross Blaim, Super Bros. World, Super Bio Man, etc. They are non MegaROMs but they use mapper. So if you only check the ROM size, they will fail.
So, again, the point is: can you be 100% sure about how a ROM works without information of the real hardware? No.
3/ If your Rom is placed on bank 0 and 1. It call at 4015h into second bank of you ROM. Here is C3 52 41. This jump on herself. This configuration is the only one that can work on real cartridge but any rom is use this configuration.
The ROM I made is using that configuration, so there is at least one ROM using that configuration
Also, your explanation is not right. When the ROM is on pages 0 and 1, the boot address is #4010. At #4010 there is a rutine that waits for a key, beeps and loops.
I checked again:
The fisrt header is:
0000h: 41 42 52 41 43 41 44 41 42 52 41 20 50 41 54 41
It select well the slot of the ROM on bank 1 and call 4152h.
So at 4152h:
4150h: 00 00 C3 52 41 57 68 61 74 21 3F 00 00 00 00 00
I was not wrong. 
If you need updates, patches or any other trick, means what I'm trying to explain: it is not possible to be 100% sure about where the ROM is located, mirrored or other hardware related features without information of the real hardware.
INK is an example. It is not a MegaROM, but can't work as a "normal" non MegaROM.
There are other ROMs, like Sofia, Cross Blaim, Super Bros. World, Super Bio Man, etc. They are non MegaROMs but they use mapper. So if you only check the ROM size, they will fail.
So, again, the point is: can you be 100% sure about how a ROM works without information of the real hardware? No.
I affirm that the method can execute all existing Roms, but not those that might exist in the future.
I checked again:
The fisrt header is:
0000h: 41 42 52 41 43 41 44 41 42 52 41 20 50 41 54 41
It select well the slot of the ROM on bank 1 and call 4152h.
So at 4152h:
4150h: 00 00 C3 52 41 57 68 61 74 21 3F 00 00 00 00 00
I was not wrong.
I'm sorry, but you are wrong again.
3/ If your Rom is placed on bank 0 and 1. It call at 4015h into second bank of you ROM. Here is C3 52 41. This jump on herself. This configuration is the only one that can work on real cartridge but any rom is use this configuration.
If the ROM is placed at page 0 and 1, the first header is not checked. BIOS only searchs for ROMs headers at pages 1 and 2 as I explained in previous posts. You said that was not true, but it is. Just have a look a BIOS.
So, if first header is ignored by BIOS, the second header at #4000 is the real one:
#4000 41 42 10 40 00 00...
#4010 CD 9F 00 CD C0 00 C3 10 40
I affirm that the method can execute all existing Roms, but not those that might exist in the future.
My ROM exists now and your method can't execute it.
But again, the point is not what ROMs your fantastic loader can execute. The point is that you can NOT get enough information from a ROM to be 100% sure where it is located, if it is mirrored, or any other feature that depends on the hardware design. I feel I'm repeating myself in every post.
If the ROM is placed at page 0 and 1, the first header is not checked. BIOS only searchs for ROMs headers at pages 1 and 2 as I explained in previous posts. You said that was not true, but it is. Just have a look a BIOS.
So, if first header is ignored by BIOS, the second header at #4000 is the real one:
#4000 41 42 10 40 00 00...
#4010 CD 9F 00 CD C0 00 C3 10 40
Ok, I was wrong this time. I was too hastened to respond.
Good news, finally your Rom works with Rom2MMM! 
My ROM exists now and your method can't execute it.
Very funny. 
Go quickly to do a ROM that does not work to show that I'm wrong!
(No, no, stop here! And read the post from Grauw above. Him he understood.)
Go quickly to do a ROM that does not work to show that I'm wrong!
You are wrong, gdx. Although I think the point is you are not reading Guillian tries to explain you: You can only to do a hypothesis how ROM works.
You need to know how works the real hardware and isn't possible with only a ROM file. The ROM Guillian made is the best example.
Can Rom2MMM load this ROM? Of course, yes! You only need add a database to the program. You could, using a CRC or similar, detect the ROM and load and run perfectly.
Without the database, you can't load this ROM example. Impossible. Your program surely detects a 32k non mapped ROM and placed on page 1 and 2: wrong.
Hey! ODO also fails. And OPF, and... all ROM loaders. It's perfectly natural.
By the way.... Rom2MMM can to load this ROM?
You sink yourself more and more. I explained all these points. Read again all posts and think a bit.
Moreover, it is not standing out errors in my explanations that you will prove anything. You are wrong and you do not digest that.
Hi gdx!
I said that the header and file size gives enough information to run all existing Roms (all Roms of 8, 16, 32, 48 and 64KB). I say that because I tested all Roms from laster Tosec and more with success. It took me six months.
I never said that the header and size allow to execute all possible cases of Roms. Do you understand the nuance now?
Let's see. I want understand you. To summarise, you say:
"With the header and file size of all TOSEC ROMs I tried, Rom2MMM can determine the type of those ROMs and load them without problems" .
Is that?
Yes the only way to demonstrate that I am wrong, it's to find an existing ROM that is not working.
I have not any obscure objetive demonstrating you are wrong, gfx. Trust me. I just want help you to improve your loader. And affirm categorically "header and file size gives enough info ... " was a error without add the "only TOSEC blah blah blah" info.
I tried it quickly on emulator. I do not know this rom. Is this is a ROM that loads a game from cassette tape?
Moreover, its size is different from what I indicated. So it should not work except if we add 8KB to make a file of 32KB.
Surely if you add 8k more neither work... The ROM is a 24k ROM using Ascii 8k Mapper. OPF works perfectly, by the way, with this ROM. Anyway, this isn't the point.
The point was to prevent bad and wrong ideas about the ROMs. And I repeat (and Guillian said 10 times and I'm totally sure you are agree too):
- BIOS searchs for ROMs only at pages 1 and 2 of ALL slots-subslots. But only page 1 and 2. Not page 0 nor page 3. Read the BIOS please. ;)
- With the header and size you can't determine ROM type, therefore you need extra work around to load perfectly all ROMs. And, of course, you need to know how hardware works.
"Extra work around":
- Tool parameters (/blah /blah2...)
- Tool database and CRC check.
That's all. ;)