SC/MP programming chat.

[Phil__G]

Thats right, -128 ($80) in a memory-reference instruction means use E as the offset - not in the case of a jump,

Originally Posted by Prog & asm manual Section 3.3.3

If the displacement in an indexed or an auto-indexed memory reference instruction equals
-128d (X'80), then the contents of E are substituted for the displacement for the given instruction.

[SiriusHardware]

Have you got a .asm file which uses the 'wraparound' feature which didn't originally work but was fixed in San's most recent official version, so we can check that I haven't broken that?

[Phil__G]

I compared the KB+ object code pre & post mod, identical
It uses stack & vars 'below zero' just like like scios does, in fact the registers are at the very same addresses as scios

[SiriusHardware]

Fair enough.

I think I can see a further single line edit to disable the -128 offset warning when the instruction mnemonic in the line currently being processed is a 'J..'. (Jump instruction of any sort).

I may give it a try later tonight, time allowing.

[Phil__G]

You mean to get rid of the unwanted line 15 'E' register warning in the post#38 .prn above?
That would be nice, though not essential...

[SiriusHardware]

Yes, I think I can make that go away when the instruction being parsed is any sort of jump instruction.

If I do that, I take it the warning is still needed in the case of all other relative access instructions because an offset of -128 which happens to come about because the LD / ST / etc instruction is exactly that far away from the target address will be interpreted as 'use E as the offset', and that may not be what the coder intended?

[SiriusHardware]

Here's a preliminary shot at it, with another edit to crscmp.py

All you have to do is add a bit to the third line from bottom of the same code block we modified before. This adds the condition that the instruction currently being parsed must NOT be a jump instruction if the -128 offset warning is to be generated.

    NoMore()
    if dec.Asm.Pass == 2:
        # Only test range in pass 2
        if offset < -128 or offset > 127:
            # The normal offset is out of range
            if offset2 < -128 or offset2 > 127:
                # We also didn't do a full page wrap
                errors.DoError('range', False)
            else:
                offset = offset2
        if offset == -128 and absolute and dec.Asm.Mnemonic[0].upper() != "J":
            # Offset calculated to -128, are you sure!
            errors.DoWarning(dec.Cross.Name + 'offset', True)

This is the output the modified crscmp.py produces from your jump2.asm test code. No sign of the warning this time.

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

[Phil__G]

Okay, I get the same good results on the test files, so I tried a substantial source file...
Bear in mind that KB+ is quite a large source with lots of jumping around including page-wrapping to the stack & variables below $0FFF...
Assembling with the "and not a jump" line in the cross file, the listing files and hex files are identical to those produced using Sans emailed cross file.
My present thoughts are that the fix is good and it hasnt broken anything!
Good work G

For anyone not familiar, this isnt the crscmp.py cross-file on Sans SB Projects download page, thats the old one with the wrapping error.
San fixed this and emailed a new cross file to those who queried it, but hasnt updated his Website or distribution.
Sans github has the emailed file, this is the 'official' latest which has the "jump-out-of-range" error. Sirius's mod is to this file.

[SiriusHardware]

Thanks for the update. Still no response from San himself, sad to say.

[Phil__G]

Ian (Coolsnaz2) asked for Sirius's modified cross file to be posted, but rather than post it here where it can't be updated, I put it on the http://philg.uk sc/mp page here
It goes in the sbapack folder.

[SiriusHardware]

There is enough info in the preceding posts to allow anyone to make the two single line edits needed to try out these fixes provided they already have San's unreleased latest version of the CRSCMP.PY 'cross' file which is available on Phil's site.

History has shown us that it is a bad idea to attach trial / experimental versions of software or scripts to forum posts which they can't easily be taken down from if someone later finds that something has gone wrong.

If nobody finds any holes in it after a couple of months of active use then it may be OK to put it in a forum post. I just wish we could get hold of San Bergmans to ask him to either implement his own official fixes for the problems mentioned, or have a look at what we have done and green light it.

[Phil__G]

I've typed-up and been working through the Erik Skovgaard 'Subroutine supervisor' which we discovered in Robert D. Haviland's book "How To Design, Build & Program Your Own Advanced Working Computer System".
Eriks SC/MP code is really clever & compact, and for me (being a bit dim) it took some time to understand all its features. It has some really useful and code-saving tricks but doesnt implement a proper stack as I'd hoped, so theres no nesting - but a great idea to build on. I had the idea to look Erik up, but apparently there are many Erik Skovgaards, one that sounded likely is a radio ham in California - I dont know. I'm going to play around with Eriks idea & see how it goes

In a nutshell, you set P3 to SSUP-1 and leave it there. To use it thereafter you code four bytes: XPPC P3, function_number, address_highbyte, address_lowbyte.
For example, any calls or jumps to anywhere, you code as XPPC P3, 3, addr_hi, addr_low. This means only 4 bytes per 'call' and a great benefit is that the Acc is saved
A 'call' (function 3) remembers the point in your code where the call was made, & 'RET' uses this to effect a return - with the Acc intact
The function RET (function_number 0) ignores addr_hi, addr_low but unless I've misunderstood they need to be there as dummies (the LD @3(P3) steps over func, addr_hi, & addr_low)
The load & stores allow you to use (addr) like you'd use (HL) in a Z80. It even allows indirect addressing where addr_hi, addr_low contain the address of a vector.

	.cr scmp
	.LF SSUP.PRN
;	.tf SSUP.hex,INT,32
;
P1	=	1
P2	=	2
P3	=	3
;
; Erik Skovgaard subroutine supervisor
; ASSUMES P2=KITBUG STACK ($0FF6)
; CALL XPPC P3 (P3=SSUP-1)
; THE FOLLOWING 3 BYTES CONTAIN
; 1. FUNCTION CODE AT P3+1
; 2. ADDRESS HIGH  AT P3+2
; 3. ADDRESS LOW   AT P3+3
; FUNCTION CODE IS AS FOLLOWS:
;  00=RETURN (ADDR BYTES IGNORED)
;  01=READ (RESULT IN ACC)
;  02=WRITE FROM ACC
;  03=GOSUB/GOTO (FAR JUMP)
; THE FOLLOWING ARE INDIRECT ADDR MODES
; IE P3 POINTS TO THE ADDR TO BE USED
; P3+0 IS HIGH, P3+1 IS LOW ADDR BYTE
;  04=READ INDIRECT
;  05=WRITE INDIRECT
;  06=GOSUB INDIRECT
; THE DEPTH OF NEXTING MAY BE CONTINUED
; BUT ONLY THE FIRST RETURN ADDR IS SAVED
;
; P2-11, -13 AND -14 MUST NOT BE 
; DESTROYED BY THE SUBROUTINE
; P2-12 AND -15 ARE ALSO USED.
; TIMING: 341 FOR GOSUB/GOTO, 153 FOR RET.
; +190 EXTRA MICROCYCLES FOR INDIRECT
;
	.OR $900

RET:	LD	-13(P2)		; (-13)(-14) IS CALLING ADDR HI LO
	XPAH	P3		; RESTORE P3 HI
	LD	-14(P2)		; AND P3 LOW
	XPAL	P3
	LD	@3(P3)		; ADJUST FOR RETURN,
	LD	-11(P2)		; ...STEP OVER PARAMS
	XPPC	P3
	; ENTRY POINT
SSUP:	ST	-11(P2)		; STORE ACC
	LD	1(P3)		; GET FNS WORD
	JZ	RET
	ST	-12(P2)		; STORE FNS WORD
	LD	2(P3)		; SET UP NEW P3
	ST	-13(P2)		; 
	LD	3(P3)		; H=P2-13
	XPAL	P3		; L=P2-14
	ST	-14(P2)		; SAVE OLD P3, IE CALLING ADDR
	LD	-13(P2)
	XPAH	P3
	ST	-13(P2)
STST:	DLD	-12(P2)
	JZ	READ
	DLD	-12(P2)
	JZ	WRITE
	DLD	-12(P2)
	JZ	GOTO
	LD	0(P3)		; GET SECONDARY ADDR
	ST	-15(P2)		; STORE TEMP
	LD	1(P3)
	XPAL	P3
	LD	-15(P2)
	XPAH	P3
	JMP	STST		; TEST AGAIN
READ:	LD	0(P3)
	ST	-11(P2)
	JMP	RET
WRITE:	LD	-11(P2)
	ST	0(P3)
	JMP	RET
GOTO:	LD	@-1(P3)		; ADJUST P3
	LD	-11(P2)		; RESTORE ACC
	XPPC	P3
	JMP	SSUP

	.END

[Mark1960]

There is probably no reason to use 01, 02 etc for the function codes, why not just use XPAL p0 instead of a chain of DLD and JZ? If you use auto index when you load each parameter byte you don’t need to adjust P3 to skip parameters, so you could have varying number of parameters for each function.

[SiriusHardware]

Phil, in that version of the CRSCMP.PY file that you have linked to under 'here' in #50, the comment line before the first modified line still refers to the IF acting only in the case of a 'not forward' jump.
For the sake of completeness maybe also edit the comment so it is more accurate.

I mean this bit here:

    NoMore()
    # if dec.Asm.Pass == 2 and not forward:
    if dec.Asm.Pass == 2:

The comment (which starts with a '#' symbol) should probably now read:

    NoMore()
    # if dec.Asm.Pass = 2
    if dec.Asm.Pass == 2:

(Which is virtually what the code says anyway).

[Phil__G]

Done! thanks G

BTW functionally, the amended cross file has been perfectly well behaved

[Phil__G]

This is the 9600 baud output I did for the Aliexpress receipt-printer demo on the MK14.
For the loop of 8 bits its based on Sylvesters 31250 baud MIDI masterpiece of cycle-counting
Output is to the SC/MP SOUT pin (pin 23) which is on the top edge connector
The printer needs only two wires, TTL serial in and common ground.
To power the printer I used a 2S 18650 Lithium pack as it takes too much current to be USB powered.
The routine just loops for the demo, but could easily be a sub (see comments at the end)
It does the job, I'm sure it could be streamlined of course, the tricky bit is the 104uS bit delay,
which mustn't affect E or A (and we dont have time to save & restore them for a DLY !)

	.CR	scmp
	.LF	out96.prn
	.tf 	out96.hex,int
;
; send MK14 message string to Aliexpress mini receipt-printer
; Based on Sylvesters midi code which is a cycle-counting masterpiece  :-)
; the "adi 40" sets bit 6 in AC register, which gets rotated right, 
; eventually setting bit 7 to end loop at the JP after 8 data bits sent
;
	.or	0F20h
	nop
