[Blindapple] introduction

[GUI Access]

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


I've never heard this.  To my knowledge the Echo had (for many years) 
the same chip as the Speak 'n Spell (chip from Texas Instruments I 
think); it had the phonemes directly on it.  Perhaps you're thinking 
of the Echo's female speech which was encoded in some whacky 6-bit 
format.  However in order to load anything onto the Echo itself the 
card would have to have either RAM or an EPROM--two things no Echo in 
the world to my knowledge has ever had.


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


Is/was this other screen reader ProSCAT?  This came with the 
SlotBuster, right?  Is it true that source for this is available? 
This would be a revelation if true.  It is true that I have no idea 
how the 16 I/O lines for the Echo work, but I know 6502/65816 
assembly fairly well and it is only too easy to find the low-level 
subroutine in Textalker that starts to talk to the Echo at its low 
level.  This is where you could patch.


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


Except that the Echo has no firmware.  No Echo other than the Echo+ 
has ever displayed anything meaningful in it's slot's 256 byte 
address space.


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


Please provide any info on this other screen reader.  I'd like to see it.

GUI Access