On (02 Mar 95) [EMAIL PROTECTED] wrote to All... > Date: Thu, 02 Mar 1995 19:52:14 GMT > From: "Brian Gaff Sam Dept." <[EMAIL PROTECTED]>
> The Blue Alpha sampler tended to sound like a cheap radio with > duff batteries. It also drifted like hell! I told Adrian that > timer IC was a bad idea! > I believe the Edwin Blink Design was better, but I never saw it > in the flesh. > On Speaking gadgets, no the Blue Alpha had rubbish software in > it. I actually debugged it a bit for Adrian, but gave up when I > hit that bl**dy page boundary bug! The Blue Alpha box also had a serious BUG in that it didn't impliment the SP-0256 busy line so it couldn't string the allophones together seamlessly. Instead it relied on PAUSE's in the basic program to delay as long as the longest allopone which causes perceivable gaps between the short allophones! Really the SP-0256 interface is virtually a minimal Centronics style interface ie you setup the alophone address on the output port data latch and wait until the chips not busy then pulse the strobe and go get the next allophone to speak and repeat until finished. > What would be needed for me would be a screen reader and > keyboard echo. That could not be done I think. There are TSRs on > the PC that allow that sort of thing, but an interrupt driven > routine on SAM would probably slow things down. It is *possible* to intercept the screen output channel and build up each word in a temporay work-space whilst passing the letters onto the normal screen output channel driver and then at the end of the word use some form of lookup table or rule system to make a good guess at the rerquired allaphones required to speak that word and even to use and unused key combination or input port to pace the speaking! ie the light pen button used so that when the button is depressed it speaks continuosly but if it's released during a text to speach attempt it'd try another logical allaphone sequence that may pronounce the word better! I believe the place such a utility should reside is in a few of the SAM utility ram 1K allocations in a 16k 'utility' page... That would basically be the same funcionality as the PeeCee screen reader TSR as that probably 'hooks' into the bios printing interupt vectors like the ANSI.SYS and KYBD.EXE TSR's do:-) IMHO a 'screen reader' that tries to decode words AFTER they've been printed would be impractical as it'd have to know about what font was used, the mode it was printed in etc. The next thing to that would be to intercept screen output and write a TEXT screen in local memory and 'screen read' that whilst pretending it's scanning the real bit-mapped screen with a cursor;-) Neither of these methods need special interupt handling, the only bit that'll slow the sam down is the actual speaking! Heck it should even be possible to use the print intecept TEXT copy of the screen to swap in a BIG FONT scrolling window using the line interupt to display in split screen mode the TEXT contents of the original screen! Of course I couldn't program this myself as it requires intimate knowledge of sam native mode operations which I don't have;-) Regards Johnathan. ... :.::: ::..: ::.::. :..:: Tagline in Braille -- |Fidonet: Johnathan Taylor 2:2501/307.9 |Internet: [EMAIL PROTECTED] | | Standard disclaimer: The views of this user are strictly his own.
