Slow graphic text scrolling...

Okay,

I know my system is not the basic “requirements” for RtP,
but even though most boards out there are maximum some sort
of AMD 486 100 MHz processor.

With a P133 and 32 MB, if I open an PTerm full screen 1024x768,
and do a ’ ls ’ command on a huge directory once the screen is filled,
it takes about a second per line scroll, this kind of fuzzy lag effects
is absolutely non-sense, driving me crazy.

I dunno, but if you would have to count up to 60 to just print
some content of a directory, I can tell you that
you will turn completely insane…

Normally, graphics scroll for a full screen should happen in a blink of
line,
30+ FPS, not 0.0005 FPS !

I’m able to play Quake I on Win98 on that machine
at low/med detail so come on !

It never happened to me even with Windows98 on a cheap 486
or with linux or QNX 4.25…

That’s really bad…

Fred.

With a P133 and 32 MB, if I open an PTerm full screen 1024x768,
and do a ’ ls ’ command on a huge directory once the screen is filled,
it takes about a second per line scroll, this kind of fuzzy lag effects
is absolutely non-sense, driving me crazy.

I noticed the same thing, and I have a 500MHZ PIII – but the real
interesting thing is that if you bring another window in the foreground
(while “ls” is printing) the output starts to go real fast!!! Quite weird…

Vlad

Fred (fprog@users.sourceforge.net) wrote:
: Okay,

: I know my system is not the basic “requirements” for RtP,
: but even though most boards out there are maximum some sort
: of AMD 486 100 MHz processor.

: With a P133 and 32 MB, if I open an PTerm full screen 1024x768,
: and do a ’ ls ’ command on a huge directory once the screen is filled,
: it takes about a second per line scroll, this kind of fuzzy lag effects
: is absolutely non-sense, driving me crazy.

Sounds like you’re running an unaccelerated graphics driver. I guess
we’ll have to make pterm smarter somehow.

: I dunno, but if you would have to count up to 60 to just print
: some content of a directory, I can tell you that
: you will turn completely insane…

Hint: switching consoles and back again will let the pterm “catch up”.

: Normally, graphics scroll for a full screen should happen in a blink of
: line,
: 30+ FPS, not 0.0005 FPS !

: I’m able to play Quake I on Win98 on that machine
: at low/med detail so come on !

: It never happened to me even with Windows98 on a cheap 486
: or with linux or QNX 4.25…

What kind of video card do you have?

: That’s really bad…

I’m putting in a bug report about this.

: Okay,

: I know my system is not the basic “requirements” for RtP,
: but even though most boards out there are maximum some sort
: of AMD 486 100 MHz processor.

: With a P133 and 32 MB, if I open an PTerm full screen 1024x768,
: and do a ’ ls ’ command on a huge directory once the screen is filled,
: it takes about a second per line scroll, this kind of fuzzy lag effects
: is absolutely non-sense, driving me crazy.

Sounds like you’re running an unaccelerated graphics driver. I guess
we’ll have to make pterm smarter somehow.

: I dunno, but if you would have to count up to 60 to just print
: some content of a directory, I can tell you that
: you will turn completely insane…

Hint: switching consoles and back again will let the pterm “catch up”.

: Normally, graphics scroll for a full screen should happen in a blink of
: line,
: 30+ FPS, not 0.0005 FPS !

: I’m able to play Quake I on Win98 on that machine
: at low/med detail so come on !

: It never happened to me even with Windows98 on a cheap 486
: or with linux or QNX 4.25…

What kind of video card do you have?

: That’s really bad…

I’m putting in a bug report about this.

I have no clue, (it’s school stuff)
I have to check, (unscrewing the case)…

I’m pretty sure it’s some sort of ATI card…

but why it does that,
it never happened on Photon for QNX 4.25 !

Also, when you quit, it doesn’t switch to Text mode,
you have to do it twice, that’s kind of stupid.

Ph Login → Ph → Ph Login → Text Mode → Login → Console mode.

Why not ?

Ph Login → Ph → Exit to Text Mode → Console Mode
???

Fred.

Fred wrote in message <8rh864$i4l$1@inn.qnx.com>…

: Okay,

: I know my system is not the basic “requirements” for RtP,
: but even though most boards out there are maximum some sort
: of AMD 486 100 MHz processor.

