Re: Looking for some help.

Re: Looking for some help.

[Ed Greenberg]

At 10:07 PM 1/15/98 -0600, John Schucker wrote:
>Well, the problem with dumping all the output to the port as I see it is 
>lack of review.  I mean, let's say you're doing cat foo.bar, and you miss 
>say a phone number.  How do you go back and look at just the line with 
>that number on it?  If you're simply dumping the output to the port, the 
>only way to do it is recat the file.
>  
>Mind, I'm not saying it's a bad idea or anything ... the more options the 
>better as far as I'm concerned .. and I could see it as especially useful 
>in a special pre-compiled kernel with that driver, so you could hook up a 
>synth and install linux yourself essentially.

I think the review problem is easy, actually. I plan to work on building a
review module into this code as soon as I have the flow control working
better.

I already have a rudamentary review going, in that when you switch from one
Virtual Console to another, the code rereads the screen as it repaints. This 
is done by actually looking at the (software) screen buffer.

Review could be by cursoring around the screen and asking for lines, words
or characters. I can already read the screen, as indicated above, so the
extent of 
the problem is making the keyboard a modal device, and then building the
review mode. 

I see all of this as taking place in keyboard.c and console.c.

The version that I have now starts talking as soon as you boot, and keeps
talking right down to "system halted." If flow control worked, I'd ask for
testers. 

</edg> 
--
Ed Greenberg               edg@greenberg.org            km6cg
                        http://www.greenberg.org/

Re: Looking for some help.

[Trevor Astrope]

On Fri, 16 Jan 1998, Whistler wrote:

> 
> 
> I would suggest if you haven't looked at them take a look at ASAP or JAWS
> for dos The number pad on the keyboards make a great control pad for
> re-reading the screan and I think with some work you should be able to
> make a dos like screan reader the way you are doing it.

I've used a few different dos screan readers over the years and I too like
the numberpad approach for review.

Trevor

Re: Looking for some help.

[Whistler]

I would suggest if you haven't looked at them take a look at ASAP or JAWS
for dos The number pad on the keyboards make a great control pad for
re-reading the screan and I think with some work you should be able to
make a dos like screan reader the way you are doing it.

Ken /whistler

On Fri, 16 Jan 1998, Ed Greenberg wrote:

> At 10:07 PM 1/15/98 -0600, John Schucker wrote:
> >Well, the problem with dumping all the output to the port as I see it is 
> >lack of review.  I mean, let's say you're doing cat foo.bar, and you miss 
> >say a phone number.  How do you go back and look at just the line with 
> >that number on it?  If you're simply dumping the output to the port, the 
> >only way to do it is recat the file.
> >  
> >Mind, I'm not saying it's a bad idea or anything ... the more options the 
> >better as far as I'm concerned .. and I could see it as especially useful 
> >in a special pre-compiled kernel with that driver, so you could hook up a 
> >synth and install linux yourself essentially.
> 
> I think the review problem is easy, actually. I plan to work on building a
> review module into this code as soon as I have the flow control working
> better.
> 
> I already have a rudamentary review going, in that when you switch from one
> Virtual Console to another, the code rereads the screen as it repaints. This 
> is done by actually looking at the (software) screen buffer.
> 
> Review could be by cursoring around the screen and asking for lines, words
> or characters. I can already read the screen, as indicated above, so the
> extent of 
> the problem is making the keyboard a modal device, and then building the
> review mode. 
> 
> I see all of this as taking place in keyboard.c and console.c.
> 
> The version that I have now starts talking as soon as you boot, and keeps
> talking right down to "system halted." If flow control worked, I'd ask for
> testers. 
> 
> </edg> 
> --
> Ed Greenberg               edg@greenberg.org            km6cg
>                         http://www.greenberg.org/
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 

Re: Looking for some help.

[Jude Dashiell]

provox 6.6 uses the numberpad approach for review functions.
That review can happen just by hitting keys on the number pad, no extra
keys are
needed to invoke review like was done on the artic symphonix synthesizers.



Jude <dashiell@clark.net>

Re: Looking for some help.

[Andrew Devenish-Meares]

On Fri, 16 Jan 1998, Trevor Astrope wrote:
> > I would suggest if you haven't looked at them take a look at ASAP or JAWS
> > for dos The number pad on the keyboards make a great control pad for
> > re-reading the screan and I think with some work you should be able to
> > make a dos like screan reader the way you are doing it.
> 
> I've used a few different dos screan readers over the years and I too like
> the numberpad approach for review.

One problem with using the keypad would be applications that require the 
use of the keypad for its own functions.  The example that springs to my 
mind is SQL*Forms30, which I failed to manage to use last year.

If you can provide facilites to re-map the review functions for these 
kinds of situations, then this would be helpful.


---
Andrew 'ADM' Devenish-Meares			    adevenis@turing.une.edu.au
http://turing.une.edu.au/~adevenis/		    adevenis@suburbia.com.au
Brain:  Pinky, are you pondering what I'm pondering?
Pinky:  Sure, Brain, but how are we going to find chaps our size? 

Re: Looking for some help.

[Travis Siegel]

On Sat, 17 Jan 1998, Andrew Devenish-Meares wrote:

> One problem with using the keypad would be applications that require the 
> use of the keypad for its own functions.  The example that springs to my 
> mind is SQL*Forms30, which I failed to manage to use last year.

This is precisely why I haven't quite managed to like asap, jaws, etc,
because I'm using artic and business vision on my computers, and although
you can use the number pad for review functions (without going into review
mode) I much prefer to use the extended cursor keys.  That way, my number
pad is still fre for those applications that require it.  I've always used
it as such, (since I moved to a 101-key keyboard anyway) and I find it
works considerably better than asap requiring the number pad for their
review functions.  I personally think it's a lot easier to just hit the
numlock to get arrows or numbers, based on what I want than it is to keep
switching from one set of keys to the other depending on what I want.

Re: Looking for some help.

[Jude Dashiell]

Isn't it possible to use the alternate keypad keys with those applications
like sql?
Those are the keys closer to the regular keyboard.



Jude <dashiell@clark.net>

Re: Looking for some help.

[Whistler]

I haven ever run into this problem because I correctly uset he softare
youcan set it up to turn on and off the keypad when needed I can still
enter numbers from the num pad with asap asaw jaws and jfw you just have
to be proficient in the software.

As for not using it on Linux tell me how many software aplications have
you actually used the key pad on I have used Linux now for 4 years and my
num pad still has dust on it.

Ken /whistler

On Sat, 17 Jan 1998, Travis Siegel wrote:

> On Sat, 17 Jan 1998, Andrew Devenish-Meares wrote:
> 
> > One problem with using the keypad would be applications that require the 
> > use of the keypad for its own functions.  The example that springs to my 
> > mind is SQL*Forms30, which I failed to manage to use last year.
> 
> This is precisely why I haven't quite managed to like asap, jaws, etc,
> because I'm using artic and business vision on my computers, and although
> you can use the number pad for review functions (without going into review
> mode) I much prefer to use the extended cursor keys.  That way, my number
> pad is still fre for those applications that require it.  I've always used
> it as such, (since I moved to a 101-key keyboard anyway) and I find it
> works considerably better than asap requiring the number pad for their
> review functions.  I personally think it's a lot easier to just hit the
> numlock to get arrows or numbers, based on what I want than it is to keep
> switching from one set of keys to the other depending on what I want.
> 
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 

Re: Looking for some help.

[K.C. Habib]

Could you please send me a copy of the DectalkPC device drivers???  I am 
greatly interested in this
Thanks
On Fri, 16 Jan 1998, Nicolas Pitre wrote:

