[Blindapple] introduction

GUI Access guiaccess at covad.net
Thu Jul 28 23:36:33 EDT 2005


>Hi,
>I have access to this other screen reader, and as far as I can tell, it
>isn't really textalker compatible.  It uses most of the same commands used
>by Textalker, but it is designed to be used with a serial voice device.  It
>won't actually emulate the functionality of Textalker for use with an Echo
>synthesizer.  Thus, the source for this screen reader would not be helpful
>in determining the low-level detection and communication protocols used by
>Textalker.


The Ctrl-E command set, right?  Hmm, I wonder how many other devices 
supported a subset of these commands.

I was dumbfounded one day when I hooked my Braille 'n Speak (Classic) 
up to the serial port, did a pr#1, threw the B&S into Speech Box 
mode, and sent Ctrl-E sequences out the serial port.  The B&S 
responded to the pitch, compressed/expanded speech, and [I think] 
volume commands.  As I said I was dumbfounded, and to this day have 
never seen a single piece of documentation mention this ability.

GUI Access
>]
>
>----- Original Message -----
>From: "Tony Baechler" <tony at baechler.net>
>To: "Blind Apple Discussions" <blindapple at jaybird.no-ip.info>
>Sent: Thursday, July 28, 2005 4:24 AM
>Subject: Re: [Blindapple] introduction
>
>
>>  Hi.  OK, my apologies.  I used the wrong terminology here.  We are talking
>>  about two different things.  One is to emulate the Echo.  That is, find a
>>  way for software to work with what it thinks is a real Echo card.  What I
>>  mean is to simulate the Echo.  We are pretending that we have a real Echo
>>  card even though we don't.  I should have been clearer on this
>>  before.  Below is your message.  I will respond to your comments.
>>
>>  At 10:59 PM 7/26/2005 -0700, you wrote:
>>  >On emulating the Echo.  It would be technically possible, all be it in a
>>  >roundabout manner.  The Echo stores the speech sounds it produces in LPC
>>  >(Linear Predictive Coding).  So there's nothing particularly special
>about
>>  >why the Echo sounds the way it sounds. You'd need to be able to grab high
>>  >quality audio samples from an Echo, covering all of the individual speech
>>  >phonemes the Echo can produce.
>>
>>  That is relatively easy.  Especially with the 1.3 Textalker, you can just
>>  hit "&" at an Applesoft prompt and try random letters until you get all of
>>  them.  With the newer Textalker, you would get better sound.  I think I
>>  read that the version of Textalker actually loaded the phonemes on the
>Echo
>>  card when it was loaded which is why it takes up the RAM card also.
>>
>>  >Directly getting the data off of the card or directly emulating the 16
>I/O
>>  >lines which all Textalker's use to talk to the Echo is out of the
>question
>>  >as this info is probably only known to a few people and getting this info
>>  >in the year 2005 is highly unlikely.  I've heard that even APH who
>>  >developed the most recent Textalker software ten years ago didn't know
>how
>>  >this low-level code worked; it was written in the days of Street
>>  >Electronics some 20 years ago and remained essentially unchanged.
>>
>>  I disagree with you there.  For one thing, there is the other screen
>reader
>>  which is compatible with Textalker.  The name escapes my memory at the
>>  moment, sorry.  I believe that source is available for this screen
>>  reader.  I don't really know assembly so I could be wrong.  Now that there
>>  are a number of cracking and disassembly tools out there, I don't think it
>>  would be hard to see how Textalker works.  You might also find info in the
>>  old Raised Dot Computing newsletters.  There would be a few different ways
>>  of getting that information.  Finally, Larry is still at APH and he worked
>>  on Textalker, so he might possibly remember something.
>>
>>  >So, my idea for an Echo emulator is to get your audio recordings of the
>>  >Echo's speech sounds and write a patch to Textalker that instead of
>>  >calling the low-level Echo code it'd call some code that'd do native
>>  >assembling of the write speech sounds from the phonemes it was past and
>  > >produce the desired speech.
>>
>>  Yes, but just how would you go about this?  You yourself said that no one
>>  knows how the low level code for Textalker works.  How are you going to
>>  patch it?  You would have better luck patching the emulator itself.  A2 is
>>  written in C.  It is designed to be portable.  I know from firsthand
>>  experience that it runs on SunOS, Linux, possibly BSDI, and DOS.  It would
>>  seem to me that it would be the easiest to hack.  It is licensed under the
>>  GPL so that isn't an issue.  My idea is just to make slot 4 respond to
>>  whatever code Textalker wants to make sure there is an Echo there and to
>>  route that slot to a serial port.  Ideally, pr#4 would treat com1 as a
>>  printer and you would get speech directly sent to the DEC-Talk.  In
>>  addition, doing a PR#0 would work just as well because Textalker itself
>>  would handle sending output to the synth on com1 since slot 4 is already
>>  routed.  I hope that makes sense.  This has the advantage that review mode
>>  could work since it would be talking directly to the serial port.  I think
>>  this could be done very easily.  The author has code to emulate some slots
>>  already and makes it relatively easy to add.  Someone might need to dump
>>  the Echo ROM or something (256 bytes) but that wouldn't be hard.  We are
>>  then simulating more than emulating, but at least one could pretend that
>>  they are using an Echo and Textalker shouldn't know the difference.
>>
>>  >There's lots more details that make this complicated.  I.e.  Getting the
>>  >correct pitch (Echo's have 63 pitches), and getting the two correct rates
>>  >(expanded/compressed).  There's probably more.  There's also the hardware
>>  >freq pot on the Echo which allowed you to twiddle the frequency--totally
>>  >independent of the ROM on the card.
>>
>>  Don't worry about emulating those things.  They could be simulated easily
>>  enough by writing drivers for other synthesizers.  That is where this
>other
>>  screen reader would come in useful.  It already has support for multiple
>>  synthesizers and could easily be patched, easier than Textalker.  It was
>>  designed not to be limited to just the Echo.  I tried it once with A2 but
>>  it crashed.  If I knew more about assembly, I would look more at it.  All
>>  you would need to do is patch a bunch of different versions for each
>>  synthesizer.  With Doubletalk LT or Litetalk, use the Control+A codes.
>The
>>  DEC-Talk uses the left bracket and semicolon.  Instead of sending Control
>>  E, C to the simulation Echo, send [:ra 300 ] instead.  That's 300 words
>per
>>  minute on the DEC-Talk which I am sure is far faster than the Echo ever
>>  talked.  Forget about emulating the hardware.  It isn't going to happen
>and
>>  it isn't necessary.  Heck, even ApplePC can do the basic type of thing I
>>  have in mind, route everything directly to a serial port.  I will do some
>>  experimentation with A2 and see if I get anywhere.  Applemu is better for
>>  this though since you can route the card to whatever port you want.
>>
>>  _______________________________________________
>>  BlindApple mailing list
>>  BlindApple at jaybird.no-ip.info
>>  http://jaybird.no-ip.info/mailman/listinfo/blindapple
>
>_______________________________________________
>BlindApple mailing list
>BlindApple at jaybird.no-ip.info
>http://jaybird.no-ip.info/mailman/listinfo/blindapple




More information about the BlindApple mailing list