This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - willrandship
Pages: 1 ... 50 51 [52] 53 54 ... 208
766
« on: November 10, 2012, 02:43:13 am »
Hmmmmm.....
I'm assuming you have a method of installing packages from the AUR. If so, try installing google-chrome. That will be the official build, so it has the flash plugin, and it might handle webGL a bit differently. Worth a try, at least.
767
« on: November 10, 2012, 02:32:04 am »
easiest way:
glxinfo | grep rendering
it should say:
Direct Rendering: Yes
which means you have 3D acceleration. If it says no, you don't, and it's probably a driver issue.
It might get some other stuff too, but only the Direct Rendering line matters.
768
« on: November 10, 2012, 02:29:21 am »
Does your area use power lines like we do here, or is it mostly underground? If it's all in towers, then that was REALLY fast getting them all back up. At my place, a power pole got struck by lightning and went down, and we were out of power for 2 weeks.
Glad to hear it went so well for you!
769
« on: November 10, 2012, 02:07:59 am »
Well, I wouldn't be surprised to see the old 32MB RAM chips from the old nspire in it, or maybe a bit lower. I don't think the 84+ emu could run in RAM amounts too much lower, though.
770
« on: November 10, 2012, 01:08:49 am »
There's pretty much no chance of the ez80, since AFAICT Texas Instruments never licensed it from zilog. In fact, it doesn't look like anyone did.
It would be really cool if we could get the nspire CAS OS running on this thing. The keys would be wrong, but the CAS touchpad OS never complained about using an 84+ keypad.
771
« on: November 09, 2012, 11:50:54 pm »
Do you have 3D graphics acceleration?
772
« on: November 09, 2012, 11:41:40 pm »
That would work, especially since pieces never have to come back from the dead.
773
« on: November 09, 2012, 11:38:10 pm »
Have no fear, DJ. Double buffering has nothing to do with split screens.
LCD displays require dedicated RAM to store their current image. This is their first buffer. Single-buffered drawing writes directly to it. However, since this involves dealing with the display controller, it's slower than normal RAM access, and it results in screen flickering.
In Axe, and most Assembly programs, we use a 'double buffer' which is simply a copy of what will be displayed stored in RAM. This is copied over once all drawing actions on it are finished, resulting in only one slow copy, rather than one for every action.
TIOS, however, is even worse: It runs a double buffer setup, but it copies it to the single buffer every time it does a drawing action. Since these drawing actions are very small (well, except bitmap) the resulting performance is as bad as a single-buffer solution in every way, but also takes up the extra RAM of a double buffer solution.
The best place to see this in action is in TI's apps, like the periodic table. You can see each line being drawn, with significant delay. A double-buffered display would draw it in RAM, then copy the picture over to the display RAM, resulting in a far smoother application.
And yes, it would be terrible if they make no improvements and just use the old emulator plus some color.
774
« on: November 09, 2012, 08:36:55 pm »
I was referring to the problem with speed. double-buffered graphing would be significantly faster than current graphing. Keep in mind that it refreshes the screen for every pixel the screen is wide. (it might be twice, depending on if the line-drawing mode also draws the pixels) This is because of how TI's bcalls for drawing are set up:
Draw to the buffer
Render to the screen
Return from the call.
It's not an issue of random updates. It's an issue of performance.
775
« on: November 09, 2012, 08:28:22 pm »
I'm thinking of people who have to use them for math, though.
776
« on: November 09, 2012, 08:27:09 pm »
I hope they make it a double-buffered display for BASIC and graphing.
777
« on: November 09, 2012, 08:15:43 pm »
Well, we'll see. Recoding the GUI on top of the nucleus RTOS wouldn't be that much work, though, compared to the work of recoding an OS from scratch.
778
« on: November 09, 2012, 07:35:44 pm »
Pawn promotion wouldn't be too difficult, if you've got an array of pieces. If a piece moves to the opposite edge, then if it's a pawn, it becomes a queen. That doesn't really change with your storage method.
779
« on: November 09, 2012, 07:12:37 pm »
I don't see why so many people think it will be z80 based. That option just seems very unlikely, considering how TI has significantly better options. Why on earth would you make a graphics chip that can interface with a 16-bit processor, but can run a true color, 320x240 display, when you can replace both with an ARM processor that you just happen to already manufacture, not to mention having the OS backend all set up.
They don't care about assembly compatibility. At all.
780
« on: November 09, 2012, 07:08:26 pm »
it needs one more attribute: Alive or dead. Way easier than having a dynamically resizing list, and you just check that first before moving.
Pages: 1 ... 50 51 [52] 53 54 ... 208
|
Show Posts