L'out of memory dovuto allo stack è un classico. Dovresti capire che si tratta di problemi di stack se la linea in cui dà errore contiene un GOSUB o un FOR. L'errore può essere dovuto tanto all'eccesso di GOSUB senza RETURN (o con uscita dalle subroutine con GOTO saltando il RETURN), quanto all'eccesso di FOR annidati o (di nuovo) da cui non si esce correttamente. Attenzione però: lo stack è condiviso fra le strutture, perciò se l'out of memory avviene su un GOSUB, potrebbe essere colpevole la mancata uscita da un FOR, o viceversa.
Il debug in questi casi è facilitato da accorgimenti che si sarebbero dovuti prendere dall'inizio della stesura di un programma: ad esempio, stabilendo una politica coerente per i numeri di linea delle subroutine, un GOTO fuori posto può saltare maggiormente all'occhio (se ogni subroutine occupa numeri di linea da xyz00 a xyz99 è evidente che non dovrebbero esserci GOTO fuori da questo intervallo). Il programma di esempio (quello grande) del libro di Mike Grace era sufficientemente ben strutturato da questo punto di vista, ma non ricordo se il testo insistesse a sufficienza su questi concetti.
Aggiungo a titolo di curiosità che su CCC (n. 39, pagg. 72-82) comparve un ottimo
articolo di Claudio Baiocchi sulle particolarità dello stack in BASIC. La lettura può risultare un po' ostica per i principianti, ma dall'articolo si evincono perfettamente i "meccanismi" con cui sono gestiti cicli e subroutine. Un listato dimostrativo accluso mostra i limiti reali dello stack sui vari modelli (C64, C16, ecc.).
Infine: non credo che sia il caso dato che realizzi un'adventure, ma anche la definizione di funzioni "troppo lunghe" con DEF FN può dare luogo a problemi di out of memory nel momento in cui la funzione viene richiamata.
