How do I clear the VERA "error led"?

[Daedalus]

Ok. So I'm writing a program in ca65 assembly that implements a unix like shell environment in r43.

I know, right? A guy's gotta have his hobbies.

Anyway. A core function is that it doesn't "implement the commands" itself, instead, the commands are special programs that it loads by name into banked ram (Starting at address $A000.) and then executes. The shell provides hook vectors for the executing program to respond back with text to be displayed as a result of that command. After the command program runs, it returns back to the shell.

That works fine. I've only implemented one command, "pwd" (Print Working Directory.) that does nothing but send back a line of text.

In the shell terminal, if you press enter with a blank command line, it detects that and just drops to the next line, but if there's text, it grabs the first word, assumes it's a command, and tried to load it. If that word was 'pwd', then great! It successfully loads the program into $A000 and executes it. The text is printed, the pwd program exits and the shell is back in charge. Great!

But if you type a bad command, like "bad"... well, it can't find that! LOAD sets the carry bit which triggers the shell to say "Command not found." and go to the next line. That works fine.

That's when it gets weird! When a bad command is entered, a blinking red rectangle about 8 by 4 pixels appears in the upper right of the screen. My thought was: "Where is that coming from? What have I screwed up?"

Much debugging and pulling of hair ensued... to no avail. I could not figure out why it's doing that.

Then I have "Moment of clarity" and think, "What would Sherlock do?" Sherlock would say "Well, if you've eliminated all other possibilities, then what remains, no matter how stupid sounding... must be true!" That would be VERA emulating the red blinking LED on an actual floppy drive. Naw... that can't be right, right?

Au contraire, mon frere! It appears that is exactly what is happening. First, I set the horizontal scale to 64 to only show 40 characters per line, and it still appears in the upper right. Then I didn't run my shell at all, instead loading the 'pwd' program from BASIC with LOAD"pwd",8,1 ... Ok, that loaded fine. So I tried loading a non existent program with LOAD"bad",8,1 and viola! It responded with an error message and started blinking the SAME rectangle of red in the upper left of the screen.

Loading any legit file will clear it.

So... how do I clear that in assembly?

[desertfish]

you can read the DOS status message that would describe the actual error. This will stop the flashing. In basic that would be
10 OPEN 1,8,15:INPUT#1,A$,B$,C$,D$:CLOSE 1 : ?A$;B$;C$;D$

Or send the "I" (initialize) command to the drive's command channel 15. in basic that would be OPEN 1,8,15,"I":CLOSE 1

[StephenHorn]

In x16emu, the blinking red square is placed in the top right corner because the emulator doesn't have any other allowance to represent the "activity LED" on an actual, physical X16.

[Daedalus]

So it's the emu doing that, not "VERA actual"... and there is a literal LED on the x16 hardware, not the one on a connected floppy disk.

That's actually damn clever. I was stumped because I'm completely co-opting the usual display pathway. I'm using a custom character glyph array and not ever using CHROUT or GETIN. I couldn't figure out where that blinking rectangle of red was coming from. It just blinked at me with it's unwavering glare as I tried to find the source of it in my code. Over and over. It just kept blinking and flashing and blinking and flashing! I couldn't take it anymore!

But that answers my question. to make it stop I write a routine that resets the error code. Ok, easy enough.

[Daedalus]

Ok. So running this function:

Code: Select all

term_clear_error:
	lda #8
	jsr LISTEN ; ($ffb1)
	lda #15
	jsr SECOND ; ($ff93)
	lda #'I'
	jsr CIOUT ; ($ffa8)
	lda #8
	jsr UNLSN ; ($ffae)
	rts

right after detecting the error clears it up nicely.

Edited to add: It doesn't seem to need the "lda #8" prior to the call to UNLSN, I assume it can only have one thing listening at a time, and that one thing has to be unlistened before another thing can be set to listen.