: With a P133 and 32 MB, if I open an PTerm full screen 1024x768,
: and do a ’ ls ’ command on a huge directory once the screen is filled,
: it takes about a second per line scroll, this kind of fuzzy lag effects
: is absolutely non-sense, driving me crazy.

Sounds like you’re running an unaccelerated graphics driver. I guess
we’ll have to make pterm smarter somehow.

: I dunno, but if you would have to count up to 60 to just print
: some content of a directory, I can tell you that
: you will turn completely insane…

Hint: switching consoles and back again will let the pterm “catch up”.

: Normally, graphics scroll for a full screen should happen in a blink of
: line,
: 30+ FPS, not 0.0005 FPS !

: I’m able to play Quake I on Win98 on that machine
: at low/med detail so come on !

: It never happened to me even with Windows98 on a cheap 486
: or with linux or QNX 4.25…

What kind of video card do you have?

: That’s really bad…

I’m putting in a bug report about this.


I have no clue, (it’s school stuff)
I have to check, (unscrewing the case)…

I’m pretty sure it’s some sort of ATI card…

but why it does that,
it never happened on Photon for QNX 4.25 !

Also, when you quit, it doesn’t switch to Text mode,
you have to do it twice, that’s kind of stupid.

Ph Login → Ph → Ph Login → Text Mode → Login → Console mode.

Why not ?

Ph Login → Ph → Exit to Text Mode → Console Mode
???

Fred.

Another thing, we are hardely discussing on this Photon Slow shit problem,
as an VERY IMPORTANT argument to NOT SWITCH to RtP and keep QNX 4.25
in the lab. Since the lab demo, must be done on an Embed Board (AMD 486 100
MHz).
We must make sure that the little animation that controls the target app,
will run without any problem on a cheap VGA 16 color video card.

They use some GUI widgets, to select what “should” happen on the target app,
so if it lags like hell this is not feasible and if it’s not feasible, then
we are in trouble.
Developping on RtP when the target is QNX 4.25 doesn’t make sense really,
since the API is totally different !

Also, the machine is not 32 MB,
it’s Pentium 133, 64 MB, 8 GB Seagate !

I will check the Video Card,
but it worked find with the QNX 4.25 driver.

Is there a way I can tell you the driver used in QNX 4.25 inside Photon ?

Fred.

Fred <fprog@users.sourceforge.net> wrote:

: Is there a way I can tell you the driver used in QNX 4.25 inside Photon ?

Post pci -v output.

: Fred.

David Donohoe wrote in message <8ri26c$idk$1@nntp.qnx.com>…

Fred <> fprog@users.sourceforge.net> > wrote:

snip

: Is there a way I can tell you the driver used in QNX 4.25 inside Photon ?

Post pci -v output.

: Fred.

Windows 98

Tseng Labs ET6000/ET6100 PCI
Manufacturer: Tseng Labs
Chip Type: ET6000 Rev A
DAC type: Internal 135 MHz
Memory 2.25 MB

On the card:

STB System inc. 1996(c)
LightSpeed 128 1.2 Rev A
Mexico

2 x MDRAM
MD909
SJ-5-100
MoSys

210-0213-001
EK SUSA 6000 PCI
1x0-0422-004
18 27/96
5T1

crttrap on QNX 4.25

vesabios.ms -i0x4103;Pg.svga -HNqnx/crt -g800x600x8 -A0xE0000000,0x240000 -W
B800 -WV240000;#800,600,8,100,1DV,svga - SVGA 256 color

crttrap on QNX RtP

io-graphics -g1024x768x24 -dldevg-vesabios.so -I0 -d0x100c,0x3208;#1024,768,
24,100,0D,vesa - unaccelerated driver for VESA 2.00 compliant adapters


pci -v on QNX RtP

PCI version = 2.10

Class = Bridge (Host/PCI)
Vendor ID = 8086h, Intel Corporation
Device ID = 1250h, 82439HX System Controller (TXC)
PCI index = 0h
Class Codes = 060000h
Revision ID = 3h
Bus number = 0
Device number = 0
Function num = 0
Status Reg = 2200h
Command Reg = 6h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 0h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = NC
Interrupt line = 0

Class = Bridge (PCI/ISA)
Vendor ID = 8086h, Intel Corporation
Device ID = 7000h, 82371SB PIIX3 PCI-to-ISA Bridge (Triton II)
PCI index = 0h
Class Codes = 060100h
Revision ID = 1h
Bus number = 0
Device number = 7
Function num = 0
Status Reg = 280h
Command Reg = fh
Header type = 0h Multi-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = NC
Interrupt line = 0

