Let's split this into 3 different problems.
How to get the address of the DSDT in memory?
The firmware provides a pointer to (one or 2) ACPI tables that contain an index of all other tables. These tables are the RSDT (Root System Descriptor Table) and XSDT (Extended Root System Descriptor Table); and the only real difference between them is that the XSDT supports 64-bit addresses (and should be used if possible) while the older RSDT does not (and should be considered "deprecated" and only used as a fallback for modern 64-bit operating systems). These tables mostly provide the identifier and address of all other tables; so if you want to find a specific table (e.g. the DSDT) you can search the index for the identifier (e.g. the 4 ASCII characters "DSDT") and find the entry that contains the table's physical address.
The pointer/s to the index are contained in a special structure called the RSDP (Root System Description Pointer); which is found in different ways for different types of firmware. For BIOS you have to search a few specific areas of physical memory looking for a special structure (with a special signature, and a valid checksum); and for UEFI you simply ask the firmware (and avoid a "cache pounding" search).
This is all (relatively clearly) described by the ACPI specification, including how to find the RSDT (e.g. the section "Root System Description Pointer (RSDP)"), and including the format of all structures and tables, and the meaning and purpose of all fields.
How to decode the information in the DSDT?
Because things can change after boot (due to hot-plug support, etc); static tables can't be used for some things and ACPI solves this problem (and creates more problems) by defining a special language called ASL (ACPI Assembly Language) that is compiled into a portable byte-code called AML (ACPI Machine Language).
The DSDT contains this AML.
To make any sense of it you need an AML interpreter, to execute the AML that is contained in the DSDT.
This is "very challenging" - to do it yourself you'll probably need to spend months studying the ACPI specification (and years working around bugs in different computers). Most people port an open source implementation (originally created by Intel) that is called ACPICA (see https://acpica.org/ ).
Sadly; being able to execute AML is only the first step. You also need to understand ACPI's namespaces, which functions/methods are provided by the AML and what they're supposed to do. To make this worse; ACPI's AML expects to be informed of what the OS is, and then enables/disables various features and changes its behavior to suit the OS (depending on what it was told the OS is); and often the only operating systems that are recognized by AML are versions of Windows and if you tell it something else it disables various features, so most operating systems just lie and say they are a version of Windows so that AML doesn't provide a crippled subset of its capabilities. However; "what each version of Windows does" (and how AML behaves for each specific version of Windows) is a horrible undocumented (by ACPI specs) disaster. Fortunately; ACPICA also hides the majority of this pain (for people that port ACPICA).
How to get a detailed memory map (ranges) and also to get which devices are connected to the CPU?
Mostly you don't. Specifically, you don't just "get a detailed memory map" in a nice single step.
Instead; you start by getting some minimal information about the physical memory from firmware (from int 0x15, eax=0xE820 for BIOS, or from GetMemoryMap() on UEFI). Then you use a variety of different sources to add more details to that minimal information, including but not limited to the CPUID instruction (for how many bits a physical address actually has), the ACPI "APIC/MADT" table (for IO APIC and local APIC addresses), the ACPI "EDT/HPET" table (for HPET addresses), the ACPI "MCFG" table (for the addresses of PCI Express memory mapped configuration space areas), the ACPI "SRAT" table (for NUMA information for memory areas and "hot-plug RAM" information), and possibly (optionally) the SMBIOS tables (if you care about things like what type of RAM is installed, etc).
After obtaining all the information you want from static/unchanging sources; you switch to "phase 2", which involves continually managing the memory map and trying to keep it up to date as information from various devices is found (and modified via. hot-plug events). This is where being able to execute AML (from DSDT, using your AML interpreter) becomes important. It also involves bus specific approaches (e.g. scanning PCI buses and extracting information from each PCI device's BARs/Base Address Registers).
Note that this isn't purely about filling in details for the memory map. It's better to thing about it as discovering the resources that devices use, which includes IO ports, IRQ lines, DMA channels (and not just areas of the physical address space alone).
Also note that you only really information about devices if/when you have a device driver that is capable of using the information to "drive" the device. If you don't, then the memory map you have will just say "reserved" and you won't know why, but you probably won't have a reason to care why anyway.
Final Note
This is "very daunting" at first glance. Don't be worried - you can (and should) start small and ignore most of it until much much later. You can do a lot with the minimal information about the physical memory from firmware alone; and add code to do almost everything else if/when it actually matters for your OS one day.
