Differences

This shows you the differences between two versions of the page.

--- javascript_terminal_v3 [2023/11/30 02:27] – appledog
+++ javascript_terminal_v3 [2025/12/05 02:36] (current) – appledog
@@ Line 35: / Line 35: @@
 Note that if we are in a multi-threaded environment we can always have the game engine running in an off-UI thread. Or the implementation can launch copies in their own threads vs, manual task and context swithching which you would need to simulate in an (ex. JavaScript) implementation. But it would be transparent to the code written for the virtual machine.
-== It's really a CPU
+== It's really an interpreter
-A monolithic atomic queue is like a CPU. Since we don't have a ROM, we write high level commands in JavaScript. Slowly, we can implement opcodes and start working more with the state machine.
+Like BASIC. The whole thing with INPUT and SET_NAME feels like you are writing your own programming language and interpreter. But on top of that, there's the actual BASIC interpreter which works exactly the same way:
 === BASIC Interpreter
-Instead of refactoring into a state machine, I threw together a quick BASIC class which processed commands in a program[] array. It handles print, and goto. Since it is a quick design it can not handle infinite loops or very long programs, since there is no time for the game loop to process updates and render or for the UI to make those changes to canvas.
+<Code:BASIC>
+PRINT A
+GOTO 40
+PRINT B
+PRINT C
+PRINT D
+LIST
+RUN
+A
+C
+D
+</Code>
+Instead of refactoring into a state machine, I threw together a quick BASIC class which processed commands in a program[] array. It handles print, and goto. Since it is a quick design it can not handle infinite loops or very long programs, since there is no time for the game loop to process updates and render or for the UI to make those changes to canvas. Then I realized... refactor into a state machine? Did I even realize what I had just said?
+== It's really a CPU
+A monolithic atomic queue is kind of like a CPU. Since we don't have a ROM, we write high level commands in JavaScript. Slowly, we can implement opcodes and start working more with the state machine.
-However, for the point of theory, yes, it is possible to write a scripting language (or a CPU simulator) and have it run in the terminal.
+This kind of blew my mind at the time so I took a lot of time off from the project thinking about it.
+== Aside
 ==== Jump Table in JavaScript
 <Code:JavaScript>
@@ Line 75: / Line 93: @@
     }
 }
+</Code>
 This example is how to support a large number of opcodes/commands quickly.
 == Refactoring Needed
-V3 is V2 but with changes made in how terminal is controlled by the main program. The error of processing commands in the terminal was addressed with the BASIC class. The same idea needs to be made with an OS or TerminalCommands class, to separate that functionality out of the Terminal class. The Terminal class is only supposed to maintain and possibly draw the terminal -- and actually the draw code might be removed into a class that maintains canvas as a virtual 'screen' object -- like in Java NetWhack where there was a Screen and a Terminal class.
+V3 is V2 but with changes made in how terminal is controlled by the main program. The code has also become somewhat spaghetti. I partially addressed this by removing the Tile class from V3 and adding BASIC command processing into its own class. But much more work needs to be done on this. The BASIC class should maintain the copy of the program code, and the Terminal class might need to offload it's draw funcion to a Screen class. We might even move event checking into an OS or CPU class. Or both. But the OS class would eventually be replaced by programs running on the CPU (a ROM).
-The code has also become somewhat spaghetti. I partially addressed this by removing the Tile class from V3 and adding BASIC command processing into its own class. But much more work needs to be done on this. The BASIC class should maintain the copy of the program code.
+In a real VM, the code would not be stored in a program[] array but in memory[] and read from there by the interpreter. There are lots of little design clashes between the idea of a VM, the idea of a Game (NetWhack) and the idea of s hybrid scripting language written in Javascript. They are not really compatable. So for a V4 the goal will be to pare down and really isolate the functionality of Terminal, and to clean up main by making a class Screen, and also perhaps a class Keyboard, class Mouse, etc.
-And, in a real VM, the code would not be stored in a program[] array but in memory[] and read from there by the interpreter. There are lots of little design clashes between the idea of a VM, the idea of a Game (NetWhack) and the idea of s hybrid scripting language written in Javascript. They are not really compatable. So for a V4 the goal will be to pare down and really isolate the functionality of Terminal, and to clean up main by making a class Screen, and also perhaps a class Keyboard, class Mouse, etc.
 == Final Thoughts
 Today's computers are many millions of times faster than (ex. a C64). Even a C65 running at 3.5mhz can 'software' simulate a C64. People have written Sega Master System (Z80) system simulators on 386 quality systems. The point is that today's processors are in many cases over a million times faster than a C64 or 8086 style processor and are overkill for this. Therefore if we move in the direction of a full cpu and system simulator the main problem will not be processing speed, but writing the software. We don't have a ROM/BIOS and we don't have an OS, and those two are both rabbitholes greater than or equal to a 'JavaScript NetWhack'. It's just a little too big to deal with before we write the game.
-== The Future of JTTD
+As it stands, V3 is a sort of kludge, filled with stop-gaps. I will need time to think over everything I have learned, and one day, approach V4 from a different direction.
-V4 will be whatever we do to support NetWhack, and then a pared down version will be presented as a V5 "final". It will represent a programmable terminal emulator slash game engine for character mode programs. Future goals would be for some interactive fiction games, or other interesting games, and possibly, as a platform for teaching JavaScript in a familiar environment (using the terminal as a codebase, and running everything in a Game class. Like modern Android design for example.) For now though, V3 is a sort of stop-gap kludge, and the rewrite will be coming after JavaScript Netwhack.
+(--Me, in 2022).