Couple of notes about burning ROMs, chips, etc

1. In 74LS138P, the P just indicates the plastic DIP package.
2. Cloning many copies in a large chip is required only in one situation: when you have to install a chip of superior capacity with backward-compatible pin-out into a socket with the same number of pins, e.g. 27C512 into a socket dedicated for 27C64/128/256, because it's hard to obtain 2764 and lower capacity chips. When you insert such a chip, some of its address pins often become floating because there is no physical connection either to ground or Vcc. so, any fluctiation in electric fields around may switch most significant bits of address to different states, so copying images guarantees that with any combination of MS bits the right data will come out. So, if you're putting 27512 chip in a socket marked "27512", each address pin will be controlled by the circuit and there will be no floating pins and there's no difference if ROM is copied or not, anyway larger addresses will never be read unless he code will set instruction pointer specifically to higher areas.

rpocc wrote on 2024-02-08, 16:04:

Couple of notes about burning ROMs, chips, etc

1. In 74LS138P, the P just indicates the plastic DIP package.
2. Cloning many copies in a large chip is required only in one situation: when you have to install a chip of superior capacity with backward-compatible pin-out into a socket with the same number of pins, e.g. 27C512 into a socket dedicated for 27C64/128/256, because it's hard to obtain 2764 and lower capacity chips. When you insert such a chip, some of its address pins often become floating because there is no physical connection either to ground or Vcc. so, any fluctiation in electric fields around may switch most significant bits of address to different states, so copying images guarantees that with any combination of MS bits the right data will come out. So, if you're putting 27512 chip in a socket marked "27512", each address pin will be controlled by the circuit and there will be no floating pins and there's no difference if ROM is copied or not, anyway larger addresses will never be read unless he code will set instruction pointer specifically to higher areas.

Thanks. That's good info and makes sense to me. It explains why I can't jam XTIDE onto the replicated space of the ROM and have both ROM images work. Also explains why the 64KB ROM isn't taking up 64KB of the upper memory area.

I've run across a couple cards that have a single large rom with split addressing. I've seen in it combo VGA/IDE controllers that display part of the rom in the VGA area and part of the rom elsewhere for int13. I've also seen caching IDE controllers that have a single rom that does both the Int 13 and uses the rest internally for the onboard 286. That's probably built into the way that the card handles address pins as well, yes?

douglar wrote on 2024-02-08, 17:55:

I've run across a couple cards that have a single large rom with split addressing. I've seen in it combo VGA/IDE controllers that display part of the rom in the VGA area and part of the rom elsewhere for int13. I've also seen caching IDE controllers that have a single rom that does both the Int 13 and uses the rest internally for the onboard 286. That's probably built into the way that the card handles address pins as well, yes?

Usually it’s handled by address translating circuits based on basic logic or PLA such as popular PAL/GAL chips.

Say, you have two 32K images in a single 64K chip, which should be allocated to segments C000 and D000 in 32-bit address space.
What would you do? You place an address decoder, that directly passes lower 15 bits, responds only when bits 29..16 are zeroes and bit 31 is 1 (a series inverter/buffer with polyinput NAND to /OE), and it sends the 30th bit to 14th address bit in the EEPROM.

Exactly the same way works the allocation of BIOS to the last segment.

Actually, it’s the main method of mapping memory addresses to various buffers, controllers, ports, display memory, etc.

P. S. Interrupts are processed via reading pointers to the interrupt handler code, or by unconditional jump to reserved address containing either iret or call instruction to the specified address.

So, nothing prevents you from keeping some interrupt handler code in any memory location if the right interrupt vectors are assigned, so probably int13 handlers doesn’t even need the address translation hardware, just a little initialization code which can be executed by display BIOS.