This is one of those "If you really have to ask then perhaps you shouldn't be doing it" kind of mods. The pitch of the memory chips' pins is 0.8mm. The CPU pins have a pitch of a mere 0.6mm.

But since you asked;

1). Wear an antistatic wriststrap, use an ESD-safe temperature-controlled soldering iron. and plenty of flux.
2). Straighten the pins on the new chips so that they will reach the old chips. Bend the RAS pins out slightly.
3). Solder the new chips to the old chips, pin for pin with the exception of the RAS pins.
4). Use a continuity meter to probe for open and bridged pins.
5). Wire both RAS pins on the new chips to RAS1 on the StrongArm.
6). Test, decipher any memory error messages using the memory datasheet to identify pins*.
7). Retouch problem pins to remove errors.
8). Test and rejoice.

The SA1100 datasheet is easy to google for, and Micron keep the memory datasheet available in their support section.

* - To decipher error messages;
The memory test uses 4 patterns written across the data lines, 0x00000000, 0xFFFFFFFF, 0xAAAAAAAA, and 0x55555555.

0x00000000 - An error from this write is usually caused by a data pin shorted to an adjacent VDD pin.
0xFFFFFFFF - An error from this write is caused either by a data pin shorted to an adjacent VSS pin or more usually by an open connection.
0x55555555 and 0xAAAAAAAA are caused by two adjacent pins shorted together - the patterns translate to binary 0101...0101 and 1010...1010 respectively. What should be a zero comes back as a one because of the short.

The error message reports what was written and what was read. Compare one to the other and see where the error is. The highest 16 bits of the data are on the chip furthest from the CPU.

So for example, "wrote 0xFFFFFFFF, read 0xFFAFF1FF" can be broken down to;

Chip furthest from CPU - 0xFFAF. We can futher break this down visually - 0xFF means that the high 8 bits are correct, 0xAF means that the lowest 4 bits are correct, and the problems are in D7...D4. 0xA is binary 1010, so the problem pins are D6 and D4, both low when they should be high. Looking at the datasheet you will see that pins 7 and 9 are probably open.

Chip nearest CPU - 0xF1FF. Breaking it down again, lowest 8 bits are fine as are topmost 4 bits, problem is in D11...D8. 0x1 is binary 0001. Pins D11, D10 and D9 are all low when they should be high. Looking at the datasheet shows that pins 44, 43 and 42 are the culprits. You will also notice that pin 45 is Vss, so it's possible that one or more of those pins are shorted together with pin 45. Or they might simply be open.

Another example, "wrote 0xAAAAAAAA, read 0xAAAAAAEA";

Problem is in lowest 16 bits, ie chip nearest CPU, 0xAAEA. Further breaking it down, highest 8 bits and lowest 4 bits are fine, problem is in D7...D4.
Wrote 0xA = binary 1010. Read 0xE = binary 1110. Problem is D6 high when it should be low, shorted to either D7 or D5. Datasheet gives D6 as pin 9. (D7= 10, D5 = 8)

There are three problems that won't fall into any of those error classes. A bad RAS connection or a bad OE connection can both manifest as an error where the whole chip refuses to talk back, such as the error that Stu had earlier in this thread.
A totally non-booting empeg, or one that crashes even after passing the memory test is usually caused by soldering errors on the address lines. Some errors will prevent the flash from being read and hence the kernel can't load, whereas others won't affect the player until the kernel attempts to use the memory space impacted.
Unfortunately it isn't possible to debug this further to individual pins.

For 48MB, rinse and repeat using RAS2 on the CPU.
For 64MB add another spin cycle using RAS3.

Note that 48MB or more increases the physical complexity signicantly and is really not recommended.

BIG FAT DISCLAIMER - I ACCEPT NO RESPONSIBILITY FOR ANY ACTIONS TAKEN UPON INFORMATION CONTAINED WITHIN THIS PURELY INFORMATIONAL POST.