Differences

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

--- javascript_terminal_v3 [2023/11/29 08:14] – appledog
+++ javascript_terminal_v3 [2023/11/30 02:37] (current) – appledog
@@ Line 38: / Line 38: @@
 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.
-=== Jump Table in JavaScript
+=== 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.
+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.
+==== Jump Table in JavaScript
 <Code:JavaScript>
 // Define functions
@@ Line 71: / Line 89: @@
     }
 }
+</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).
+== Bugs
+Well, there are still a few 'bugs' but maybe they are just quality of life fixes. I'd like the terminal to retain it's cursor y position, if possible, during a resize -- or, to clear the screen of existing text. Frankly it isn't important enough for me to worry about right now, and it probably isn't really a true bug, so I will leave it for now.
 == 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.
-== More Final Thoughts
-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.
+== The Future of JTTD
+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.