17 Aug
2016
17 Aug
'16
9:08 p.m.
On 2016-Aug-17, at 8:26 PM, william degnan wrote:
Yes, we've had that debate a few times.
AIR, it was decided that bottom-posting was the 'list practice'.
> 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.
It would be a lot easier if everyone picked top or bottom posting when they
reply but I digress.... My suggestion to use the "monitor method" is
a stop-gap just to get to the
point of loading in something useful when no other means was workinhg. I
agree any process that has no checksum will be unreliable. Whatever.. .
Let's say for now you have at least the monitor method until something
better comes along.
But as far as MIKBUG/SWTBUG goes, you also always have the "L" command with
S-record method.
If the data in your TSC BASIC "M" text were converted to S-record format - a
trivial programming exercise -
it would be easier (no delays required) (and more reliable) to load into the SWTP.
They're both ASCII text input, just different formats.
I'm not clear why you resorted to the M-command method, was the TSC BASIC data not
originally
in S-records? - that would be the standard format for loading such software into an SWTP.