How to suppress the "PRESS RECORD & PLAY ON TAPE" prompt?

[chysn]

Ooh, this is getting fun!

Code: Select all

LAB_F94B
	JSR	LAB_FFE1		; scan stop key
	CLC				; flag no stop
	BNE	LAB_F95C		; exit if no stop

	JSR	LAB_FCCF		; restore everything for STOP
	SEC				; flag stopped
	PLA				; dump return address low byte
	PLA				; dump return address high byte

It's getting past the BNE. It thinks STOP is pressed!

[Mike]

Ah yes. You should keep the stop flag in $91 updated by your own IRQ routine. Only then can JSR $FFE1 work as supposed.

The KERNAL IRQ routine updates the stop flag during the jiffy clock update:

Code: Select all

.EABF  20 EA FF  JSR $FFEA  ; KERNAL IRQ vectored to from ($0314)
.EAC2  [...]

.FFEA  4C 34 F7  JMP $F734

.F734  A2 00     LDX #$00
.F736  E6 A2     INC $A2
[...]
.F755  AD 2F 91  LDA $912F
.F758  CD 2F 91  CMP $912F
.F75B  D0 F8     BNE $F755
.F75D  85 91     STA $91    ; update stop flag
.F75F  60        RTS

[chysn]

I'm bypassing the normal ROM jiffy counter, and rolled my own timer for this game. Which means I'm also bypassing the VIA2 DRA read. So the last time $91 gets set is the last time the STOP key was pressed. The STOP key thus haunts the next tape operation.

There's a bevy of ways to handle this, and just clearing out $91 at some point seems to do the trick.

But geez, that was a couple hours tracing KERNAL code! I learned a ton about tape I/O in the process, so it wasn't wasted time.

[Mike]

I'm bypassing the normal ROM jiffy counter, and rolled my own timer for this game.

The tape routines install their own IRQ handlers during their operation, and it's there where the stop flag still gets updated.

There's a bevy of ways to handle this, and just clearing out $91 at some point seems to do the trick.

Or just add a JSR $F755 at the end of your custom IRQ handler. This will also make sure $91 has a valid value upon the next invocation of SAVE.

[chysn]

Or just add a JSR $F755 at the end of your custom IRQ handler. This will also make sure $91 has a valid value upon the next invocation of SAVE.

I don't need a real value for it, as long as the tape IRQ handles itself, so I'm just piggybacking off an existing LDA to STA $91. It'll never get set to $FE this way.

Thanks!

[Mike]

I don't need a real value for it, as long as the tape IRQ handles itself, so I'm just piggybacking off an existing LDA to STA $91. It'll never get set to $FE this way.

O.K. - if you only need to clear out $91 at one place in the code, that saves you one byte.

[chysn]

I don't need a real value for it, as long as the tape IRQ handles itself, so I'm just piggybacking off an existing LDA to STA $91. It'll never get set to $FE this way.

O.K. - if you only need to clear out $91 at one place in the code, that saves you one byte.

The byte and some cycles, but the most precious of all is the byte. I might need it later!

[chysn]

There's a routine in the KERNAL which checks whether PLAY or RECORD & PLAY are depressed: JSR $F8AB returns with Z=1, if that is the case. Together with a check of $BA (last used device, =1 for tape) this can be used to suppress these two prompts (and also the "OK" prompt when the user follows suit). You just put a BNE loop around this.

Oh, Mike... What do you mean by "together with a check of $BA (last used device)" here? I'm already setting device number in the SETLFS, which sets $BA, so what form does that check take? Would it make sense to call SETLFS before checking the cassette motor?

The reason I'm asking is because, despite the looping check of $F8AB, I get messages on some occasions, in both VICE and hardware. Sometimes it's "Found {filename}" during LOAD, and sometimes "PRESS RECORD & PLAY ON TAPE" during SAVE.

[Mike]

Oh, Mike... What do you mean by "together with a check of $BA (last used device)" here? I'm already setting device number in the SETLFS, which sets $BA, so what form does that check take? Would it make sense to call SETLFS before checking the cassette motor?

You only would need to suppress those tape operation prompts, if the intended storage device actually is tape. For disk drives employing that check wouldn't make sense. When I wrote this I wasn't aware that you foremostly intended to use tape with the game. Then of course a check for $BA isn't needed as you force tape operation. And SETLFS doesn't do anything other than setting $B8/$BA/$B9 from the A/X/Y registers.

The reason I'm asking is because, despite the looping check of $F8AB, I get messages on some occasions, in both VICE and hardware. Sometimes it's "Found {filename}" during LOAD, and sometimes "PRESS RECORD & PLAY ON TAPE" during SAVE.

"FOUND ..." should only ever appear in direct mode. Are you sure $9D is always $00 while your program runs? (One idea: I see you use STOP/RESTORE to restart the game. Does this possibly reset $9D to $80?)

