SWTPC 6800

[Brent Hilpert]

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.