Class = Mass Storage (IDE)
Vendor ID = 8086h, Intel Corporation
Device ID = 7010h, 82371SB PIIX3 IDE Interface (Triton II)
PCI index = 0h
Class Codes = 010180h
Revision ID = 0h
Bus number = 0
Device number = 7
Function num = 1
Status Reg = 280h
Command Reg = 5h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 0h
IO Address = f000h length 16 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = NC
Interrupt line = 0

Class = Network (Ethernet)
Vendor ID = 10b7h, 3Com Corporation
Device ID = 9050h, 3C905-TX Fast Etherlink XL PCI 10/100
PCI index = 0h
Class Codes = 020000h
Revision ID = 0h
Bus number = 0
Device number = 17
Function num = 0
Status Reg = 200h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 0h
IO Address = 6000h length 64 enabled
Expansion ROM = ffef0000h length 65536 disabled
Max Lat = 8ns
Min Gnt = 3ns
PCI Int Pin = INT A
Interrupt line = 11

Class = Display (VGA)
Vendor ID = 100ch, Tseng Labs
Device ID = 3208h, ET6000 Graphics/Multimedia Engine
PCI index = 0h
Class Codes = 030000h
Revision ID = 14h
Bus number = 0
Device number = 19
Function num = 0
Status Reg = 400h
Command Reg = 3h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
Mem Address = e0000000h 32bit length 16777216 enabled
IO Address = 6100h length 256 enabled
Expansion ROM = fe000000h length 16777216 disabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = no connection



That’s about all I can say about this Video Card !

It’s a P133, 64 MB, 8 GB.
The video card is a Tseng Labs 2 MB ET6000 Rev A


Fred.

Fred <fprog@users.sourceforge.net> wrote:

David Donohoe wrote in message <8ri26c$idk$> 1@nntp.qnx.com> >…
Fred <> fprog@users.sourceforge.net> > wrote:

snip

: Is there a way I can tell you the driver used in QNX 4.25 inside Photon ?

Post pci -v output.

: Fred.



Windows 98

Tseng Labs ET6000/ET6100 PCI
Manufacturer: Tseng Labs
Chip Type: ET6000 Rev A
DAC type: Internal 135 MHz
Memory 2.25 MB

On the card:

STB System inc. 1996(c)
LightSpeed 128 1.2 Rev A
Mexico

Well, it looks like you did not have an accelerated driver under
QNX4 either. I believe there was a buffering trick used by pterm
to prevent the slow behaviour you were seeing, but something changed
which caused it to stop working.

Perhaps Wojtek can comment…

David Donohoe <ddonohoe@qnx.com> wrote:

Well, it looks like you did not have an accelerated driver under
QNX4 either. I believe there was a buffering trick used by pterm
to prevent the slow behaviour you were seeing, but something changed
which caused it to stop working.

Perhaps Wojtek can comment…

Yes, it seems that the pty driver behaves differently under Neutrino:
under QNX4, a call to read() on the master end of the pty returns all
the data the pty has in the buffer. Even if that happens to be more
than one line, pterm will only scroll once.

The Neutrino driver never gives you more than one line of input. It’s
actually even worse than that: pterm needs to call read() twice for
each line. I’ll have to either find out how to convince the driver to
give me more data or call read() more than once before giving the data
to the terminal engine.


Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.

Wojtek Lerch wrote in message <8rktqd$csv$1@nntp.qnx.com>…

David Donohoe <> ddonohoe@qnx.com> > wrote:
Well, it looks like you did not have an accelerated driver under
QNX4 either. I believe there was a buffering trick used by pterm
to prevent the slow behaviour you were seeing, but something changed
which caused it to stop working.

Well, the Arcom ELAN-104 kit is surely not accelerated neither,
but this is very critical, if we can’t have something that “make sense”,
it must be fixed, some people with Pentium III doesn’t have accelerated
driver
neither and might tell everyone that QNX RtP “sucks” because it’s slow,
when it fact it’s just the graphic driver…

Arcom Elan 104 description:
http://www.arcom.co.uk/products/icp/dev_kits/QNX/elan_dk.htm

