| Author |
Message |
|
Michael
Newbie
Joined: 21 Dec 2007
Posts: 39
|
 Posted: 08 Sep 2009 12:29:12 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 14 Sep 2009 10:25:21 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
| Posted: 14 Sep 2009 10:53:54 pm Post subject: |
|
|
| That...sounds serious. Can TI-Boy work around it? |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 14 Sep 2009 10:57:58 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
TheStorm
Calc Guru
Joined: 17 Apr 2007
Posts: 1233
|
| Posted: 14 Sep 2009 11:27:12 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 14 Sep 2009 11:34:42 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 15 Sep 2009 02:47:39 pm Post subject: |
|
|
I am also extremely skeptical. Who ever heard of a 48k RAM chip?
How was this test performed? |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 15 Sep 2009 04:20:57 pm Post subject: |
|
|
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
Last edited by Guest on 15 Sep 2009 04:43:19 pm; edited 1 time in total |
|
| Back to top |
|
|
TheStorm
Calc Guru
Joined: 17 Apr 2007
Posts: 1233
|
| Posted: 15 Sep 2009 06:11:07 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 15 Sep 2009 07:10:28 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 15 Sep 2009 07:26:53 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 15 Sep 2009 07:31:13 pm Post subject: |
|
|
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.
Last edited by Guest on 15 Sep 2009 07:49:59 pm; edited 1 time in total |
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 15 Sep 2009 07:42:56 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 15 Sep 2009 07:54:04 pm Post subject: |
|
|
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.
Last edited by Guest on 15 Sep 2009 09:54:14 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 15 Sep 2009 08:03:27 pm Post subject: |
|
|
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.
Last edited by Guest on 15 Sep 2009 08:50:30 pm; edited 1 time in total |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 15 Sep 2009 09:58:19 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 15 Sep 2009 11:54:18 pm Post subject: |
|
|
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).
Last edited by Guest on 16 Sep 2009 03:58:35 pm; edited 1 time in total |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 16 Sep 2009 03:09:01 pm Post subject: |
|
|
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
Last edited by Guest on 16 Sep 2009 04:21:04 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 16 Sep 2009 04:25:16 pm Post subject: |
|
|
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.
Last edited by Guest on 16 Sep 2009 04:26:54 pm; edited 1 time in total |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 16 Sep 2009 04:36:47 pm Post subject: |
|
|
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
Last edited by Guest on 16 Sep 2009 04:47:19 pm; edited 1 time in total |
|
| Back to top |
|
|
|
Calculator Tech Support => Technology & Calculator Open Topic
