From d1dfa833037420aad9c48732ee229554fa88f261 Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Mon, 3 Aug 2020 14:10:32 +0100
Subject: [PATCH] Update SPLIT_MEMORY_MODE.md

---
 SPLIT_MEMORY_MODE.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/SPLIT_MEMORY_MODE.md b/SPLIT_MEMORY_MODE.md
index 903bdf0..52a7a01 100644
--- a/SPLIT_MEMORY_MODE.md
+++ b/SPLIT_MEMORY_MODE.md
@@ -1,10 +1,15 @@
 # SPLIT_MEMORY_MODE
-Aka. the enabling of the 'feature' (enabled by default) with:
+
+### New Feature
+
+With version 1.1.0 of the library onwards, there is now a 'feature' to split the framebuffer  over two memory 'blocks' (mallocs) to work around the fact that typically the ESP32 upon 'boot up' has 2 x ~100kb chunks of memory available to use (ideally we'd want one massive chunk, but for whatever reasons this isn't the case). This allows non-contiguous memory allocations to be joined-up potentially allowing for 512x64 resolution or greater (no guarantees however). This is enabled by default with:
+
 ```
 #define SPLIT_MEMORY_MODE 1
 ```
 ...in 'ESP32-RGB64x32MatrixPanel-I2S-DMA.h'
 
+
 ## What is it trying to resolve?
 
 For whatever reason (and this may not be consistent across all ESP32 environments) when `heap_caps_print_heap_info(MALLOC_CAP_DMA)` is executed to print information about the available memory blocks that are DMA capable (which we need for a DMA-enabled pixel framebuffer), you may see something like this: