Hiya. This is a comparison between qtalk running in a pterm window under QNX4
and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000 AGP,
QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM, 3dfx
VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at 1280x1024x32,
with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded thingie
at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
bottom of the pterm and scrolling commences I begin to lose characters coming
in over the serial port. I played with the RtP system, and I get the problem
all the way down to 1024x768x32. It starts to go away with various
combinations of lower resolution, or less color depth. At 1200x1600 I can make
the problem go away by using 16-bit color and a significantly smaller window.
I don’t know if this is a problem per say, but it seems to me that we lost at
least a little something as far as the pterm scrolling speed goes. I don’t
believe there to be any issues with devc-ser8250 losing characters other than
the fact that the pterm can’t keep up. I like to run at 1600x1200 with 93x80
pterms so you can imagine the mess that created I figure I’d throw this out
here, in hopes that someone may take a look at that particular section of code
and dream up a few enhancements. In the meantime, I’ll play with the buffer
settings (although at some point if you can’t keep up, you can’t keep up) on
devc-ser8250 and perhaps just live with a smaller pterm for my serial dealings
(mumble, grumble, complain, etc. Hopefully a simple solution will present
itsself and you’ll let me beta test it for you (mooohahaha). TIA.
Hiya. This is a comparison between qtalk running in a pterm window under QNX4
and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000 AGP,
QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM, 3dfx
VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at 1280x1024x32,
with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded thingie
at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
bottom of the pterm and scrolling commences I begin to lose characters coming
in over the serial port. I played with the RtP system, and I get the problem
all the way down to 1024x768x32. It starts to go away with various
combinations of lower resolution, or less color depth. At 1200x1600 I can make
the problem go away by using 16-bit color and a significantly smaller window.
I don’t know if this is a problem per say, but it seems to me that we lost at
least a little something as far as the pterm scrolling speed goes. I don’t
believe there to be any issues with devc-ser8250 losing characters other than
the fact that the pterm can’t keep up. I like to run at 1600x1200 with 93x80
pterms so you can imagine the mess that created > > I figure I’d throw this out
here, in hopes that someone may take a look at that particular section of code
and dream up a few enhancements. In the meantime, I’ll play with the buffer
settings (although at some point if you can’t keep up, you can’t keep up) on
devc-ser8250 and perhaps just live with a smaller pterm for my serial dealings
(mumble, grumble, complain, etc. > > Hopefully a simple solution will present
itsself and you’ll let me beta test it for you (mooohahaha). TIA.
Ah yes, the fabled “Patch A” of yore… Upon its arrival, there may not be
dancing in the streets, but I guarantee you that there will be a bunch of us
computer nerds beating the heck out of your web site
I never would have guessed devc-pty. I was betting it was a new Photon
driver issue (you know, speed for portability and so on). I’m happy it
wasn’t so involved! Have a good one…
The pterm problem turned out to be a bug in devc-pty. This has been
fixed, and will be available in the fabled Patch-A. >
Warren Peece <> warren@nospam.com> > wrote:
Hiya. This is a comparison between qtalk running in a pterm window
under QNX4
and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx
VooDoo3/3000 AGP,
QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M
DRAM, 3dfx
VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at
1280x1024x32,
with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded
thingie
at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits
the
bottom of the pterm and scrolling commences I begin to lose characters
coming
in over the serial port. I played with the RtP system, and I get the
problem
all the way down to 1024x768x32. It starts to go away with various
combinations of lower resolution, or less color depth. At 1200x1600 I
can make
the problem go away by using 16-bit color and a significantly smaller
window.
I don’t know if this is a problem per say, but it seems to me that we
lost at
least a little something as far as the pterm scrolling speed goes. I
don’t
believe there to be any issues with devc-ser8250 losing characters other
than
the fact that the pterm can’t keep up. I like to run at 1600x1200 with
93x80
pterms so you can imagine the mess that created > > I figure I’d throw
this out
here, in hopes that someone may take a look at that particular section
of code
and dream up a few enhancements. In the meantime, I’ll play with the
buffer
settings (although at some point if you can’t keep up, you can’t keep
up) on
devc-ser8250 and perhaps just live with a smaller pterm for my serial
dealings
(mumble, grumble, complain, etc. > > Hopefully a simple solution will
present
itsself and you’ll let me beta test it for you (mooohahaha). TIA.
The pterm problem turned out to be a bug in devc-pty. This has been
fixed, and will be available in the fabled Patch-A. >
Instead of running qtalk in a pterm, you could consider attaching your
pterm directly to the serial port (“pterm -d /dev/serN”). Bypassing
devc-pty and qtalk will save some CPU cycles and work around the
devc-pty bug…
Warren Peece <> warren@nospam.com> > wrote:
Hiya. This is a comparison between qtalk running in a pterm window under QNX4
and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000 AGP,
QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM, 3dfx
VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at 1280x1024x32,
with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded thingie
at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
bottom of the pterm and scrolling commences I begin to lose characters coming
in over the serial port. I played with the RtP system, and I get the problem
all the way down to 1024x768x32. It starts to go away with various
combinations of lower resolution, or less color depth. At 1200x1600 I can make
the problem go away by using 16-bit color and a significantly smaller window.
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:8vm8u7$mqm$1@nntp.qnx.com…
| cburgess@qnx.com wrote:
|
| > The pterm problem turned out to be a bug in devc-pty. This has been
| > fixed, and will be available in the fabled Patch-A.
|
| Instead of running qtalk in a pterm, you could consider attaching your
| pterm directly to the serial port (“pterm -d /dev/serN”). Bypassing
| devc-pty and qtalk will save some CPU cycles and work around the
| devc-pty bug…
|
| > Warren Peece <warren@nospam.com> wrote:
| >> Hiya. This is a comparison between qtalk running in a pterm window under
QNX4
| >> and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000
AGP,
| >> QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM,
3dfx
| >> VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at
1280x1024x32,
| >> with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded
thingie
| >> at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
| >> bottom of the pterm and scrolling commences I begin to lose characters
coming
| >> in over the serial port. I played with the RtP system, and I get the
problem
| >> all the way down to 1024x768x32. It starts to go away with various
| >> combinations of lower resolution, or less color depth. At 1200x1600 I can
make
| >> the problem go away by using 16-bit color and a significantly smaller
window.
Rats. It looked like it was going to be fine, but then I ran into the same
problem. It appears to be a little bit less sensitive, as I can use a 34 line
window with pterm -d /dev/ser1 in 24-bit color mode and not have problems, but
anything much larger than that gives me the same thing. Maybe it’s as bad as I
thought it was
“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:8vm8u7$mqm$1@nntp.qnx.com…
| cburgess@qnx.com wrote:
|
| > The pterm problem turned out to be a bug in devc-pty. This has been
| > fixed, and will be available in the fabled Patch-A.
|
| Instead of running qtalk in a pterm, you could consider attaching your
| pterm directly to the serial port (“pterm -d /dev/serN”). Bypassing
| devc-pty and qtalk will save some CPU cycles and work around the
| devc-pty bug…
|
| > Warren Peece <warren@nospam.com> wrote:
| >> Hiya. This is a comparison between qtalk running in a pterm window under
QNX4
| >> and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000
AGP,
| >> QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM,
3dfx
| >> VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at
1280x1024x32,
| >> with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded
thingie
| >> at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
| >> bottom of the pterm and scrolling commences I begin to lose characters
coming
| >> in over the serial port. I played with the RtP system, and I get the
problem
| >> all the way down to 1024x768x32. It starts to go away with various
| >> combinations of lower resolution, or less color depth. At 1200x1600 I can
make
| >> the problem go away by using 16-bit color and a significantly smaller
window.
Rats. It looked like it was going to be fine, but then I ran into the same
problem. It appears to be a little bit less sensitive, as I can use a 34 line
window with pterm -d /dev/ser1 in 24-bit color mode and not have problems, but
anything much larger than that gives me the same thing. Maybe it’s as bad as I
thought it was >
“Wojtek Lerch” <> wojtek@qnx.com> > wrote in message
news:8vm8u7$mqm$> 1@nntp.qnx.com> …
| > cburgess@qnx.com > wrote:
|
| > The pterm problem turned out to be a bug in devc-pty. This has been
| > fixed, and will be available in the fabled Patch-A. >
|
| Instead of running qtalk in a pterm, you could consider attaching your
| pterm directly to the serial port (“pterm -d /dev/serN”). Bypassing
| devc-pty and qtalk will save some CPU cycles and work around the
| devc-pty bug…
|
| > Warren Peece <> warren@nospam.com> > wrote:
| >> Hiya. This is a comparison between qtalk running in a pterm window under
QNX4
| >> and QNX6. The QNX4 machine is a PII/400 with 128M DRAM, 3dfx VooDoo3/3000
AGP,
| >> QNX 4.25 Photon 1.14. The QNX6 machine is a dual PIII/800 with 256M DRAM,
3dfx
| >> VooDoo3/3000 AGP, RtP (2.11?), Photon 2.0. I have both set at
1280x1024x32,
| >> with a pterm size of 60x80. Under QNX4 I’m able to talk to my embedded
thingie
| >> at 8,n,1,19200 with no problems. Under RtP, as soon as the data hits the
| >> bottom of the pterm and scrolling commences I begin to lose characters
coming
| >> in over the serial port. I played with the RtP system, and I get the
problem
| >> all the way down to 1024x768x32. It starts to go away with various
| >> combinations of lower resolution, or less color depth. At 1200x1600 I can
make
| >> the problem go away by using 16-bit color and a significantly smaller
window.
Wojtek Lerch (> wojtek@qnx.com> ) QNX Software Systems Ltd.
“David Rempel” <drempel@qnx.com> wrote in message
news:8vmk7e$rvf$1@nntp.qnx.com…
| Your pterm isn’t using anti-aliased text is it? That could slow the
rendering process
| down considerably…
|
| Warren Peece <warren@nospam.com> wrote:
| > Rats. It looked like it was going to be fine, but then I ran into the same
| > problem. It appears to be a little bit less sensitive, as I can use a 34
line
| > window with pterm -d /dev/ser1 in 24-bit color mode and not have problems,
but
| > anything much larger than that gives me the same thing. Maybe it’s as bad
as I
| > thought it was
Not as far as I can tell. In launch->disfigure->fontserver, none of the
anti-aliasing boxes are checked. Is that definitive or is there somewhere else
I need to look? I’m not sure why there are three different anti-aliasing
boxes, but none are checked (in fact nothing is checked at all). What are
“font hints”? There’s no data loss whatsoever at any resolution until the
window starts to scroll when the cursor hits the bottom, if that means
anything. I would assume that once the font is drawn, you just block move the
window up to make room and don’t re-draw each character for each line scrolled,
no? Hmmm… Did you know that after a reboot, “Enable FontFusion
Anti-Aliasing” always comes back checked even if you unset and apply it? Do I
need to restart Photon to remove that anti-aliasing (cuz that’s gonna be
tough!)?
I’m happy to try anything you want, although I’d think this would be easy
enough to reproduce on your side (if you’ve got a big enough monitor that is
I figure I’d throw this out
Hopefully a simple solution will present