From dba7e21423ed468eb228c60ea20179af32fabcd7 Mon Sep 17 00:00:00 2001
From: zeromus <zeromus@users.sf.net>
Date: Sat, 30 Nov 2013 05:07:58 +0000
Subject: [PATCH] revert a little bit of r4815. it seems wrong, or needs more
 documentation: the rom header should not be consulted when deciding whether
 to return 0xFFFFFFF for out of range cart rom data. did dsi have something to
 do with this? please explain or comment.

---
 desmume/src/NDSSystem.cpp            |  8 ++++++++
 desmume/src/addons/slot1comp_rom.cpp | 21 +++++++++++----------
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/desmume/src/NDSSystem.cpp b/desmume/src/NDSSystem.cpp
index 4fdf9c7e8..822b00c3e 100644
--- a/desmume/src/NDSSystem.cpp
+++ b/desmume/src/NDSSystem.cpp
@@ -464,6 +464,7 @@ void GameInfo::closeROM()
 
 u32 GameInfo::readROM(u32 pos)
 {
+	//TODO - endian correctness?
 	if (!romdata)
 	{
 		u32 data;
@@ -474,7 +475,14 @@ u32 GameInfo::readROM(u32 pos)
 		return data;
 	}
 	else
+	{
+		if(pos + 4 >= romsize)
+		{
+			printf("Panic! GameInfo reading out of buffer!\n");
+			exit(-1);
+		}
 		return *(u32*)(romdata + pos);
+	}
 }
 
 static int rom_init_path(const char *filename, const char *physicalName, const char *logicalFilename)
diff --git a/desmume/src/addons/slot1comp_rom.cpp b/desmume/src/addons/slot1comp_rom.cpp
index cac3068fc..702a6831d 100644
--- a/desmume/src/addons/slot1comp_rom.cpp
+++ b/desmume/src/addons/slot1comp_rom.cpp
@@ -51,21 +51,22 @@ u32 Slot1Comp_Rom::read()
 		{
 			//TODO - check about non-4-byte aligned addresses
 
-			//OBSOLETED?
-			////it seems that etrian odyssey 3 doesnt work unless we mask this to cart size.
-			////but, a thought: does the internal rom address counter register wrap around? we may be making a mistake by keeping the extra precision
-			////but there is no test case yet
-			//at any rate, this is good for safety's sake.
-
+			//it seems that etrian odyssey 3 doesnt work unless we mask this to cart size.
+			//but, a thought: does the internal rom address counter register wrap around? we may be making a mistake by keeping the extra precision
+			//but there is no test case yet
 			address &= gameInfo.mask;
 
-			//"Can be used only for addresses 8000h and up, smaller addresses will be silently redirected to address `8000h+(addr AND 1FFh)`"
+			//feature of retail carts: 
+			//B7 "Can be used only for addresses 8000h and up, smaller addresses will be silently redirected to address `8000h+(addr AND 1FFh)`"
 			if(address < 0x8000)
 				address = (0x8000 + (address & 0x1FF));
 
-			//as a sanity measure for funny-sized roms (homebrew and perhaps truncated retail roms)
-			//we need to protect ourselves by returning 0xFF for things still out of range
-			if (address > gameInfo.header.endROMoffset)
+			//1. as a sanity measure for funny-sized roms (homebrew and perhaps truncated retail roms) we need to protect ourselves by returning 0xFF for things still out of range.
+			//2. this isnt right, unless someone documents otherwise:
+			//if (address > gameInfo.header.endROMoffset)
+			//  ... the cart hardware doesnt know anything about the rom header. if it has a totally bogus endROMoffset, the cart will probably work just fine. and, the +4 is missing anyway:
+			//3. this is better: it just allows us to read 0xFF anywhere we dont have rom data. forget what the header says
+			if(address+4 >= gameInfo.romsize)
 			{
 				DEBUG_Notify.ReadBeyondEndOfCart(address,gameInfo.romsize);
 				return 0xFFFFFFFF;