A fairly simple 8051-based SBC project.

[westfw]

how do I implement a boot loader and a BASIC interpreter then?

Really?  Usually one gets the Intel BASIC52 firmware and adapts that.  It's all over the net, in various forms.  Here's one:  http://home.arcor.de/h.boehling/80c32.htm#MCS-BASIC-52
It's a real (from text) interpreter, complete with floating point, and I assume that it's REALLY slow on stock 8051, but it's essentially THE defacto standard for the 8051 world.  Or was, back when there weren't very many other choices.   http://www.nomad.ee/nomad/micros/bas52man/index.shtml

PJRC (now of "Arduino Teensy" fame) used to do 8051 stuff:  http://pjrc.com/tech/8051/

I've never gotten close enough to implementing anything that I've looked into finding an updated version for the newer chips, or into how much effort might be required to get the source code working on a non-Intel 8052-like chip.   IIRC, the big claim to fame was that once you had an 8052 with BASIC-52 in it's on-chip program memory (either by programming it yourself, or by buying an 8052BASIC chip), you could write BASIC into RAM and/or save the text in an external EPROM and run your home automation software on it (that was the killer-app.  Steven Ciarcia (more recently of Circuit Cellar Magazine) was a big proponent, and sold 8052BASIC chips via his MicroMint company.