I really don’t want to show 200 computer engineering students
“how bad is the graphic driver…”, if you know what I mean…
since that would probably won’t make help you to sell
commercial copies for embedded applications,
when they go out in the industry, right ?

Anyway, I suggest that you fix the problem as soon as possible,
since that doesn’t show up what QNX RtP should really be…

Sincerly yours,

Fred.

Perhaps Wojtek can comment…

Yes, it seems that the pty driver behaves differently under Neutrino:
under QNX4, a call to read() on the master end of the pty returns all
the data the pty has in the buffer. Even if that happens to be more
than one line, pterm will only scroll once.

The Neutrino driver never gives you more than one line of input. It’s
actually even worse than that: pterm needs to call read() twice for
each line. I’ll have to either find out how to convince the driver to
give me more data or call read() more than once before giving the data
to the terminal engine.


Wojtek Lerch (> wojtek@qnx.com> ) QNX Software Systems Ltd.

Fred <fprog@users.sourceforge.net> wrote:

crttrap on QNX 4.25

vesabios.ms -i0x4103;Pg.svga -HNqnx/crt -g800x600x8 -A0xE0000000,0x240000 -W
B800 -WV240000;#800,600,8,100,1DV,svga - SVGA 256 color

crttrap on QNX RtP

io-graphics -g1024x768x24 -dldevg-vesabios.so -I0 -d0x100c,0x3208;#1024,768,
24,100,0D,vesa - unaccelerated driver for VESA 2.00 compliant adapters

Before you freak out too much about the vast speed difference between QNX4
and RTP, why don’t you run them both at the same resolution and color depth?

On QNX4, you were running at 800x600 in eight bit color. You are running
RTP at 1024x768 in 24 bit color. You’re stacking the deck against RTP
by using a screen that requires five times as much horsepower to drive it.

crttrap on QNX 4.25

vesabios.ms -i0x4103;Pg.svga -HNqnx/crt -g800x600x8 -A0xE0000000,0x240000 -W
B800 -WV240000;#800,600,8,100,1DV,svga - SVGA 256 color

crttrap on QNX RtP

io-graphics -g1024x768x24 -dldevg-vesabios.so -I0 -d0x100c,0x3208;#1024,768,
24,100,0D,vesa - unaccelerated driver for VESA 2.00 compliant adapters


Before you freak out too much about the vast speed difference between QNX4
and RTP, why don’t you run them both at the same resolution and color
depth?

On QNX4, you were running at 800x600 in eight bit color. You are running
RTP at 1024x768 in 24 bit color. You’re stacking the deck against RTP
by using a screen that requires five times as much horsepower to drive it.

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

I will try 800x600x256 tomorrow.

Fred.

Also, I tried to play Tetris or whatever the name of that game,
in full and non-full screen mode.

At full screen, it hangs, I couldn’t do anything,
it started to drop the block VERY VERY SLOWLY,
then STOPPED, for few minutes.

I tried ALT-CTRL-DELETE, ESC, CTRL-C, CTRL-BREAK,
whatever the key. Nothing works, only the RESET button.

I did this three times and the three times, the same problem happened.

If I play the game in non-full screen it works a bit, but the mouse is
getting slow
like hell, response time 3 minutes later with chaotic effects.

It follow the edges of the screen or was bursting movement weirdly.

Othello worked fine perhaps in window mode.
Couldn’t win anything higher than Harder level,
Genius is unmakeable yet. =)

For Video poker, the cards looks ugly (black/white) compare to QNX4 version.

I also run 1024x768x256color on Node 4, same type of computer without any
problem
on QNX 4.25, I didn’t install RtP on it yet.

I will return to you soon, with the problem.

Sincerly yours,
Fred.

crttrap on QNX 4.25

vesabios.ms -i0x4103;Pg.svga -HNqnx/crt -g800x600x8 -A0xE0000000,0x240000 -
W
B800 -WV240000;#800,600,8,100,1DV,svga - SVGA 256 color

crttrap on QNX RtP

io-graphics -g1024x768x24 -dldevg-vesabios.so -I0 -d0x100c,0x3208;#1024,768
,
24,100,0D,vesa - unaccelerated driver for VESA 2.00 compliant adapters


Before you freak out too much about the vast speed difference between QNX4
and RTP, why don’t you run them both at the same resolution and color
depth?

