The United-TI Forum is Read-Only.

Goto page Previous  1, 2, 3, 4 ... 9, 10, 11  Next

08 Sep 2009 12:29:12 pm by Michael
If you do, I believe you'll be the first person ever to get a technical reply from ti-cares. I used to get shot down by "Belinda". Oh, my nemesis...

14 Sep 2009 10:25:21 pm by calc84maniac
No need now, I have solved the puzzle! It appears that on these newer TI-84+/TI-84+SE calculators, there is only one extra RAM page as opposed to six. When we try to map in any of those six extra pages we are used to, we get the same 16KB block of RAM! After getting some positive test results from some of the afflicted calculators, I got Spencer to make a hacked version of Wabbit which emulates this behavior (which you can download here if you want to test for yourself). Here's a screenshot of TI-Boy running on this emulator: Compare to this Youtube video: http://www.youtube.com/watch?v=kdURerrKqXo They match perfectly. Also, Realsound hangs in this emulator, as would be expected. So, in effect, TI has removed 80KB of RAM from our TI-84+ calculators in the last 2 years! Though, this doesn't affect the OS because it doesn't use more than one of the extra RAM pages at a time, and never stores any permanent data there.

14 Sep 2009 10:53:54 pm by DigiTan
That...sounds serious. Can TI-Boy work around it?

14 Sep 2009 10:57:58 pm by calc84maniac
Not likely. This means I only have 16KB of extra RAM to work with - not enough, especially considering that the Game Boy had more RAM than that.

14 Sep 2009 11:27:12 pm by TheStorm
I'm skeptical of this, Ti would have to do more than just chop off ram pages like that, eve if they don't use those ram pages they would still have to account for them somewhere in their code and yet there is no difference in the boot code or os to support that. It may just be that TI is using crappier hardware like they did with the Display Driver and so it just can't handle all the swapping required for TI-Boy/Realsound. I'd say that is much more likely than them just being gone.

14 Sep 2009 11:34:42 pm by brandonw
I want a calculator that does this. Someone please trade with me (I have both 84+s and 84+SEs in perfect condition, so you have nothing to lose). Contact me privately if you have one. I'll go to Wal-Mart tomorrow and get a "newer" one and see if this is actually the case, which I highly doubt. It's far more likely that they've screwed up the hardware along the way at some point (like the RAM/Flash delays and the LCD delays, which some of the upper ports control) and they're configured just well enough for the OS to work but not us (the OS itself uses pages 83h and 82h). More research is in order. And TI will certainly not respond or care about technical issues like this.

15 Sep 2009 02:47:39 pm by FloppusMaximus
I am also extremely skeptical. Who ever heard of a 48k RAM chip? How was this test performed?

15 Sep 2009 04:20:57 pm by calc84maniac
Tests involved writing different bytes to the same byte in various RAM pages and then checking the values. It turned out that it was reading the last value written to any of the pages. Edit: Here's a simple example (returned "write failed" on the newer revisions and "write okay" on my calc) Code:    di    ld a,2    out (5),a    xor a    ld ($c000),a    ld a,3    out (5),a    ld a,$ff    ld ($c000),a    ld a,2    out (5),a    ld a,($c000)    or a    ld hl,goodtext    jr z,_    ld hl,badtext _    xor a    out (5),a    ei    bcall(_puts)    res 5,(iy)    ret goodtext:    .db "Write was okay  ",0 badtext:    .db "Write failed   ",0

15 Sep 2009 06:11:07 pm by TheStorm
What if you added a delay between the reads and writes, just to see if it makes a difference? Its just a thought of something else you could test.

