Think you have to merge the Lo + Hi together using a tool that properly reads/writes the alternates bytes before opening in IDA (or MAME) then when done editing you have to Split them back into Lo Hi or Odd Even.
I use romwak for windows mostly (found at github) for merging dual rom files but there are some others. Will dig into my BIOS tools for a few merge tools when I get to my work computer.

Kidrash wrote on 2020-10-24, 17:22:

Hello, i'm trying to understand how a bios parted in 2 chips is used by the CPU. I'm trying to disassembly a bios to understand […]
Show full quote

Hello,
i'm trying to understand how a bios parted in 2 chips is used by the CPU.
I'm trying to disassembly a bios to understand some post codes sent to the LPT1 (Olivetti M290S does that) but i'm having troubles wit IDA.
First, let's say i know nothing about disassembly, machine code and such but i'm reading and watching some tutorial to get some ideas.
I load the 2 .bin files into IDA and at FFF0 (reset vector) i don't have the jump intruction EA.
The first EA instruction it's at FFF8, the same address i get with logic analyzer hooked to the Eprom on the motherboard.
With Winhex i can merge the files, first low and then high one and i get something better to read. And now at the bottom i get the "magical" sequence EA 5B E0 00 F0
(jump to f000:e05b) but..... it's at location 1FFFF cause the files have been merged togheter.
So in some ways the chipset translate the FFF0 address from the CPU to FFF8 in the rom and send the data back in the correct order.
In IDA when i use "Makecode" to see the commnad often i get something with the unk in the description, red coxe xref and i think it's IDA's way to tell me that was expecting something in the first 64K but they are in the 2nd slice.
How i can tell IDA to take in charge the fact the bios has been slipt into two?

You have to intermix bytes between the two files. You can't just concatenate them together as two big blocks. It's pretty easy to write a python script to pull one byte from each file and then write them to output.

I get the impression that the interleaving ("merging") was done correctly, but the result is larger than one segment so IDA has to be told how the memory is mapped.

What's the size of the ROM after merging? 128K?

Normally a 64K system BIOS is loaded at F000. With larger ones I don't know if you can assume anything. I've done this with the IBM PS/2 30-286 BIOS, which is 128K, with the two segments mapped to E000 and F000.
The Olivetti may do it differently, so you'll have to know how the segments are mapped.

It's also possible that all the code you want is in the upper segment, especially if it's initialization stuff like sending POST codes. That upper segment has to be mapped to F000 - since you say the "magic" initialization jump is at the end of the merged file.
In that case you can get away with just taking the last 64K (of your *merged* file) and loading it in IDA as one segment mapped to F000.

VileR wrote on 2020-10-27, 02:36:

I get the impression that the interleaving ("merging") was done correctly, but the result is larger than one segment so IDA has […]
Show full quote

I get the impression that the interleaving ("merging") was done correctly, but the result is larger than one segment so IDA has to be told how the memory is mapped.

What's the size of the ROM after merging? 128K?

Normally a 64K system BIOS is loaded at F000. With larger ones I don't know if you can assume anything. I've done this with the IBM PS/2 30-286 BIOS, which is 128K, with the two segments mapped to E000 and F000.
The Olivetti may do it differently, so you'll have to know how the segments are mapped.

It's also possible that all the code you want is in the upper segment, especially if it's initialization stuff like sending POST codes. That upper segment has to be mapped to F000 - since you say the "magic" initialization jump is at the end of the merged file.
In that case you can get away with just taking the last 64K (of your *merged* file) and loading it in IDA as one segment mapped to F000.

I recommend to just load the file into IDA at segment E000, and uncheck "create segments" in the loading screen, then adding two 16-bit segments (E0000..F0000 with base E000, and F0000..100000 with base F000) manually. I switched to always creating the segments manually after having some kind of issues dealing with the automatically created segments (IIRC revolving around the "base address") that went away as soon as I manually created the segment with the same principal settings.

I've seen a couple of uncompressed 128K BIOSes that "spilled over" functions from the F000 segment into the E000 segment (and put stubs or FAR calls into the F000 segment), so even for POSTing, the lower half might be worth having.

"WinHex" hex editor also has several options to interleave, merge, split binary files.
It works even in the shareware/trial version.

Thanks everyone for the answers.
@Viler: yes, it's 2 64Kb files merged with Winhex, bytewise (8bit). The result it's a 128Kb file.
@mkarcher: I followed your suggestion and now i have a more healthy situation. As soon i have created the segments, the function windows populated and the first far jump pointed to a location with some data. I will try to find about what refers some post codes sent to the LPT1.