Extra RAM page trouble

[calcdude84se]

I second that uniqueness test gives 82h-86h all with a value of 87
Retention test gives 82h-86h all with value 4000h
Delay test still reports nothing

Iambian's test also gives me a 1.

All results are the same under hacked Wabbit.
If there is still all the memory that was on the older models, than the port must be really screwed. On the other hand, we are still screwed if there is only 48k of RAM. The best I can suggest is "protocol change?". However, I feel that that is not the problem.
Seriously, we're screwed.

[Graphmastur]

Can we "force" a port to have the extra pages, or are they just not there?

[FloppusMaximus]

Crazy. What happens if you set port 6 to 82h (or 83h) in mapping mode 1?

Are you permitted to execute code on "page 82h", "page 83h", both, or neither? (And what if you set port 21h to 11h? Note that doing that is a bit difficult since the port is protected.)

[calc84maniac]

I know that running on "page 83h" and "page 87h" both work. I haven't tried any others though.

[Iambian]

There may be a problem with the program I wrote. I'm going to see if I can iron it out.

EDIT: Caught the error. Rewrote the program so I don't make that mistake again. Again, it'll show up as XCOPY both as the file and on the calculator. Included is the source.

[calc84maniac]

[Iambian]

See my previous post. An error like that *could* have crashed the calc (but didn't because it never wrote back to any other RAM). I actually found a different error but it was all the same. Should've used subroutines to begin with.

[thepenguin77]

Iambian's new program shows 16384.

[DrDnar]

This is perplexing. No matter. Our course is clear: we must do our best to capture---er, rather, test the other RAM banks. I'll try to put together a program to test the other banks and memory mapping modes tomorrow. I've got it all outlined, so writing the code shouldn't be too hard.

If anybody would like to try to beat me to the punch, you might find this log useful. Also check out WikiTI's page on unknown ports.
[quote name='"BrandonW and I were discussing memory access yesterday"']<DrDnar> The next step is to test the other banks.
<DrDnar> And perhaps the other memory mapping mode.
<BrandonW> You should swap them in pairs to the last two banks (1\0, 3\2, 5\4, and 7\6 like the OS does).
<BrandonW> The OS also zeroes out port 0F before writing to 05.
<BrandonW> So do that, too.
<BrandonW> Also, Calcsys tells me all the extra RAM pages are the same.
<BrandonW> But this same calculator was used to DEVELOP msd8x, so there's no problem with it.
<BrandonW> So I don't put much stock in any tests at the moment.
<DrDnar> Quite odd.
<DrDnar> What do you mean by the last two banks? 8000h and C000h?
<BrandonW> Yes, I mean 8000h and 0C000h.
<BrandonW> You don't need to use three RAM pages.
<BrandonW> Zero out both pages, write a 1 to 8000h and read 0C000h.
<DrDnar> I was going to write the page number to the base of the page plus the page number. Then I could see which pages were interacting.
<DrDnar> I'm writing a RAM program, and that program has to live somewhere in the active address space.
<DrDnar> Swapping 80h/81h into the 4000h bank seems to work fine, so I can swap that in and jump to myself.
<BrandonW> Copy all of page 81h to 83h and swap pages 3\2 in.
<BrandonW> It will seem no different.
<BrandonW> The purpose is to duplicate what the OS does.
<BrandonW> And access the memory successfully.
[some time later after futher thinking]
<DrDnar> Bah, BrandonW, know any parts---off the top of your head---of the OS I should look at concerning RAM paging?
<BrandonW> There are several functions they use for it.
<BrandonW> And everything calls those 2 or 3.
<BrandonW> I forget where they are...
<BrandonW> One reads/writes involving a RAM page in the 4000h bank and system RAM (81h).
<BrandonW> Two reads/writes*
<BrandonW> And then the last two banks like I was saying earlier.
<BrandonW> It's scattered all over the direct USB routines on page 76h if you want a place to look.
<DrDnar> Really? The OS uses the 4000h bank for RAM? Is the OS code executing from ramCode?
<BrandonW> No, I can't remember, it might be page 0, but it never uses ramCode for that.
<BrandonW> Only for Flash routines.
<BrandonW> But yes, a couple of BCALLs do swap there.
<BrandonW> http://brandonw.net/calcstuff/toDoIO.txt That lists a couple of BCALLs near the bottom that backup/restore graph stuff to the extra RAM pages.
<BrandonW> They're short and quick to disassembly.
<BrandonW> disassemble.*
<DrDnar> Graph stuff? In the extra RAM?
<BrandonW> Yes.
<DrDnar> Crazy.
<BrandonW> I really have no idea what it's for.
<BrandonW> I can't even find where one of them is being called.
<BrandonW> So it might not even be used.[/quote]

Writing these tests from afar is hard. Wating for results is hard! A TI hack's lot is not a happy one.

Arg, it's stuck in my head again. This is what I get for doing theatre.

[calc84maniac]

A little tidbit from Revsoft:
[quote name='"DarkSunDS"'][quote name='"TI Tech Support"']You requested confirmation that the hardware specifications for our TI-84 Plus family models of graphing calculators hasn't changed. This is correct. The TI-84 Plus and the TI-84 Plus Silver Edition still have 24K of RAM and 480K/1.5MB of FLASH ROM available as they have always had.[/quote][/quote]
Too bad that doesn't tell us anything at all. It's talking about available user RAM, not the total amount of RAM in the calculator (and has TI ever officially documented those extra pages in the first place?)

[brandonw]

They've gone so far as to say they'll be used by the OS in the future (which they were).

[FloppusMaximus]

I'm a little confused now. Is there actually any reason to believe the OS uses more than 16k of extra RAM? It's been a while since I looked at it, but I don't ever remember seeing it use more than the first few kilobytes of page 83, and perhaps also the very end of page 82 for stack space.

[calc84maniac]

[calcdude84se]

I'm not very optimistic, but we shouldn't just conclude that TI cut the RAM (although they probably did). We should verify this completely before we say, "The new TI-84+(SE) calculators only have 48KB total RAM."

[calc84maniac]

[brandonw]

I have a relatively new blue 84+SE that doesn't have any of these problems, and I just bought a brand new pink 84+SE to test this stuff, so we'll see once and for all what the deal is (when I get the time to open it up and run a couple of programs).

[calcdude84se]

Then we'll sit around waiting for results.

When you say the blue one has no problems, you do mean all the extra pages are separate and work, right?

[DrDnar]

I've written the long-promised program to test the other banks. The attached program tests pages 82h-87h in pairs like the OS uses them. It'll print a series of hexadecimal numbers. If the pages are all unique, only one byte on each line will be non-zero (except the first byte of every second line, which is garbage). Please report the entire output.

Source.

[calcdude84se]

Results:

[DrDnar]

Apparently they got cross-linked even through the memory banks. I'll look at some disassemblies of TI-OS, but I doubt I'll come up with anything that'll change anything.