diff --git a/inxi b/inxi
index 817629f..a1d376f 100755
--- a/inxi
+++ b/inxi
@@ -1,9 +1,9 @@
 #!/usr/bin/env bash
 ########################################################################
 ####  Script Name: inxi
-####  Version: 2.1.98
-####  Date: 2014-08-17
-####  Patch Number: 01
+####  Version: 2.2.00
+####  Date: 2014-08-18
+####  Patch Number: 00
 ########################################################################
 ####  SPECIAL THANKS
 ########################################################################
@@ -4901,7 +4901,7 @@ get_dmidecode_data()
 			# strip out all the stuff we don't want to see in the results. We want the error data in 
 			# stdout for error handling
 			if [[ $b_debugger == 'true' && $HOSTNAME == 'yawn' ]];then
-				dmiData="$( cat ~/bin/scripts/inxi/data/dmidecode/dmidecode-memory-variants-2.txt )"
+				dmiData="$( cat ~/bin/scripts/inxi/svn/misc/data/dmidecode/dmidecode-memory-variants-2.txt )"
 			else 
 				dmiData="$( $dmidecodePath 2>&1 )"
 			fi
@@ -8216,6 +8216,9 @@ get_ram_data()
 			/^Handle .* DMI[[:space:]]+type[[:space:]]+6(,|[[:space:]])/ {
 				while ( getline && !/^$/ ) {
 					if ( $1 == "Installed Size" ) {
+						# get module size
+						aMemory[k,j,18]=calculateSize($2,0)
+						# get data after module size
 						sub(/ Connection/,"",$2)
 						sub(/^[0-9]+[[:space:]]*[MGTP]B[[:space:]]*/,"",$2)
 						aMemory[k,j,16]=$2
@@ -8534,9 +8537,20 @@ get_ram_data()
 						aArrayData[m,"maxModuleSize"] = 0
 						# print "yes"
 					}
+					if ( bDebugger1 == "true" ){
+						print "5: dms: " aArrayData[m,"derivedModuleSize"] " :dc: " aArrayData[m,"deviceCount16"] " :wmc: " workingMaxCap
+					}
 					## prep for output ##
 					if (aArrayData[m,"maxModuleSize"] == 0 ){
 						aArrayData[m,"maxModuleSize"]=""
+						# ie: 2x4gB
+						if ( estCap == "" && int(aArrayData[m,"derivedModuleSize"]) > 0 &&
+						    workingMaxCap > ( int(aArrayData[m,"derivedModuleSize"]) * int(aArrayData[m,"deviceCount16"]) * 4 ) ) { 
+							estCap=" (check)"
+							if ( bDebugger1 == "true" ){
+								print "G"
+							}
+						}
 					}
 					else {
 						# case where listed max cap is too big for actual slots x max cap, eg:
@@ -8544,8 +8558,8 @@ get_ram_data()
 						if ( estCap == "" && aArrayData[m,"maxModuleSize"] > 0 ) {
 							if ( int(workingMaxCap) > int(aArrayData[m,"maxModuleSize"]) * aArrayData[m,"deviceCount16"] ) {
 								estCap=" (check)"
-								if ( deBugger1 == "true" ){
-									print "G"
+								if ( bDebugger1 == "true" ){
+									print "H"
 								}
 							}
 						}
diff --git a/inxi.changelog b/inxi.changelog
index c3816b4..522a713 100755
--- a/inxi.changelog
+++ b/inxi.changelog
@@ -1,3 +1,82 @@
+=====================================================================================
+Version: 2.2.00
+Patch Version: 00
+Script Date:  2014-08-18
+-----------------------------------
+Changes:
+-----------------------------------
+New version, tarball, man page. Maintainers, this is the official release of -m feature.
+
+I have collected enough datasamples to allow for reasonably fine grained corrections, estimates,
+warnings about unreliable capacity now, and have fixed all major failures. 
+
+Also, because this stuff is filled out by people somewhere, or not, some fields often are just
+empty, or contain the default values, ie, they are worthless. inxi shows N/A for those situations,
+it means there is really no actual data to show you.
+
+This feature, sadly, well never be totally reliable, because dmi data is frankly junk, especially
+dmi type 5 and 16, which is what is supposed to tell you total capacity of memory array, and the
+maximum module size (type 5). However, this data is totally random, often it is right, sometimes
+it is wrong. Sometimes type 5 is right and type 16 is wrong, sometimes the other way. And since
+type 5 is only present in some systems, it's not reliable anyway.
+
+What is reliable and always right is the actually installed memory per device, ie, sticks. I have
+not seen any errors in that, so that seems to be actually coming from the system itself. type 5 / 16
+sadly are clearly entered in manually by some poorly paid engineers out there in the world, and are
+often total fictions, either far too small, or far too big, or whatever.
+
+inxi will attempt to correct all clear logic errors, and whenever it changes the listed data from 
+type 5/16, it notes either (est) or (check). (est) means it is a good guess, one I am comfortable making,
+(check) means it is either an unreliable guess, or that what the system is reporting is so unlikely that
+even though inxi is showing it, it doubts it could actually be true, or at least, it thinks you
+should check this yourself. 
+
+-m has 3 extra data options, -x prints the part number, if found, and the max module size, if type 5
+is present. inxi does NOT attempt to guess at max module size based on what is installed, it only will
+correct a listed max module size if installed modules are > than listed max size. Usually part numbers,
+if present, are all you need to order a new stick.
+
+-xx shows serial number, manufacturer (often empty, or just random alphanumeric identifiers, but sometimes
+they list the actual company name, which is helpful. It also shows, if type 5 data is present, single/double
+bank.
+
+-xxx as usual shows largely useless data that may be of interest to soemone, like if ram type is synchronous, 
+memory bus width data, and module voltage (type 5 data).
+
+This feature will never be reliable I am sad to say because the source data itself is random and much
+has been filled out, or not filled out, by engineering drones somewhere out there in the underpaid
+world. The ranges of errors are so wide that inxi just has to check what is possible, reasonable, unlikely,
+etc, to generate its numbers. In other words, this is NOT just parsing dmidecode output, that is the raw
+material only, sad to say.
+
+So this is it, for better or worse. All bug / issue reports with this MUST come with a full:
+inxi -xx@14 
+hardware data upload, run as root. 
+
+Also, much to my annoyance, this feature requires root, since /dev/mem needs root to be read, and I assume
+the dmi table, so that is a departure from normal inxi standards, as is the low quality input, and thus,
+output, data, though I can guarantee that what inxi tells you is in most cases on average more accurate than
+what dmidecode tells you, since dmidecode simply prints out what it finds in the dmi table, and nothing else,
+in whatever order it finds it, from what I can see, ie, you also cannot trust the order of dmidecode output.
+
+I had been hoping that /sys would start to contain memory data like it does mobo/system data, but it never
+happened so I finally decided to just do the ram thing, require dmidecode, require root/sudo, and that's
+that.
+
+There will be issue reports, you can help them by looking up the mobo stats/specs yourself and listing them
+in the issue, so I don't have to do it. I use the tool at crucial.com which is very accurate and also very 
+complete in terms of all possible hardware out there. 
+
+I would trust that tool before trusting the companies that have the least reliable data, like ASUS.
+
+Much thanks to everyone who is contributing datasets, and the distros, particularly siduction, that really 
+were very helpful in this process, by finding more and more failure cases that helped me start to tighten
+the logic, and make it more and more robust. Special thanks to Mikaela, of #smxi irc.oftc.net, who came up
+with two systems that both required a full redo of the logic, and thus who helped a lot in this process.
+
+-----------------------------------
+-- Harald Hope - Mon, 18 Aug 2014 15:07:36 -0700
+
 =====================================================================================
 Version: 2.1.98
 Patch Version: 01