Applesoft BASIC in JavaScript
Go to file
Joshua Bell 6278f871fb Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.

Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.

***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.

***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.

The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".

Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.

***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.

***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.

***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").

***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...

***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 11:03:15 -08:00
cm Simulate Thunderclock in Slot 4 2024-02-10 18:22:08 -08:00
res Move some resource files to res/ 2016-02-05 20:42:40 -08:00
samples Several sample fixes/improvements by Alan Ratliff 2024-02-19 11:03:15 -08:00
tools Squish the font bitmaps 2013-08-18 15:30:55 -07:00
vfs Snapshot 2012-02-08 22:13:44 -05:00
.gitignore Remove old ignore entry 2013-05-08 00:00:56 -04:00
LICENSE.md Update font refs to https 2018-08-15 21:55:00 -07:00
README.md Update README.md 2018-08-14 13:00:32 -07:00
basic.js Thunderclock: Tweak DOS/BASIC handling of colons 2024-02-11 15:16:39 -08:00
bell.js Use WebAudio for beep, if available 2017-02-19 21:17:01 -08:00
bs.html Add script example 2013-12-08 15:56:19 -08:00
display.css Move some resource files to res/ 2016-02-05 20:42:40 -08:00
dos.js Thunderclock: Tweak DOS/BASIC handling of colons 2024-02-11 15:16:39 -08:00
favicon.ico Updated favicon 2015-03-12 21:25:07 -07:00
hires.js Fix ESLint warnings (and one actual bug) 2023-01-04 19:34:48 -08:00
index.html Page: Use OPTGROUP in SELECT 2023-09-21 21:39:20 -07:00
index.js Add softswitch reads for display modes 2020-05-29 21:55:32 -07:00
lores.js Improve GR/HGR colors 2020-06-13 10:38:34 -07:00
printer.js Remove copyright/license from individual JS files 2013-08-21 23:07:46 -07:00
reference.html Simulate Thunderclock in Slot 4 2024-02-10 18:22:08 -08:00
script.js Add softswitch reads for display modes 2020-05-29 21:55:32 -07:00
script.md Update font refs to https 2018-08-15 21:55:00 -07:00
styles.css Update font refs to https 2018-08-15 21:55:00 -07:00
tty.js Simulate Thunderclock in Slot 4 2024-02-10 18:22:08 -08:00

README.md

jsbasic - Applesoft BASIC in JavaScript

This is hosted for playing with at https://inexorabletash.github.io/jsbasic/

Notes & Known Issues

  • The BASIC program is compiled to JavaScript before execution. Syntax errors are therefore detected at compile-time rather than at run-time as on a traditional interpreter. For example, the following program would run without errors on an Apple since the erroneous second statement is never reached. 10 END : CHR$(PRINT)
  • Handling of BASIC code that does not match the canonical LIST output format may not behave as on an Apple:
    • Keyword parsing differs from Applesoft command line. For example FOR I = S TO P doesn't collapse into FOR I = STOP.
  • Limitations:
    • Floating point overflow is only detected on variable assignment.
    • Only a subset of DOS 3.3 and ProDOS useful for basic file I/O are implemented.
    • Only a small number of common PEEK, POKE and CALL locations are supported.
    • Commands that refer to assembly routines (&, USR() etc.), shape tables, and tape I/O are not implemented.
  • Commands that operate on the program itself (LIST, RUN, DEL, etc.) are not implemented.
  • A handful of extensions are made beyond Applesoft BASIC:
    • To improve readability, lines may start with : and continue the previously numbered line.
    • DEF FN can define string functions
    • == can be used as =
    • CHR$() values > 255 do interesting things
    • HSCRN(x, y) allows probing the hi-res screen
    • hexadecimal literals e.g. $C010 can be used as numbers