SC/MP programming chat.

[Phil__G]

That last post can still be used for the original NS Kitbug, but is redundant for
KitbugPlus which now has a serial loader that works very well

Meanwhile, back at the ranch...
I've been playing with PUTC and GECO in KitbugPlus, experimenting with higher baud rates. PUTC isnt a problem, but at higher speeds GECO is too busy and just cant get the bits out fast enough. GECO takes async serial input whilst simultaneously echoing bit by bit to transmit, to give full duplex - so its very busy code.

I have both PUTC and GECO running reliably at 2400 which is nice, but I was hoping for 4800, maybe even 9600. The problem is that GECO isnt a tight loop and the bitbang serial instructions simply take too long. With the inherent longer delays, 110 baud, 300, 1200 are not a problem, but not so 4800.

I havent done it yet but I'm sure 4800 and possibly 9600 will be fine if we give GECO an easier time and go half-duplex with Teraterm set to local echo 'on'.
As an example, the PICL uses half-duplex and needs local echo, it doesnt bother me but I know some really dont like having to use local echo.

My question is:
What does the panel think - which is preferable, faster baud rate but necessitating local echo, or full duplex at 2400 without the need for local echo?
or...
maybe conditional assembly in the source, provide both and give the choice?

...actually...

... I think I might have answered my own question...


.

[ortek_service]

Originally Posted by Phil__G

>>
I havent done it yet but I'm sure 4800 and possibly 9600 will be fine if we give GECO an easier time and go half-duplex with Teraterm set to local echo 'on'.
As an example, the PICL uses half-duplex and needs local echo, it doesnt bother me but I know some really dont like having to use local echo.

My question is:
What does the panel think - which is preferable, faster baud rate but necessitating local echo, or full duplex at 2400 without the need for local echo?
or...
maybe conditional assembly in the source, provide both and give the choice?
>>
.

Just a thought, rather than conditional-assembly, would it be possibly to have the routine support multiple baud rate / echo options options via checking a 'local-variable' config memory location and still be fast enough when required?
It may then be possible to configure this either via sending a command within Kitbug+ or selecting an option at reset etc.
That way you'd only need one common version of the binary, although would have to decide what to default to, if using a command to change it. Plus might then need to reconfigure Terminal program, if changing baud rate from the default, without using some local DIP-switches on an I/O-space address etc.

Otherwise, I think having higher-speed would be preferably for small penalty of making terminal emulator locally-echo, as it made quite a difference on your PICL version.

[Phil__G]

Has anyone else noticed that SBASM will happily assemble a beyond-range relative jump, with no warning or error message?
Say you code a JMP from 0x800 to 0x890, thats out of range but SBASM will work out the offset as a 'positive' ie forward jump,
when of course an offset above 80h is actually a backward jump:

0000-                  4        ; SBASM relative jump offset error demo
0000-                  5
0800-                  6                .OR $800
0800-08                7 (   5)         NOP
0801-90 8D             8 (  11)         JMP     TOOFAR  ($8D is backwards)
0803-42 4C 41 48 
     20 42 4C 41 
     48 20 42 4C 
     41 48 00          9                .DB     "BLAH BLAH BLAH",0
0890                  10                .NO     $890
0890-C4 00 37 C4 
     00 33 3F         11        TOOFAR: JS      P3,1
0897-                 12                .END

I'm finding I have to manually check every long-ish jump to make sure its going in the right direction, & if not, add a midway stepping-stone

.

[coolsnaz2]

Yes Phil, I came across the issue while I was developing Solitaire, and had to add a couple of stepping-stones. I am a late adopter of SBASM and just assumed that’s the way it is.

[SiriusHardware]

It doesn't have to be, report the issue to San Bergmans (author of SBASM) and he will, in my experience, be happy to fix it. out of range jumps should definitely be flagged as an error.

I've reported several bugs to him before (in the Z80 cross, as it happens, rather than the SC/MP cross), and he has always responded positively and fixed them quickly - not bad for someone who doesn't charge for his software.

[Phil__G]

Could you PM his contact details to me please G?

[SiriusHardware]

I could, but I have just been on his website and mentioned the issue to him. That was only minutes ago so we'll have to give him a chance to respond.

I find the icon-driven user interface on his website slightly obscure and he is very spam-shy, probably due to a bad experience in the past, so attempting to send him an email will lead you on a little dance before you finally get the opportunity to email him.

Start on the home page here

https://www.sbprojects.net/index.php

and click on the little black envelope on the green bar, lower right corner of the page. Then follow the steps, which involve clicking on the envelope symbol a couple more more times, and you will eventually get a link to email him on.

