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

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. . .

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.

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.

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 =(

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.

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

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.

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

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?

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!

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...

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. . .

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

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.

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)

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 =)

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

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.

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

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

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.

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)

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

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?

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.