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

[chysn]

Is this the best way to suppress system tape prompts?

Code: Select all

lda #<LONE_RTS      ; Redirect CHROUT to a lone RTS
sta $0326           ;   to suppress prompts
lda #>LONE_RTS      ;   ,,
sta $0327           ;   ,,
            
; and then after the operation
            
lda #$7a       ; Put CHROUT back in some way
sta $0326
lda #$f2
sta $0327

; LONE_RTS is just a label given to some random RTS in the code...
LONE_RTS:   rts                 ; This is a CHROUT vector destination. Leave be!

This works, but is there a less code-y way to do it?

[Mike]

I suppose you have an own method to notify tape users to either press PLAY or RECORD & PLAY?

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.

I use this routine in MINIGRAFIK to indicate a tape save with the border temporarily blinking red/black (and tape load uses green/black) as any 'normal' screen prompt would interfere with the graphics bitmap.

[srowe]

Is this the best way to suppress system tape prompts?

Messages are controlled by two bits in MSGFLG ($9D)

Code: Select all

MSGFLG	= $9D			; KERNAL message mode flag,
                                ; $C0 = both control and error messages,
                                ; $80 = control messages only,
                                ; $40 = error messages only
                                ; $00 = neither control nor error messages

The correct method of changing the flags is via the SETMSG KERNAL routine but you can just write to the location.

[Mike]

Messages are controlled by two bits in MSGFLG ($9D) [...]

This doesn't work for the aforementioned prompts. They appear regardless how $9D is set - unless the user already has pressed PLAY or RECORD & PLAY!

The other prompts ("FOUND ...", "LOADING ...", "SAVING ...") should already be suppressed, as $9D is set to $00 upon entering program mode.

[srowe]

This doesn't work for the aforementioned prompts. They appear regardless how $9D is set - unless the user already has pressed PLAY or RECORD & PLAY!

The other prompts ("FOUND ...", "LOADING ...", "SAVING ...") should already be suppressed, as $9D is set to $00 upon entering program mode.

Ah right, I'd missed that these two skipped the test of MSGFLG and jump directly to the display routine.

A dirty way to do this would be to patch the CHROUT vector to be an no-op for the duration of your save routine.

Code: Select all

; display KERNAL I/O message

KMSGSHOW
	LDA	KMSGTBL,Y		; get byte from message table
	PHP				; save status
	AND	#$7F			; clear b7
	JSR	CHROUT			; output character to channel
	INY				; increment index
	PLP				; restore status
	BPL	KMSGSHOW		; loop if not end of message

[Mike]

Ah right, I'd missed that these two skipped the test of MSGFLG and jump directly to the display routine.

... and there's a good reason for this: the running program would otherwise 'stop' execution with no indication for the user what to do.

A dirty way to do this would be to patch the CHROUT vector to be an no-op for the duration of your save routine.

That's what the OP already did.

[srowe]

That's what the OP already did.

Yeh, I should learn to read the question.

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

The routine at $f8ab turned out to work perfectly! It's elegant, and replaced 20 bytes of vector setting with a 13-byte test (that includes a Stop key check). It also happens to alleviate a problem I was experiencing when the Stop key was pressed during transfer. When the user interrupts a save or load with the Stop key, the next invocation of SAVE or LOAD fails. But it doesn't simply fail, it does something weird to the stack so that I return to the routine that called the load or save subroutine.

I plan to delve into some other save-to-tape routines (maybe Adventureland) to make sure my logic is right. I mean... there's seriously not much to it, but if you Stop out of a save, it shouldn't break future tape operation attempts.

[chysn]

That's what the OP already did.

Yeh, I should learn to read the question.

Ha ha! No worries. You were right about the "dirty" part , but I don't like to ask questions without presenting what I've already tried.

[Mike]

When the user interrupts a save or load with the Stop key, the next invocation of SAVE or LOAD fails. But it doesn't simply fail, it does something weird to the stack so that I return to the routine that called the load or save subroutine.

Exactly how do you call the KERNAL LOAD and SAVE routines? When called from within the 'BASIC environment', upon detecting the STOP key, the stack is purged (see $E153..$E161 and $E164..$E1B8).

If you press STOP upon a direct call (JSR $FFD5 or JSR $FFD8) they just return, with the C flag set.

Generally, all BASIC I/O wrappers (see $E109 .. $E121) react this way when they register the STOP key, which is probably not what you want.

[chysn]

It’s direct KERNAL calls, based on wAx’s code, which has pretty robust tape support. I’ll post the subroutines when I’m at my Mac.

[chysn]

Here it is. It seems pretty straightforward to me, and as long as you don't STOP in the middle of a save or load, it works perfectly and repetitively. Once you hit STOP during save or load, it's like it returns to another part of the code. It never even gets to the inc SCRCOL ($900f) code. Stepping through with VICE's monitor, the monitor totally loses track of what's going on and the monitor locks up.