15 Sep 2009 07:10:28 pm by calcdude84se
Well, if calc84maniac is right, then there is absolutely nothing I can do (save re-wiring the ports for additional RAM pages. But that would be bulky and I would be against it.) If brandonw, FloppusMaximus, and TheStorm are right, then new code would have to be very hacked, or it would still be impossible. This is looking bad... Using the hacked WabbitEmu, I sent my copy of Emu8x (I mentioned that it didn't work at the beginning) It behaves exactly the same as it does on my physical calculator. This gives support to both hypotheses (or theories), but not either one in particular. It does show that it acts as calc84maniac suggested, but again, I'm not really supporting any idea over the other. I hope that this problem gets solved...

15 Sep 2009 07:26:53 pm by calc84maniac
TheStorm wrote: What if you added a delay between the reads and writes, just to see if it makes a difference? Its just a thought of something else you could test. I've tried adding delays... no effect except everything going slower.

15 Sep 2009 07:31:13 pm by DrDnar
Run this program. First, run the uniqueness test. Nothing should be reported. Then run the retention write test and immediately run the verify test. Nothing should be reported. This test takes a few seconds. (You can quit the program after writing, do stuff, and then run the verify test to see if TIOS or any apps use the memory. Oddly enough, I get a hit on page 82h at 6C00h.) Then run the delay. Nothing should be reported. This program assumes that the problem is a delay, and so all writes to extra memory have a delay. I've tried to make it very thorough. EDIT: The program does Code: ; Set CPU speed    ld   a, 1    out   (20h), a ; Turn off memory delays    in   a, (2Ah)    and   %11111100    out   (2Ah), a The source is here. All includes are in the same directory.

15 Sep 2009 07:42:56 pm by calcdude84se
Uniqueness test reported page 82h: 87 Retention Test reported pages 82h to 86h (inclusive) with address 4000h If I mess around in the OS a bit, 87h also occasionally gets added (with the same address) Delay test reports nothing Doing it in hacked Wabbit does the same thing

15 Sep 2009 07:54:04 pm by Iambian
Oh. I guess I was beaten to the punch. I wrote myself a delay test as well... but since I spent time doing it, I might as well post it too. This only tests between pages 2 and 3. A result of 0 indicates that there's no delay. A result of 16384 shows that this test fails entirely. http://unitedti.pastebin.com/m7506481b Note: The attachment will load to the calculator as "XCOPY". Just run it as an asm program. EDIT: Bugfix? 15 minute coding session FTW EDIT2: Alternatively, you can view the patterns in Calcsys. EDIT3: If you run my program, I'm interested in numbers that will vary between 0 and 16384.

15 Sep 2009 08:03:27 pm by DrDnar
I'm upping the delay to ten times the values it previously was (it's now 250). Redownload the program and try it again. The retention test will take much longer now, so just wait. If the tests still don't pass, then a delay isn't the problem. The fact that you get results after messing around in TI-OS isn't surprising. I get that too. Do you have Omnicalc installed? It uses the extra RAM too. EDIT: Yeah, my program is huge. I spent a long time on it, but it is quite thorough. EDIT 2: Be sure to run the retention verify test immediately after writing. Don't even quit the program. EDIT 3: Woah, we can make attachments! I know, I'm slow. EDIT 4: Do give Iambian's a try, just to make sure mine isn't broken. Okay, too many edits.

15 Sep 2009 09:58:19 pm by calc84maniac
And okay, to expound on my theory, I can't say how much RAM is actually inside these calculators. I can more safely say, however, that only 48KB of RAM is accessible.

