Feasibility of a Threaded Code VM on the 2600

[Kenneth Cochran]

I've been thinking about how to make programming for the 2600 even more accessible and the idea struck me that many high level languages for early microprocessors like the 6502 used threaded code interpreters to squeeze larger programs into those memory constrained systems. Examples include Forth, several variants of Pascal P-systems and some BASIC variants as well. The P-systems even had other languages target the P-code in much the same way languages target the JVM or the CLR today.

 

This came at a cost of course. These techniques were essentially early forms of virtual machines that traded performance for instruction density. But all examples I've read about seemed to have higher memory requirements than the 2600's meager 128 bytes of RAM. Forth programmers used to boast that a minimal Forth system could be implemented in under 2Kb of RAM.

 

It occurred to me that if a bare bones threaded code interpreter is feasible it may have too much memory overhead to justify it's use. And even if the memory overhead is small it may be too slow to be useful for game development. Still, the idea is intriguing.

 

Anyone have experience with these systems? How useful were they? My first computer was a Tandy 1000 HX with the memory expansion and I didn't start programing until the Pentium era so I have no point of reference.

Edited December 10, 2021 by Kenneth Cochran
Spelling errors

[+bcombee]

I think it could be fun to have some sort of compiled FORTH REPL with a host system and a 2600 emulator where the emulator would be restarted after each system change. You could perhaps use a system like the Melody cart to host an ARM core running an IDE on a 2600 ROM emulator system. I don't think you could really get something working well hosted on a bare 2600 - timing is just too tight for the display kernel.

 

The Basic Programming cart does have a simple interpreter allowing running the small number of possible statements, but it does most program running in the vertical blank.

[ScumSoft]

Well...it just so happens that the next big project I started on earlier this year is just such a thing. 

 

It's a FORTH I've nicknamed Maestro. It's a completely new firmware for the Harmony/Encore carts which allows us to develop 2600 games in real time and leverages the ARM cpu in the likeness of the Sega 32X.

 

I can make no eta on a release date just yet, but you're not the only ones that thought this was a great idea!

[Sohl]

25 minutes ago, ScumSoft said:

Well...it just so happens that the next big project I started on earlier this year is just such a thing. 

 

It's a FORTH I've nicknamed Maestro. It's a completely new firmware for the Harmony/Encore carts which allows us to develop 2600 games in real time and leverages the ARM cpu in the likeness of the Sega 32X.

 

I can make no eta on a release date just yet, but you're not the only ones that thought this was a great idea!

Wow, sounds interesting!  Looking forward to hearing more about this.

 

@Kenneth Cochran I'm a big fan of Forth starting about 1990.  I had the Atari 2600 BASIC programming cart and keypad before that, and was frustrated by how limited the thing was.  Happily, I moved on to a TRS-80 Color Computer in `81 and a C64 in `83 or so.  

 

Forth was traditionally an interpreter with a teletype or video terminal interface where the developer iteratively built software in RAM, which would be tough to do interactively in a ROM-only cart, as you point out with only 128 bytes of RAM, but perhaps some very tiny apps could be built that way.  Probably a much more viable approach is cross-compiling Forth source into a ROM image that can use RAM for stacks and variables, but that sacrifices the interactive nature, of course.  If you are using it to make video games, you'd need a few CODE routines with tight native code to implement the drawing kernels and some other really time-critical code.  Perhaps a full keyboard can be interfaced to the 2600 to make it interactive, but there'd be scant space to extend the dictionary of Forth words unless you use a cart with much more RAM.

[+Pat Brady]

10 hours ago, Kenneth Cochran said:

This came at a cost of course. These techniques were essentially early forms of virtual machines that traded performance for instruction density. But all examples I've read about seemed to have higher memory requirements than the 2600's meager 128 bytes of RAM. Forth programmers used to boast that a minimal Forth system could be implemented in under 2Kb of RAM.

 

It occurred to me that if a bare bones threaded code interpreter is feasible it may have too much memory overhead to justify it's use. And even if the memory overhead is small it may be too slow to be useful for game development. Still, the idea is intriguing.

 