On QNX4, you were running at 800x600 in eight bit color. You are running
RTP at 1024x768 in 24 bit color. You’re stacking the deck against RTP
by using a screen that requires five times as much horsepower to drive it.

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

I will try 800x600x256 tomorrow.

Fred.

Fred <fprog@users.sourceforge.net> wrote:

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

It must be related to the fact that you’re using an accellerated driver
under Windows, and under RTP, you have to use a generic driver (since this
card is not supported on RTP or QNX4).

We might as well just throw in the towel right now anyway. If this
is the same card you described in an earlier post as having 2.25 MB
of video RAM, I don’t think we could ever make it run at 1280x1024 in 24 bit
color depth. All of our drivers would require that the card have at least
3.84 MB of video RAM to do that. That Windows stuff sure is clever.

It’s a shame that TSeng went out of business. With RAM compression technology
like that, I’m surprised that you can’t buy a TSeng card anymore.

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

On Windows 98B:

640x480x24/16/8
800x600x24/16/8
1024x768x16/8
1152x864x16/8
1280x1024x8

At any of these mode, I can play Quake I Full screen,
Doom II, Duke Nukem 3D, Warcraft II, without any problem at all.

The card run smooth in QNX4 using
“svga” driver, I can’t use correctly
“svgadc” driver in QNX that’s why I’m stuck at 256 colors on QNX4,
the svgadc driver turns every color odd, like gray becomes green,
black becomes purple, yellow becomes red, etc.

Perhaps, 1280x1024x8 under QNX4, is pretty smooth
and works very well. Without any lag, even with Moire,
Othello, Poker, signal and the other Moire program all at once,
plus a shell filling the screen and scrolling without any
display problem. It doesn’t lag at all.

Any of these under RtP would create a mess,
slow laggy inthinkable slow refresh rate and weird
graphic bug effects.

All I want is a generic driver that works fine at least
in 800x600x8, 800x600x16, 1024x768x8, 1024x768x16.

Fred.

It must be related to the fact that you’re using an accellerated driver
under Windows, and under RTP, you have to use a generic driver (since this
card is not supported on RTP or QNX4).

We might as well just throw in the towel right now anyway. If this
is the same card you described in an earlier post as having 2.25 MB
of video RAM, I don’t think we could ever make it run at 1280x1024 in 24
bit
color depth. All of our drivers would require that the card have at least
3.84 MB of video RAM to do that. That Windows stuff sure is clever.

It’s a shame that TSeng went out of business. With RAM compression
technology
like that, I’m surprised that you can’t buy a TSeng card anymore.

