I extended fxTerm to be able to be able to receive requests from the serial port and send back data at a requested address. What I found gives me pretty good confidence that the Casio fx-CG50 has an 8 MiB RAM chip (or at-least mine does) and that all the address lines are wired up correctly such that it's possible to access that memory. By access I mean that literally. I don't mean that it's safe to access in your program because some of it is used by the OS.

What I did was run this command:

Code:


I then split the file up in half and verified that the first half and the second half match for the most part. Of course it's not going to be exactly the same because the screen changes but it was very close.

Now the question is how much of that memory do we get to use? I don't have that answer yet. It would be nice to be able to get it from a system call like we can for both the primary and secondary VRAM buffers but unfortunately the best we can do might be disassembling the OS and seeing what is not used. Of course the problem with that approach is the add-in would only work on one version of the OS.

Just being able to perform a pointer access is not enough proof, for severals reasons (two mainly). One of them is that the upper half of the virtual space (P1 through P4) is not covered by the MMU (well except P3 but the OS doesn't use that), so you don't get a TLB miss for accessing bad addresses, you just get garbage.

The second reason is that RAM wraps around; on older models (RAM mapped at 0x88000000) with sometimes 256 kB, sometimes 512 kB, you could always access 0x88040000, but on models with 256 kiB this would hit the same byte as 0x88000000, and you need to check for this. This RAM detection function in my testing add-in, which I used for on-chip RAM, does this (and if you don't check for wrap-arounds, you'll think you have 2 MB of ILRAM x3).

This being said, I am still confident that the RAM area will pass those tests, because I don't see why the RAM would not be configured in the BSC.

In principle, if we can establish that the memory is there and is unused, then why not use it? If it's just incompatibility with some OS versions we could always add some version detection and either implement a workaround later or refuse to start the application on a newer OS. You mentioned you had some project ideas that would greatly benefit for a couple more MB of RAM, and I'm totally in for it.

The only thing I would recommend to keep this safe is a detailed documented test to determine whether the memory is used by the OS or not, and only allow a whitelist of OS versions to start the program. Clearing and overriding the extra memory on a newer OS that uses it could be pretty bad to really bad (the new G-III that finally uses the second half of the 512 kiB RAM puts both the heap and stack there!), but if the add-in is careful I see little to no way to damage a calculator with it.

Yes I agree, I think I'm a long way away from a test but one idea I do have is I noticed that I see a large area of zeroed ram. I could test that it's all zero and then if it is let he program proceed and if not display an error. When the program is done the RAM can be zeroed again so it's as if nothing has changed.

That sounds good, that would be the super-safe option. There is the chance the RAM is also 0x5555 at startup or other kind of uninitialized values, which could also be detected.

For 256-kB-vs-512-kB thing an add-in was used to write a pattern (0x5555, 0xaaaa, random sequence...), then simple and advanced functions of the OS were used for a while. Finally, the add-in checked that the RAM had not changed. This would be less safe though, if the memory is consistently zeroed out this might work out better.

Another "confidence test" could be to look for RAM-looking addresses within either the code or the whole OS file. I've looked for 4-aligned values between 0x8c200000 and 0xc87fffff in OS 3.40, and I've found a couple of them (something like 3 to 30 occurrences of each first byte: for instance 20 occurrences of 0x8c46xxxx). Most of them were in data sections though, because there was just no valid code around. Given the size of the OS (~ 10 MB), we can expect to see that just from randomly-distributed data. And it's far from the endless stream of references to the first 2 MB too.