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 >>> 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....
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.
