hilpert at cs.ubc.ca
Wed Aug 17 23:08:32 CDT 2016
On 2016-Aug-17, at 8:26 PM, william degnan wrote:
>>> No doubt you can get it to work, and it can be a useful ability in some
>>> But monitors and loaders tended to be written with different objectives.
>>> Monitors targetted interactive use, not receipt of back-to-back
>>> which would be why you have to add per-char delays.
>>> The monitor is likely dropping a character or starting a read in the
>>> of one and getting garbage because it went away for too long while
>>> up the command.
>>> It only has the stop bit period, or even less time, to do processing
>>> 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
>>> checksums can be good.
> It would be a lot easier if everyone picked top or bottom posting when they
> reply but I digress....
Yes, we've had that debate a few times.
AIR, it was decided that bottom-posting was the 'list practice'.
> 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.
More information about the cctalk