It would do no harm for you to raise the issue independently, I'm sure.

[SiriusHardware]

Incidentally does this bug also apply to backward jumps and does it apply to any other relative addressing instructions such as LD and ST?

(I'm at work, so I don't have SBASM in front of me at the moment).

[Phil__G]

Ah ok I just wondered if you had a personal email, I've tried Sans published email a couple of times in the past about his Nano 6802 board but never had a reply.
Cheers
Phil

[SiriusHardware]

No reply as yet but I don't know how often he checks it. When I get back home I'll look through and see if I still have any of the old emails I traded with him but there is no guarantee that he will still be using that one of course.

The Python source code for SBASM is very nicely written, I would think that anyone who is actually quite good at Python could look through it and devise a temporary fix until we have an official one.

The answer to my question though - is this problem limited to forward jumps, to all relative jumps, or does it also affect other instructions, such as LD and ST, which use relative addressing?

[Phil__G]

I've emailed San, lets see what happens. It doesnt seem to affect backward jumps, they do get flagged if out of range (see error below)
but note that the forward jump to 'TOOFAR:' is coded as $85 which is a backward offset:

0000-                  3        ;       .tf jumptest.hex,INT,32
0000-                  4        ;
0800-                  5                .OR $0800
0800-08                6 (   5)         NOP
0801-06                7 (   5) LOOP:   CSA
0802-E4 06             8 (  10)         XRI     6
0804-07                9 (   6)         CAS
0805-C4 FF            10 (  10)         LDI     $FF
0807-8F FF            11 ( 13+)         DLY     $FF
0809-90 85            12 (  11)         JMP     TOOFAR
080B-                 13
0890                 14                .NO     $0890
Source file: jumptest.asm

*** Error: Out of range
     15 TOOFAR: JMP     LOOP

0892-                 16                .END

[SiriusHardware]

I found some old emails to / from San but they dated from around 2012 / 2013 and the address ends in .com, which at the time his website was (a .com) but he has since gone with .net, probably to make it clearer that he is not a commercial enterprise or entity - so I would be very surprised if that old email address was still live.

Even in the modern day he seems to say that he changes his actual email address as soon as it starts attracting SPAM so, while I'm sure I contacted him more recently it is very likely that he has changed it even since then.

Let's see what, if anything, comes back from the current email address.

If he has trapped the 'reverse jump out of range' instance it sounds possible that there may also be a 'forward jump out of range' trap which is just not working due to a typo in the line of code. One of the Z80 cross bugs I reported was an instance where a a line contained 'flase' instead of the clearly meant 'false'.

[SiriusHardware]

I've said before that my own Python programs are not really Python code at all, but 1980s BASIC in my head translated to the nearest equivalent in Python, so I am not even close to being a competent Python coder.

Still, I had a little look. All I can find related to 'range' in the CRSCMP.CR cross file is this:

    NoMore()
    if dec.Asm.Pass == 2 and not forward:
        # Only test range in pass 2
        if offset < -128 or offset > 127:
            # Range error
            errors.DoError('range', False)
        if offset == -128 and absolute:
            # Offset calculated to -128, are you sure!
            errors.DoWarning(dec.Cross.Name + 'offset', True)

The very first line seems to be saying "If this is assembler pass two and the offset is not a forward offset, then..."

And yet in the third line within that 'if' block it is looking for offset <-128 or offset >127, which would be out of range for (a) a backward jump and (b) a foward jump.

My problem with this is that the range limit check for both backwards and forwards only seems to be getting done after the status of the forwards / backwards flag (FORWARD) has been checked and found to be 'backwards'.

I wonder, if we changed that first line to

if dec.Asm.Pass == 2:

Would it then check the offset range on both backward and forward jumps?

A word of warning, when attempting to edit a Python script, save a backup of the unedited, working script somewhere first because with python code blocks being denoted by indentation instead of, say, curly brackets, it is all too easy to mess up the indentation and get the code into such a bad state that you can't get it back into working order, especially if you didn't originally write it.

[Phil__G]

I dunno. I'd be scared of breaking it, Python isnt my thing, I've no confidence messing with it...
The most recent update I could find on sbprojects.net is dated June 23, so he is still maintaining his website
I left a message on wisclub.nl and also on oeioei.nl which may or may not be San
I suppose it wouldnt be right to try via his work, Dual Inventive....

Maybe the only way is to click 'Donate', Paypal San a well-earned tenner, and leave a message?

[SiriusHardware]

