I understand what's going on.
The getting started page
https://wdc65xx.com/getting-started/men ... g-started/ said to upload the .hex file, which is EasySXB's default extension. When I look at the content of the generated file it contains:
Code:
:1800C00078D8BA8E4001A9008D40DF8D27DF8D04DF8D05DF8D06DFA272
:1800D8000000EAA9AA8D23DF6B8DA0018E42011A8DA101E88E44011ABC
:0F00F0008DA201E88E4601E88E48018D23DF6B5B
:00000001FF
That is an Intel hex file, not S records. When you run the WDC assembler and linker it also produces a .s28 files which contains this:
Code:
S2140000C078D8BA8E4001A9008D40DF8D27DF8D04D9
S2140000D0DF8D05DF8D06DFA20000EAA9AA8D23DFEB
S2140000E06B8DA0018E42011A8DA101E88E44011A83
S2130000F08DA201E88E4601E88E48018D23DF6B56
S804000000FB
That's more like it, as those are 28 bit SREC format, and that is one of the other file extensions. It's also the monitor's supported format.
So it looks like the EasySXB program is at fault because it defaults to the .hex file extension. The monitor glitches out when it receives an Intel hex file and responds with gibberish. The gibberish response causes the EasySXB program to lock up because it doesn't get the expected response. But when I try the .s28 file nothing useful seems to happen, although there are no lockups.
To get visibility into what's going on I connect to the monitor using TeraTerm and upload the .s28 file and get this output:
Code:
READY
>S2140000C078D8BA8E4001A9008D40DF8D27DF8D04D9
S2140000D0DF8D05DF8D06DFA20000EAA9AA8D23DFEB
S2140000E06B8DA0018E42011A8DA101E88E44011A83
S2130000F08DA201E88E4601E88E48018D23DF6B56
S804000000FB
S .0001.0002.0003.0004
READY
>
That is exactly the output shown on the getting started page! So I do a J 00:00C0 and the LED's change.
OK so the bottom line is that the EasySXB program is buggy and doesn't match the documentation. Not the best quality control and I suspect that most users a using the monitor via a terminal program.