Storing data to NVRAM
Since you want to access the memory "behind the CPU's back" while holding it in halt mode, you'll need something else to generate the necessary control and data signals, hopefully while you have a way to tri-state the CPU's bus signals.  Conversely, your "something else" will need to tri-state it's lines (except for the halt output) when the CPU is running.

In an earlier era, you would have connected up an 8255 parallel peripheral interface chip to your PC's parallel port, and used that and software to access the NVRAM one byte at at time.  Before releasing things to the CPU, you would configure the 8255 to be all inputs (ie, tri-state) and rely on resistors to keep the write signal to the memory from actuating during the handover.  You'd have to drive the halt signal from a port that you weren't otherwise using, since you couldn't tri-state it, and the 8255 only lets you control the direction of entire ports except for one port which you can control in two halves.

However, in this era of legacy-free PC's you may not have a parallel port, and so likely instead have to work off of USB.  You can use a a simple USB IO chip much as the 8255 would have once been used, using software to generate all the memory cycles.  But the USB ports actually have a much higher latency (delay) for a single access than the old printer ports did, so this may prove a very slow way to access your memory.

A better solution in the USB era is to use a small micrcontroller downstream of the USB (or even a USB-serial converter) to generate the memory access cycles, and send it commands such as "read this byte"  or "write the following 32 bytes starting at address xx".  Use the USB-serial paradigm and make these commands human-readable ASCII and you have something that can be used as a primitive debugger/monitor from a terminal program, or a download tool when driven by a specialized program.  You can use a binary interface instead, but USB is so fast at moving bulk data (can emulate serial ports at insane baud rates) that the overhead of ASCII (hex) encoding the payload data is no big deal, and doing so lets you use newline or carriage returns for block synchronization, instead of having to work out a scheme for differentiating framing codes from data bytes.