I believe the 2K for Forth refers to the interpreter itself, so on a 4K machine it would leave 2K for the program and its variables.

 

On the 2600, the interpreter can go in ROM. For your purposes the only things that must go in RAM are the program, its variables, and display kernel state. 128 bytes is still very little, so you might consider a cartridge format that provides extra RAM. Atari's SARA gives an extra 128 bytes, CBS's RAM Plus gives 256 bytes, and M Network's Big Game (used for BurgerTime) gives 2K.

[Mr SQL]

11 hours ago, Kenneth Cochran said:

I've been thinking about how to make programming for the 2600 even more accessible and the idea struck me that many high level languages for early microprocessors like the 6502 used threaded code interpreters to squeeze larger programs into those memory constrained systems. Examples include Forth, several variants of Pascal P-systems and some BASIC variants as well. The P-systems even had other languages target the P-code in much the same way languages target the JVM or the CLR today.

 

This came at a cost of course. These techniques were essentially early forms of virtual machines that traded performance for instruction density. But all examples I've read about seemed to have higher memory requirements than the 2600's meager 128 bytes of RAM. Forth programmers used to boast that a minimal Forth system could be implemented in under 2Kb of RAM.

 

It occurred to me that if a bare bones threaded code interpreter is feasible it may have too much memory overhead to justify it's use. And even if the memory overhead is small it may be too slow to be useful for game development. Still, the idea is intriguing.

 

Anyone have experience with these systems? How useful were they? My first computer was a Tandy 1000 HX with the memory expansion and I didn't start programing until the Pentium era so I have no point of reference.

 

Excellent ideas! Developing a threaded code VM is feasible and a lot of fun on the 2600. 

 

In choosing a threading model one important aspect to consider is the 6502's unique racing the beam architecture.

 

"Television architecture threading model" is what I used to develop SuperCharger BASIC which is compiled but has a 2K runtime.  

 

 

Threading the Television design architecture allows greater code density and saturation of available cycles.

 

[Kenneth Cochran]

On 12/10/2021 at 9:04 PM, ScumSoft said:

Well...it just so happens that the next big project I started on earlier this year is just such a thing. 

 

It's a FORTH I've nicknamed Maestro. It's a completely new firmware for the Harmony/Encore carts which allows us to develop 2600 games in real time and leverages the ARM cpu in the likeness of the Sega 32X.

 

I can make no eta on a release date just yet, but you're not the only ones that thought this was a great idea!

This is an awesome idea. My goals are slightly different. I'm focusing primarily on making it easier to implement high level languages. Forth is one of the easier languages to implement due to it's minimalist design philosophy and extensibility but I'd like to see more popular languages and I'd like to target other game systems as well.

 

After doing some research I've concluded that the CLR and JVM are too modern to target these early game systems. They were designed around the larger address space of 32-bit and 64-bit processors. Even the VMs that target embedded and resource constrained environments still expect far more resources than a 4th gen game system let alone a 1st gen one.

 

So I'm leaning toward a lightweight interpreter that implements a stack machine. I may start with a Forth or p-machine interpreter and adapt it from there. One thing I'd like to do is give the game developer fine grained control over which code is interpreted and which is compiled to machine code that way they can fine tune performance. Another idea I had was to create an assembly language for the virtual machine that could be directly implemented by languages that support inline assembly.

 

But this is just the tip of the iceberg. I'd eventually like to use this as a springboard to create a small, single process operating system that provides abstractions for common game system features as libraries.

 

[stepho]

It's been a few decades since I've dabbled in Forth but I remember a few things to be aware of:

- most things go on the stack - which is usually a simulated stack, not the CPU's hardware stack.

- Forth was often used to write assemblers for new machines.

- Forth's threaded nature allowed mixing of purely interpreted code with code that was compiled. It even allowed you to replace a previously compiled subroutine with new script code and the other compiled code would automatically call the new script instead of the old compiled subroutine. It did this by each call checking a table before calling the script interpreter or call the complied version. This table checkup is of course expensive but your new language could skip that (or make it optional). The compiled form still uses the simulated stack for variables, so it may or may not be fast enough for a kernel if it skips the table check.