Sorry, the explanation is a bit lengthy - but I hope worth reading :-) .

There are 2 kinds of "codes" - programs - somewhere in the memory (here: one of internal memories of the chip) - the interpreter itself and the interpreted BASIC program. The interpreter is uploaded at once and the chip can be fully erased for it.
It is different with the BASIC program. In this respect, it should be seen as DATA.

The original Intel Basic52 stored the BASIC program in RAM, while being edited; and had provisions to burn a debugged program into an attached (pre-erased) EPROM (more BASIC programs could sit in the EPROM, while only one in the RAM). The RAM holds also the data of a running program, of course, and also the internal data of the interpreter (512 bytes). The manual suggested to use 2kB-8kB RAM (2kB SRAM chips being big memories those times), some boards use 32kB chips.
(I did not mention it yet, but the P89C(V)51RD2 has also the drawback of having only 768 bytes of data RAM, leaving only 128 bytes for the user data.)

Using various techniques, BASIC programs beyond the RAM limit can be used. One of the options is to write a short "bootloader", which fits into the smallish RAM, receives bytes from serial port and programs them into the EPROM (basically an EPROM burner). The program has to be edited and tokenized in the PC - various utilities are available for this, none of them (I am aware of) free. Also, you lose the biggest and perhaps only advantage of the interpreted program - you cannot do the debugging on the target.

I have chosen a differen approach.

To overcome the 1kB(Temic)/1.75kB(Atmel) XRAM limit for the BASIC programs, first I extended the GOSUB (and also GOTO) syntax so that it contains also the number of the program in EPROM (here: in FLASH). This way, small programs/routines/utilities/modules could be written, programmed into FLASH and then a "main" program would glue them together.

But then I realized that the FLASH can be programmed in a very RAM-ish manner - no erasing is needed (the IAP firmware using a well-deviced hardware takes care of that transparently). So I simply modified the editing routines so that now you can edit the program in the FLASH itself.

And this requires, that the FLASH should be either written with no (visible) erasure, or alternatively only a small chunk of FLASH should be erased at a time so the data it contains could be backed up somewhere in the internal XRAM.


Jan Waclawek