If organized properly, you can GOSUB within a GOSUB then RETURN to a RETURN to get back to the original calling code.

Check that every time your program enters a subroutine through a GOSUB it always exits through a RETURN. Also check that your program never enters a subroutine other than through a GOSUB if it must exit through a RETURN.

If a program's flow causes it to use GOSUB without matching RETURN statements, eventually the stack's memory will be full and an error will occur. Similarly, if a program's flow causes it to use more RETURN than GOSUB statements, RETURN will attempt to access memory outside of that allocated to the stack, resulting in an error.

GOSUB stores the "from" address on the stack and adjusts the stack pointer. RETURN retrieves that address from the stack and adjusts the stack pointer back to what it was.

Can you upload it and provide the key? I'm guessing your code is leaving the GOSUB by means other than RETURN, but it's hard to tell from just a short snippet.

Why are you incrementing S? (2nd last line)

Yes, it's similar in that they're both dialects of BASIC. Do a Google search on SmartBASIC and you should be able to quickly find the language reference - instruction list, specs, etc.

When you save a variable, you're saving the value of that variable.

On the direct screen (that's the one that doesn't have numbers going down the left edge), type SAVE and a filename in quotes, such as follows. SAVE"TICTACTOE" This will save the program that's currently in slot 0. If you want save a program that's in a different slot, you need to specify PRGx in front of the name (where x is the slot number.) Such as this. SAVE"PRG1:TICTACTOE"

Also, the BREAK statement in line 71 is unreachable because the variable BT is never set anywhere in your code.

You might want to insert an XON MOTION somewhere in between all those LOCATE and PRINT commands.

However if length 0-seconds is specified, it uses a circlular buffer, meaning that it wraps around and new data overwrites the oldest in the buffer. If you use this setting, you would need to continuously pull the data out of its buffer and store it in your own buffer, while it's still recording.

There are two restrictions in place. Playback: Only 8180, 8-bit samples per second are supported by WAVSETA. Recording: At 8180, 8-bit samples per second, MICSTART can record up to 30 (or maybe it's 32) seconds maximum unless you write some fairly complicated code to wrap around it. Normally the mic data is stored from beginning to end of the mic chip's internal buffer. (cont. below)

That doesn't answer the question. Perhaps I phrased it wrong. How do you get SmileBasic to multitask?

How does your program get the CPU time necessary to do the recording when another program is running?

The code in this screenshot will capture 2 seconds from the mic and play it back.

What do you use to play it back?

Which programs? e-shop-published programs such as Pokemon, or user-created programs written in SmileBasic? For e-shop programs, usually you go to the e-shop, find the update there and download it. For programs written in SmileBasic, get the new version's download key from the author, and use it to download the new version.

Clear it of what? If you want the keyboard to disappear, the XSCREEN 2 will do that, but it'll reappear when your program is finished running. If you've printed text to the lower console screen, try DISPLAY 1 and CLS. If you've drawn graphics on the lower screen, try DISPLAY 1 and GCLS.

No, it doesn't work. Error message in attached screenshot.