15 Sep 2009 11:54:18 pm by DrDnar
I actually wrote the uniqueness test with the assumption it would work, so it gives up after the first incorrect page. I'm updating it to test all pages. I actually discovered there's a bug in it, so it would only ever test one page, even if it was correct. I've fixed it now. So redownload the program and run it again. Now it'll report what pages are cross-linked. EDIT: I've modified the program to test pages 80h and 81h. Don't worry, 8000h is scrap RAM and C000h is saved to 8001h so no data is lost. If you know how, check the values on pages 82h--87h using Calcsys after running the uniqueness write. Post the first four and last four values on each page. So here's what the tests do: Uniqueness test: This writes the page number to the first byte of each page. Then it reads the first byte of each page back. If they don't match, it reports an error and reports the data read. 87 implies that 82h and 87h are cross-linked. The old version would stop after the first incorrect read; the new reads all pages. Retention write test: This writes a pattern to each byte of each page where each byte is related to both the current page and address. If there's any bleed though, the values will be off. Retention verify test: This verifies the pattern written above. It reports the first address of any changed data and stops scanning that page there. TIOS sometimes uses the extra RAM, so reports may mean nothing. 4000h is the first address in the page. Delay test: This tests to see if a delay is needed between setting the page and reading and writing data. It tests, first, weather a delay is needed between a page change and a read. Then it tests weather a delay is needed between a page change and a write. The tests also run with the CPU in fast mode and all memory delays off. My next step will be to test weather it matters which bank is used matters and weather the memory mapping mode matters. I'll need the results of Iambian's test and the new version of my test to know weather or not to include a delay (but I'm doubting that's the problem now).

16 Sep 2009 03:09:01 pm by thepenguin77
I have one of the new P-0508M calculators. Iambian's gave me a value of 1. The latest link to Dr. D'nar's didn't work so the previous one said: Uniqueness test: all are 87 Retention test: all are 4000h Delay test: umm... I think it worked?, just said "page change test", "now for part II.", "test complete" And when I checked it with calcsys: Code: page   first four     last four 80h   00 00 00 00    00 00 00 00  ;although I don't think these two were written to 81h   00 FD CB 2E    00 00 00 00  ; 82h   86 46 84 46    8A 07 88 07 83h   86 46 84 46    8A 07 88 07 84h   86 46 84 46    8A 07 88 07 85h   86 46 84 46    8A 07 88 07 86h   86 46 84 46    8A 07 88 07 87h   86 46 84 46    8A 07 88 07 Edit: The link started working and the results were the same

16 Sep 2009 04:25:16 pm by DrDnar
The link was to the same program as the last. I just provided it again for convince. And yeah, I fixed it. Anyway, for the uniqueness test, did it do Code: Page 80h: 87 ; This one might get scrolled off the screen, so watch closely. Page 81h: 87 Page 82h: 87 Page 83h: 87 Page 84h: 87 Page 85h: 87 Page 86h: 87 Page 87h: 87 Or were pages 80h and 81h omitted? (It is important you report all pages individually since nothing is reported for a page if everything is fine.) 87 on pages 80h and 81h implies that pages 80h and 81h are the same. In fact, it would imply that all eight RAM pages are the same page---which is clearly impossible. So it would seem that RAM paging on that port is broken. Further testing is required to see just what is wrong with the port(s). You are correct, the retention test doesn't test pages 80h and 81h. That would crash the calculator. The numbers the program writes those pages are related to both the address and page; the fact that all pages have the data implies that they're all actually the same page. If, in fact, 87 was read from pages 80h and 81h, then we have evidence for a page changing problem. If pages 80h and 81h weren't reported, it is evidence neither for nor against the 48K RAM chip theory. It is good that the delay test reported nothing. It implies there is no delay between switching between the RAM pages. (Or at least between them and ROM pages.) On the other hand, the result of 1 on Iambian's test implies there is a small delay. His test uses the 0C000h bank. If I understand the test correctly, it should report 16384 if the two pages turned out to be the same. This gives more credit to the page-changing problem theory.

16 Sep 2009 04:36:47 pm by thepenguin77
Ok, now I see how the program works. I don't think pages 80h or 81h show up on the uniqueness test because "uniqueness test:" is still displayed at the top of the screen. Uniqueness test: Code: 82h  87 83h  87 84h  87 85h  87 86h  87 Retention test: Code: 82h  4000h 83h  4000h 84h  4000h 85h  4000h 86h  4000h

The United TI Forum is Read-Only.

Goto page Previous  1, 2, 3, 4 ... 9, 10, 11  Next