005A Protocol - Record Key Processing Vector for S3C8+

[jmezz13]

I've been using RMPB to review existing protocols and have been focused on the NEC 005A since it has applicability to one of the issues that brought me back here in the first place.

Anyway, I looked at an old doc that Rob did commenting on the 005A protocol for the SC38, and I think I notice a difference between that code and what is being used today.

Here is an excerpt from Rob's commented code:

Code: Select all

L17:	INC	R01		; skip control byte
	LD	RC0, R03	; load control byte to C0

	BTJRF	L33, RC0.2	; if bit2=0, jump to main

				; *** 04/05/24 processing ***
	CALL	0120H		; record key pressed?
	JRNC	L33		; no, skip to main

	BTJRT	L2D, RC0.5	; if bit5=1, jump
	LD	R04, R05	; copy dev2 to dev1
	COM	R05		; comp dev2
	JR	L3B		; jump back in

Notice the CALL 0120H related to the vector for checking if the record key is pressed.

Here is the disassembled code from importing the current 005A protocol using RMPB (the same result came from importing the Hex into PB)

Code: Select all

L0:	INC	R01
	LD	W0, R03
	BTJRF	L2, W0.2
	CALL	0146H
	JR	NC, L2
	BTJRT	L1, W0.5
	LD	R04, R05
	COM	R05
	JR	L3

This is for the S3C8+ instead of the SC38 so the vectors are different, but note that the Call is to 0146H which is the IR Engine vector not the Check Record Key vector (which is supposed to be 0133H?). Is that right? This is UEI code from what I understand, but it seems like something has changed since Rob commented on the code for the S3C8.

I have no idea how often the Record Key mode is used, so in most cases this wouldn't present a problem, or maybe I'm not reading this right.

[The Robman]

I'm sure they've tweaked the code several times over the years. Efficiency is a key part of executors, so we're/they're always trying to trim off a byte or two of code. I'd need to review the whole code to see if the RECORD button test is still in there.

[jmezz13]

I'd need to review the whole code to see if the RECORD button test is still in there.

Here's the code I get in RMPB when I import the NECx1 (005A) protocol (not sure if you were asking me for this ).

Code: Select all

			PROC	S3C80
			ORG	FF00H	;Byte count = 120
FF00	43		DB	43H	;Carrier ON: 8.625uSec
FF01	8B		DB	8BH	;Carrier OFF: 17.625uSec
FF02	31		DB	31H	;dev 3, cmd 1 bytes
FF03	8B 12		JR	L0
FF05	CF		DB	CFH	;pf0: R28
FF06	44		DB	44H	;pf1: R29
FF07	08 08		DW	0808H	;pd00/pd01: R12/R13
FF09	01 18		DW	0118H	;pd02/pd03: R14/R15
FF0B	01 06		DW	0106H	;pd04/pd05: R16/R17
FF0D	01 18		DW	0118H	;pd06/pd07: R18/R19
FF0F	03 39		DW	0339H	;pd08/pd09: R1A/R1B
FF11	D2 DC		DW	D2DCH	;pd0A/pd0B: R1C/R1D
FF13	11 94		DW	1194H	;pd0C/pd0D: R1E/R1F
FF15	08 B6		DW	08B6H	;pd0E/pd0F: R20/R21
FF17	20 01	L0:	INC	R01
FF19	08 03		LD	W0, R03
FF1B	37 04 15		BTJRF	L2, W0.2
FF1E	F6 01 46		CALL	0146H
FF21	FB 10		JR	NC, L2
FF23	37 0B 07		BTJRT	L1, W0.5
FF26	E4 05 04		LD	R04, R05
FF29	60 05		COM	R05
FF2B	8B 0E		JR	L3
FF2D	B6 04 80	L1:	XOR	R04, #80H
FF30	B6 05 80		XOR	R05, #80H
FF33	37 0B 05	L2:	BTJRT	L3, W0.5
FF36	E4 04 05		LD	R05, R04
FF39	60 05		COM	R05
FF3B	E4 06 07	L3:	LD	R07, R06
FF3E	60 07		COM	R07
FF40	20 11		INC	R11
FF42	37 06 05		BTJRF	L4, W0.3
FF45	F6 01 04		CALL	0104H
FF48	7B 12		JR	C, L6
FF4A	37 09 15	L4:	BTJRT	L7, W0.4
FF4D	37 02 06		BTJRF	L5, W0.1
FF50	F6 01 49		CALL	0149H
FF53	F6 01 46		CALL	0146H
FF56	37 01 03	L5:	BTJRT	L6, W0.0
FF59	46 29 0D		OR	R29, #0DH
FF5C	46 29 01	L6:	OR	R29, #01H
FF5F	8D 01 49		JP	0149H
FF62	E4 20 1E	L7:	LD	R1E, R20
FF65	E4 21 1F		LD	R1F, R21
FF68	37 01 EB		BTJRT	L5, W0.0
FF6B	F6 01 49		CALL	0149H
FF6E	E6 28 C1		LD	R28, #C1H
FF71	60 04		COM	R04
FF73	E6 12 01		LD	R12, #01H
FF76	8B E4		JR	L6

[mathdon]

The S3F80 is the processor I know least about, as when I joined the forum there were many S3F80 experts and I left that processor to them. But I have looked again at the MAXQ code for PID=005A and record key handling is definitely present in that. It is in effect if bit 2 of the first fixed byte is set, in which case there are two alternative special behaviours for this key with bit 5 determining which applies. Bit 5 has a different significance when bit 2 is clear.