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.

Just some information on how to run the (XTIDE) option ROM on the QD6580 controller, it took me a few hours of fiddling with setup and reverse engineering to figure it out:
I don't know if it's a mistake or intention, but the description on the PCB says "27C512" under the option EPROM socket, but in fact it is intended only(*) for 27C256 EPROM.
So for option ROM to work, put 27C256 and 74LS138 into empty sockets on the controlled board.

* 27C512 can only be used if the option ROM image is burned at upper half of the memory ie. with offset 0x8000. The reason is that IC socket has pin 1 connected to +5V, as there is VPP input on 27C256 which is to be connected to +5V at read mode. But 27C512 is little different and has address input A15 at this pin, so if this address pin is held at logical 1, upper 256kb of the memory is addressed.