NF300 and CAC-3 peculiarity

[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).

[David G]

I know this is a year later ... but was just using your ROM V2 comments to solve a problem. I appreciate your hard work

On the ZX81 I believe the ROM (0-1FFF) is shadow mapped to 2000-3FFF. Could it be the same with these machines? if so, JP C,2000h would reset the machine (JP 0000). What would 2003 do, and more importantly what is the point of those flag bits. Do you have a copy of NF300 and CAC ROMs? My hard drive was dropped, so the roms are lost, well they are still on the hard drive, but the bearing doesn't spin freely (a Samsung 2TB drive). I had considered those file non-critical so didn't put them in my off-site backups