Page 1 of 1

NF300 and CAC-3 peculiarity

Posted: Mon Oct 09, 2023 1:04 pm
by stefano
This is an odd one.

While disassembling the CAC-3 and NF300 ROMs I ran into a strange behaviour of th STK-FETCH routine.

First of all, differently than on the ZX81, it was positioned at $20 permitting it to be invoked by RST rather than CALL and save a couple of bytes every time. Ok, that happens also on ROM V2, but it does more..

Code: Select all


;; STK-FETCH
00000020:	PUSH AF
00000021:	BIT 2,(IY+1Eh)      ; .. mistery bit in BREG/FLAGS
00000025:	JP 153Bh

(...)

0000153B:	JP NZ,2006h      ; <<<<---------------------------
0000153E:	POP AF

;---------------------------
; THE 'STK-FETCH' SUBROUTINE
;---------------------------
; This routine fetches a five-byte value from the calculator stack...

;; STK-FETCH
0000153F:	LD HL,(401Ch)
(...)

(IY+1Eh) points to the equivalent of FLAGS (well, actually the LAMBDA collapes BREG and FLAGS in the same byte), and bit 2 was used on the ZX81 to toggle between "K" and "L" mode.
Clearly it was reused, because the keyword editing mode was not available on the LAMBDA clones.

Moreover address $2006 is out of the normal ROM or RAM space !
This suggests a hook for an optional ROM, but still it is unclear why they chose to overload STK-FETCH. Perhaps it was simply a way to force the RST optimization in the extra ROM.

Good, now let's look around to see if this flag was set or checked elsewhere..

Code: Select all


00001069:	CALL 0784h          ; initialize BORDER
0000106C:	CALL 1602h          ; routine CLS
0000106F:	CALL 0C54h          ; ALERT BEEP
00001072:	CALL 13C2h          ; routine SLOW/FAST
00001075:	BIT 0,(IY+09h)      ; VERSN / BERG
00001079:	JP NZ,2000h      ; <<<<---------------------------

0000107C:	BIT 2,(IY+1Eh)      ; .. mistery bit in BREG/FLAGS
00001080:	JP NZ,2003h      ; <<<<---------------------------

Uh oh, now we spotted two more entries in the startup code, $2003 and $2000 !
Interestingly, $2000 was present also on the "normal" V2 ROM "

Code: Select all


(...)
00000F92: F9		LD SP,HL				; and initialize the stack-pointer to this location.
00000F93: E5		PUSH HL					; HL now holds the current machine stack
00000F94: ED 73 02 40	LD (4002h),SP		; set the error stack pointer ERR_SP to the base of the now empty machine stack.
00000F98: E1		POP HL
00000F99: CD EB 06	CALL 06EBh		; initialize BORDER
00000F9C: CD 7D 1C	CALL 1C7Dh		; routine CLS
00000F9F: CD B0 0B	CALL 0BB0h		; ALERT BEEP
00000FA2: CD A9 12	CALL 12A9h		; routine SLOW/FAST
00000FA5: FD CB 09 46	BIT 0,(IY+09h)		; VERSN / BERG
00000FA9: C2 00 20	JP NZ,2000h      ; <<<<---------------------------


.and in the V1 ROM the same entry is mentioned but reacts to bit 0 in the MODE flags, probably somewhat equivalent to bit 0 of VERSN/BERG in V2 ROM.

Code: Select all


000004E9:	LD (4035h),A
000004EC:	CALL 1692h       ; 
000004EF:	CALL 0450h       ; BEEP, fixed tone
000004F2:	CALL 0285h       ;; SLOW/FAST
000004F5:	LD A,(4006h)     ; editor MODE
000004F8:	RRA
000004F9:	JP C,2000h      ; <<<<---------------------------


So, was it the colour module? Or what?

EDIT:
$2000 - $3000 is also used to store colour information, this possibly means that the stored data could be used to execute code as well (the colour layer can be disabled).