srinivas,

If you are building a product you have a lot of issues to deal with regarding parts; their availability, reliability, cost, footprint, power, etc.

If you are building a "one of" project then you deal with alternative issues. If you work with the more modern components you are gaining experience that may help you get a head start on current technologies.

That said, there is a lot you can learn from implementing a project with any number of different parts.

The well known, and well documented 8255 is maligned because it is slow (between succesive writes, use the A-5), power hungry (compared to it's gates equivalent), and it glitches when you write the mode word), ... if you can tolerate this (and we all did) then go ahead use the part.

Now to your decode question. Set one of your '138 decoders to select the 8255's.

Route 8051 signals A12,A13,A14 to the A,B,C inputs (#1,#2,#3). Route PSEN to '138 pin #6, and A15 to '138 #4, Ground pin #5. This sets your 8255's on 4K boundries below 8000H

Your 8255 will now be found between addrs:
8255(0) @ 0000-0FFFH
8255(1) @ 1000-1FFFH
8255(2) @ 2000-2FFFH

Now if you must use the other '138 for the RAM then... Route A15 '138 pin #6, PSEN to '138 C (#3). Ground '138 #1,#2,#4,#5, Connect Y3 to the SRAM CE input. Use two 8051 port pins to drive the SRAM A16/A15 inputs consider them MA16,MA16 two bits which select which of four 32K pages are positioned into the 8051 address space between 8000H and FFFFH.

Now we find ourselves back at Erik's argument, the second '138 works but the entire Port/RAM decode arrangement would fit nicely in a GAL/PAL.

regards,
p