Code: Select all

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; TAPE SAVE/LOAD
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
TapeSave:   jsr TapeSetup       ; Set up tape
            beq TapeCancel      ; STOP was pressed
            lda #4              ; Filename is the current four-digit year,
            ldx #<SCREEN+40     ;   which can be scraped from the screen
            ldy #>SCREEN+40     ;   ,,
            jsr SETNAM          ;   ,,
            ldx #1              ; Device number
            ldy #0              ; Command
            jsr SETLFS          ; ,,
            ldx #<SCREEN        ; Low byte start
            stx $2b             ; ,,
            ldy #>SCREEN        ; High byte start
            sty $2c             ; ,,
            lda #$2b            ; Set tab
            iny                 ; 512 bytes
            iny                 ; ,,
            jsr SAVE            ; SAVE
TapeClnup:  inc SCRCOL          ; Put color back to green border (from red)
            inc SCRCOL          ;   ,,
            inc SCRCOL          ;   ,,
TapeCancel: inc SCRCOL          ; Put color back to blue border (from green)
            jsr MusicPlay       ; Restart music
            lsr ACTION_FL       ; Turn off Action flag
            jmp cancel          ; Return from tape operation cancels Action         

; Tape Load
TapeLoad:   jsr TapeSetup       ; Set up tape
            beq TapeCancel      ; STOP was pressed
            lda #0              ; Get whatever the next file is
            jsr SETNAM          ; ,,
            ldx #1              ; Tape device number
            ldy #1              ; Load to header location
            jsr SETLFS          ; ,,
            lda #$00            ; Command for LOAD
            jsr LOAD            ; ,,
            ldx #0              ; Preserve whatever came from the load
            lda (PTR,x)         ;   under the Cursor
            sta UNDER           ;   ,,
            jsr Roads           ; Re-colorize the world
            jmp TapeClnup       ; Clean up the operation

; Tape Setup
; - Removes the Cursor from the screen
; - Stops music
; - Changes screen border color to green
; - Waits for tape button activation or STOP
; Returns with Z=1 if operation is canceled
TapeSetup:  lda UNDER           ; Clear the Cursor out of the way
            jsr Place           ; ,,
            jsr MusicStop       ; Stop music during tape
            dec SCRCOL          ; Change screen border
-wait:      jsr CS10            ; Check for Record/Play
            beq rolling         ; ,,
            lda KEYDOWN         ; Check for Stop key
            cmp #$18            ; ,,
            bne wait            ; ,,
            rts                 ; Return from caller with Z=1
rolling:    dec SCRCOL          ; Set screen color to red border
            dec SCRCOL          ; ,,
            dec SCRCOL          ; ,,
            rts                 ; Return from caller with Z=0

[Mike]

Once you hit STOP during save or load, it's like it returns to another part of the code. It never even gets to the inc SCRCOL ($900f) code. Stepping through with VICE's monitor, the monitor totally loses track of what's going on and the monitor locks up.

Within the VICE monitor, please put a breakpoint on $C683. This is the TXS of the BASIC stack purge routine.

For the moment I don't see any issues with your TapeSave routine (though I'd use $C1/$C2 to hold the start address: the value ends up there anyway and you don't thrash the BASIC start in $2B/$2C).

[chysn]

Within the VICE monitor, please put a breakpoint on $C683. This is the TXS of the BASIC stack purge routine.

That breakpoint is never reached.

For the moment I don't see any issues with your TapeSave routine (though I'd use $C1/$C2 to hold the start address: the value ends up there anyway and you don't thrash the BASIC start in $2B/$2C).

Sure, I did that. I just pulled $2B from the Programmer's Reference Guide. Once the program is running, I pretty much disregard everything BASIC uses, though.

I'd love to be able to step through the execution of $FFD5, but the VICE monitor simply crashes when I enter "n". But the program in the emulator actually does what it would normally do had the tape execution worked! It executes those INC $900f, and gets back to the main loop. It simply seems to skip the actual tape work, exactly as though STOP were still being pressed. Weird. The nice thing about software is that I usually have only myself to blame. People have been using the KERNAL for decades, including me.

I have a small and subtle error somewhere. Maybe it's a stack issue (although those generally make themselves known far and wide), maybe it's something going on in the ISR. It's time to go through the code line-by-line, which is something I usually do anyway.

[chysn]

Update: When I set the breakpoint to $F542 instead of $FFD5, I can step through the code just fine. I don't really get that, but that's how it is. I've found that, after pressing STOP during LOAD and starting another one, this happens (from mdawson.net disassembly):

Code: Select all

LAB_F5EE
	JSR	LAB_F7AF		; find tape header, exit with header in buffer
	BEQ	LAB_F646		; exit if ??

During a normal LOAD, it doesn't exit at $F5F1. In my bad LOADs, I "exit if ??". So now I've got to figure out what "??" is!