[Blindapple] introduction

[Tony Baechler]

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.