start:	ldi	20	; a delay counter - otherwise prints
	st	count	; ...continuously and wastes paper!
	
	ldi	1	; set static high
	xae		; 
	sio		; 

stdel:	ldi	$ff
	dly	$ff	; startup delay
	dld	count
	jnz	stdel

	ldi	#text
	xpal	p1
	ldi	/text
	xpah	p1	; p1 --> text string

loop:	ld	@1(p1)	; get char, increment pointer
	jz	start	; end of string, restart

out96:	xae		; data byte
	ldi	00	; start bit b0
	xae		; to send. E=0, A=char
	sio		; sout start bit
	xae		; data to send. E=char
	ccl		;

; 72 cycles to add to start bit
	nop		; 5
	lde		; 6
	ldi 19		; 10
	dly 0		; 51

	ldi	00	; rotating mask
shift:	rr		; 5+7+5+10+5 = 32 uS
	sio		; data bits b0 to b7
del72:	xae		; 72 microcycle delay preserving A and E
	xae
	xpal	p1	; all these wacky instructions have no
	xpal	p1	; function other than that their combined
	xpal	p1	; cycle time adds up to 104uS for 9600 baud 
	xpal	p1	; whilst avoiding the use of A or E
	xpal	p1
	xpal	p1
	nop
	nop

	adi	40h	; accumulate bits
	jp	shift	; until 8 done	5+5+11+11 = 32 uS
	xae		; FF to E reg
	sio		; sout stop bit

	ldi	45	; decimal	104-10 (LDI) -7 (XPPC P3) = 87 uS
	dly	0	; stop bit

	jmp loop	; *** Temporary for this demo ***
			; ...or...
	xppc	3	; *** if out96 is a subroutine ***
	jmp	out96	;

