Multi-line macro not fully transmitting

[chrstphrchvz]

I have also noticed that some multiple-line macros don't run correctly (at least on a Mac using an FTDI USB serial device): I'm not sure if I've described the issue comprehensively, e.g. when mixed with Macro Commands, but it seems that for the second Regular Output Text line only the first character is output, and the rest of the macro is not output. For example, the macro

mdw 1000
mdw 2000
mdw 3000

is output to the terminal as

>mdw 1000

1000  0D0A 2575 - 2025 7520 - 2575 2025 - 7520 2575    ..%u %u %u %u %u
>m

[hotwolf]

I'll see if I can reproduce this problem. What kind of D-Bug12 debugger are you using?

[chrstphrchvz]

This is using the onboard monitor firmware D-Bug12 4.0.0.b32 for the Dragon12-Light by EVBplus.com (more info: http://evbplus.com/dragon12_light_9s12_files/dragon12_light_rev_a.html), running in EVB mode.
I tried some tests with socat to monitor HSW12's output: all lines are transmitted, both on Mac and Linux; I haven't tried intercepting communication with the board connected.
(I haven't gotten the board working with HSW12 on Linux yet, but I don't think it's an issue with HSW12 specifically. It looks as if it's immediately echoing back any prompts from D-Bug12 and gets stuck in a "Bad Command" loop, but the same happens when using cat < /dev/ttyUSB0. minicom works, though.)

[chrstphrchvz]

I think I've figured out what the issue is: after D-Bug12 receives the first command from HSW12, only up to one additional character is buffered before returning to the prompt (I have not studied the D-Bug12 code or the SCI system enough to know entirely why). Depending on the amount of time until D-Bug12 returns (e.g. how much output there is), the rest of the macro is subject to being discarded.
So this is not an issue with HSW12 per se, but it makes many multiline macros otherwise unusable with DBug-12.
I haven't thought of a solution that would be simple to implement in HSW12, but I'd think this is not an unforeseen issue in serial communication, and there could already be something in hardware/drivers that resolves this.

[chrstphrchvz]

I've since learned about software flow control a.k.a. XON/OFF, and stty's ixon option. I've also read in DB12RG4.pdf that software flow control support is required for interacting properly with D-Bug12, at least for when loading programs. However, it doesn't look like D-Bug12 sends any software flow control characters while printing monitor command output (e.g. for RD)*, so the connected terminal won't wait until the > prompt appears before sending more characters, even if software flow control is enabled. I'm guessing this behavior is fine for typical interaction by a human, but for HSW12 macros a workaround is desirable, e.g. adding an option to the macro dialog or language that waits for the > prompt after each line before continuing.

* I verified this on D-Bug12 v4.0.0b32 using a sniffer tool jpnevulator.
I manually output an XON character:

	CLRA
	LDAB	#$11	;XON
	LDX	putchar
	JSR	0,X
	SWI

I then made sure that with ixon disabled (checking for -ixon in stty -a), the XON character is logged by the sniffer, while with ixon enabled the OS/driver filters out the XON character. Then when running the RD command with ixon disabled, there were no XON or XOFF characters logged by the sniffer, meaning D-Bug12 didn't send any.