Additionally, simply put, what IBM did was to include the 8-bit PC slot inside the AT slot. If a 8 bit simple memory card decodes from the 8 bit section of the slot, it uses the SMEMW and SMEMR which contain additional decoding to prevent wrapping around the below-1MB memory space 16 times when it repeats at higher locations if a card or expansion chip only would do decoding up to A19. Another very smart 8 bit compatibility trick by the PC designers. For our system, we mostly don't use these 8 bit address space memory control lines. Specifically I only use it on the LAN and SCSI chips because they decode only up to A19. I think the LAN doesn't use that line though since it's wired as an IO device, but just to be safe. From memory, on the Realtek chip the MEMR and MEMW lines are probably only used to interface with optional card stuff like a EPROM for a LAN BIOS, but I connect them to the lower address space SMEMW and SMEMR since this is the best way to do it. I could probe them later which would probably confirm they are not used and can be left out. The 53C400 NCR SCSI chip I really love because it maps right into the 8 bit expansion card reserved memory space. I see no need to remap this chip using programmable logic as seen by certain manufacturers, and I simply use it as intended by NCR themselves which works perfectly.
Memory on the mainboard is decoded directly from the CPU address lines. Which are also controlled by the DMA and bus master process by transceiver switching as I mentioned above. What IBM did for the RAM is to decode the address lines directly through a PROM decoder and this can control 512KB of onboard RAM, it looks like a second bank as well, maybe later I will read and analyze the PROM in more detail to know what their possible original intention was with it. The 5170 schematic hints at a larger RAM configuration possibly 640KB or more, which could be present in the decoder as additional decodes but just not fully implemented in the 5170 design revisions produced. Maybe I will revisit this later just for historical purposes.
So after decoding the RAM selection from the CPU address lines, this goes through a filtering latch which loads the decoded signals during valid CPU address periods on the address bus, where during DMA it's normal constant address line control, not needing the extensive synchronization which the Intel CPU does.
So basically the AT decodes the CPU A17-A23 lines directly and latches them. I do it the other way around in the CPLD, I first latch all the lines to make sure they are valid at times when coming from the 286 and then decode the latched lines inside the CPLD. The resulting decoded RAM control lines need no further synchronization to the CPU during CPU access of RAM since this is already done initially. As you said, it's simple but at the same time needs to be done correctly or the system won't function of course. With everything in IT, as long as you know the exact methods, caveats, issues and exceptions, it will become "simple" for the person viewing the matter.
So for a basic perspective, the RAM/ROM memory selection is decoded mainly from A17-A23 on the CPU bus. In the ISA slot connector we have functionally these exact same signals in LA17-LA23 which IBM provided for this specific purpose in the AT ISA slot. When you study the IBM 2MB DRAM expansion card for the AT you can also see that IBM also employed these LAx lines to decode the RAM. Whether a decode happens on the mainboard or on the card, functionally makes no difference viewed from the system's perspective. On a card such as that 2MB card for example, the memory decoding is 100% the same as it was done on the mainboard, the circuits are quite similar. First they run the CPU lines through a PROM, and then they sync the control lines through a BALE latch which is exactly the same as GATE_ALE on the mainboard address latches, simply put it's a combination of DMA control and CPU control for the memory decoders. So whether I put all the SRAM on the mainboard and interface it to the system bus (SAx/SDx) and CPU address bus(A17-A23) or put it all on an ISA card and interface it to the system bus(SAx/SDx) and CPU address bus(A17-A23) makes no difference at all, it's only a different physical location where I place the SRAM chips and decoder, while functionally it's exactly the same in the way the memory is decoded and responds to the various address and control lines. There is no delay or wait state or anything happening, the SRAM on the ISA slot card is controlled in exactly the same way as any onboard RAM in the original AT design in our project.
I moved the memory decoder CPLD onto the ISA slot SRAM card to save the necessary PCB space for our project and I will feature a small 10 pin IDC flatcable from the ISA RAM card to the mainboard to control the EPROMs for the BIOS and option ROM EPROMs on the mainboard and where I exchange a few other things such as CPU control for the delayed CPU cycles during 8 bit memory access. The memory decoder CPLD is also involved in the mechanisms to discern between 8 and 16 bit memory access. I simply want to keep the EPROMs on the mainboard because that looks cooler and it's what we typically recognize on a PC mainboard. I want to feel a similar traditional experience when seeing our project circuit board.
Another thing worth mentioning, for your impression, the RAM employs no clock pulse. There is no mechanism of control which is different in my method of placing the RAM on the ISA crd. Internally the 8 to 16 bit conversions and cycle synchronizations use certain clock pulses, those I have directly linked to whatever CPU clock is provided in the system. So in other words, if we raise the CPU clock, the CPU synchronization will also take the faster clock timings inside the CPLD. So everything changes proportionally, which I have intentionally made that way already in the CPLD. The fixed clock devices including the 8237 DMA chips and their timings, take a separate fixed 16Mhz clock from an additional clock generator in our project design, and only the CPU and CPU related timings are derived from a separate, to be varied, clock input on the CPLD. Part of the CPU synchronization such as also the HOLD/READY states happens inside the 82284 chip. So when using a faster 286, we will also need a 82284 which can handle that higher speed, there is no way around this due to how the system works. So eventually when going up in CPU clock speed, we will need to find a faster way to control the CPU by either a faster 82284 chip(which exist for example on the ARC mainboard) or a faster logic recreation of the 82284 for example in CPLD or FPGA.