> On Thu, 15 Jan 1998, Ed Greenberg wrote:
> 
> > At 08:57 PM 1/15/98 -0500, you wrote:
> > >What you need here first is a kernel device driver.  Since I wrote one for
> > >the DECtalk PC, I can try to help writing a driver for the Accent.
> > 
> > What sort of a kernel driver did you write? I've been experimenting with a
> 
> I don't understand exactly what you mean here...  The DECtalk PC driver is
> a device driver to access the DECtalk PC ISA card as a character
> device wich can't be accessed without some kernel side driver, like any
> other piece of hardware in your PC.
> 
> > Kernel Driver for console.c that drives all console output to the serial
> > port as well as the internal screen. I have it mostly working. 
> 
> Isn't it already there in the 2.1.x kernel series?  Something like
> CONFIG_SERIAL_CONSOLE?
> 
> > I'm sighted, but have a blind friend who uses Unix via telnet on his OS/2
> > laptop. He likes Unix better, and is interested in a native linux box that
> > can run his Audapter. 
> 
> What kind of hardware is it (serial device, ISA card, etc.)?
> 
> > Can we compare notes? 
> 
> You can find the DECtalk PC driver I wrote from ftp.leb.net in
> /pub/blinux as dectalk_pc-0.91.tgz.
> 
> If I didn't answered your interrogations, feel free to ask again!  :)
> 
> 
> Nicolas Pitre, B. ing.
> nico@cam.org
> 
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 

Re: Looking for some help.

[Luke Davis]

Good point . . .
The key would then be to write a screen review package that can cope with
that.
In the mean time: a grep or awk for the line with the number, redirected
to the port will handle that problem.

On Thu, 15 Jan 1998, John Schucker wrote:

> Well, the problem with dumping all the output to the port as I see it is 
> lack of review.  I mean, let's say you're doing cat foo.bar, and you miss 
> say a phone number.  How do you go back and look at just the line with 
> that number on it?  If you're simply dumping the output to the port, the 
> only way to do it is recat the file.
>   
<snipage>

Re: Looking for some help.

[Nicolas Pitre]

On Thu, 15 Jan 1998, Ed Greenberg wrote:

> At 08:57 PM 1/15/98 -0500, you wrote:
> >What you need here first is a kernel device driver.  Since I wrote one for
> >the DECtalk PC, I can try to help writing a driver for the Accent.
> 
> What sort of a kernel driver did you write? I've been experimenting with a

I don't understand exactly what you mean here...  The DECtalk PC driver is
a device driver to access the DECtalk PC ISA card as a character
device wich can't be accessed without some kernel side driver, like any
other piece of hardware in your PC.

> Kernel Driver for console.c that drives all console output to the serial
> port as well as the internal screen. I have it mostly working. 

Isn't it already there in the 2.1.x kernel series?  Something like
CONFIG_SERIAL_CONSOLE?

> I'm sighted, but have a blind friend who uses Unix via telnet on his OS/2
> laptop. He likes Unix better, and is interested in a native linux box that
> can run his Audapter. 

What kind of hardware is it (serial device, ISA card, etc.)?

> Can we compare notes? 

You can find the DECtalk PC driver I wrote from ftp.leb.net in
/pub/blinux as dectalk_pc-0.91.tgz.

If I didn't answered your interrogations, feel free to ask again!  :)


Nicolas Pitre, B. ing.
nico@cam.org

Re: Looking for some help.

[Jude Dashiell]

It's possible to use more foo.bar too.



Jude <dashiell@clark.net>

Re: Looking for some help.

[John Schucker]

Well, the problem with dumping all the output to the port as I see it is 
lack of review.  I mean, let's say you're doing cat foo.bar, and you miss 
say a phone number.  How do you go back and look at just the line with 
that number on it?  If you're simply dumping the output to the port, the 
only way to do it is recat the file.
  