The sporadic "PRESS RECORD & PLAY ON TAPE" prompts actually might occur when the tape buttons bounce, which would be somewhat unfortunate. Is VICE now so accurate it even emulates that?

In MINIGRAFIK, a few hundred µs elapse between the button check and the actual save operation, where the tool prepares extra data to be saved along with the raw bitmap (BASIC stub, VIC register values and a compressed copy of the colour RAM). This is probably enough time to settle things so I never got aware of this issue. With the load operation, there's no substantial delay between check and JSR $FFD5, but in the end it works out: any 'stray' screen prompts will be overwritten by the freshly loaded file ($10F1 onward) and the (re-)activation of the graphics mode by a tail call to @ON (which regenerates $1000..$10EF. $10F0 is unused).

[chysn]

Are you sure $9D is always $00 while your program runs? (One idea: I see you use STOP/RESTORE to restart the game. Does this possibly reset $9D to $80?)

Yeah, after going through the ROM disassembly, I figured that was the issue. The comments in disassembly refer to it was a "message mode flag" rather than an indication of program mode, but it seems to be doing the trick in either case.

The sporadic "PRESS RECORD & PLAY ON TAPE" prompts actually might occur when the tape buttons bounce, which would be somewhat unfortunate. Is VICE now so accurate it even emulates that?

Heh, I don't think so. It was most likely $9D.

[Mike]

(One idea: I see you use STOP/RESTORE to restart the game. Does this possibly reset $9D to $80?)

I checked that, and found yet another bug: you restart the game by jumping to $1046 but do not clean up the stack or re-init the stack pointer. After a dozen or so presses of RESTORE, the CPU stack overflowed and I got the BREAK prompt from MINIMON (which I had started up before to take a look at the code).

[chysn]

(One idea: I see you use STOP/RESTORE to restart the game. Does this possibly reset $9D to $80?)

I checked that, and found yet another bug: you restart the game by jumping to $1046 but do not clean up the stack or re-init the stack pointer. After a dozen or so presses of RESTORE, the CPU stack overflowed and I got the BREAK prompt from MINIMON (which I had started up before to take a look at the code).

Yep, that's already corrected in RC2. I would hit wAx after about 40 restarts. I'm just doing LDX #$FB / TXS, like BASIC does. Now I can restart 'til I'm purple, as my boss says for some reason.

[chysn]

The sporadic "PRESS RECORD & PLAY ON TAPE" prompts actually might occur when the tape buttons bounce, which would be somewhat unfortunate.

So... my hardware VIC/C2N combo is subject to this mechanical "bounce" phenomenon. Not always, but sometimes. Never in VICE.

It seems like the most reliable hedge against this is to redirect CHROUT. I'm still using the "check tape switches" technique. That and the CHROUT redirect actually solve different problems, with the check allowing me to create my own prompts and visual feedback. Are there things I'd rather do with the 20 bytes? Oh, yeah. But I'm saving screen memory, and I simply don't want to hear anybody say that their save data is being corrupted.

It just shows to go ya: when dealing with hardware, sometimes you have to deal with hardware. I think Yogi Berra said that in 1970.

[srowe]

The following seems to work, and I think it is safe

Code: Select all

SA	= $57
	
MSGFLG	= $9D			; KERNAL message mode flag,

VIA1DDRA	= $9113		; VIA 1 DDRA
VIA1PA2		= $911F		; VIA 1 DRA, no handshake

SETLFS  = $FFBA
SETNAM  = $FFBD
CHROUT	= $FFD2
SAVE	= $FFD8


	* = $0400-2
	.WORD	$0400

	LDA	#'S'
	JSR	CHROUT
WAIT	BIT	VIA1PA2
	BVS	WAIT
	LDA	#$00			; set all DRA lines low
	STA	VIA1PA2			; set VIA 1 DRA
	STA	MSGFLG			; disable KERNAL messages
	LDA	#%11000000		; OOIIIIII, set cassette switch to output
	STA	VIA1DDRA
	LDA	#$00			; clear file name length
	JSR	SETNAM			; clear filename
	LDX	#$01			; set default device number, cassette
	LDY	#$00			; set default command
	JSR	SETLFS			; set logical, first and second addresses
	LDA	#<$1000
	STA	SA
	LDA	#>$1000
	STA	SA+1
	LDA	#SA
	LDX	#<$1200
	LDY	#>$1200
	JSR	SAVE
	LDA	#%10000000
	STA	VIA1DDRA
	RTS

It works by flipping the Data Direction Register to make the cassette switch an output with a value of 0.

[chysn]

The following seems to work, and I think it is safe

It works by flipping the Data Direction Register to make the cassette switch an output with a value of 0.

That's a clever idea. Unfortunately, it's one byte more than the CHROUT-to-/dev/null method.