So are you saying with real fast memory, the CPU can access the fast memory at the same time that custom chips access chip ram?
I usually run with only chip RAM so all the games work. I do have an A500 with 4MB trapdoor card and an IDE board so total is 5MB (1MB chip RAM + 4MB fast RAM), but it has problems with games. The 2MB Agnus (8375) A500 has no jumpers but uses the 1MB from trapdoor and 1MB from motherboard (rev. 8a) and that's more compatible with games. This revision does have the ECS Denise as well. The 1MB chip RAM A500 has normal Denise but again no jumpers.
Yes, real Fast Memory runs on a completely separate bus. The trapdoor slot runs on the custom chipset bus, so RAM there is substantially slower regardless of whether it is mapped as Chip or "Fast". You can test this yourself by running a RAM benchmarking program. If you run it in a 2 color 320x200 screen, and a 16-color 640x400 screen, you'll see that the "Fast" RAM is slowing down just like the Chip RAM, because the DMA for the screen refresh is hogging time on the bus.
If you look at the trapdoor expansion on your A500, you'll see that the board has an extra connector going to the Gary chip -- this hack is there to make sure that the memory mapping used for the expansion shows up properly on the internal bus. (Incidentally this can stop other expansions from working properly!)
If you want true Fastmem in your A500, it needs to be added to the CPU bus (either via a piggyback on the CPU socket, or the expansion slot on the left side). If you add a new CPU board that has local RAM on the expansion, this will create the best-case scenario.
I don't know why it's having problems with games, it could do with how the memory is being mapped conflicting with your IDE expansion's mapping. Also, a lot of very early badly-behaved games expected RAM to be in very specific locations, so this could be your issue. In general the original 24-bit Amiga memory map (introduced with the A1000, but the specific tweaks on the A500 became the "standard" map that a lot of people wrote for) had very specific portions of memory reserved for the trapdoor, while other parts were reserved for other parts of the system.
The "Slow RAM" portion of the memory map starts at 0x00C00000 and can be up to 1.5M in size. An additional 256k of reserved space immediately after this was sometimes appropriated for this as well. If you use UAE and drag the "Slow RAM" slider all the way to 1.8M, it's mapping into this reserved space.
Chip RAM starts at 0x00000000 and initially only was mapped up to 512k, but reserved space up to 2M was used up through ECS/AGA. Some very stupid early expansions used this space assuming it wouldn't be Chip RAM.
Pretty much all non-trapdoor expansions respect the first 512k from 0x00c00000 as reserved for the trapdoor, since just about everyone had the 512k expansion (even if it didn't get mapped there). This is why it's generally safe to have it there. They also generally respect the full 1.5M of that part of the memory map.
The first thing you should do is use a system info tool that can display your memory mapping to see where your RAM expansion is mapping itself. I believe AmigaOS 2.x and up has a built-in tool for this, but I don't remember if there's anything that comes with 1.x. You can download a third-party tool like Ranger or SysInfo to show what's there.
Try pulling out your IDE expansion and see if the games start running correctly. If not, it's probably a problem with how they see the trapdoor memory. In general trapdoor expansions beyond the generic 512k expansion should be avoided. (There were some very strange expansions for the trapdoor though, including a weird NEC-clone-CPU XT-compatible IBM-PC-clone expansion!)
If you really must put more than 512k on the trapdoor, you really should limit it to 2M. A good expansion will let you map 512k to Chip RAM and the rest to the full 1.5M of the 0x00c00000 portion of the map. When you try to do weird multi-mappings from the trapdoor (i.e. anything not a contiguous block starting from 0x00c00000), that's where the Gary hacks come in. When you start to go into that space you know you are inviting trouble.
Generally the best way to combine expansions is to not use ones that mix address space on different buses. i.e. trapdoor expansions should stick to the trapdoor Slow RAM portion of the memory map, and the CPU-only portion should go on either a CPU piggyback or on the sidecar.
CPU piggyback expansions are particularly problematic because they, by their nature, can muck with the entire memory map that the CPU sees. I strongly recommend that the only expansion you place there be a CPU card, and if it has any RAM on it it should be true 32-bit RAM that the rest of the system can't see anyway. If you put anything 24-bit on the CPU socket, don't put anything on the side expansion slot. Well-designed stuff should play nicely via autoconfig, but there's no way to guarantee this will happen. There were a few 32-bit CPU cards that went on the side slot (GVP made one, I recall). If you use any of those try to avoid putting anything on the CPU socket.
Your A500+, on the other hand, is in a very straightforward config. The trapdoor card is mapping the extra RAM to the Chipmem portion of the memory map. It's a very clean setup and should have no problems (other than incompatibility with very ancient stupid games that make hard jumps to the ROMs or demand that RAM exist at 0x00c00000). Slap a hard drive controller with some extra RAM on the side expansion port, and possibly a CPU expansion (either in the sidecar expansion or in the CPU socket, preferably one that allows 68000 fallback for particularly stupid games) and you're golden.
If you do go with a 32-bit CPU card, you can use WHDLoad installers to put the games on the hard drive (the faster CPU taking care of any WHDLoad overhead). Almost all of these have patches to make them work with a 68030, so you don't need to worry about compatibility. In practice I've found that games work best with a CPU card that runs synchronous to the chipset (14Mhz or 28Mhz, rather than 25, 33, 40, or 50Mhz).
My A500 has a "Sapphire" 14Mhz 68020 card on the CPU socket, and a GVP HD8+ hard drive controller with expansion RAM on the side expansion slot. While the CPU card has no provision for 32-bit RAM and thus the speed of the system is limited, WHDLoad stuff runs like a champ on this setup and almost everything is compatible with it and runs at good speed, and there's no lag from custom chipset waitstates since the CPU is run synchronously.
There's also a couple of CPU cards out there that use a 68000 but clock it at 16 or 28Mhz. (AdSpeed or SupraTurbo). These have the advantage of being compatible with stuff that expects the broken behaviors of the 68000 concerning 24-bit addressing and supervisor stack pointer (which was fixed in the 68010 and higher). You can use these to run some broken games without patching them. I don't recommend them, however.
Isn't this FUN? =D
On the plus side, using a real Amiga you get super-silky scrolling from your games, something that is next-to-impossible to achieve in an emulator due to the levels of abstraction in the host OS's video drivers.
