ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Archives :: News :: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00

Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
Posted by Nick on 18 November 1999, 03:15 GMT

Scott Noveck of Assembly Coder's Zenith (ACZ) wrote an interesting bit of information on his home page yesterday concerning exactly why Hardware Version 2.00 has problems with grayscale.

The text of the news item is as follows:

"Also, I've finally managed to get some important information from TI on the hardware and software differences between the original 89s and the 'new' ones (if you go to file -> about from the home screen and see 'Hardware Version 2.00,' then you have a new model - these have problems running several programs). In addition to the usual quirks found in ROM v1.05 that requires programs to be patched, some hardware modifications have been made that prevent greyscale from running the conventional way. I should be able to fix this, although any greyscale routines will need to be modified directly through the source - not just patched. Also, these are running the exact same processors that the old ones used - same speed and all. There were some modifications to the way the LCD screen refreshes, which does speed up complex math a lot on new models. More information coming soon =)"

We hope this sheds some more light on the issue, and why it's so hard to upgrade some programs. Also, in the long run, this will help out with doing math on the calculator (which was its original intention *g*) which is a big plus in my opinion.

 


The comments below are written by ticalc.org visitors. Their views are not necessarily those of ticalc.org, and ticalc.org takes no responsibility for their content.


Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
David Phillips  Account Info
(Web Page)

Nice work Scott. Glad to see you make it to the front page of ticalc.org :)

     18 November 1999, 03:43 GMT

Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
David Ricciardi
(Web Page)

I see that ticalc has deleted about 3 post to this artical. im replying to one about whats the diffrence between the two versions. this was posted by scott on another discussion

All greyscale planes may ONLY be at addresses $4c00, $5c00, $6c00, and $7c00 on the new calcs.
However, the data at these addresses is used by TI, so I believe that they must be preserved when
the program runs.

Greyscale right now just uses tios::heapalloc and uses the area it returns as the second greyscale
layer -- however, HWv2 does not allow the second plane to be at the address.

Instead, I've proposed the following workaround: Create the buffer (3840 bytes) with tios::heapalloc,
then copy the 3840 bytes at $5c00 into that buffer. Use $5c00 as the location for the second plane.
When finished with greyscale, copy the 3840 bytes in the buffer back to $5c00. I think that this will
work, assuming that TI's interrupts create a problem.

Note that this requires a modification to the SOURCE -- I don't think a general patching program will
fix this.

Right now, greyscale technically "works" but the second plane is never SHOWN. This is bearable in
programs using LCD_MEM ($4c00) as the DARK plane, as the graphics will be decent, but NOT in
programs using it as the light plane (solitaire, using grey4lib). I'll try to get grey4lib working later this
week. . .

     18 November 1999, 04:27 GMT

Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
David Ricciardi
(Web Page)

sorry im going to make this clear so i dont get into trouble. everything that i just posted above is written by scott not me i just copied it over.

     18 November 1999, 04:33 GMT


Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Riba

A quote from the message Scott forwarded to assembly-89:

">2. Along with this hardware change (to alleviate the security chip's
>prior shortcomings), there was some changes to the underlying
> hardware's means of how display pages are selected and displayed.
>(The) LCD can only start at 0x4c00, 0x5c00, 0x6c00, or
> 0x7c00.) Writes to the LCD memory are copied to a buffer internal
>(in one of the gate arrays). Consequently, selecting an alternate
> display page is not enough to load up the gate array's display
>buffer."

So, reserving buffer area may not be enough. The post doesn't mention whether or not the gate arrays buffer _all_ the possible start addresses or just the one currently selected. It does say that having data at a certain location of memory is not enough to make it seen on LCD. The data must specifically be written so that gate-array can catch it.

If the gata-array is 'single-buffer-only', doing grayscale would require updating screenbuffer by CPU, at every refresh! Though this would drain huge percentage of CPU time (if CPU even could do it at all!).

Could someone with HW2 test this? (Reserving two buffer locations, drawing different stuff to them and switching the gate-array-address)

If gate-array buffers all locations, the required modification could be made in the grayscale libraries. I don't know about all the shells but DoorsOS allocates grayscale buffers by itself and lets user to read the addressed, so it could do the relocation-allocation to get two of the fixedlocation buffers and let user to write on them.

     18 November 1999, 08:44 GMT


Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Scott Noveck  Account Info
(Web Page)

TI addressed that -- the gate array is updated when the screen is modified -- changing the address of the screen data will NOT update it, so that must be done by the CPU.

They suggest this routine:

move.l #959,d0
move.l #LCD_MEM,a0 ;could also be $4c00
\loop:
move.l (a0),d1
move.l d1,(a0)+
dbra.s d0

That's gonna cause more slowdown than is desireable, but it can be relieved by unrolling the loop a bit. Still not good. . .

For many programs, a libaray modification is sufficient - but not all programs use the libaries, and graphlib (the most popular) is not open source =(

     18 November 1999, 23:24 GMT

Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
David Phillips  Account Info
(Web Page)

Who wrote it? Xavier? I'm sure if you emailed him you could get the source. At worst, you could dissassemble it, modify the grayscale code and recompile. I don't know the structure of libraries, but if dissassembly is too much work, you could probably tack a modified routine onto the end of the install code, and patch that code to jump there.

Of course, this is not the ideal solution, but when everyone decides to used closed source libraries, that's what happens.

     19 November 1999, 03:21 GMT

Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Riba
(Web Page)

move.l #959,d0
move.l #LCD_MEM,a0 ;could also be $4c00
\loop:
move.l (a0),d1
move.l d1,(a0)+
dbra.s d0

     19 November 1999, 07:45 GMT

Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Riba

Educational cycle counting:

move.l #959,d0 (=20)
move.l #LCD_MEM,a0 (=20)
\loop:
move.l (a0),d1 (=12)
move.l d1,(a0)+ (=12)
dbra.s d0 (=10/14)

Since loop is done 960 times, total cycle count is 32684 cycles. And since LCD is refreshed normally at 85Hz and CPU operating frequency is 10MHz, CPU time used is around 28%. Unrolling the loop 16 times would reduce that to 20%. This does not include time wasted on synchronizing. Given the 20% increase in CPU speed this would seem ok. IMHO its just very ugly.

     19 November 1999, 07:59 GMT

Re: Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Niklas Brunlid  Account Info
(Web Page)

How about this?

Store registers:
lea Regs(pc),a0 ;8
movem.l a0-a7/d0-d7,(a0) ;8+8*16 = 136
lea.w LCD_MEM,a0 ;8

;Repeat 64 times:
movem.l (a0),a1-a7/d0-d7 ;12+8*15 = 132
movem.l a1-a7/d0-d7,(a0) ;8+8*15 = 128
add.w #4*15,a0 ;8+8 = 16

;Restore registers:
lea Regs(pc),a0 ;8
movem.l (a0),a0-a7/d0-d7,(a0) ;12+8*16 = 140


Regs: ds.l 16


Total cycles spent: 17964 (not counting the greyscale "pointer" stuff, but that's so small that it won't be noticed here).

In Prosit I run grayscale with auto-int 5, with the counter initially set at $f1, i.e. the interrupt will be run in sync with the LCD refresh - every 16th time the auto-int 5 counter is incremented, i.e. 10000000/(6250*16) = 10Hz. So we get ca 1800

     20 November 1999, 00:43 GMT


Re: Re: Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Riba
(Web Page)

Come on! 10MHz/(6250*16) = 100Hz... Use your Ti-89 more :-)

Theoretical total usage would then be 18%.

OTOH, this got me thinking:
If HW1 and HW2 differ only so that LCD-buffer isn't in main memory, the LCD-controller on HW1 sucks 20% of 10MHz bus.
So, CPU doing read-write cycles is faster than DMA-based LCD-controller doing just read cycles...

Either the TI-engineers who designed the LCD-controller wrong, or the memory bus has wait states.
If the memory bus has wait states, each memory access takes additional cycles, thus all calculations would be a bit wrong. Does anyone know how the memory bus is timed?

     20 November 1999, 09:27 GMT


Re: Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Niklas Brunlid  Account Info
(Web Page)

So we get ca 10*18000 = 180000 cycles spent easch second, or 1.8% of the CPU. Seems a bit low - someone please check my calculations!

     20 November 1999, 01:01 GMT


Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Niklas Brunlid  Account Info
(Web Page)

Shouldn't this work?

move.l #959,d0
move.l #LCD_MEM,a0 ;could also be $4c00
\loop:
move.l (a0),(a0)+
dbra.s d0

It would save 4 cycles per loop. OTOH, if you unroll it you would probably use movem.l instead...

     19 November 1999, 17:10 GMT


Re: Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Scott Noveck  Account Info
(Web Page)

I'm under the impression that the calc wouldn't like this somehow -- either the gate array wouldn't accept it or the 68k (or its assembler) wouldn't like copying memory from one place to itself. . .

     20 November 1999, 04:38 GMT


Re: Re: Re: Re: Re: Possible fix (was Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00)
Niklas Brunlid  Account Info
(Web Page)

I just read the PRM to get this... if I read it correctly, the move mnemonic can code (a0),(a0)+ as $20d0.

     20 November 1999, 13:15 GMT

additional info
Scott Noveck  Account Info
(Web Page)

I didn't expect this to be front-page news, but as long as it is I might as well add the details.

I inquired about the changes to someone at TI, who managed to get me some information from the calc's engineers/programmers. The changes were explained on a very technical level, but it does explain the problem.

*** THE TEXT OF THE MESSAGE FROM TI (complete with technical details) CAN BE FOUND THROUGH THE "WEB PAGE" LINK AT THE TOP OF THIS POST

To explain it in plain English:

1.) The "hardware/firmware change" was meant to fix a slight security issue. The old 89s have a very, very slight chance that the ROM may be corrupted by a program, although it's so little that I wouldn't be concerned. This is what allows Archive Utility (a program which allows you to keep your archive memory when the calc is reset) to work, and for most uses the old 89s are probably better (in terms of compatibility with programs).

2.) Normally, the "screen" - which is represented in memory - is located at $4c00. An ASM program can change this address, and the screen will display the data at the new address. Greyscale is created by creating two planes - essentially two screens - and changing the location that the calculator reads the screen data from very quickly.

This is where the problems come in -- the old 89s can read from any address divisible by 8. The new 89s have a change in the way the LCD works, only allowing the screen to be read from 4 specific addresses. When the greyscale routine tells the calculator to display the screen from a certain area in memory which is not allowed on the new 89s, the change is ignored. One of the planes is never displayed, so greyscale fails.

I want to stress that this LCD change makes calculations and access to the memory FASTER. They do use the same processor at the same speed, it's the LCD change that makes the difference.

ROM version 1.05 was created to fix a few bugs and allow compatibility with the new 89s. Version 1.00 will not run on a newer 89 because it isn't compatible with the hardware changes. There are some other differences between the two ROM versions, and TI plans to document all these locations in the next ROM version (the SDK).

4.) Several I/O ports need to be set properly. This is why there may be some contrast problems when using ROM v1.05 with VTI, and Rusty is working on it =)

And lastly, TI follows up with a promotion for the upcoming SDK.

This information should cover just about all the relevant changes, so there should be some working greyscale programs on the new hardware version soon. Unfortunately, every program requires the source to be modified and cannot simply be patched.

     18 November 1999, 05:09 GMT


Re: additional info
Blue_Z  Account Info
(Web Page)

OK, thanks a lot for these informations ! However, I still have two questions :

_ how do you change the LCD adress ? Is it done the same way as before, i.e by dividing one of the four possible adress by 8, then writing it to a port ?

_ Is there a way for a program to test if HW2 is present ? (this could avoid allocating more memory than needed when running on the old hardware)

     18 November 1999, 14:36 GMT


Re: Re: additional info
Scott Noveck  Account Info
(Web Page)

1.) Yes, should still be writing the address divided by 4 to the same port

2.) I don't know -- I'll ask. I don't see that changing much, since the code for testing that will take up abotu as much space as the changes will =)

     18 November 1999, 23:32 GMT

Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
DarkForce Account Info

I am just wondering where can I download ROM for version 2.00
TI just wont release it on its web site.

     18 November 1999, 09:12 GMT


Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
Niklas Brunlid  Account Info
(Web Page)

ROM 1.05 is compatible (in fact it's the only one that is) with *hardware* version 2.0.

*ROM* 2.00 hasn't been released yet. Rumours say December 1st, or at least December.

     18 November 1999, 09:58 GMT


Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
David Ricciardi
(Web Page)

well i just got a reply from ti and i was told december 21st is the expected release date. odd thing is the update is allready finished. they are just holding out on us. all the devolpers have ams 2.00 but its serial locked so dont try to get it from one of them its useless

     18 November 1999, 18:14 GMT

Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
Scott Noveck  Account Info
(Web Page)

. . . except that I can CHANGE the serial number on my HWr1 89 -- which is one of the major reasons that HWr2 came out =)

     18 November 1999, 23:33 GMT

Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
yosweetlady  Account Info

Ti told me that the release date was set for late november. I'm gonna be pissed if I have to wait another month. The security addition to hardware v.2 was a good idea, archive utility v.3 messed my rom up bad. I was forced to upgrade to rom 1.05, and there's no way to go back. I sure hope I'll be able to install rom v.2.00 when it's out.

     19 November 1999, 02:02 GMT

Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
S67  Account Info
(Web Page)

December 21st at 23:59:59 ams 2.00 is going to be releases, if they want to honor their "fall" release date. the same thing as:
I am going to release a cool 89 game in the 21st century. (probably true, also)

     19 November 1999, 05:17 GMT


Re: Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
Bryan Rabeler  Account Info
(Web Page)

What timezone? :)

--
Bryan Rabeler
"The power to, as you say "romp on over you", comes from the fact that a majority of the staff says so." - Magnus Hagander, 22 November 1998

     19 November 1999, 07:56 GMT


Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
LoneWolf

I just went to ti's website and they said that there would only be 705k in the flash and 188k in the ram available to the user. Correct me if I'm wrong, but wasn't the original amount of free ram, 850k in the flash and 188k in the ram?

     20 November 1999, 18:52 GMT


Re: Re: Re: Re: Re: Scott Noveck Addresses Concerns With TI-89 Hardware v2.00
h4X0r  Account Info
(Web Page)

It was 890k before. It has be reworded to split up the archive/flash and ram. However if you add the two numbers (720+170=890) you get 890k still. So the website is correct.

     21 November 1999, 00:22 GMT

1  2  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2011, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer