Jump to content

CX16UserSteveC

Members
  • Posts

    32
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by CX16UserSteveC

  1. Has anyone been able to get binary byte-oriented file I/O working in cc65 C applications? If so, could you please point me to an example of some working code? I've only been able to get the cbm_load() and cbm_save() functions working which loads or saves an entire file. I noticed C3c posted assembly source code below which loads an entire file into memory. As I said above I've been able to accomplish this with the cbm_load function defined in the cbm.h file in the cc65 include directory. To clarify I'd like to load and save a file a byte at a time which is what I meant by byte-oriented file I/O. This provides the ability to save and load files where different portions go to or come from different portions of memory. This also provides the ability to extract the relevant portion of very large files while discarding the remainder. My primary interest is a working example of cc65 C source code, but a working example of cc65 assembly source code might provide some insight. I've tried various level of APIs including the following. c - fopen() seems to work but fgetc() seems to hang cbm - cbm_load() and cbm_save() seem to work as mentioned above, but cbm_open() returns error code 6. cbm_k: cbm_k_open() returns error code 6 after first executing cbm_k_setnam() and cbm_k_setlfs() I believe the cbm_k level API above is the direct interface to the kernel API which is claimed to work by desertfish below, but perhaps there's an error in cc65 (or my code). I've also implemented my own C interface to the kernel API which works for everything I've tested except file I/O. Assuming the following definitions #define INFILE_STR "celestemap.dat" #define lfn 0 #define device 8 #define sec_addr 0 cbm_load(INFILE_STR, device, inputBuffer) works but cbm_open(lfn, device, sec_addr, INFILE_STR) returns error code 6 and cbm_k_open() also returns error code 6 after first executing cbm_k_setnam(INFILE_STR) and cbm_k_setlfs(lfn, device, sec_addr). I also tried using #define lfn 1 which just seems to lead to error code 5 instead of 6 returned by cbm_open() and cbm_k_open(). I also tried various BASIC OPEN statements and they all returned a DEVICE NOT PRESENT error. I noticed the Commander X16 Emulator User Guide indicates the following: "Note that this feature is very limited! Manually reading and writing files (e.g. OPEN in BASIC) is not supported by the host filesystem interface. Use SD card images for this." So perhaps I need to create an SD card image for my data file instead of using the host computer's local filesystem.
  2. Version 1.0.1

    6 downloads

    I've been investigating the feasibility of using fantasy console development environments to develop new fantasy-console-style video games for the Commander X16 and also to potentially port existing fantasy console video games to the Commander X16. I've primarily been investigating the PICO-8 and TIC-80 fantasy consoles (see https://www.lexaloffle.com/pico-8.php and https://tic80.com/ ), but there are a variety of fantasy consoles/computers (see https://github.com/paladin-t/fantasy ).This Commander X16 demo repetitively cycles through sequential display of the PICO-8 color palette, sprite sheet, and 16 screens of the map that I imported from the PICO-8 CELESTE video game by Matt Thorson and Noel Berry which was the initial basis for their computer/console version (see https://en.wikipedia.org/wiki/Celeste_(video_game) ).
  3. CELESTEMAP.PRG View File I've been investigating the feasibility of using fantasy console development environments to develop new fantasy-console-style video games for the Commander X16 and also to potentially port existing fantasy console video games to the Commander X16. I've primarily been investigating the PICO-8 and TIC-80 fantasy consoles (see https://www.lexaloffle.com/pico-8.php and https://tic80.com/ ), but there are a variety of fantasy consoles/computers (see https://github.com/paladin-t/fantasy). This Commander X16 demo repetitively cycles through sequential display of the PICO-8 color palette, sprite sheet, and 16 screens of the map that I imported from the PICO-8 CELESTE video game by Matt Thorson and Noel Berry which was the initial basis for their computer/console version (see https://en.wikipedia.org/wiki/Celeste_(video_game)). Submitter CX16UserSteveC Submitted 11/05/21 Category Demos  
  4. Version 1.0.0

    30 downloads

    The Commander X16 8-BitCoin Miner application supports the mining of a notional crypto currency which I refer to as 8-BitCoin which has no monetary value but perhaps you can gain a bit of notoriety by posting snapshots of rare results on the Commander X16 Facebook page, and perhaps this application will inspire those unfamiliar with BitCoin to learn a bit more about it. The Commander X16 8-BitCoin Miner application is based on Bitcoin Miner 64 by YTM/Elysium (https://github.com/ytmytm/c64-bitcoin-miner) which was inspired by stacksmasher's GameBoy miner (https://www.youtube.com/watch?v=4ckjr9x214c). Bitcoin Miner 64 supports a demo mode as well as a cooperative mining mode which interfaces to an eternal process running ntgbtminer (https://github.com/ytmytm/c64-ntgbtminer). I don't know of any way of communicating with an external process from an application running on the Commander X16 emulator, so I removed the cooperative mining mode and focused on enhancing the standalone demo mode in the port to the Commander X16. Enhancements include the ability to randomize the block data, keep track of total number of hashes and associated 8-BitCoin value earned, display the best and last hash results and associated nonces and 8-BitCoin values, and to load and save state which allows a user to restore their data between sessions. I've created and posted a C64 version as well as a CX16 version. For the CX16 version a single penny is earned for the first leading zero in the binary representation of the hash result and each subsequent leading zero increases in value by a 2x factor. When the first one is detected in the binary representation of the hash result, each subsequent zero decreases in value by a 2x factor until the value is less than a single penny. Since the CX16 clock rate is approximately 8x the C64 clock rate, the earned value for the C64 version is calculated by multiplying the earned value for the CX16 version by a factor of 8. When the 8-BitCoin Miner application is started a title screen is displayed at which point the user can press any key to advance to the main menu. At the main menu the user can randomize the block data, start mining, and save and load the mining state via the R, M, S, and L keys respectively. When the block data is randomized any previous best and current hash results are cleared but the total hash count and associated earned value are retained. The best and last hash results are cleared and the total hash count and associated earned value are initialized to zero when the 8-BitCoin Miner application is started, but loading a previously saved state will restore the best and last hash results and the total hash count and associated earned value. There's a single "BITMINER.DAT" save file, so be aware saving will overwrite any previous existing version of this file. Likewise when you perform a load command you will lose any results accumulated since the last save operation. If you want to save and load state you'll probably have to download the application because I doubt that these features will work properly with the online emulator associated with the "Try it now" feature (since there's the possibility of multiple simultaneous users and only a single save file which doesn't seem to be retained between on-line emulator sessions). When mining the user may return to the main menu by pressing the M key. I tested the CX16 version on the CX16 emulator revision R38 and I briefly tested the C64 version on the VICE C64 emulator and the C64 mini. The save and load functions seem to work on the VICE C64 emulator but not on the C64 mini. However, you can use the save and load functions provided by the C64 mini to save and restore the state between mining sessions. Here's some C source code which is equivalent to the implementation and intended to clarify calculation of the earned value from the hash result. The calculation of hashWord is not shown but occurs in the ... portion between the variable declaration and subsequent code. uint32_t hashWord, value, bitMask, deltaValue; . . . value=0; bitMask=0x80000000; deltaValue=1; while((bitMask!=0) && ((bitMask & hashWord)==0)) { value+=deltaValue; bitMask=bitMask>>1; deltaValue=deltaValue<<1; } bitMask=bitMask>>1; deltaValue=deltaValue>>1; while((bitMask!=0) && (deltaValue!=0)) { if ((bitMask & hashWord)==0) value+=deltaValue; bitMask=bitMask>>1; deltaValue=deltaValue>>1; } #ifdef C64 // multiply value by 8 for C64 version value=value<<3; #endif
  5. 8-BitCoin Miner View File The Commander X16 8-BitCoin Miner application supports the mining of a notional crypto currency which I refer to as 8-BitCoin which has no monetary value but perhaps you can gain a bit of notoriety by posting snapshots of rare results on the Commander X16 Facebook page, and perhaps this application will inspire those unfamiliar with BitCoin to learn a bit more about it. The Commander X16 8-BitCoin Miner application is based on Bitcoin Miner 64 by YTM/Elysium (https://github.com/ytmytm/c64-bitcoin-miner) which was inspired by stacksmasher's GameBoy miner (https://www.youtube.com/watch?v=4ckjr9x214c). Bitcoin Miner 64 supports a demo mode as well as a cooperative mining mode which interfaces to an eternal process running ntgbtminer (https://github.com/ytmytm/c64-ntgbtminer). I don't know of any way of communicating with an external process from an application running on the Commander X16 emulator, so I removed the cooperative mining mode and focused on enhancing the standalone demo mode in the port to the Commander X16. Enhancements include the ability to randomize the block data, keep track of total number of hashes and associated 8-BitCoin value earned, display the best and last hash results and associated nonces and 8-BitCoin values, and to load and save state which allows a user to restore their data between sessions. I've created and posted a C64 version as well as a CX16 version. For the CX16 version a single penny is earned for the first leading zero in the binary representation of the hash result and each subsequent leading zero increases in value by a 2x factor. When the first one is detected in the binary representation of the hash result, each subsequent zero decreases in value by a 2x factor until the value is less than a single penny. Since the CX16 clock rate is approximately 8x the C64 clock rate, the earned value for the C64 version is calculated by multiplying the earned value for the CX16 version by a factor of 8. When the 8-BitCoin Miner application is started a title screen is displayed at which point the user can press any key to advance to the main menu. At the main menu the user can randomize the block data, start mining, and save and load the mining state via the R, M, S, and L keys respectively. When the block data is randomized any previous best and current hash results are cleared but the total hash count and associated earned value are retained. The best and last hash results are cleared and the total hash count and associated earned value are initialized to zero when the 8-BitCoin Miner application is started, but loading a previously saved state will restore the best and last hash results and the total hash count and associated earned value. There's a single "BITMINER.DAT" save file, so be aware saving will overwrite any previous existing version of this file. Likewise when you perform a load command you will lose any results accumulated since the last save operation. If you want to save and load state you'll probably have to download the application because I doubt that these features will work properly with the online emulator associated with the "Try it now" feature (since there's the possibility of multiple simultaneous users and only a single save file which doesn't seem to be retained between on-line emulator sessions). When mining the user may return to the main menu by pressing the M key. I tested the CX16 version on the CX16 emulator revision R38 and I briefly tested the C64 version on the VICE C64 emulator and the C64 mini. The save and load functions seem to work on the VICE C64 emulator but not on the C64 mini. However, you can use the save and load functions provided by the C64 mini to save and restore the state between mining sessions. Here's some C source code which is equivalent to the implementation and intended to clarify calculation of the earned value from the hash result. The calculation of hashWord is not shown but occurs in the ... portion between the variable declaration and subsequent code. uint32_t hashWord, value, bitMask, deltaValue; . . . value=0; bitMask=0x80000000; deltaValue=1; while((bitMask!=0) && ((bitMask & hashWord)==0)) { value+=deltaValue; bitMask=bitMask>>1; deltaValue=deltaValue<<1; } bitMask=bitMask>>1; deltaValue=deltaValue>>1; while((bitMask!=0) && (deltaValue!=0)) { if ((bitMask & hashWord)==0) value+=deltaValue; bitMask=bitMask>>1; deltaValue=deltaValue>>1; } #ifdef C64 // multiply value by 8 for C64 version value=value<<3; #endif Submitter CX16UserSteveC Submitted 05/02/21 Category Demos  
  6. Data in the 6502 microprocessor RAM can also be loaded and saved via the following cc65 function calls which are declared in cbm.h: unsigned int __fastcall__ cbm_load (const char* name, unsigned char device, void* data); /* Loads file "name", from given device, to given address -- or, to the load ** address of the file if "data" is the null pointer (like load"name",8,1 ** in BASIC). ** Returns number of bytes that were loaded if loading was successful; ** otherwise 0, "_oserror" contains an error-code, then (see table above). */ unsigned char __fastcall__ cbm_save (const char* name, unsigned char device, const void* addr, unsigned int size); /* Saves "size" bytes, starting at "addr", to a file. ** Returns 0 if saving was successful, otherwise an error-code (see table ** above). */ Here are some example invocations: r=cbm_save("bitminer.dat",8,&minerData,sizeof(minerData)); bytesLoaded=cbm_load("bitminer.dat",8,&minerDataLoadBuffer);
  7. Has anyone ever tried the Commodore OS Vision (see https://en.wikipedia.org/wiki/Commodore_OS) or Commodore OS Vision II (https://sparrosdeveloperteam.github.io/COS/)?
  8. 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  
  9. Version 1.0.0

    57 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
  10. 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.
  11. 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  
  12. Version 1.0.0

    61 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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?
  18. 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.
  19. Does this program actually work? When I load and execute loader.prg it immediately returns to the Basic READY prompt. If it worked I was expecting it to execute b1.prg and b2.prg after loading these two into RAM which I believe should have printed "hello, bank 1!" and "hello, bank 2!" to the screen. My reason for investigating this program is that I've read Revision R37 of the Commander X16 emulator doesn't support file IO to disk (except perhaps loading VRAM via the VLOAD function). I tried some file IO to disk with some of my own C applications and couldn't seem to get disk file IO to work, so I'd like to determine if it really is a problem with the Commander X16 emulator or a problem with cc65 or my C applications.
  20. Color Sketch (COLORSKETCH) View File When used with keyboard or SNES game-pad controls the COLORSKETCH application is somewhat analogous to an "Etch-A-Sketch" device but with support for assigning colors to the pen and toggling the pen state "on/off". When used with mouse controls COLORSKETCH is more akin to a primitive drawing/painting program. COLORSKETCH supports a resolution of 320x240 pixels at 8-bit color and is currently compatible with revision R37 of the Commander X16 emulator. COLORSKETCH also provides the ability to edit the RGB values of the color palette (except for color index 0 which corresponds to transparent). COLORSKETCH supports two primary modes of operation including sketch mode and color selection mode which are described below. Sketch Mode: In sketch mode the space bar toggles the "on/off" state of the pen which defaults to "off" when COLORSKETCH is started. When the pen state is "off" a pointer appears on the screen to show the current location of the cursor. When the pen state is toggled "on" the cursor pointer is turned off and the pixel at the current cursor location is populated with the currently selected color. The Arrow keys (and also "WSAD" keys) are used to move the cursor vertically and horizontally between pixels, and the "QEZX" keys are used to move diagonally between pixels. When the pen state is "on" the currently selected color is populated in all pixels visited as the cursor is moved. In sketch mode the "B" key may be used to toggle the pen between the layer 0 background color (which is selected at startup as described further below) and the currently selected color. This capability is intended as a means to quickly address/erase mistakes. In sketch mode the "F1" key may be used to toggle the display of the cursor coordinates between the top left of the screen (which is the default when COLORSKETCH is started), top right of the screen, and off. In sketch mode the "F3" and "F4" keys may also be used to cycle the layer 1 foreground and background colors used for the display of the cursor coordinates mentioned above and in the color selection mode menu described below. The layer 1 foreground color also affects the color of the cursor pointer described above. The layer 1 foreground and background colors can be set to any of the first 16 entries in the color palette except the layer 1 background color can not be set to index 0 (which corresponds to transparent). The "C" key is used to enter color selection mode which is described below. Color Selection Mode: In color selection mode the color palette is organized into 16 rows where each row contains 16 colors, and only a single row of the color palette is displayed at the top of the screen. The left and right arrow keys (and also "A/D" keys) are used to move between colors in the same row, and the up/down arrow keys (and also "W/S" keys) are used to move between rows of the color palette. The currently selected color is underlined and the left side of the color selection mode screen displays information including the color index and the RGB values of the currently selected color. The RGB values of the currently selected color may be edited using the "R/r", "G/g", and "B/b" keys (except the transparent color associated with index 0). The "0" key may be used to navigate directly to the first entry in the color palette (with index 0). When the Enter key is pressed the currently selected color is assigned to the pen and color selection mode is exited transferring control back to sketch mode described above. Color selection mode may also be exited by pressing the "Q" key which retains any changes made to the color palette but does not affect the currently selected color. Sketch Mode Background Color: When COLORSKETCH is started it initially enters color selection mode described above to select a layer 0 background color for sketch mode which defaults to index 0 which corresponds to transparent. Controller Support: COLORSKETCH supports the SNES controller when the emulator is started with the "-joy1 SNES" option. The D-pad is supported in color selection mode as well as sketch mode. When attempting to draw a diagonal line in sketch mode many times one of the D-pad controls activates before the other one. To address this issue the right or left bumper may be depressed and held down and then the up or down D-pad control may be depressed in order to draw a diagonal line. In sketch mode the SNES controller "A" button is used to toggle the pen state "on/off", the "B" button is used to toggle between the layer 0 background color and the currently selected color, and the "X" button may be used to enter color selection mode. In color selection mode the "Y" button is used to return to sketch mode. Mouse Support: I haven't found mouse support to be particularly smooth or reliable in the Commander X16 emulator at this point so COLORSKETCH provides the ability to toggle the mouse "on/off" with the "M" key. The mouse defaults to "off". When the mouse is turned "on" the left mouse button is used to control the pen. In mouse mode the cursor is always visible. When using the mouse to draw (with the left mouse button depressed) it is advisable to move the mouse slowly in order to color all pixels visited by the mouse. The mouse is only used in sketch mode and is disabled in color selection mode both of which are described above. At times the mouse seems to be restricted to a subset of the Commander X16 emulator screen and in this case sometimes the problem can be resolved by moving the mouse all the way to the left, right, top, and bottom sides of the entire monitor screen and then moving the mouse back into the window associated with the Commander X16 emulator. The cursor and SNES game pad controls provide more precise control than mouse controls. For example the cursor and SNES game pad controls can be used to draw perfectly horizontal, vertical, and diagonal lines. The option to display cursor coordinates also provides the ability to achieve exactness with respect to the placement and dimensions of drawn objects. It's desirable to add support for saving/loading of the sketch and color palette data to/from disk files but unfortunately Revision R37 of the Commander X16 emulator doesn't support file input/output to disk. Submitter CX16UserSteveC Submitted 08/08/20 Category Graphics Apps  
  21. Version 1.0.0

    45 downloads

    When used with keyboard or SNES game-pad controls the COLORSKETCH application is somewhat analogous to an "Etch-A-Sketch" device but with support for assigning colors to the pen and toggling the pen state "on/off". When used with mouse controls COLORSKETCH is more akin to a primitive drawing/painting program. COLORSKETCH supports a resolution of 320x240 pixels at 8-bit color and is currently compatible with revision R37 of the Commander X16 emulator. COLORSKETCH also provides the ability to edit the RGB values of the color palette (except for color index 0 which corresponds to transparent). COLORSKETCH supports two primary modes of operation including sketch mode and color selection mode which are described below. Sketch Mode: In sketch mode the space bar toggles the "on/off" state of the pen which defaults to "off" when COLORSKETCH is started. When the pen state is "off" a pointer appears on the screen to show the current location of the cursor. When the pen state is toggled "on" the cursor pointer is turned off and the pixel at the current cursor location is populated with the currently selected color. The Arrow keys (and also "WSAD" keys) are used to move the cursor vertically and horizontally between pixels, and the "QEZX" keys are used to move diagonally between pixels. When the pen state is "on" the currently selected color is populated in all pixels visited as the cursor is moved. In sketch mode the "B" key may be used to toggle the pen between the layer 0 background color (which is selected at startup as described further below) and the currently selected color. This capability is intended as a means to quickly address/erase mistakes. In sketch mode the "F1" key may be used to toggle the display of the cursor coordinates between the top left of the screen (which is the default when COLORSKETCH is started), top right of the screen, and off. In sketch mode the "F3" and "F4" keys may also be used to cycle the layer 1 foreground and background colors used for the display of the cursor coordinates mentioned above and in the color selection mode menu described below. The layer 1 foreground color also affects the color of the cursor pointer described above. The layer 1 foreground and background colors can be set to any of the first 16 entries in the color palette except the layer 1 background color can not be set to index 0 (which corresponds to transparent). The "C" key is used to enter color selection mode which is described below. Color Selection Mode: In color selection mode the color palette is organized into 16 rows where each row contains 16 colors, and only a single row of the color palette is displayed at the top of the screen. The left and right arrow keys (and also "A/D" keys) are used to move between colors in the same row, and the up/down arrow keys (and also "W/S" keys) are used to move between rows of the color palette. The currently selected color is underlined and the left side of the color selection mode screen displays information including the color index and the RGB values of the currently selected color. The RGB values of the currently selected color may be edited using the "R/r", "G/g", and "B/b" keys (except the transparent color associated with index 0). The "0" key may be used to navigate directly to the first entry in the color palette (with index 0). When the Enter key is pressed the currently selected color is assigned to the pen and color selection mode is exited transferring control back to sketch mode described above. Color selection mode may also be exited by pressing the "Q" key which retains any changes made to the color palette but does not affect the currently selected color. Sketch Mode Background Color: When COLORSKETCH is started it initially enters color selection mode described above to select a layer 0 background color for sketch mode which defaults to index 0 which corresponds to transparent. Controller Support: COLORSKETCH supports the SNES controller when the emulator is started with the "-joy1 SNES" option. The D-pad is supported in color selection mode as well as sketch mode. When attempting to draw a diagonal line in sketch mode many times one of the D-pad controls activates before the other one. To address this issue the right or left bumper may be depressed and held down and then the up or down D-pad control may be depressed in order to draw a diagonal line. In sketch mode the SNES controller "A" button is used to toggle the pen state "on/off", the "B" button is used to toggle between the layer 0 background color and the currently selected color, and the "X" button may be used to enter color selection mode. In color selection mode the "Y" button is used to return to sketch mode. Mouse Support: I haven't found mouse support to be particularly smooth or reliable in the Commander X16 emulator at this point so COLORSKETCH provides the ability to toggle the mouse "on/off" with the "M" key. The mouse defaults to "off". When the mouse is turned "on" the left mouse button is used to control the pen. In mouse mode the cursor is always visible. When using the mouse to draw (with the left mouse button depressed) it is advisable to move the mouse slowly in order to color all pixels visited by the mouse. The mouse is only used in sketch mode and is disabled in color selection mode both of which are described above. At times the mouse seems to be restricted to a subset of the Commander X16 emulator screen and in this case sometimes the problem can be resolved by moving the mouse all the way to the left, right, top, and bottom sides of the entire monitor screen and then moving the mouse back into the window associated with the Commander X16 emulator. The cursor and SNES game pad controls provide more precise control than mouse controls. For example the cursor and SNES game pad controls can be used to draw perfectly horizontal, vertical, and diagonal lines. The option to display cursor coordinates also provides the ability to achieve exactness with respect to the placement and dimensions of drawn objects. It's desirable to add support for saving/loading of the sketch and color palette data to/from disk files but unfortunately Revision R37 of the Commander X16 emulator doesn't support file input/output to disk.
  22. The Commander X16 Programmer's Reference Guide indicates the following: **** Description: The routine joystick_get retrieves all state from one of the joysticks. The number of the joystick is passed in .A (0 through 3), and the state is returned in .A, .X and .Y. .A, byte 0: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | NES | A | B |SEL|STA|UP |DN |LT |RT | SNES | B | Y |SEL|STA|UP |DN |LT |RT | .X, byte 1: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | NES | 0 | 0 | 0 | 0 | 0 | 0 | 0 | X | SNES | A | X | L | R | 1 | 1 | 1 | 1 | .Y, byte 2: $00 = joystick present $FF = joystick not present If joystick 0 is not present, it will fall back to returning the state of the keyboard, if present: Keyboard Key NES Equivalent Ctrl A Alt B Space SELECT Enter START Cursor Up UP Cursor Down DOWN Cursor Left LEFT Cursor Right RIGHT **** I thought the play was to support SNES controllers, not NES controllers. Why is the NES equivalent shown instead of the SNES equivalent? This is confusing as the A button maps to a different byte and the B button maps to a different bit in the controller data returned by the joystick_get function. Why are there no keys assigned for the extra buttons on the SNES controller (X, Y, L, and R)? Also it seems to me there should be keys assigned to the four diagonal directions. What are the codes returned when the Ctrl and Alt keys are pressed which correspond to the NES A and B buttons?
  23. Sprite Editor View File Commander X16 Sprite Editor This is a screen snapshot and the executable file of a Commander X16 Sprite Editor which is built from "C" source files I’ve been developing that currently runs on Release 37 of the emulator. Features The sprite editor supports all combinations of sprite height and width dimensions up to 64x64. The sprite editor is currently limited to 4 color bits per pixel, but provides the ability to edit the RGB values of the first 16 entries of the color palette. The sprite editor supports a pen mode which reduces the keystrokes required to assign colors to sprite pixels, and the ability to shift the design of the sprite to make more room near the edge of the sprite. The sprite editor provides the ability to export color palette data as well as sprite data to the terminal in a BASIC program format and also in a format more amenable to importing into a C program. The BASIC program allows the sprite to be rendered and moved around a bit using the W/A/S/D keys. This export capability requires the -echo option when starting the emulator. Operation Cursor Movement The arrow keys are used to move the cursor around the sprite pixel edit grid. When width=64 the edit grid can be paged left and right using the less-than and greater-than keys ("<" and ">"), and when height=64 the edit grid can be paged up and down using the comma and period keys ("," and "."). Assigning Colors to Sprite Pixels The 0-9/A-F keys are used to assign a color to the sprite bit corresponding to the current edit grid cursor position. When pen mode is turned on using the P key, the color at the current edit grid cursor position is assigned to the pen, and this color is automatically assigned to pixels as the edit cursor is moved. The pen color can be changed by selecting a new color via the 0-9/A-F keys. Pen mode is manually turned off by pressing the P key a second time, and is automatically turned off when the cursor is moved past the edge of the edit grid and when the edit grid is paged when height=64 or width=64. The fill command (F5 key) fills the entire sprite with the color at the current edit grid cursor position. RGB Edit Mode RGB edit mode provides the ability to edit the RGB values of the first 16 entries of the color palette. RGB edit mode is entered and exited by pressing the F6 key. In RGB edit mode, a right arrow appears to the left of the selected color, and selected color is changed by using the up/down cursor keys. The red, green, and blue components of the selected color are changed by using the R/shift-R, G/shift-G, and B/shift-B keys. Sprite Design Shifting The sprite design can be shifted up or down one pixel row using the U and shift-U keys, and can be shifted right or left one pixel column using the R and shift-R keys. This feature is useful when a sprite design is not centered correctly when started and one runs out of space near an edge. The sprite design can be shifted to make more room near the edge which avoids having to start the sprite design over again at a new location. Sprite Options V-flip and H-flip (V and H keys) affect the display of the actual sprite but not the sprite edit grid. The palette offset (+/- keys) also only affects the display of the actual sprite (the edit grid colors and remainder of the screen colors are not affected). Screen Options The BG and FG options (F3 and F4 keys) provide the ability to change the screen background color and the color of the text on the screen. There's an anomaly associated with color 0 which is black in the standard color palette. Color 0 is shown as black on the screen and edit grid but is transparent when used in sprites, so the edit grid doesn't match the sprite with respect to color 0. Exported BASIC Program The exported BASIC program between line 10 and the DATA statements is constant. Line 10 varies with the height and width of the sprite and the DATA statements vary with the color palette data and design of the sprite. The SA7 value is based on the enumerated values of the height and width dimensions (0 for 8, 1 for 16, 2 for 32, and 3 for 64) and places these values into the proper position to be populated in the most significant nibble of the last sprite attribute register which has an offset of 7. The least significant nibble of this register is the palette offset which I assumed to be 0. The SA7 value is computed in the C program, but it could have been computed in the BASIC program since the enumerated values can be determined from the height and width which are exported on line 10 and palette offset is assumed to be 0. I deferred support for saving/loading palette and sprite data because I'm under the impression the emulator currently doesn't support file I/O, but the BASIC program provides a near-term workaround. The palette and sprite data exported in the BASIC program format can be reloaded into the sprite editor via the following steps: (1) start the emulator using the -echo option; (2) paste the BASIC program into the emulator; (3) execute the RUN command; (4) push the Esc key to quit the running program; (5) execute the NEW command; (6) load the sprite editor; and (7) execute the RUN command. The sprite editor will then pick up the palette data that was loaded into the color palette and sprite data that was loaded into the VERA sprite attribute registers and VRAM by the BASIC program. The following two steps are an alternative to step (2) above: (2a) paste the BASIC program into a text file; and (2b) use the emulator -bas option to load the program from the text file when starting the emulator. This alternative approach is recommended if you're having problems with the emulator corrupting lines when pasting the BASIC program directly into the emulator. The palette and sprite data are automatically exported when exiting the sprite editor to avoid accidental loss of data. The exported data can be recovered before reloading and restarting the sprite editor as described above. Potential Future Enhancements I'm considering enhancements including support for 8 color bits per pixel, saving/loading of palette and sprite data, rotation of sprites, and undo/redo of changes to the sprite graphics data in VRAM. Submitter CX16UserSteveC Submitted 07/24/20 Category Graphics Apps  
  24. Version 1.0.0

    210 downloads

    Commander X16 Sprite Editor This is a screen snapshot and the executable file of a Commander X16 Sprite Editor which is built from "C" source files I’ve been developing that currently runs on Release 37 of the emulator. Features The sprite editor supports all combinations of sprite height and width dimensions up to 64x64. The sprite editor is currently limited to 4 color bits per pixel, but provides the ability to edit the RGB values of the first 16 entries of the color palette. The sprite editor supports a pen mode which reduces the keystrokes required to assign colors to sprite pixels, and the ability to shift the design of the sprite to make more room near the edge of the sprite. The sprite editor provides the ability to export color palette data as well as sprite data to the terminal in a BASIC program format and also in a format more amenable to importing into a C program. The BASIC program allows the sprite to be rendered and moved around a bit using the W/A/S/D keys. This export capability requires the -echo option when starting the emulator. Operation Cursor Movement The arrow keys are used to move the cursor around the sprite pixel edit grid. When width=64 the edit grid can be paged left and right using the less-than and greater-than keys ("<" and ">"), and when height=64 the edit grid can be paged up and down using the comma and period keys ("," and "."). Assigning Colors to Sprite Pixels The 0-9/A-F keys are used to assign a color to the sprite bit corresponding to the current edit grid cursor position. When pen mode is turned on using the P key, the color at the current edit grid cursor position is assigned to the pen, and this color is automatically assigned to pixels as the edit cursor is moved. The pen color can be changed by selecting a new color via the 0-9/A-F keys. Pen mode is manually turned off by pressing the P key a second time, and is automatically turned off when the cursor is moved past the edge of the edit grid and when the edit grid is paged when height=64 or width=64. The fill command (F5 key) fills the entire sprite with the color at the current edit grid cursor position. RGB Edit Mode RGB edit mode provides the ability to edit the RGB values of the first 16 entries of the color palette. RGB edit mode is entered and exited by pressing the F6 key. In RGB edit mode, a right arrow appears to the left of the selected color, and selected color is changed by using the up/down cursor keys. The red, green, and blue components of the selected color are changed by using the R/shift-R, G/shift-G, and B/shift-B keys. Sprite Design Shifting The sprite design can be shifted up or down one pixel row using the U and shift-U keys, and can be shifted right or left one pixel column using the R and shift-R keys. This feature is useful when a sprite design is not centered correctly when started and one runs out of space near an edge. The sprite design can be shifted to make more room near the edge which avoids having to start the sprite design over again at a new location. Sprite Options V-flip and H-flip (V and H keys) affect the display of the actual sprite but not the sprite edit grid. The palette offset (+/- keys) also only affects the display of the actual sprite (the edit grid colors and remainder of the screen colors are not affected). Screen Options The BG and FG options (F3 and F4 keys) provide the ability to change the screen background color and the color of the text on the screen. There's an anomaly associated with color 0 which is black in the standard color palette. Color 0 is shown as black on the screen and edit grid but is transparent when used in sprites, so the edit grid doesn't match the sprite with respect to color 0. Exported BASIC Program The exported BASIC program between line 10 and the DATA statements is constant. Line 10 varies with the height and width of the sprite and the DATA statements vary with the color palette data and design of the sprite. The SA7 value is based on the enumerated values of the height and width dimensions (0 for 8, 1 for 16, 2 for 32, and 3 for 64) and places these values into the proper position to be populated in the most significant nibble of the last sprite attribute register which has an offset of 7. The least significant nibble of this register is the palette offset which I assumed to be 0. The SA7 value is computed in the C program, but it could have been computed in the BASIC program since the enumerated values can be determined from the height and width which are exported on line 10 and palette offset is assumed to be 0. I deferred support for saving/loading palette and sprite data because I'm under the impression the emulator currently doesn't support file I/O, but the BASIC program provides a near-term workaround. The palette and sprite data exported in the BASIC program format can be reloaded into the sprite editor via the following steps: (1) start the emulator using the -echo option; (2) paste the BASIC program into the emulator; (3) execute the RUN command; (4) push the Esc key to quit the running program; (5) execute the NEW command; (6) load the sprite editor; and (7) execute the RUN command. The sprite editor will then pick up the palette data that was loaded into the color palette and sprite data that was loaded into the VERA sprite attribute registers and VRAM by the BASIC program. The following two steps are an alternative to step (2) above: (2a) paste the BASIC program into a text file; and (2b) use the emulator -bas option to load the program from the text file when starting the emulator. This alternative approach is recommended if you're having problems with the emulator corrupting lines when pasting the BASIC program directly into the emulator. The palette and sprite data are automatically exported when exiting the sprite editor to avoid accidental loss of data. The exported data can be recovered before reloading and restarting the sprite editor as described above. Potential Future Enhancements I'm considering enhancements including support for 8 color bits per pixel, saving/loading of palette and sprite data, rotation of sprites, and undo/redo of changes to the sprite graphics data in VRAM.
  25. Color Palette Editor View File This is a snapshot and executable file of a Commander X16 Color Palette Editor which was built from C source files and is compatible with Release 37. The up/down and left/right cursor keys are used to move between palette entries which are displayed on a color grid. The currently selected palette entry is surrounded by a box in the color grid and is also displayed at the top of the color grid with the associated index and RGB values displayed to the left and the associated palette data displayed to the right. All values are displayed in decimal. The Commander X16 Color Palette Editor can be used to view the default color palette and to change the RGB values of the entries if desired. The RGB values of the currently selected palette entry can be changed with the r/R, g/G, and b/B keys which increment/decrement the red, green, and blue components respectively. The palette data can be exported to a BASIC program which can be used to load the modified color palette for a user application or before running the Commander X16 Color Palette Editor again. The palette data is also exported in a format more amenable for inclusion into a C program. The palette data exported in the BASIC program format can be reloaded into the Palette Editor via the following steps: (1) start the emulator using the -echo option; (2) paste the BASIC program into the emulator; (3) execute the RUN command; (4) execute the NEW command; (5) load the Palette Editor; and (6) execute the RUN command. The Palette Editor will then pick up the palette data that was loaded into the color palette by the BASIC program. The following two steps are an alternative to step (2) above: (2a) paste the BASIC program into a text file; and (2b) use the emulator -bas option to load the program from the text file when starting the emulator. This alternative approach is recommended if you're having problems with the emulator corrupting lines when pasting the BASIC program directly into the emulator. The palette data is automatically exported when resetting to the default palette and when exiting the palette editor to avoid accidental loss of data. The exported data can be recovered before reloading and restarting the palette editor as described above. Submitter CX16UserSteveC Submitted 07/24/20 Category Graphics Apps  
×
×
  • Create New...

Important Information

Please review our Terms of Use