...Forth? Wow. I wonder how much code change was necessary between the various systems. It's hard to imagine a Megadrive Forth compiler, but then again, the game was on several other M68k systems so maybe it wasn't as hard...

▲

jhbadger 6 hours ago | parent | next [-]

It is really, really easy to write a Forth interpreter (You can write a simple one in an afternoon). It's often the first software written for an architecture. The structure of Forth means that the hardware-dependent parts are contained in a small number of words (sort of like functions in other languages but not exactly). Forth can be implemented on tiny microcontrollers; a Megadrive would be luxury.

▲

lstodd 7 hours ago | parent | prev [-]

It's.. not a compiler (besides I had Forth on my C64). Maybe one can call it a translator to ad-hoc bytecode. I also had USCD Pascal on that C64 which translated to bytecode. This was more JVM-like. So nothing hard about it.

	▲	lebuffon 27 minutes ago \| parent \| next [-]
		Forth is a compiler but what it "compiles" is not standard. The implementor decides what they need. Forth can compile pointers to native code that are the VM's instructions, called direct threading. Forth can compile pointers to pointers to native code VM instructions, called indirect threading. Forth can compile byte code like OpenFirmware/OpenBoot. And modern systems compile optimized native code (VFX Forth, SwiftForth) but still remain fully interactive at the console.
	▲	EarlKing 5 hours ago \| parent \| prev [-]
		Point of information: By and large FORTHs did not use bytecode. Execution tokens (XTs) were usually stored as a function of the default word size, which typically was 16 bits. There were some FORTHs that went out of their way to use token threading so they could store programs in byte codes, but those were pretty rare. Rarer still were programs that mixed byte code with word-sized code (although one such scheme is described in an issue of Forth Dimensions).