count:	.db	0	; just a delay counter to save paper

text:	.DB	"As you can see, the",13,10
	.DB	"Science of Cambridge MK14 is",13,10
	.DB	"a jolly fine buy",13,10,10,0
	.end

Vid: https://www.youtube.com/watch?v=530YZAUb-Mw

Cheers
Phil

[Phil__G]

I wrote some notes as I was admiring Sylvester's code:

Based on Sylvesters midi code which is a cycle-counting masterpiece  :-)
the "adi 40" sets bit 6 in AC register, which gets rotated right, 
eventually setting bit 7 to end the jump-if-positive loop after 8 data bits sent

Assuming the ascii char is in E after the xae:

			ACC:
start			00000000
xae, ccl, ldi 0		00000000
sio			start bit
add40			01000000
rr			00100000
sio	b0
add40			01100000
rr			00110000
sio	b1
add40			01110000
rr			00111000
sio	b2
add40			01111000
rr			00111100	
sio	b3
add40			01111100
rr			00111110
sio	b4
add40			01111110
rr			00111111
sio	b5
add40			01111111
rr			10111111
sio	b6
add40			11111111
rr			11111111
sio	b7
jp drops through
xae, si			stop bit

[SiriusHardware]

Nicely documented, thanks Phil. I take it this is based on the initial / first version of Silvester's MIDI output code which outputs the serial data stream in the sense normally expected for UART-level transactions (TX line idle state high, TX line active state low?)

[Phil__G]

Yes thats right G, initialising SOUT to a 1 beforehand isnt a problem

[SiriusHardware]

I did find it to be a problem specifically for MIDI, my Yamaha synth really objected to the constant 'active' (low) level present on the SO output after the MK14 was reset, hence my badgering Silvester to do an 'upside down' output version of the output code, which he very kindly did. It actually made the MIDI output hardware (potentially) simpler, just a transistor and 3 resistors, although I played safe by buffering SO anyway.

Your printer probably just discards anything with framing errors and waits patiently for a legitimate serial byte, so it is obviously better behaved in that respect.