Jump to content

CX16UserSteveC

Members
  • Content Count

    25
  • Joined

  • Last visited

  • Days Won

    2

CX16UserSteveC last won the day on August 9

CX16UserSteveC had the most liked content!

Community Reputation

34 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Version 1.0.0

    4 downloads

    LIFE.PRG is an implementation of Conway's Game of Life compatible with the Commander X16 Emulator R38 (see https://en.wikipedia.org/wiki/Conway's_Game_of_Life). Configuring the Grid Dimensions: D - Toggles the grid dimensions between 29x29 (which is the default), 30x30, 59x59, and 60x60 options. The cell grid is always configured as a perfect square to permit more degrees of symmetry. Odd and even dimensions are both supported since they have different symmetry. The dimension of the length and width is illustrated in the upper right corner of the display. The 29x29 and 30x30 grid dimensions utilize 40x30 text mode, whereas the 59x59 and 60x60 grid dimensions utilize 80x60 text mode. The grid is cleared when the cell grid dimensions are changed. Initializing the Cell Grid: C - Clears all of the grid cells. E - Enters edit mode to manually configure the grid cells. The cursor keys are used to move the cursor pointer, the space bar toggles the state of the cell at the current cursor position, and E key is used to exit edit mode. In edit mode the row and column coordinates of the cursor are displayed in the upper left corner in the format "row,column". The mouse cursor is reused as a cursor pointer but the mouse is not currently supported. R - Randomizes the grid cells. H - Randomizes the grid with horizontal symmetry. V - Randomizes the grid with vertical symmetry. B - Randomizes the grid with both horizontal and vertical symmetry. F - Randomizes the grid with full symmetry (horizontal, vertical, and both diagonals). The edit mode entered by pressing the E key can be used to configure different patterns such as still-lifes, oscillators, and space ships (some of which are described at https://en.wikipedia.org/wiki/Conway's_Game_of_Life#Examples_of_patterns). The H, V, B, and F symmetrical configuration options generally result in more visually appealing patterns than the R configuration option. Iterating the Grid: U - Updates the grid a single time. S - Starts repetitive update of the grid, press S a second time to stop. The number of iterations performed on the cell grid is displayed in the upper left corner except in cell grid edit mode described above. The iteration count is initialized to zero at startup and reset to zero when the grid dimensions are changed via the D key or any of the grid initialization commands are executed (via the C, E, R, H, V, B, or F keys). When iterating the grid the left and right sides of the cell grid are considered to be adjacent as well as the top and bottom resulting in a toroidal array. Potential Future Enhancements: There are several potential future enhancements under consideration such as optimization to speed up the iteration of the cell grid, context-sensitive help, support for user-configurable grid sizes, support for multiple colors (e.g. based on state of a cell and the number of live neighbors), and support for other life-like cellular automaton (see https://en.wikipedia.org/wiki/Life-like_cellular_automaton). Life Video
  2. Game of Life View File LIFE.PRG is an implementation of Conway's Game of Life compatible with the Commander X16 Emulator R38 (see https://en.wikipedia.org/wiki/Conway's_Game_of_Life). Configuring the Grid Dimensions: D - Toggles the grid dimensions between 29x29 (which is the default), 30x30, 59x59, and 60x60 options. The cell grid is always configured as a perfect square to permit more degrees of symmetry. Odd and even dimensions are both supported since they have different symmetry. The dimension of the length and width is illustrated in the upper right corner of the display. The 29x29 and 30x30 grid dimensions utilize 40x30 text mode, whereas the 59x59 and 60x60 grid dimensions utilize 80x60 text mode. The grid is cleared when the cell grid dimensions are changed. Initializing the Cell Grid: C - Clears all of the grid cells. E - Enters edit mode to manually configure the grid cells. The cursor keys are used to move the cursor pointer, the space bar toggles the state of the cell at the current cursor position, and E key is used to exit edit mode. In edit mode the row and column coordinates of the cursor are displayed in the upper left corner in the format "row,column". The mouse cursor is reused as a cursor pointer but the mouse is not currently supported. R - Randomizes the grid cells. H - Randomizes the grid with horizontal symmetry. V - Randomizes the grid with vertical symmetry. B - Randomizes the grid with both horizontal and vertical symmetry. F - Randomizes the grid with full symmetry (horizontal, vertical, and both diagonals). The edit mode entered by pressing the E key can be used to configure different patterns such as still-lifes, oscillators, and space ships (some of which are described at https://en.wikipedia.org/wiki/Conway's_Game_of_Life#Examples_of_patterns). The H, V, B, and F symmetrical configuration options generally result in more visually appealing patterns than the R configuration option. Iterating the Grid: U - Updates the grid a single time. S - Starts repetitive update of the grid, press S a second time to stop. The number of iterations performed on the cell grid is displayed in the upper left corner except in cell grid edit mode described above. The iteration count is initialized to zero at startup and reset to zero when the grid dimensions are changed via the D key or any of the grid initialization commands are executed (via the C, E, R, H, V, B, or F keys). When iterating the grid the left and right sides of the cell grid are considered to be adjacent as well as the top and bottom resulting in a toroidal array. Potential Future Enhancements: There are several potential future enhancements under consideration such as optimization to speed up the iteration of the cell grid, context-sensitive help, support for user-configurable grid sizes, support for multiple colors (e.g. based on state of a cell and the number of live neighbors), and support for other life-like cellular automaton (see https://en.wikipedia.org/wiki/Life-like_cellular_automaton). Life Video Submitter CX16UserSteveC Submitted 10/17/20 Category Games  
  3. Thanks for the feedback. I'm currently working on implementing the new strategic mode described in the post above, but lately I've been thinking perhaps I should also implement a mode with a single larger shared grid where each player starts on their own side of the grid but can invade the opponent's side of the grid as the game progresses. Also shells could perhaps be fired in more directions than horizontal which is a limitation of the new strategic mode currently under development.
  4. CX16UserSteveC

    Sea Battle

    Version 1.0.0

    21 downloads

    Sea Battle is a variation on the classical game "Battleship". Sea Battle is a cc65 application currently compatible with revision R38 of the Commander X16 emulator. The graphics and computer targeting could both stand some improvement, but the game is fairly playable in it's current state. I believe computer targeting is strongest when "HIT NOTIFICATION" is configured as "IMMEDIATE" and "SHIP NOTIFICATION" is configured as "SHIP" which are the default settings. I'm at the point where I've had to optimize the code several times to squeeze in more functionality, and adding any significant additional functionality will likely require an investigation into the possibility of taking advantage of memory bank switching. Configuration Options: The "P" key is used to toggle the player-mode between single-player, two-player, and computer-vs-computer modes. The entity names on the bottom of the left and right grids illustrate the currently selected player-mode. The "S" key is used to toggle the fleet size between 5 and 6 ships. Player-mode and fleet size can only be changed before player-1 accepts configuration of their ships after which the "Q" key must be used to quit the game in order to change player-mode or fleet size. The "F1" key is used to select the number of "TURN GUESSES" which consists of an initial number of guesses for the first turn and also the number of guesses for each subsequent turn. In "1/1" mode each player is allowed one guess per turn including the initial turn. In "n/SHIPS LEFT" mode the entity (player or computer) taking the first turn is allowed "n" guesses, and the number of guesses allowed on each subsequent turn is based on the number of ships left in the attacking entity's fleet. The ability to configure the number of guesses for the entity taking the first turn is intended to be a way to offset the advantage of taking the first turn. The "F2" key is used to toggle the "HIT NOTIFICATION" between "IMMEDIATE" and "END OF TURN". This configuration is only relevant when "TURN GUESSES" is set to the "n/SHIPS LEFT" mode described above (since both "HIT NOTIFICATION" options are equivalent when "TURN GUESSES" is set to the "1/1" mode described above). The "F3" key is used to control the "SHIP NOTIFICATION" related to the sinking of ships. When the "NONE" option is selected there is no notification of sunken ships. The "NONE" option only applies when "TURN GUESSES" is set to "1/1" as described above. When the "COUNT" option is selected the notification is limited to the sinking of a ship. When the "SHIP" option is selected a hidden ship is displayed on the grid when sunk. Fleet Setup: Two-Player Mode: In two-player mode player-1 selects their ships using the "1-6" keys, moves their ships using the cursor keys, and rotates their ships using the "L" and "R" keys. Ships of odd length are rotated about their center, and ships of even length are rotated about the the first segment behind their center. The currently selected ship is indicated by the cursor. Movements and rotations that result in part of the ship being off-grid are disallowed.The space bar may also be used to generate a random ship configuration. When player-1 presses the "ENTER" key the display of player-1's ships is turned off (assuming a valid ship configuration with no overlap of ships) and then player-2 configures the location of their ships in a likewise manner. When player-2 presses the "ENTER" key the display of player-2's ships is turned off and player-1 then takes the first turn. It is assumed each player looks the other way when their opponent configures the location of their ships. Single-Player Mode: In single-player mode player-1 configures the location of their ships as described in the preceding paragraph. When player-1 presses the "ENTER" key the locations of the computer's ships are randomly generated and hidden. The location of player-1's ships remains visible to player-1 and the referee part of the application but are hidden from the computer opponent part of the application. Game play begins after player-1 chooses whether to take the initial turn or let the computer take the initial turn. Computer-vs-Computer Mode: In computer-vs-computer mode the player configures the location of the ships for both computer opponents. Both ship configurations remain visible to the player and the referee part of the application for the entire game, but each computer's ships remain hidden to the opponent computer part of the application. After accepting both configurations with the "ENTER" key, the left computer takes the first turn. Computer-vs-computer mode is intended as an aid to explore the strengths and weaknesses of the computer targeting system and the effects of "n" on the game outcome when "TURN GUESSES" is configured to "n/SHIPS LEFT". Game-Play: Player: The cursor may be moved on the opponent's grid using the cursor keys. The "0-9" and "A-J" keys may also be used to select any column or row respectively. The space bar may be used to select a random untested coordinate, and the "T" key may be used to select a coordinate preferred by the computer targeting system. This last option is intended as an aid to explore the strengths and weaknesses of the computer targeting system. When the user presses the enter key the selected coordinate is fired upon. Hits are indicated by red, misses are indicated by white, the last hit that sinks a ship is indicated by orange (assuming "SHIP NOTIFICATION" is not configured to "NONE"), and yellow is used to temporarily indicate selected targets when "TURN GUESSES" is configured to "n/SHIPS LEFT" and "HIT NOTIFICATION" is configured to "END OF TURN". Computer: When the computer takes it's turn the player is prompted to press a key to acknowledge each of the computer's guesses. Support: If you encounter a problem that you think is related to a bug in the source code please take and submit a screen shot in a problem report illustrating the configuration where you're having a problem to aid in diagnosis of the problem. Future Strategic Mode: My ultimate goal is to develop a game mode with a much deeper strategy than the classical "Battleship" game. The basic concept is to allow each player to see the position of their opponents ships at all times, and also to allow movement of each of a player's ships on their turn. Each ship may be moved one position backward, starboard or port on a single turn, or it may be moved multiple positions forward on a single turn. The number of positions forward is based on the length of the ship (smaller ships which are presumably faster can move further than larger ships). Alternatively a ship can be rotated 90-degrees clockwise or counterclockwise. Movements and rotations that result in part of the ship being off-grid are disallowed. At the beginning of the game player-1 (who takes the first turn) configures the position of their ships, and then player-2 configures the position of their ships. This is intended to partially offset the advantage of player-1 taking the first turn. This player-1 advantage can be further offset by configuring the number of shells that can be fired on player-1's first turn to be less than the fleet size (which is the maximum number of shells that can be fired on each player's subsequent turn until their first ship is sunk). Each ship segment is initially loaded with a shell, and each ship with a remaining shell can fire each turn. Shells are only fired horizontally along the same row and limited to a range of 10, so a only a shell fired from the closest column adjacent to the enemy's grid can reach the furthest column of the enemies grid. The probability of a hit can be adjusted such that it decreases with range, and also can be adjusted such that it decreases when a shell is fired after a ship moves (instead of before it moves) on a player's turn. A ship's shells can be reloaded when part or all of the ship is on the column furthest from the enemy's grid which is considered home base (which is column-0 for player-1 and column-9 for player-2). When a ship segment is damaged that segment can no longer be reloaded, and when all segments are damaged a ship is considered sunk. A player's ship shells are reloaded at the beginning of their turn assuming one or more of the ship segments is on the home-base column. When only a single segment of the ship is on the home-base column a single shell is reloaded to the first undamaged and empty segment of the ship closest to the home-base column. When the entire ship is on the home-base column all undamaged and empty segments of the ship are reloaded in parallel at the beginning of a player's turn. I was originally thinking of integrating the future strategic mode into the current Sea Battle application, but due to memory constraints mentioned above I'll probably end up making it a separate application. I'm planning on implementing two-player mode first since the computer targeting strategy required for single-player mode is much more complicated for the future planned strategic mode than it is for the currently implemented mode which is only a slight variation of the classical "Battleship" game. Collaboration: I'm defining an API for the computer targeting function which I'm separating out from the rest of the current Sea Battle application, and I'm planning on taking a similar approach with the future strategic mode application. The intent is to support collaboration on enhancing the computer targeting function of the current Sea Battle application as well as collaboration on the development of the computer targeting and ship movement functions of the future strategic mode application (which I consider to be the most difficult part), so let me know if anyone is interested in collaboration on the computer functions of either of these two applications.
  5. Sea Battle View File Sea Battle is a variation on the classical game "Battleship". Sea Battle is a cc65 application currently compatible with revision R38 of the Commander X16 emulator. The graphics and computer targeting could both stand some improvement, but the game is fairly playable in it's current state. I believe computer targeting is strongest when "HIT NOTIFICATION" is configured as "IMMEDIATE" and "SHIP NOTIFICATION" is configured as "SHIP" which are the default settings. I'm at the point where I've had to optimize the code several times to squeeze in more functionality, and adding any significant additional functionality will likely require an investigation into the possibility of taking advantage of memory bank switching. Configuration Options: The "P" key is used to toggle the player-mode between single-player, two-player, and computer-vs-computer modes. The entity names on the bottom of the left and right grids illustrate the currently selected player-mode. The "S" key is used to toggle the fleet size between 5 and 6 ships. Player-mode and fleet size can only be changed before player-1 accepts configuration of their ships after which the "Q" key must be used to quit the game in order to change player-mode or fleet size. The "F1" key is used to select the number of "TURN GUESSES" which consists of an initial number of guesses for the first turn and also the number of guesses for each subsequent turn. In "1/1" mode each player is allowed one guess per turn including the initial turn. In "n/SHIPS LEFT" mode the entity (player or computer) taking the first turn is allowed "n" guesses, and the number of guesses allowed on each subsequent turn is based on the number of ships left in the attacking entity's fleet. The ability to configure the number of guesses for the entity taking the first turn is intended to be a way to offset the advantage of taking the first turn. The "F2" key is used to toggle the "HIT NOTIFICATION" between "IMMEDIATE" and "END OF TURN". This configuration is only relevant when "TURN GUESSES" is set to the "n/SHIPS LEFT" mode described above (since both "HIT NOTIFICATION" options are equivalent when "TURN GUESSES" is set to the "1/1" mode described above). The "F3" key is used to control the "SHIP NOTIFICATION" related to the sinking of ships. When the "NONE" option is selected there is no notification of sunken ships. The "NONE" option only applies when "TURN GUESSES" is set to "1/1" as described above. When the "COUNT" option is selected the notification is limited to the sinking of a ship. When the "SHIP" option is selected a hidden ship is displayed on the grid when sunk. Fleet Setup: Two-Player Mode: In two-player mode player-1 selects their ships using the "1-6" keys, moves their ships using the cursor keys, and rotates their ships using the "L" and "R" keys. Ships of odd length are rotated about their center, and ships of even length are rotated about the the first segment behind their center. The currently selected ship is indicated by the cursor. Movements and rotations that result in part of the ship being off-grid are disallowed.The space bar may also be used to generate a random ship configuration. When player-1 presses the "ENTER" key the display of player-1's ships is turned off (assuming a valid ship configuration with no overlap of ships) and then player-2 configures the location of their ships in a likewise manner. When player-2 presses the "ENTER" key the display of player-2's ships is turned off and player-1 then takes the first turn. It is assumed each player looks the other way when their opponent configures the location of their ships. Single-Player Mode: In single-player mode player-1 configures the location of their ships as described in the preceding paragraph. When player-1 presses the "ENTER" key the locations of the computer's ships are randomly generated and hidden. The location of player-1's ships remains visible to player-1 and the referee part of the application but are hidden from the computer opponent part of the application. Game play begins after player-1 chooses whether to take the initial turn or let the computer take the initial turn. Computer-vs-Computer Mode: In computer-vs-computer mode the player configures the location of the ships for both computer opponents. Both ship configurations remain visible to the player and the referee part of the application for the entire game, but each computer's ships remain hidden to the opponent computer part of the application. After accepting both configurations with the "ENTER" key, the left computer takes the first turn. Computer-vs-computer mode is intended as an aid to explore the strengths and weaknesses of the computer targeting system and the effects of "n" on the game outcome when "TURN GUESSES" is configured to "n/SHIPS LEFT". Game-Play: Player: The cursor may be moved on the opponent's grid using the cursor keys. The "0-9" and "A-J" keys may also be used to select any column or row respectively. The space bar may be used to select a random untested coordinate, and the "T" key may be used to select a coordinate preferred by the computer targeting system. This last option is intended as an aid to explore the strengths and weaknesses of the computer targeting system. When the user presses the enter key the selected coordinate is fired upon. Hits are indicated by red, misses are indicated by white, the last hit that sinks a ship is indicated by orange (assuming "SHIP NOTIFICATION" is not configured to "NONE"), and yellow is used to temporarily indicate selected targets when "TURN GUESSES" is configured to "n/SHIPS LEFT" and "HIT NOTIFICATION" is configured to "END OF TURN". Computer: When the computer takes it's turn the player is prompted to press a key to acknowledge each of the computer's guesses. Support: If you encounter a problem that you think is related to a bug in the source code please take and submit a screen shot in a problem report illustrating the configuration where you're having a problem to aid in diagnosis of the problem. Future Strategic Mode: My ultimate goal is to develop a game mode with a much deeper strategy than the classical "Battleship" game. The basic concept is to allow each player to see the position of their opponents ships at all times, and also to allow movement of each of a player's ships on their turn. Each ship may be moved one position backward, starboard or port on a single turn, or it may be moved multiple positions forward on a single turn. The number of positions forward is based on the length of the ship (smaller ships which are presumably faster can move further than larger ships). Alternatively a ship can be rotated 90-degrees clockwise or counterclockwise. Movements and rotations that result in part of the ship being off-grid are disallowed. At the beginning of the game player-1 (who takes the first turn) configures the position of their ships, and then player-2 configures the position of their ships. This is intended to partially offset the advantage of player-1 taking the first turn. This player-1 advantage can be further offset by configuring the number of shells that can be fired on player-1's first turn to be less than the fleet size (which is the maximum number of shells that can be fired on each player's subsequent turn until their first ship is sunk). Each ship segment is initially loaded with a shell, and each ship with a remaining shell can fire each turn. Shells are only fired horizontally along the same row and limited to a range of 10, so a only a shell fired from the closest column adjacent to the enemy's grid can reach the furthest column of the enemies grid. The probability of a hit can be adjusted such that it decreases with range, and also can be adjusted such that it decreases when a shell is fired after a ship moves (instead of before it moves) on a player's turn. A ship's shells can be reloaded when part or all of the ship is on the column furthest from the enemy's grid which is considered home base (which is column-0 for player-1 and column-9 for player-2). When a ship segment is damaged that segment can no longer be reloaded, and when all segments are damaged a ship is considered sunk. A player's ship shells are reloaded at the beginning of their turn assuming one or more of the ship segments is on the home-base column. When only a single segment of the ship is on the home-base column a single shell is reloaded to the first undamaged and empty segment of the ship closest to the home-base column. When the entire ship is on the home-base column all undamaged and empty segments of the ship are reloaded in parallel at the beginning of a player's turn. I was originally thinking of integrating the future strategic mode into the current Sea Battle application, but due to memory constraints mentioned above I'll probably end up making it a separate application. I'm planning on implementing two-player mode first since the computer targeting strategy required for single-player mode is much more complicated for the future planned strategic mode than it is for the currently implemented mode which is only a slight variation of the classical "Battleship" game. Collaboration: I'm defining an API for the computer targeting function which I'm separating out from the rest of the current Sea Battle application, and I'm planning on taking a similar approach with the future strategic mode application. The intent is to support collaboration on enhancing the computer targeting function of the current Sea Battle application as well as collaboration on the development of the computer targeting and ship movement functions of the future strategic mode application (which I consider to be the most difficult part), so let me know if anyone is interested in collaboration on the computer functions of either of these two applications. Submitter CX16UserSteveC Submitted 09/06/20 Category Games  
  6. Thanks for your offer to take a look but I added the .PRG extension to my file names and now all of my cc65 applications seem to work (at least to some degree) with the web emulator. My currently uploaded cc65 applications can all be downloaded (or tested with the "try it now" feature) from the Graphics Apps folder.
  7. Thanks for your feedback. I added the .PRG extension to my file names and now my cc65 applications seem to work (at least to some degree) with the web emulator.
  8. My cc65 application file names are currently all upper case but with no extension. My programs can be loaded into the local emulator using the -prg option using their current file names, and so I thought it was only necessary to specify the file name for the web emulator as well. I always use upper case for my file names in case the user chooses to start the emulator first and then load the application via the Basic LOAD command. Should I use the .prg or .seq extension, and should these be .PRG or .SEQ when added to my file names? Also, I have no zip file. Is a zip file required?
  9. Maybe I should have posted this to the "Off-topic Lounge" instead of the "X16 Discussion Lounge" since it's a bit off-topic to the mainstream development. I'm not really seriously proposing to emulate the Commander X16 with the DE10-Nano Kit at this point (this is more of a hypothetical question), but I was curious if something like the DE10-Nano Kit is powerful enough to fully "hardware" emulate the Commander X16. I was also wondering how hard it would be since I believe there are existing FPGA cores for the 6502 and the Commodore 64, and the VERA FPGA code could also perhaps be ported to the DE10-Nano Kit FPGA.
  10. I'm wondering if in hindsight it would have made more sense to develop the X16 on something like the DE10-Nano instead of developing a new hardware platform. I understand there was an initial resistance to using FPGAs in the Commander X16, but that resistance was eventually abandoned for the VERA. And there 's a Commodore 64 “hardware emulation core” that could have been used as a starting point.
  11. I don't understand the comparison to RPI4 which would be software emulation. I don't know much about the MiSTer FPGA project but my understanding is the DE10-Nano Kit can perform hardware emulation of more powerful machines than the Commodore 64 or Commander X16 using the onboard FPGA resources of the DE10-Nano Kit (see https://www.retrorgb.com/systems.html). I'm not talking about running a version of the Commander X16 SW emulator on the DE10-Nano Kit, rather I'm talking about running a “hardware emulation core” of the Commander X16 hardware itself similar to the way the other more powerful machines are emulated.
  12. I'm wondering if it'd be possible to perform hardware emulation of a Commander X16 with something like a DE10-Nano Kit (see https://www.retrorgb.com/mister.html). Just curious.
  13. Where are the limitations of the "Try it now" web emulator documented? None of the cc65 applications I've uploaded seem to work with the "Try it now" feature.
  14. Is there an assembly API for the Commander X16 Basic VLOAD function and if so, where is it documented? Also, where is the Commander X16 VLOAD Basic function documented? (the Commander X16 Programmer's Reference Guide indicates TODO) Also, are there plans to support a Commander X16 VSAVE Basic function and assembly API?
  15. I originally put the three files in my program file directory which is one layer deeper than the emulator executable and then executed the following command from the terminal: ../x16emu -echo -prg loader.prg. Today I tried changing the names of all three files from lower case to upper case and now it seems to be working. I believe the original problem was the b1.prg and b2.prg files were not found by the emulator, but changing their names to B1.PRG and B2.PRG seems to have fixed the problem. Perhaps you could clarify in your tutorial the names of the b1.prg and b2.prg files need to be changed from lower case to upper case, or re-post the files with upper case names instead of lower case names. You could also enhance your program which currently has no error checking on the LOAD operation. This would allow you to print a message informing the user of the error returned by READST on the LOAD operation and avoid attempting to execute code that hasn't been loaded.
×
×
  • Create New...

Important Information

Please review our Terms of Use