what is the meaning of the NAND external connected driving _BLIT in depency of _ROMEN? I cant see the need mainipulate _BLIT by accessing the ROM. Is this an Gary bugfix? Strangely A500+ does not have this NAND Gates.
This is just GARY performing its basic logic for multiplexing the Amiga's CHIP RAM bus, with the aid of some external logic. The *ROMEN signal is mutually exclusive with the *BLIT signal because there is no reason to assert *BLIT during accesses to ROM because the CPU doesn't need the CHIP RAM bus when accessing ROM.
It would make more sense to design Gary with this logic being internal to the gate array, in hindsight, but the Gary chip might have been designed first with some assumptions in mind that didn't pan out. Later versions of Gary perhaps "fixed" this, but it would have been a chip count optimization, rather than a bug fix.
Caveat: I'm not exactly an Amiga guy. I did work with them, but never had much positive thought about :))
From the combination of signals I assume (*1) the IC in the lower right is supposed to be an AGNUS, Amigas RAM/DMA/Blitter all in one handler (*1). The combination of question wording ant the shown schematic sniplet is a bit confusing, as the line is named /BLIT, a name introduced with the ECS (Enhanced ChipSet), while the text reads that the gates are not present at the Amiga 500+ - which used the ECS.
So all this little combination does is inhibiting /BLIT (making it High) whenever /ROMEN is active (Low).
/BLIT is what /DBR was in the OCS (Original ChipSet), the signal that AGNUS want's to issue a bus cycle. AGNUS always had priority in bus access. Only a /BLISS assertion could 'ask politely' for a cycle (*3), which AGNUS could grant by deasserting /BLIT for a single cycle. This additional circuit now did block (or delay) AGNUS requests when the address actually decoded by GARY was a ROM address.
Without looking at the timing three possible situations may come to mind:
Due some circumstances AGNUS did generate ROM addresses (no idea how) which ofc, wasn't a good idea in the first place. This would protect against - maybe - some leftover from the A1000 WOM/WCS.
It was a strange way to keep the CPU prioritize the CPU during ROM access.
It delays /BLIT until a prior active /ROMEN is deactivated. This would be the case if there is a race condition within GARY's decoding. In this case the gates provide an external fix. The condition might be that /ROMEN is still active due a prior ROM access by the 68k when AGNUS pulls /BLIT to start a RAM cycle. Since /ROMEN is directly connected to /OE (Output Enable) of the ROM and RAM-/OE is fixed to ground, this might screw the data bus, during early CAS cycle having ROM drive the data lines against RAM.
I would go for #3, as the other are rather obscure. But as said before, it's just an educated guess. I would need to dig out the exact schematic and more important timing sequence for each chip in conjunction with the 68k timing.
Another way would be simply to look what GARY version machines with or without that lock have. I bet that correlates.
*1 - Assumptions are bad It's always better if a question includes at least the basic information about the system and the environment it is asked on, so there are no basic assumptions necessary. Especially with the Amiga as there are literally dozens of internal versions for each Amiga. It's extremely hard to guess from which combination some sniplet is. Especially when, like in this case, after market schematics are used.
*2 - I think for the AGNUS alone there where more than 10 versions with different par numbers like 8361/8367/8370/8372/8375 plus appendixes like A/AB/B/R0/R01/R2/R3/R1/FAT. There isn't the AGNUS. Sure, from a software side there where only two or 3 versions to distinguish, but hardware wise they where many more.
*3 - Which usually was inserted by GARY after three consecutive AGNUS cycles.