I have attached some kind of screenshots regarding wall drawing pattern of SNES PoP1. Being different from PC version, it seems that walls of SNES version are manually drawn without automatic drawing algorithm.

Practically speaking, the only way to do random tile generation with SNES is to limit yourself to using 48x4 tiles per environment.
To start with the x4: SNES tiles change depending on which tile is below them.
The four tile groups that influence this are: space, pillar, wall and gate.
And since the original game does not use all four tile groups under all other tiles, some tiles simply do not exist.
The 48 are, subjectively, the most used and useful tiles used for building levels.
To better understand what I just wrote above, you can use apoplexy.
If you start apoplexy in SNES editing mode, you will see its tiles screen has 48 tiles.
Three rows of 13 tiles and one row with 9 tiles, and 13+13+13+9=48.
When you clear a room (middle mouse button) and place a wall in the middle of the room, the tile's lower right is slanted.
If you then place a second wall under that first wall, the first (top) tile's lower right changes.
So, there are 48 tiles that each have 4 possible states, depending on what is under them.
And, since the original game does not use all combinations, sometimes apoplexy has to improvise.
In level 1, for example, the blue environment, if you place a gate under a wall, the lower right is not a gate graphic.
Now, to quickly get a list of all 48x4 tiles for all 10 environments that SNES has, use apoplexy.
You will have to start apoplexy from a DOS prompt, with a special command-line option.
Use "apoplexy -t=x" to get a list of all the tiles for the x environment.
But replace x with the environment letter.
For the blue environment, for example, run: apoplexy -t=b
All possible environment letters are: b, f, g, h, i, j, l, m, s, u
You will see a listing that includes something like:
-----
[ INFO ] Tile 46:
[ OK ] png/blue/b_00_01_1c_01.png
[ OK ] png/blue/b_00_24_1c_01.png
[ OK ] png/blue/b_00_04_1c_01.png
[ OK ] png/blue/b_00_04_1c_01.png
-----
If you look at the tiles screen, tile number 46 - if you count as you read text - is the kill potion.
And the [ OK ]-lines I pasted above are, from top to bottom what the tile is like above: space, pillar, wall and gate.
This means that, for this environment (b), if you want to randomly use a kill potion somewhere...
...and there is a wall below that random position, you need to use tile 00 04 1c 01.
Because the third OK-line is for the wall, and that one says: [ OK ] png/blue/b_00_04_1c_01.png
If you don't know what 00 04 1c 01 means, see the wiki page about the SNES format.
The very short version is: fore back object attribute. Attribute 00 is space, 01 is floor, and 02 is wall.
You can use Pr1SnesLevEd to learn more about all available fore and back layers for each environment.

Practically speaking, the only way to do random tile generation with SNES is to limit yourself to using 48x4 tiles per environment.
To start with the x4: SNES tiles change depending on which tile is below them.
The four tile groups that influence this are: space, pillar, wall and gate.
And since the original game does not use all four tile groups under all other tiles, some tiles simply do not exist.
The 48 are, subjectively, the most used and useful tiles used for building levels.
To better understand what I just wrote above, you can use apoplexy.
....

Thank you so much for your kind and detailed comment. SNES data format is quite a different from PC one but it would not be diffcuit if I fully understand the information you mentioned above.

Also each level type blocks does change in each level, so wall block tile in level 2 could be uses different than the one in level 1(for example most of the caves tiles not used) and using the editor you could also check that some tiles will not have flags for "wall" collision, so will be easy to get only few one tiles that can be used.

salvadorc17 wrote:
Now i have discovered that each level loaded from Snes is stored in the RAM with the same values used in ROM,

Yeah, I figured that out much before I made the Pr1SnesLevEd SNES level editor (in 2009, or rather in 2007).
That's what helped me to figure out the compression: I compared the level data in RAM (from savestates) with that in ROM.
(I even posted about it then (on PoPUW, I think), and someone answered that there is "no point looking through savestates".)

The level is loaded into the RAM area at 7F:E440..7F:F3A3.
That's exactly 0xF3A3-0xE440+1 = 0xF64 = 3940 bytes, as mentioned on the SNES format page.

Also, there is a separate area that stores the objects for each tile position, at 7F:E170..7F:E43F (i.e. just before the area where the level is unpacked).
(0xE43F-0xE170+1 = 0x2D0 = 720 bytes = 24 rooms * 30 tiles/room.)
This is generated from the "blocks layer" and "block objects" areas.
The purpose of this area is so that the game can change objects without bothering with the "blocks layer" and "block objects" areas.
Examples of such changes are: drinking a potion, breaking a loose floor, etc.

And even before that, at 7F:E030..7F:E16F, there is an area where various layers of the current room (and parts of the adjacent rooms) are loaded.
(0xE16F-0xE030+1 = 0x140 = 320 = 16 columns * 5 rows * 4 layers.)