AFAIK, hobbyist use of 8051 systems dropped off rather rapidly after PCs capable of running a cross-compiler became common, and relatively-easily programmed flash/eeprom microcontrollers (PIC, AVR, 68HC11) show up.
(It's hard to recall that PCs used to be so expensive that buying an 8051 SBC for $300 and using an old ASR33 or "dumb CRT terminal" to program it was the preferred "embedded solution"...)

[legacy]

yes, I got a few '51 assembly example of the basic interpreter from Dr.Dobb's
and it was super fast 

[technix]

how do I implement a boot loader and a BASIC interpreter then?

Really?  Usually one gets the Intel BASIC52 firmware and adapts that.  It's all over the net, in various forms.  Here's one:  http://home.arcor.de/h.boehling/80c32.htm#MCS-BASIC-52
It's a real (from text) interpreter, complete with floating point, and I assume that it's REALLY slow on stock 8051, but it's essentially THE defacto standard for the 8051 world.  Or was, back when there weren't very many other choices.   http://www.nomad.ee/nomad/micros/bas52man/index.shtml

PJRC (now of "Arduino Teensy" fame) used to do 8051 stuff:  http://pjrc.com/tech/8051/

I've never gotten close enough to implementing anything that I've looked into finding an updated version for the newer chips, or into how much effort might be required to get the source code working on a non-Intel 8052-like chip.   IIRC, the big claim to fame was that once you had an 8052 with BASIC-52 in it's on-chip program memory (either by programming it yourself, or by buying an 8052BASIC chip), you could write BASIC into RAM and/or save the text in an external EPROM and run your home automation software on it (that was the killer-app.  Steven Ciarcia (more recently of Circuit Cellar Magazine) was a big proponent, and sold 8052BASIC chips via his MicroMint company.

AFAIK, hobbyist use of 8051 systems dropped off rather rapidly after PCs capable of running a cross-compiler became common, and relatively-easily programmed flash/eeprom microcontrollers (PIC, AVR, 68HC11) show up.
(It's hard to recall that PCs used to be so expensive that buying an 8051 SBC for $300 and using an old ASR33 or "dumb CRT terminal" to program it was the preferred "embedded solution"...)

That is a full featured product, but it won't work very well for me, as I need to squeeze in native code boot and EEPROM in system programming support.

I will probably use a byte code VM as it can be a full C implementation with all those features and Von Neumann bus in mind.

[westfw]

BTW.  Quick and approximate cheat sheet, especially for people who might be reading this thread that are less familiar with the history:

8051:  Usually the label for the Architecture.  Aka "MCS-51"
           Also, an Intel chip with 4k internal ROM and 128 bytes RAM.

8052:  Chip with 8k internal ROM and 256 bytes RAM.

8031, 8032: like 51/52, only no internal ROM.  Could only be used in "external program memory" configurations.  pre-programmed 8052/etc would appear on the surplus markets as "8032", since the same wiring for external program memory would simply bypass any internal program memory that happened to exist.

80C52/etc:  Like 8051, only CMOS instead of NMOS - lower power!

87C52/etc:   Like 8052/etc, only with internal EPROM (UV-erasable) rather than ROM.  Usually ceramic package with quartz window for UV-erasure.  (Later, plastic with no window for One-time programming (OTP))

89C52:  like 87C52, but with FLASH internal program memory. (Atmel part number)

89C2051: low pin count (20pin) variant with 2k Flash and 128bytes RAM (Atmel.)

89S52: like 89C52, but with In-circuit Serial Programming.  Devices earlier than this required complex HV parallel programming.  (Atmel part number)


Sometime around then everyone started shipping 8051 clones (when Intel lost interest?  When they opened up the IP?  I dunno.)  Different vendors used different part number schemes to indicate different features/memorysize/memory technology.  On some, the numbers tell the story.  Others, alphabetic suffixes are more relevant...

The original architecture uses as least 12 clock cycles for each instruction.  Intel implemented a faster version (MCS-151) that did 2 clocks, and I think since then many vendors have done single-clock versions without being explicit via part numbering.  (This is "clock cycles per machine cycle", some instructions require more than one machine cycle.)  (This has some substantial impact on external program memory and such...)  (There's some microcontroller history in here somewhere.  8bit PICs are widely sneered at these days for using 4 clocks/machine cycle.  But when they were first introduced, that was pretty uncommon...)

There was a follow-on MCS-251 architecture introduced by Intel, but it didn't go very far.  (IIRC, Intel exited the microcontroller business shortly after introducing the architecture, and may have been fussier about licensing.  And by then, there were a lot more competing microcontroller architectures.)

[westfw]

[BASIC52] is a full featured product, but it won't work very well for me, as I need to squeeze in native code boot and EEPROM in system programming support.

The full basic interpreter fit in 8k.  There should be plenty of room in a modern implementation for that PLUS any additional code you need, PLUS the code to have them interoperate.
I think paul's page also had pointers to a "tiny basic" for 8051.

[legacy]

(if anyone needs the original intel 51-basic,
PM me for the binary, 8Kbyte size  )

[technix]

[BASIC52] is a full featured product, but it won't work very well for me, as I need to squeeze in native code boot and EEPROM in system programming support.

The full basic interpreter fit in 8k.  There should be plenty of room in a modern implementation for that PLUS any additional code you need, PLUS the code to have them interoperate.
I think paul's page also had pointers to a "tiny basic" for 8051.

Will they play nice with my Von Neumann bus unmodified? XDATA and CODE memory goes to the same place, 0x0000 - 0x7fff is non volatile while 0x8000 - 0xffff is volatile, and I also have to allow for dual booting so BASIC program does not start at EEPROM address 0x0000.

My byte code virtual machine is a Von Neumann RISC instruction set with always-aligned 16-bit instructions and botf 0x0000 and 0xffff being nop. This mean using this byte code I can easily tell if it is byte code or 8051 native code in the ROM, since the first four bytes of a 8051 program will almost never be all 0x00 or 0xff. The byte code interpreter will always refuse to boot any ROM content not starting with two nops in its own instruction set, allowing the system controller (PIC16F1455) to detect this scenario and reboot the 8051 from external bus.

[legacy]

dealing with NV-RAM(1) is not a good idea

my 68hc11 board bootstraps from the NVRAM
which is also used for the stack and data sessions
sometimes gets corrupted

also, the battery doesn't last 10 years.

I am using fe-RAM instead of NV-RAM.

(1) static ram + battery, Dalsemi/Maxim technology

[technix]

dealing with NV-RAM(1) is not a good idea

my 68hc11 board bootstraps from the NVRAM
which is also used for the stack and data sessions
sometimes gets corrupted

also, the battery doesn't last 10 years.

I am using fe-RAM instead of NV-RAM.

(1) static ram + battery, Dalsemi/Maxim technology

I am using EEPROM and FRAM as the nonvolatile RAM technology. (FM18W08 on SOP-28 adapter board is a drop-in replacement for AT28C256 anyway)