Upgrade Ram to 1 MB Amiga 500?

[amigaksi]

...
A note about the trapdoor expansions/motherboard RAM. This RAM exists on the Chip Memory bus, so when the custom chipset's DMA seizes the bus for operations, the CPU can't talk to it, regardless of whether the OS considers it Chip or Fast. This means that it's not "real" Fast Memory that the CPU has exclusive bandwidth to. Because of this, the community generally refers to this memory as "Slow Memory" when it's not mapped as Chip.

Also note that the Fat Agnus socket on the A500 and A1500/A2000/A2500 does not have enough physical address lines wired to it to support 2M of Chip, regardless of how much memory is on the Chipmem bus. If you drop a 2M Fat Agnus into this socket, it will work, but it will only ever be able to address 1M.

There are, however, expansion boards out there that provide the extra address line and onboard RAM to let the 2M Agnus have its full addressable space. One example is the DKB MegaChip. The board has the 2M Agnus mounted on it and then drops into the Fat Agnus socket.

....

Hopefully these explanations help! =D

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.

[amigaksi]

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.
...

I don't know if they are badly behaved games-- perhaps they didn't foresee people adding hard drives and 8+ MB of fast RAM.  I like those games that go directly to the hardware and take over the system to squeeze the maximum potential out of the hardware.  Too bad we don't have that sort of innovative stuff nowadays on modern machines.  Last I heard even the Playstation/Nintendo stuff involves going through APIs.

...
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.

I guess a good test would be to heavy a loaded copper list and have the processor use fast RAM to do calculations and see if turning on/off the copper list affects the performance.  For true coprocessing w/dual bus, it shouldn't affect the time to do the calculations.

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.

I can't really run any of my hardware interfacing stuff w/emulation anyways amongst other things.