[Blindapple] introduction

[Jayson Smith]

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.
Jayson.

----- 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