hehe, no there isn’t any compression =[,
but still 1280x1024 in 256 color is pretty nice
when you need workspace in PhAB, for instance.

For pterm, the other guy told me that it doesn’t “buffer” the screen
and this is why the scroll is laggy compare to QNX4,
is there a way to fix this too ?

Fred.

Fred <fprog@users.sourceforge.net> wrote:

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

On Windows 98B:

640x480x24/16/8
800x600x24/16/8
1024x768x16/8
1152x864x16/8
1280x1024x8

I’m pretty sure in Windows, there is a driver specific to the TSeng
card.

The card run smooth in QNX4 using
“svga” driver, I can’t use correctly
“svgadc” driver in QNX that’s why I’m stuck at 256 colors on QNX4,
the svgadc driver turns every color odd, like gray becomes green,
black becomes purple, yellow becomes red, etc.

Perhaps, 1280x1024x8 under QNX4, is pretty smooth
and works very well. Without any lag, even with Moire,
Othello, Poker, signal and the other Moire program all at once,
plus a shell filling the screen and scrolling without any
display problem. It doesn’t lag at all.

Any of these under RtP would create a mess,
slow laggy inthinkable slow refresh rate and weird
graphic bug effects.

Photon 2.0 drivers have new capabilities to take advantage
of features common to most modern video cards, and the
new applications in Photon 2.0 make use of those features.

Poker is a good example. The new one uses offscreen memory,
alpha blending, and offscreen/onscreen blitting with chroma
keying. If your card doesn’t have those features, and we
have to simulate them with the CPU, you’re in trouble.

So you are comparatively worse off now if you don’t have
an accellerated card than if you didn’t have one under Photon
1.1x. that is why the hardware requirements for RTP include a supported
accellerated card.

Some of the issues you’re raising are valid, but you’re also
making invalid comparisons such as between 800x600x8 and 1024x768x8
and between a generic Photon 2.0 driver on a new platform and an
accellerated Windows driver on a mature platform.

All I want is a generic driver that works fine at least
in 800x600x8, 800x600x16, 1024x768x8, 1024x768x16.

Fred.

hehe, no there isn’t any compression =[,
but still 1280x1024 in 256 color is pretty nice
when you need workspace in PhAB, for instance.

You weren’t clear in your post that you did 1280 in only eight bit.

For pterm, the other guy told me that it doesn’t “buffer” the screen
and this is why the scroll is laggy compare to QNX4,
is there a way to fix this too ?

It’s being looked at as we speak.

Well, on Windows 98 B, same machine, same card, different partition,
I run it at that resolution and even higher resolution 1280x1024,
WITHOUT ANY PROBLEM AT ALL !

On Windows 98B:

640x480x24/16/8
800x600x24/16/8
1024x768x16/8
1152x864x16/8
1280x1024x8

I’m pretty sure in Windows, there is a driver specific to the TSeng
card.

True, it’s part of Windows automatic detection set of drivers.

The card run smooth in QNX4 using
“svga” driver, I can’t use correctly
“svgadc” driver in QNX that’s why I’m stuck at 256 colors on QNX4,
the svgadc driver turns every color odd, like gray becomes green,
black becomes purple, yellow becomes red, etc.

Perhaps, 1280x1024x8 under QNX4, is pretty smooth
and works very well. Without any lag, even with Moire,
Othello, Poker, signal and the other Moire program all at once,
plus a shell filling the screen and scrolling without any
display problem. It doesn’t lag at all.

Any of these under RtP would create a mess,
slow laggy inthinkable slow refresh rate and weird
graphic bug effects.

Photon 2.0 drivers have new capabilities to take advantage
of features common to most modern video cards, and the
new applications in Photon 2.0 make use of those features.

Poker is a good example. The new one uses offscreen memory,
alpha blending, and offscreen/onscreen blitting with chroma
keying. If your card doesn’t have those features, and we
have to simulate them with the CPU, you’re in trouble.

That sounds cool, but offset screen can be simulated using RAM, no ?

So you are comparatively worse off now if you don’t have
an accellerated card than if you didn’t have one under Photon
1.1x. that is why the hardware requirements for RTP include a supported
accellerated card.

Worst, is a good word to describe the situation…
Turtle speed stuck in the some blueberry jam would be another… =]

Some of the issues you’re raising are valid, but you’re also
making invalid comparisons such as between 800x600x8 and 1024x768x8

Well 480 KB and 786 KB out of 2.25 MB is not a big deal,
there is still space for off-screen Video RAM buffering…

1.31 MB for 1280x1024x8, which about 85% off-screen buffering space needed.
2.25/2.62 x 100%, which means you can buffer some part of the screen…

and between a generic Photon 2.0 driver on a new platform and an
accellerated Windows driver on a mature platform.

I’m not necessarly asking for Tseng driver, unless that’s the only way to
go,
but the generic driver should work just fine, like it is working fine on
QNX4, no ?

How much virtual screen space do you need ?!

I don’t plan to play Quake 3, on this machine, but normal programs that
comes with it,
and the program I will translate with all the animation should works fine on
it also.

How can you explain that 1280x1024x8 on QNX4/Photon 1.1x,
I can have many intensive flicker-free animation going on, many moire,
poker, othello and a pterm without any problem.

And a single Tetris game on QNXRtP,
get my system running on his knees praying for help ?!

All I want is a generic driver that works fine at least
in 800x600x8, 800x600x16, 1024x768x8, 1024x768x16.

Fred.

hehe, no there isn’t any compression =[,
but still 1280x1024 in 256 color is pretty nice
when you need workspace in PhAB, for instance.

You weren’t clear in your post that you did 1280 in only eight bit.

Yeah, I figure that out, sorry… =]

For pterm, the other guy told me that it doesn’t “buffer” the screen
and this is why the scroll is laggy compare to QNX4,
is there a way to fix this too ?

It’s being looked at as we speak.

Thanks to work on the problem,
it’s very very appreciated.

Sincerly yours,
Fred.

Fred <fprog@users.sourceforge.net> wrote:

That sounds cool, but offset screen can be simulated using RAM, no ?

Not really. It’s not the offscreen memory alone that’s useful, but
the ability to have the graphics card move stuff around in it without
using the CPU.

If you can’t do that, you’ve actually made things worse for the CPU.

Well 480 KB and 786 KB out of 2.25 MB is not a big deal,
there is still space for off-screen Video RAM buffering…

1.31 MB for 1280x1024x8, which about 85% off-screen buffering space needed.
2.25/2.62 x 100%, which means you can buffer some part of the screen…

Unless you can use the graphics accellerator, offscreen video RAM is
actually slower than just using system RAM.

I’m not necessarly asking for Tseng driver, unless that’s the only way to
go,
but the generic driver should work just fine, like it is working fine on
QNX4, no ?

Yes, but you’re asking it to do far more under RTP than under QNX 4.

How much virtual screen space do you need ?!

It’s not the space, but the ability to mopve stuff around with the blit
engine and not have the CPU and bus tied up doing it that is the benefit.

How can you explain that 1280x1024x8 on QNX4/Photon 1.1x,
I can have many intensive flicker-free animation going on, many moire,
poker, othello and a pterm without any problem.

How can you look at the Photon 1.1x version and the Photon 2.0 version
and not see that there is a big difference in the look of the two?

And a single Tetris game on QNXRtP,
get my system running on his knees praying for help ?!

Yes. I assume you mean PhColumns, which is very, very dependant on the
new features.

Fred <fprog@users.sourceforge.net> wrote:


And a single Tetris game on QNXRtP,
get my system running on his knees praying for help ?!

Ok, I’m going to jump in here…I wrote Columns, and at the time it was written
there wasn’t a “generic” driver for Photon 2, and it’s design is assuming that
the video driver can service it’s draw requirements faster than it can issue it (2D
video accelerator required, which is a requirement of the RtP). On on unaccellerated
driver, Columns can get way ahead of the
driver, which is running at priority 12. So the driver gets overloaded with draw commands so
will only be in a blocked state for a short period of time, so most other priority 10 apps
are being starved, and Columns timer is still kicking causing it to queue up more operations.
This would have happened in photon 1.14, (run rebound under ph 1.14 at prio 11 at full speed
and your system will come to a standstill…it’s not quite the same case, but the root of
the issue is the same).

I am aware of this, and will be changing Columns to behave better when the driver can’t keep up
when I get some spare cycles.

Dave Rempel

I try also RtP on a P200MMX with a rage driver, dunno what’s the graphic
card, with 32 MB.
Instead of P133 with Tseng, generic driver, 64 MB.

On P200MMX, columns was playable…
the screen didn’t screw up, neither the mouse.

I didn’t try the pterm, but I assume it was okay at 1024x768x24 bit.

colums ran out of memory for partial column (window mode),
which is not the case on the P133.

Fred.

pete@qnx.com wrote in message <8s7nf6$4n5$1@nntp.qnx.com>…

Fred <> fprog@users.sourceforge.net> > wrote:

SNIP

That sounds cool, but offset screen can be simulated using RAM, no ?

Not really. It’s not the offscreen memory alone that’s useful, but
the ability to have the graphics card move stuff around in it without
using the CPU.

If you can’t do that, you’ve actually made things worse for the CPU.

Well 480 KB and 786 KB out of 2.25 MB is not a big deal,
there is still space for off-screen Video RAM buffering…

1.31 MB for 1280x1024x8, which about 85% off-screen buffering space
needed.
2.25/2.62 x 100%, which means you can buffer some part of the screen…

Unless you can use the graphics accellerator, offscreen video RAM is
actually slower than just using system RAM.

I’m not necessarly asking for Tseng driver, unless that’s the only way to
go,
but the generic driver should work just fine, like it is working fine on
QNX4, no ?

Yes, but you’re asking it to do far more under RTP than under QNX 4.

How much virtual screen space do you need ?!

It’s not the space, but the ability to mopve stuff around with the blit
engine and not have the CPU and bus tied up doing it that is the benefit.

How can you explain that 1280x1024x8 on QNX4/Photon 1.1x,
I can have many intensive flicker-free animation going on, many moire,
poker, othello and a pterm without any problem.

How can you look at the Photon 1.1x version and the Photon 2.0 version
and not see that there is a big difference in the look of the two?

And a single Tetris game on QNXRtP,
get my system running on his knees praying for help ?!

Yes. I assume you mean PhColumns, which is very, very dependant on the
new features.