17 Aug
2016
17 Aug
'16
3:26 p.m.
On 2016-Aug-17, at 11:48 AM, william degnan wrote:
No doubt you can get it to work, and it can be a useful ability in some situations.
But monitors and loaders tended to be written with different objectives.
Monitors targetted interactive use, not receipt of back-to-back characters, which would be
why you have to add per-char delays.
The monitor is likely dropping a character or starting a read in the middle of one and
getting garbage because it went away for too long while looking up the command.
It only has the stop bit period, or even less time, to do processing after receipt of a
character.
Loaders expect back-to-back characters and are written or optimised accordingly, not that
one can't still run into problems, which is why the checksums can be good.
Bill's
method, of executing an M command from a text file, achieves the
same thing: filling memory.
Something it's missing versus the S-record/loader format method is a
checksum or any data check.
One may may not be concerned about line noise over a short RS-232 line,
but if there are problems like
dropped characters, receivers overruns, framing errors, etc., due say to
speed or line config issues the
M command method isn't going to tell you about it, while the S-record
method will/should (in most cases)
report a data error.
My instructions suggest one use a character delay. I found that the
monitor program will bomb if it gets its instructions too fast anyway. For
the OP, I felt this was the simplest straight-forward method to get TSC
BASIC running. I tested and documented the process, worked for me very
reliably and it eliminiates the need to do anything other than get to the
monitor prompt to work.