The additional 2M are located on the back of the PCB, where the pick&place machine can't reach it. It must be placed manually.
In addition to that, the CPLD firmware and the software need patches. As many people already wrote, you're not paying for the RAM chip, but for the whole functionality. The RAM chip does not fit the space on the other side, and if I tried, it would get bigger, making the whole production run more expensive. That's not an option - the ACA500 was always planned to be an extremely low-cost product, and "just enough memory" is part of that concept.
Sure, I could put the second RAM chip on the other side and make the whole product more expensive for everyone else - with the drawback that board size makes the majority of the cost, and I'd scare off those who really just want the 79-EUR-version, which would not be available at all in that case. As an effect of that, quantities would go down, and the base cost (development, machine setup, tooling) must be paid for with fewer units, making them even more expensive. So yeah, I'd save a bit with the larger PCB - maybe 5,- EUR. So.. everybody happy with an ACA500 for 104,- EUR? I doubt that.
The only reason why I put the additional RAM place on the back was a few guys over on a1k.org who were bragging about the kind of money they'd be willing to pay for a 4MB version. They now have a chance to put their money where their mouth is.
If anyone here has a viable concept, please present it. Just complaining about the price and comparing memory prices doesn't cut it. Total project cost is what you need to calculate. There is a risk involved, and that introduces an unknown factor which needs to be priced. If anyone here can take the risk out of the equation, for example by pre-paying for a couple of hundred units, please step forward.
Back to technical things:
I have just verified the VBR function of the ACA500. As I wrote sometime last week, the initial plan was to make a special function for the WHDload ESC-key. However, it turned out to be not too complicated to introduce a general move of the vector base to a reserved fastmem area. This area is just 512 bytes at the end of fastmem and won't be added to the freemem list - just in case someone here is worried about a conflict with stack.
The flash contains a resisdent command called "acavbr", which can be started in a shell. Moving the vector base into fastmem has two advantages: System performance is a tiny bit better, and WHDload can add it's keyboard handler in a way that no game can do anything against it.
Measuring the performance advantage is hardly possible. Neither AIBB, nor Sysinfo show any better ratings. Only the logic analyzer shows that fetching the vectors takes a few cycles less. The only measurable advantage is on IRQ-heavy operations such as serial transfers and HD/CF operations: My CF card transfers about 4KBytes per second more with the vectors in fastmem :-)