I'm a nerd, I know =P
If you really want to access memory and look at it because you think it would be 'cool' then create your own array, fill it with data, stream to std out, and enjoy. If that's not 'cool' enough for you then you probably are interested more in something we do not condone on this board. Well behaved programs don't go poking around in memory they do not own nor do they attempt to access the hard drive at a low level. Exceptions to the rule would be low level utils like defrag or Diskkeeper or some other utils. I highly doubt this is one of those exceptions.
You can access memory but only that which belongs to you and that which you have allocated. There is nothing exciting about ton of hexadecimal digits.
I'm not going to argue with you cause you can ban me. But if I were interested at the moment in lobbinb stuff like this onto other computers, I wouldn't be on this forum. It'd just be intersting to make a different interface into the hard drive, but not a really high-level one.
I'm a nerd. You're just a masochist.
A hard drive is a huge thing to look at. Load data files like PNGs or MP3s into a hex editor and compare their headers and general structure to the format descriptions, if that's your thing.
I believe that as long as the drive isn't mounted, you can actually open a hard-disk for read/write as a raw device. Of course this excludes the boot-device, as that is definitely being mounted as part of the boot process. But if you have a disk that isn't being used by the OS, then you can [assuming you have sufficient [e.g. administrator] rights on the machine] open the drive itself for read/write, and use ReadFile and WriteFile to access the raw data on the drive.
Now why anyone would want to do that on a modern OS with a modern filesystem is a different story.
Of course, if you write your own driver, you can also access the hard-disk directly there - just bear in mind that if you mix this with OS accesses, God [or Satan, more likely, perhaps] only knows what you'll end up with, but it is unlikely to be anything good.
Or because you want to write a userspace format utility.
Or because you want to draw a bit-by-bit backup.
Or ... you get the idea.
I would recommend to pick up a book about driver writing for the OS you want to work on
First, I think people are gettign virtual memory confused with paging. Virtual memory is specifically when the OS uses mass storage to create the appearance of more memory than the system has physical RAM. Hence 'virtual' memory. It does this by marking unused pages as not-present in the global descriptor table or one of the local tables. The decriptor table entry is what maps the apparent memory location to a physical memory location, or to an external device. When the processor accesses a memory location the paging unit looks up the location in the descriptor tables, and if it is marked as present uses the value in the tables to access physical memory, if it is marked as not-present, then it causes a page fault, which the OS must handle. Usually this is done by paging a not recently used page to the pagefile, and paging the needed address block into physical ram, although there are other schemes.
Paging and virtual memory are essentially, in a modern system, done by the page-table, where pages of 4KB at a time can be made present or not present. 
But paging is also used in conjunction with protection, such that each process has it's own page-table, so that only that process can access the pages that particular process owns.
Once paging is enabled, addresses within the processor [at least on x86] are considered "virtual", meaning that the page is accessed through the page-table. The virtual to physical translation can be linear or non-linear, where a linear translation is "direct", 1:1 between the virtual and the physical address. The non-linear, any virtual address can point to "any" physical location.
 Technicaly, there is a duplicate set of segment descriptors for when the OS is in the kernel, and perhaps also some other "administrative", for example a TSS segment to handle Double-Fault/Stack-Fault [in kernel mode] conditions.
 Some processors and OS's support "Large pages", where pages are for example 2MB instead of 4KB, which reduces the size of the page-table for example when having large shared sections of OS memory that is common between all processes, and thus don't need the small 4KB granularity.