Differences

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

--- javascript_terminal_v3 [2023/11/29 08:14] – appledog
+++ javascript_terminal_v3 [2025/12/05 02:36] (current) – appledog
@@ Line 34: / Line 34: @@
 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 an interpreter
+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
+<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 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.
+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.
-=== Jump Table in JavaScript
+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>
 // Define functions
@@ Line 71: / Line 93: @@
     }
 }
+</Code>
 This example is how to support a large number of opcodes/commands quickly.
-== The Goal of V3
+== Refactoring Needed
-A full featured terminal like V2 but refactored in the direction of a virtual machine, so the user can program that way if he needs.
+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).
-It's kind of like writing a shell. The terminal mode is the shell. Your actual game can be written in JavaScript and you can run it there, and turn off terminal mode, or you can remain in terminal mode and try to use the scripting functionality there, like extending a game engine.
+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.
-In most cases, the input method of v2 is going to be good enough. It is good enough to do an interactive fiction game (anything like a shell -- and therefore we could write a whole computer system on top of V2). V3 is more like reorganizing things to make the computer system part more obvious and accessible. Why, so maybe we can just remove it and focus more on a barebones terminal. This might ultimately be the way, since gameState's terminal and command modes are now merged and it maybe doesn't make sense to have any kind of os-like commands (like HELP).
 == 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. 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 this should run on anything. Maybe even a 2020s Apple Watch.
+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.
-Second, the idea of a CPU simuator is very interesting, but we don't have a ROM/BIOS and we don't have an OS and that alone is way too big to worry about for a simple roguelike game. It's interesting, it would be fun, but it is perhaps a little too big for now.
-Even an 80486 had five pipelines and ran at 100mhz, and this might have already been 500 to 1000 times faster than a 6502/6510/etc.
+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.
-== More Final Thoughts
+(--Me, in 2022).
-I don't think anything similar to this really exists. There are almost ten different C64 emulators written in JavaScript here: https://github.com/fcambus/jsemu and this list includes many more for other systems (more than twenty Nintendo emulators for example). That page also lists many CPU emulators. So while there might be nothing really like this, there are very many similar things and we know the concept is tried and true.
-Of particular interest will probably be ZZT.js and Parchment, as well as others -- which are game engines written in JavaScript. In it's current state, Terminal V2 (using gameState) is already good enough to serve as a platform for interactive games, since enter-on-a-line is good enough. You could also use V2 as a MUD platform. So why V3? It just feels like the next step in development of the terminal, but we must be careful to step into the rabbithole of writing an entire virtual computer and OS, at least not just yet.