Mind, I'm not saying it's a bad idea or anything ... the more options the 
better as far as I'm concerned .. and I could see it as especially useful 
in a special pre-compiled kernel with that driver, so you could hook up a 
synth and install linux yourself essentially.

Re: Looking for some help.

[Ed Greenberg]

At 08:57 PM 1/15/98 -0500, you wrote:
>What you need here first is a kernel device driver.  Since I wrote one for
>the DECtalk PC, I can try to help writing a driver for the Accent.

What sort of a kernel driver did you write? I've been experimenting with a
Kernel Driver for console.c that drives all console output to the serial
port as well as the internal screen. I have it mostly working. 

I'm sighted, but have a blind friend who uses Unix via telnet on his OS/2
laptop. He likes Unix better, and is interested in a native linux box that
can run his Audapter. 

Can we compare notes? 

</edg> 
--
Ed Greenberg               edg@greenberg.org            km6cg
                        http://www.greenberg.org/

Re: Looking for some help.

[T. V. Raman]

This might not be necessary --from memory the Accent PC can
be jumpered to work as a serial card, and once you do that
Linux should be able to talk to it like any other serial
device.

I'm pretty sure of this because I used an Accent PC  card
for many years with IBM Screenreader with the card connected
to com1 as a serial device.

-- 
Best Regards,
--raman

      Adobe Systems                 Tel: 1 (408) 536 3945   (W14-129)
      Advanced Technology Group     Fax: 1 (408) 537 4042 
      (W14 129) 345 Park Avenue     Email: raman@adobe.com 
      San Jose , CA 95110 -2704     Email:  raman@cs.cornell.edu
      http://labrador.corp.adobe.com/~raman/        (Adobe Intranet)
      http://cs.cornell.edu/home/raman/raman.html    (Cornell)
----------------------------------------------------------------------
    Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________

Re: Looking for some help.

[Nicolas Pitre]

> >     Hello to all.
> > 
> >     I have gotten permission from Aicom Corperation and they are going
> > to send me the source code for the accent-pc internal card.  I'm not
> > familliar with linux enough to port the code from dos to linux.  Is
> > there anyone who knows 80x86 assembly language who would be willing to
> > help me with this?  This is the only thing that is keeping me from
> > using Linux.

What you need here first is a kernel device driver.  Since I wrote one for
the DECtalk PC, I can try to help writing a driver for the Accent.

Re: Looking for some help.

[Jude Dashiell]

Rick,

Please understand it's possible to run an accent card with
provox 6.6.  That was written for dos but was written in C a language
far more
native to linux.  Perhaps efforts would be better directed
to porting provox over first.
Once that was done, it might be possible to write additional C code to
make
a linux clone of the accent software but this isn't guarranteed
possible.
On 15 xxx -1,
Rick Hayner wrote:

> 
>     Hello to all.
> 
>     I have gotten permission from Aicom Corperation and they are going
> to send me the source code for the accent-pc internal card.  I'm not
> familliar with linux enough to port the code from dos to linux.  Is
> there anyone who knows 80x86 assembly language who would be willing to
> help me with this?  This is the only thing that is keeping me from
> using Linux.
> 
>     Thanks.
> 
> 
> Rick Hayner
> rhayner@complink.net
> Baritone, Kalamazoo chapter SPEBSQSA Mall City Chorus
> It's great to be a barbershopper!
> 
> 
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 


Jude <dashiell@clark.net>

Looking for some help.

[Rick Hayner]

    Hello to all.

    I have gotten permission from Aicom Corperation and they are going
to send me the source code for the accent-pc internal card.  I'm not
familliar with linux enough to port the code from dos to linux.  Is
there anyone who knows 80x86 assembly language who would be willing to
help me with this?  This is the only thing that is keeping me from
using Linux.

    Thanks.


Rick Hayner
rhayner@complink.net
Baritone, Kalamazoo chapter SPEBSQSA Mall City Chorus
It's great to be a barbershopper!