Hi,

In AppleWin (emulator), there's an experimental(*) command line option (-speech) to trap calls to COUT and then use Windows' speech API to speak the text after each CR (carriage return).

This seems to work OK either without any DOS loaded or from DOS 3.3.

But a user has just reported that "in ProDOS BASIC.SYSTEM, output from AppleSoft speaks using double characters. For example, Syntax error becomes SSyynnttaaxx eerrrroorr."

Does anyone know why ProDOS BASIC.SYSTEM calls COUT twice for every character typed?

(*) It's experimental as I added it quickly many years ago, and didn't do a great deal of testing with it, nor did I properly document it.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ffc65ab4-c385-4c67-868f-ce0c814b9e78n@googlegroups.com>,
TomCh <tomcharlesworth26@gmail.com> wrote:

Hi,

In AppleWin (emulator), there's an experimental(*) command line option >(-speech) to trap calls to COUT and then use Windows' speech API to
speak the text after each CR (carriage return).

This seems to work OK either without any DOS loaded or from DOS 3.3.

But a user has just reported that "in ProDOS BASIC.SYSTEM, output from >AppleSoft speaks using double characters. For example, Syntax error
becomes SSyynnttaaxx eerrrroorr."

Does anyone know why ProDOS BASIC.SYSTEM calls COUT twice for every
character typed?

(*) It's experimental as I added it quickly many years ago, and didn't
do a great deal of testing with it, nor did I properly document it.

Thanks.

I believe this is due to ProDOS capturing output so that it can find ctrl-D's. To handle further redirection, it restores $36/$37 to $fdf0 and then calls $fded again. This is so that if PR#1 is done, $36/$37 would indicate $c100 so that it can be redirected properly (the $c100 handler will update $36/$37 to a different vector for the next character, since in#1/pr#1 both call $c100, so code there has to figure out what's really being requested by looking at $36/37). And after this $fded call returns, ProDOS restores the $36/37
vector back to point to ProDOS and then returns.

DOS 3.3 does the same thing, but doesn't actually call $fded again,
it just JSR's to a DOS routine which just does JMP (0036). DOS 3.3 could save 3 whole bytes if it JSR'ed to $fded instead.

My suggestion is to capture $fdf0 calls instead, since that will not be repeated. And capture "pr#3" output as well (I think that will be $c307).

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 8 March 2021 at 06:49:58 UTC, Kent Dickey wrote:

In article <ffc65ab4-c385-4c67...@googlegroups.com>,
TomCh wrote:

Hi,

In AppleWin (emulator), there's an experimental(*) command line option >(-speech) to trap calls to COUT and then use Windows' speech API to
speak the text after each CR (carriage return).

This seems to work OK either without any DOS loaded or from DOS 3.3.

But a user has just reported that "in ProDOS BASIC.SYSTEM, output from >AppleSoft speaks using double characters. For example, Syntax error
becomes SSyynnttaaxx eerrrroorr."

Does anyone know why ProDOS BASIC.SYSTEM calls COUT twice for every >character typed?

(*) It's experimental as I added it quickly many years ago, and didn't
do a great deal of testing with it, nor did I properly document it.

Thanks.

I believe this is due to ProDOS capturing output so that it can find ctrl-D's.
To handle further redirection, it restores $36/$37 to $fdf0 and then calls $fded again. This is so that if PR#1 is done, $36/$37 would indicate $c100 so that it can be redirected properly (the $c100 handler will update $36/$37 to a
different vector for the next character, since in#1/pr#1 both call $c100, so code there has to figure out what's really being requested by looking at $36/37). And after this $fded call returns, ProDOS restores the $36/37
vector back to point to ProDOS and then returns.

DOS 3.3 does the same thing, but doesn't actually call $fded again,
it just JSR's to a DOS routine which just does JMP (0036). DOS 3.3 could save 3 whole bytes if it JSR'ed to $fded instead.

My suggestion is to capture $fdf0 calls instead, since that will not be repeated. And capture "pr#3" output as well (I think that will be $c307).

Kent

Hi Kent, a quick test from ProDOS (and from PR#3), and this seems to be working well now!

So thanks very much for your input and sharing these details.

Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)