I have actually done that before simply because I felt he deserved something for the work but I didn't really connect that with the fact that he also chose to communicate with me.

As I said, you can't break anything permanently if you stash the original (working) script file away somewhere safe before working on a copy. It does seem to me there is a logical error in that function in #33 ,where it first seems to check specifically for the case of a backward offset, and then within that conditional block, checks to see whether the offset is too far minus AND whether it is too far plus.

I'll try it here if you give me a sample .asm file which SHOULD fail with a forward 'jump out of range" error, but currently doesn't.

[Phil__G]

Here you go G. If you look at the .prn first, you'll see the forward jump-too-far is (wrongly) coded and the backward jump-too-far is (correctly) errored out.

[SiriusHardware]

With my CRSCMP.CR file modified as suggested in #33 above:

Please specify file name: jump.asm

Assembling....

Pass one
Loaded scmp overlay version 3.01.02

Pass two
0000-                  1                .cr scmp
0000-                  2                .tf jump.BIN,BIN
Source file: jump.asm

*** Error: Out of range
     12         JMP     TOOFAR  ; This should give an error but doesnt

*** Error: Out of range
     15 TOOFAR: JMP     LOOP    ; This should give an error and does!


2 Errors found during assembly.
0 Warnings found during assembly.

Of course I can't say at this stage whether this small mod will bring the roof down somewhere else. I don't think I have the 'current' version of CRSCMP.CR, unfortunately. Where do I find that again, and I'll mod that and email the modified version to you. (I don't want to post barely tested code in a post, where it can't be taken down easily).

Edit: I notce from the above output that I have CRSCMP version 3.01.02. Is that what everyone else is running or is there a newer version of the 'cross' file?

[Phil__G]

That looks promising
I just checked if mine was up to date and yes its Sans current (4/4/19) release:

SB-Cross Assembler version 3.03.06
Loaded scmp overlay version 3.02.00

Anywho, I just tried your mod and as far as i can see, its spot on!

Heres my test source with some good & some bad jumps:

	.cr scmp
	.tf jump2.hex,INT,32
	.LF jump2.prn
; SBASM relative jump offset test

	.OR $800
LOW1:	JMP	HIGH1 ; too far, should error
	JMP	HIGH1 ; this ones ok, should be no error
	JMP	HIGH1 ; this ones ok, should be no error
	JMP	HIGH1 ; this ones ok, should be no error

	.NO	$87A
	JMP	LOW1  ; this ones ok, should be no error
	JMP	LOW1  ; this ones ok, should be no error
	JMP	LOW1  ; this ones ok, should be no error
	JMP	LOW1  ; too far, should error
HIGH1:	JMP	LOW1  ; too far, should error

	.END

and the result:

0000-                  4        ; SBASM relative jump offset test
0000-                  5
0800-                  6                .OR $800
Source file: jump2.asm

*** Error: Out of range
                       7 LOW1:          JMP     HIGH1 ; too far, should error

0802-90 7E             8 (  11)         JMP     HIGH1 ; this ones ok, should be no error
0804-90 7C             9 (  11)         JMP     HIGH1 ; this ones ok, should be no error
0806-90 7A            10 (  11)         JMP     HIGH1 ; this ones ok, should be no error
0808-                 11
087A                  12                .NO     $87A
087A-90 84            13 (  11)         JMP     LOW1  ; this ones ok, should be no error
087C-90 82            14 (  11)         JMP     LOW1  ; this ones ok, should be no error

*** Warning: Offset is -128, E register conflict
087E-90 80            15 (  11)         JMP     LOW1  ; this ones ok, should be no error

*** Error: Out of range
                      16                JMP     LOW1  ; too far, should error

*** Error: Out of range
                      17        HIGH1:  JMP     LOW1  ; too far, should error

0884-                 18
0884-                 19                .END

This looks spot on to me, ta v much! The 'E' warning is misplaced, but its only a warning so no problem...
Using the modded cross, I just assembled KitbugPlus and Life, both of which are large-ish programs, and the resulting hex and prn files compare perfectly
with pre-mod versions
Phil


.

[SiriusHardware]

So far, so good - where do I find the current version of CRSCMP.CR - is it in the current 'release' of SBASM3 or do I have to go looking for it in some quiet corner of San's website?

[SiriusHardware]

As regards the 'E' warning, remind me - a -128 offset is legal as long as the instruction is a jump instruction because they never use the 'E' register as the offset?

If so, the second part of the function should probably include a check on the instruction type or class, and if the instruction is a jump instruction and the offset works out at -128, no warning should be given. I'd have to understand the code a bit better to be able to make that change.