Jump to content


Popular Content

Showing content with the highest reputation on 01/18/21 in all areas

  1. 3 points
    Slightly optimized... Thanks to @StephenHorn and @SlithyMatt
  2. 2 points
    Sorry for being late to the party. I'm currently using CC65 tool chain since it provides relocatable object models and a capable linker, plus integration with C. On top of that, since it runs on my modern machine, I have access to GIT (or what ever SCS you want). With out a source code control system, life ain't worth living! I totally get the idea of having a native development system, but modern editors (although I use Emacs) and source control are too much of an ask for me. Combine with the X16 emulator, and it's a pretty fast edit-compile-debug cycle.
  3. 1 point
    I wrote a series of blog posts/articles on Commander X16 architecture and coding. I have started with focus on beginners and then slowly moved to more advanced topics and techniques. First I tackle smaller chunks and use simple examples to show the topic in practice. After enough new knowledge is covered I write a complete game to utilize several of the techniques to illustrate how it all comes together so each new complete project is more complex than the one before. I do cover only Commander X16 specific so I recommend reading Commodore C64 BASIC tutorials and guides. Please note that the games and most examples are written with a goal to be as clearly readable and understandable so there is very little source code optimizations. Snake Game This game is written in very clean BASIC with very little trickery so not much special Commander X16 knowledge is required. We do VPOKE directly into video memory so only understanding of fundamentals is required. Recommended reading VERA Overview Topics Covered in Game Analyzing the game itself is a great way to learn basics like: How to structure source code (outer loops, game loop) What is Game loop Use of Data structure like multiple Arrays How to read Joystick, Keyboard How to use VPOKE to “talk to” VERA Video RAM organization and using colors Writing to certain location on the screen Using PETSCII control characters to display messages and title screen GOTO Crazy Snake Tutorial GOTO Download Tetris Clone This game introduces some more advanced features of Commander X16 and we have to take a bit more care of how to use data structures and optimize some parts of the game to make it playable. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Colors and Palettes Topics Covered in Game Tetris clone requires us to improve on pretty much all parts of the snake game structure: We have additional loops outside and inside game loop Advanced game collisions based on screen state Pre-calculate relative positions of four segments of each tetromino Customize color palette Customize tiles (characters) Speed increase per level Adding sound to the game GOTO Crazy Tetrominoes Tutorial GOTO Download Boulder Dash style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. We have to pay close attention to timings, synchronizing scrolling and animation, take care of different types of collisions, etc. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Simplest Sound Effects Library for BASIC Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Two phase approach to development Full color mode Full screen scrolling Two layer graphics Scrollable playfield Static HUD Animated full color sprites 256 color title screen in graphics mode Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset Sprite Sheet Fonts Sound effects library Title screen GOTO Crazy Boulders Tutorial GOTO Download
  4. 1 point

    Version 1.0.4


    A simple game fully in Basic. NOTE: If you just want to run the latest version of this game on the Web based emulator do like this. 1. Copy the code from: https://raw.githubusercontent.com/JoystickAndCursorKeys/x16basic/main/fallingsnake.v4.bas.txt (CTRL-C) 2. Go here: https://www.commanderx16.com/emulator/x16emu.html and paste the code. (CTRL-V) 3. Press "Run" This (version 0 of the game) is a very little game I wrote on the commodore 64 ages ago, I changed it a little to work with vpeek, vpoke, the new color command, and the new screen resolution. To me starting with a simple game in basic is how I learned about the c64, and now the X16, before jumping in machine language. In the code for this game you can see practical examples, on how to set characters on the screen, read characters from the screen, change colors for characters, listen to the keyboard, set a screen mode. What surprised me was that I needed a delay in the code in order to have it not run too fast. This was not the case on the c64. I really like the way you can use the emulator in the browser, as it allows you to type in basic inside the browser, using "regular key mappings", and the run it. When I wanted to save it, I copy-pasted it into the installed emulator (hats off for who added he paste function there), and types the save command. This was done, because in the browser you cannot save it, and see it on disk (as far as I know) I added many REMs in the code, in order so it can be understood, and it is more of a tutorial, then a "real" game. Below I will go through the code. From line 5, the program initializes From line 9, the title screen is drawn From line 49, the game is initialized From line 199, the game loop starts From line 300, the game over screen is drawn Some miscelanious notes: The SCREEN command is used to set the screen in text mode (Petscii) 40x30 The color command is used to set character fore and background colors. Unlike the c64 each char has its own background color. There is no "global" background color CHR$(113) is used to draw the Petscii circle character, used on the title screen. Adding the actual character into the code listing, makes it hard to edit outside the emulator. CHR$(119) is another Petscii character VPOKE 0,0,x, pokes a character on the top level corner of the screen. So the text screen address = 0 (not like on the C64) On line 52 the bottom of the screen offset is calulated. NOTE: Even though the screen is 40 chars long, to get to VPOKE address of the next line, you need to add 256 bytes. SI and PI (StoneImage and PlayerImage) are Petsci chars, that are used in the game. NOTE: Petscii chars have different values in the PRINT or the VPOKE commands. Reminder: In C64/Microsoft basic a variable name is only two characters long max. Reminder: Lines in Basic should not be longer then 80 chars. When you make them longer, the emulator ignores them. A good place to see all PETSCII character codes is here: https://www.commanderx16.com/forum/index.php?/files/file/23-vera-chars/ Have fun! And the code itself: (it is easier to copy paste it in the browsers emulator and be able to modify it more easy here: https://www.commanderx16.com/emulator/x16emu.html ----- code below for copy & pasting, also you can get it by downloading FALLSNAKE.PRG or checked out at: https://github.com/JoystickAndCursorKeys/x16basic/blob/main/fallingsnake.v0.bas.txt----- 5 REM SET TO 40X30 CHARS SCREEN 6 SCREEN 0 7 HM$=CHR$(19) 9 REM TITLE SCREEN ----------------- 10 REM SET COLORS TO BLACK AND WHITE, CLEAR SCREEN 11 COLOR 1,0: CLS 12 PRINT:PRINT:PRINT:PRINT : REM PRINT TITLE 13 PRINT " FALLING SNAKE": PRINT: COLOR 15 14 PRINT " YOU ARE FALLING DOWN A HOLE" 15 PRINT " AVOID ALL OBSTACLES" 16 COLOR 7: PRINT " PRESS SPACE TO START" 17 BA$=CHR$(113):BB$=CHR$(119) : REM BALL SYMBOLS 18 COLOR 2,0 : PRINT " "+BA$ 19 PRINT " "+BA$:PRINT " "+BA$ 20 PRINT " "+BA$+BA$+BA$+BA$+BA$+BA$+BA$+BA$+BA$;:COLOR 8:PRINT BB$ 25 GET A$: IF A$="" GOTO 25 : REM WAIT FOR KEY 35 TS=0 : REM SET TOP SCORE 49 REM START GAME ----------------- 50 COLOR 1,0: CLS 51 FOR T=1TO29:PRINT:NEXT 52 BO=29*256:SI=42: : REM BOTTOMSCREENOFFSET, STONEIMAGE 53 PO=15*256:PI=81:PC=2:PX=20 : REM PLAYEROFFSET, PLAYERIMAGE, PLAYERCOLOR 54 DE=1000 : REM DELAY VALUE 55 S=0 : REM SET SCORE 199 REM GAME LOOP ----------------- 200 GET A$ 201 IF A$=CHR$(29) AND PX<40 THEN PX=PX+1 : REM GO RIGHT 202 IF A$=CHR$(157) AND PX>0 THEN PX=PX-1: REM GO LEFT 210 X=INT(RND(1)*40)*2: C=INT(RND(1)*15)+1 : REM GET RANDOM STONE POSITION 211 PE=VPEEK( 0, PO+(PX*2)) 212 IF PE=SI THEN GOTO 400 220 VPOKE 0, BO+X, SI: VPOKE 0, BO+X+1, C 221 VPOKE 0, PO+(PX*2), PI: VPOKE 0, PO+(PX*2)+1, PC 296 FOR W=1 TO DE: NEXT : REM DELAY, SLOW DOWN CODE 297 PRINT : S=S+1 : DE=DE-1 : IF DE<0 THEN DE=0 298 GOTO 200 399 REM GAME OVER ----------------- 400 IF S>TS THEN TS=S 401 PRINT HM$:PRINT:PRINT:PRINT " GAME OVER": PRINT 402 PRINT " SCORE: "+STR$(S); 405 PRINT " TOP SCORE="+STR$(TS) 410 COLOR 7: PRINT: PRINT " PRESS SPACE TRY AGAIN" : PRINT:PRINT 420 GET A$ 421 IF A$ = "" OR A$=CHR$(29) OR A$=CHR$(157) THEN GOTO 420 422 GOTO 50 ---------------------------------------------------------- End of Code First Version ---------------------------------------------------------- The way I normally work when creating a game, I create first the skeleton, and then add more and more niceties, like effects, and game play elements. Above, we have the skeleton, we have a minimal game. We have a title screen, we have a playable section, we have a score, a game over section, and a high score. Below I will show the improvements I made so far, and are saved in FALLSNAKE2. In the init section of the program, I rearranged the line numbers, so I would not overlap with the rest of the program, when adding two more lines. The added lines are in Bold/Underline. Line 3, I allocate an array called EX to store the "petscii picture" of an "explosion". It is 9 chars. The "picture" is 3x3 chars. No colors. 3x3=9, which is how much we need to allocate with the DIM command. Line 4, reads data from the DATA statements at the end of the program into the array called "EX". 0 REM SET TO 40X30 CHARS SCREEN 1 SCREEN 0 2 HM$=CHR$(19) : REM HOME CHARACTER 3 DIM EX(9) 4 FOR T=0TO8: READ C : EX(T)=C: NEXT : REM READ PETSCII EXPLOSION In the "Game over" section of the game, I added the drawing of the explosion picture, and a flashing color effect to go with it. Again, I renumbered the code around it a bit. We iterate through the characters in the EX array, by looping x and y from 0 to 2, and calculating the offset to EX (called DO, data offset). We use VPOKE to put the bytes on the screen memory, at address SO (screen offset). SO is calculated by using the xx + the player y coordinate, minus 1 (this will be XS). Similar will be done for y, but to calculate SO, we add XS*2 (each char takes two bytes) + YS*256 (from one row to the next the distance offset is 256 chars) 401 REM DRAW EXPLOSION 402 FOR XX=0TO2:FOR YY=0TO2 403 XS=XX+PX-1: YS=YY+15-1 : REM SCREEN X,Y 404 IF PX<1 THEN XS=XX+1 : REM CHECK PLAYER X TO BE ON SCREEN 405 IF PX>38 THEN XS=XX+38 406 DO=XX+(YY*3):SO=(XS*2)+(YS*256) : REM CALC DATA OFFSET, SCREEN OFFSET 407 VPOKE 0,SO,EX(DO) : REM WRITE TO SCREEN 408 NEXT:NEXT Below there is a simple color cycling effect for the background, this is done by adding random values into palette register for color 0. The register is stored in two addresses, $FA00 and $FA01. Actually some bytes are not used, but for a random effect we ignore that. If we want to have for example a red explosion flicker, we need to be more careful on the values we put into the register. 410 REM EXPLOSION COLOR EFFECT 411 FOR T=1 TO 50 412 C0=INT(RND(1)*255) 413 C1=INT(RND(1)*255) 414 VPOKE 1,$FA00,C0: VPOKE 1,$FA01,C1 415 NEXT: VPOKE 1,$FA00,0: VPOKE 1,$FA01,0 and the last part (after renumbering even more lines of code), we added the data for the explosion petscii "picture". 2000 REM PETSCI EXPLOSION 2001 DATA $4D, $20 , $4E, $20, $D6, $20, $4E, $20, $4D The complete code can be found in FALLSNAKE1.PRG, or checked out at: https://github.com/JoystickAndCursorKeys/x16basic/blob/main/fallingsnake.v1.bas.txt One thing that keeps me going when creating a game, is but adding sessions where I make the game look nicer, without adding functionality. The changes below (1.0.2 version, FALLSNAKE2.PRG), is all about this. Just Renumber it To start off, we have been renumbering again the lines of the source code. For those that are not used to using old school type basic, it is very easy to add extra code and run out of numbers. And it is important to "reserve" numbers. So for example if you make a program like this. 1 PRINT "HELLO WORLD" 2 GOTO 1 And you want to add something between line 1 and 2, you cannot do it, unless you renumber the existing lines. For that reason it is a better idea to start coding like this: 10 PRINT "HELLO WORLD" 20 GOTO 10 This way you have some space in between, and you could easily add a line 15 to print something else, if you want to. Nevertheless it can still happen even when you have reserve ranges, and they get to be "full". This is especially the case when you add new sections of verbose code between other code. And this is exactly why I am once more renumbering. -- -- -- To add sprites, you need to have the images stored some where. The old school way of doing it, is to add "DATA" commands to the code, like below. I will not write it completely here, since it becomes very verbose, but it looks something like this: 11000 DATA $00, $00, $22, $22, $22, $22, $00, $00 11001 DATA $00, $22, $82, $82, $82, $82, $22, $00 11002 DATA $02, $88, $88, $28, $28, $28, $28, $20 11003 DATA $28, $08, $08, $22, $22, $22, $82, $8b 11004 DATA $28, $88, $88, $20, $00, $28, $28, $b0 11005 DATA $02, $82, $82, $00, $02, $82, $8b, $00 11006 DATA $00, $22, $20, $00, $28, $22, $b0, $00 ..... Many more lines of this NOTE: Only in the 80s would you type in lines and lines of DATA like this. Now there are easier ways, for example a sprite editor with an export function. There are many options, below is one of them that I am coding on myself. The important thing is to export to a sprite data that the X16 understands. In this case 16x16 dimensions, 16 colors, so 4bpp (4 bits per pixel for color info), and basic support HEX numbers. And to use them, you write something like this. 1000 REM READ SPRITE DATA 1001 FOR I=O TO 255 1011 READ PX : REM READ ONE NUMBER FROM THE DATA. 1012 VPOKE $0,$4000+I,PX: REM USE VPOKE TO MOVE THE DATA IN VIDEO MEMORY 1013 NEXT I 1014 RETURN At the end of these lines of code, you see the command RETURN. What is this about? Well, with basic we can simulate calling a function/subrouting, with GOSUB. RETURN returns back to where it was called. The code is being called in the beginning, something like this: 10 GOSUB 1000 : REM READ SPRITE DATA After the call to the subroutine at line 1000, it continues to the next line. This is one way to organize the code inside Commodore/Micro$oft basic. I will not mention all the details of setting up the sprite here, you can check the code yourself, if you want to. Later I will go deep into this topic, but not here. However to get the sprite in the right position we have another subroutine. 1070 REM SET SPRITE 0,X0,Y0 1171 VPOKE $1,$FC12,X0 AND $FF 1172 VPOKE $1,$FC13,(X0 AND $0300)/$100 : REM MAGIC TO GET HI BYTE OF THE X COORDINATE 1173 VPOKE $1,$FC14,Y0 : REM YPOS 128 1174 VPOKE $1,$FC15,$00 : REM WE DON'T CALCULATE THE HI BYTE OF THE Y COORDINATE 1175 RETURN Which I call in the title screen build up like this. 75 X0=150: Y0=68: GOSUB 1070 : REM SET SPRITE X,Y Note that for calling the subroutine with parameters, we simply assign global variables. To keep from clashing with other global variables, use a naming convention. Here I used 0 (zero) as the second 'letter' in the name as the naming convention. In the game, the position changes all the time, so instead we do like this: 295 X0=PX*8: Y0=122: GOSUB 1070 : REM SET SPRITE X,Y X0 is calculated. Y0 is static, but X0 is PlayerX (PX) times 8 (the width of a character on screen in bits) Color effect Now for the colour effect, we chose one color to be the one that has the effect, and we draw our blinking characters with this color. Like below. 60 PRINT "FALLING SNAKE";: COLOR 14: PRINT "**": PRINT: COLOR 15 And we cycle / blink, by doing something like this. 80 C0=C0+1: IF C0>2 THEN C0=0: C1=C1+1: IF C1>255 THEN C1=0: 82 VPOKE 1,$FA1C,C1: VPOKE 1,$FA1D,C1 Offset $FA1C and $FA1D in the VERA video ram, control the palette registers for color 14. Each color has two bytes, so if you want to find the color register for color 0, you just substract 28 decimal (2*14) from hex $FA1C. (Convert 28 to hex first) Feel free to check out the code or the PRG file, at this stage. Code: https://github.com/JoystickAndCursorKeys/x16basic/blob/main/fallingsnake.v2.bas.txt PRG file: FALLSNAKE2.PRG -- In the next session we will concentrate a bit more on gameplay. It is no use to pimp up the graphics, if the gameplay is boring. Since this is really a simple game, we easily can do a few things to spice it up. So now it is time to look a little at the game play. So far the gameplay has been very simplistic. Avoid obstacles, and do it as long as you can. And the obstacles are the same. And the speed is the same always. ...... Hold on, not so fast. In the previous sections I managed to sneak in two lines of code that change the play speed over time. The longer you play the quicker the game becomes. This was done as such. 54 DE=1000 : REM DELAY VALUE Here the delay between each "cycle" in the game is defined as 1000, before the game starts. And then to use the delay, we have: 296 FOR W=1 TO DE: NEXT : REM DELAY, SLOW DOWN CODE And to decrease we have: 297 ......................... DE=DE-1 : IF DE<0 THEN DE=0 This already gives a little variation in the game. Let's add even more. (ps, you can see all the latest changes here on github https://github.com/JoystickAndCursorKeys/x16basic/commit/83b422502739076f2f01ad45223f3d66e9258428#diff-e83889dbe05ea5d067f684fe8fd1dbfc372ed11215335bcf8b85f2ef850ad047) Slow and Extra Points The two gameplay elements I intend to add are "Slow down" and "Extra (Bonus) Points"' Since the game goes faster and faster it it reasonable tro asume that the player wants to slow down from time to time. With this "feature", this will be possible. How will it work? Some of the objects that need to be avoided will look different. (Arrow up sign) And to make them recognizable they also have a blue blinking color. When you catch one, your speed (DE) will be increased. Extra points is implemented in a similar way. There is another symbol (a green clover, to symbolize snake food (yes Simon is a vegetarian snake :) ). When you run into this symbol, your score will be increased by a fixed amount. NOTE: In order to do all this, we needed to renumber a few things again. You see that happening alot in old school basics, at least when I am programing there To do all this, first we defined all the colors characters for the different types of obstacles. #COLORS 6 DIM CO(6): CO(0)=9: CO(1)=11: CO(2)=12: CO(3)=15: CO(4)=5: CO(5)=6 #CHARACTERS. see any Petscii table like on page https://www.linusakesson.net/art/three-petscii-pieces/index.php 7 DIM IO(6): IO(0)=$66: IO(1)=$6F: IO(2)=$54: IO(3)=$75: IO(4)=$58: IO(5)=$1E Now we have 6 characters defined, we can select a random one by just doing a INT(RND(1)*6) But actually I do a little differently, to make the changes to select a special character lower, my code looks like this. 225 R=( INT(RND(1)*5) IF RND(1) > .95 THEN R=5 226 C=CO(R): I=IO(R) C = the value for the color, I is the value for the character (I=image) And we poke them on the screen like so: 231 VPOKE 0, BO+X, I: VPOKE 0, BO+X+1, C But now we cannot just jump to "explosion", when we hit something, we we also adjust our code here: IF PE<>32 THEN O0=O: C0=PE: D0=1: GOSUB 500 : IF D0=1 THEN GOTO 400 O0,C0 are the input parameters for the gosub, and D0 is the output. O0, is the object offset on the screen of the object we collide with. C0, is the character code of this object. D0, is returned. It is 1 if we died, zero otherwise. If D0 is returned 1, we jump to 400, where we go into the "die/explosion" state. The handling of the different collisions with "slow" and "extra points" is done at line 500. 500 REM CHECK COLISSION 501 D0 = 1 502 IF C0 = $58 THEN S=S+50 : D0=0: GOSUB600 : REM GOT FOOD = EXTRA POINTS 503 IF C0 = $1E THEN DE=DE+100 : D0=0: GOSUB630 : REM GOT "SLOW DOWN" SYMBOL 505 RETURN Write "50" on the screen. 600 VPOKE 0,O0-256,$35 : VPOKE 0,2+O0-256,$30 601 VPOKE 0,1+O0-256,1 : VPOKE 0,3+O0-256,1 602 RETURN Write Slow on the screen 630 VPOKE 0,O0-4-256,$13 : VPOKE 0,2+O0-4-256,$0C: 631 VPOKE 0,4+O0-4-256,$0F :VPOKE 0,6+O0-4-256,$17 632 VPOKE 0,1+O0-4-256,1 : VPOKE 0,3+O0-4-256,1 633 VPOKE 0,5+O0-4-256,1 : VPOKE 0,7+O0-4-256,1 634 RETURN And this i basically our changes. Feel free to copy the code from: https://raw.githubusercontent.com/JoystickAndCursorKeys/x16basic/main/fallingsnake.v3.bas.txt To test it in the emulator. As I mentioned before, in order to keep the interest for such a game, I usually sneak in some visual improvements, so that also happened during my focus on game play. The "slow" character has been made to flash blue/cyan. This is done like this. 1. The character is always drawn with color 6 2. The pallette color for color 6 flips between 2 presets. This is done with these 3 lines of code. 280 CL=CL+1 Increase a counter. This counter has only one purpose, to control the speed of the blinking. 281 IF CL>2 THEN CL=0: CC=1-CC : LO=255:HI=8: IF CC=1 THEN LO=15:HI=1 If the counter is larger then 2, then reset it, and flip a flag called CC, by inverting it's value with CC=1-CC Set the low and high value of the color index. If the flag is set, overwrite the color low and high value with different values. 284 VPOKE 1,$FA0C,LO: VPOKE 1,$FA0D,HI And this last line, writes it into the palette register, so it becomes visible. Remember to only now use color 6 for things that should blink. (And the same goes for color 15, which is blinking during the title screen) To make it a little more looking like a professional game, we add a score display on the screen. While we are add it, we also add the speed. Making it finally look like this: Let's have a look on how we added this. The problem: Writing the information to the top of the screen buffer would not work very well, since the whole screen buffer is scrolling upwards, and so it would keep dissapearing, resulting in a flicker. Also, since this is Basic, updating 80 bytes for each cycle, would create alot of delays. A solution: The X16 has hardware support for two layers of text. And the top layer can have transparency, so you can still see the bottom layer. The transparency is enabled by using color 0, which is black. The score is "printed" in the frontmost layer. We can add this extra layer by direcly poking in Vera's registers. There are some things to keep in mind: The extra text layer is not accessible through "PRINT", so it needs to be changed by POKING directly in the buffer. Per default BASIC uses layer 1, which is the front layer. We want BASIC to use layer 0, which is the background, since we're printing everything on the background with basic commands. Writing a number to the screen, is time consuming, and slows down the game. So for now, we only update the score-bar, each ten cycles, to save on speed. We start out by adding a new routing, to setup the layered text based screens. 1030 REM SETUP 2 LAYERS SCREEN 1031 POKE $9F29,($20 OR $10 OR PEEK($9F29)) Enable layer 0 and 1. 1032 POKE $9F2F, PEEK( $9F36) 1033 POKE $9F2D, PEEK( $9F34) Swap screens. Move layer 0 pointers to layer 1 pointers. These registers point to the tilebase and the layer 0 config. So layer 0 looks now like layer 1. Same font, same screen dimensions. 1034 POKE $9F2E, $00: POKE $9F35, $0F Now setting layer 0 to point to screen memory offset 0, and layer 1 to screen offset "$0F" (note this is only the "high byte" of the offset) And last, we clear the screen with the right colors. (this affects now layer 0, after our changes) 1035 COLOR 1,0: CLS 1040 RETURN More problems to solve: Since one of our layer is now in a different memory space then basic looks at, we need to manually update this layer with the poke command. By running a simple for loop, we can clear the while screen, while poking a value into the screen buffer. The code turned out so, that it was very slow. So I created a "fill text line" routine, which is somewhat quicker. When I want to clear the screen, I call it with the right parameters (offset, draw character, draw color) The code below, as you see is repeating alot of pokes, instead of doing a for loop with one poke in it. This not-so-nice trick, gets us just a tiny bit of speed improvement. Since clearing the screen takes long, any improvement in speed is worth is. 2499 REM CLEAR LINE FAST(O0,P0,C0) 2500 FOR X=0TO39 STEP 10: O=(X*2)+O0 Many pokes below. Instead of just one poke. To get this tiny speed improvement. 2501 VPOKE 0,O,P0: VPOKE 0,O+1,C0:VPOKE 0,O+2,P0: VPOKE 0,O+3,C0 2503 VPOKE 0,O+4,P0: VPOKE 0,O+5,C0:VPOKE 0,O+6,P0: VPOKE 0,O+7,C0 2505 VPOKE 0,O+8,P0: VPOKE 0,O+9,C0:VPOKE 0,O+10,P0: VPOKE 0,O+11,C0 2507 VPOKE 0,O+12,P0: VPOKE 0,O+13,C0:VPOKE 0,O+14,P0: VPOKE 0,O+15,C0 2509 VPOKE 0,O+16,P0: VPOKE 0,O+17,C0:VPOKE 0,O+18,P0: VPOKE 0,O+19,C0 2515 NEXT 2516 RETURN Note that O0, P0, and C0 are the "input parameters" to the routine. (offset, draw character, draw color) The next part is the routine to draw a number on the screen, for the score. We have the similar routine for the speed, but the code is basically a copy-paste. The trick is to get the score, which is a number, into a sequence of printable (pokeable) characters. We want the score to also always have the same "size", which is six digits. There are not commands in Basic to format the string nicely for us, so we use tricks. 2999 REM UPDATE SCORE 3000 S$=STR$(N0 + 1000000) We convert N0 (the input of the routing, which is the Score in our case), to a string with STR$. But before that we add 1000000 to it so the output is always score + 1000000, which is 7 digits always. (unless you get more the 1 millions points, then the code stops working fine) And the trick is to use the last 6 characters from the string only. Example: Score = 555 -> 10000000 + Score = 1000555 -> last 6 digits is -> 000555 To get the last 6 digits, we start our loop below at position 2. Then we use MID$ to get one character from the string, and ASC to convert that character to a pokeable number. 3001 FOR T=2TOLEN(S$)-1 3002 C=ASC(MID$(S$,T+1)) 3004 VPOKE 0,7676+O0+(T*2),C And here we poke it to the video memory. (O0 is the offset) 3005 NEXT 3006 RETURN And we're done. So far this tutorial. The code can be found at: https://github.com/JoystickAndCursorKeys/x16basic/blob/main/fallingsnake.v4.bas.txt FALLSNAKE4.PRG is the final program. Recreating this old program on the X16 was fun, and quite informative on how the VERA video chip worked. There is many more things you can do to improve the game. One thing we found is that the game currently is "almost" a little on the slow side. So adding more features, would need rewrites of certain sections, or moving things into assembly language. Since this is a "simple game basic manual", I will not do this here, but the game may evolve in that way in the future. Things you can easily add to the program, without compromising speed, is "cutscenes", dedicated character graphics, and perhaps some simple sound effects. On the code itself. For the snake and snake head, I could have used character graphics instead of sprites. In fact there is no real need to use sprites here, but then again, in the end it made the snake head less flickery, which is a nice bonus. Using text mode was a design decision, since Basic has the build in scroll-screen feature, if you print a newline on the bottom line. This is what this game utilizes to it's fullest. Why does the snake fall? In fact it has nothing to do with the story, it is more that it is the simplest way of having a scrolling game. It started out as a car racing game, but the care left trails. So calling the trails for snake was easiest. And since it went down, falling seemed appropriate. If you want a more interesting background story, I can also provide. Simon is domesticated snake, and he goes out one day, and falls down a hole. He needs to avoid obstacles like branches and so on to survive, so he can splash down in the water at the bottom safely, before climbing up again. Feel free to clone the code, and make a more convincing background story if you wish. Color palette changes. Changing the palette is a really cool way to change many things on the screen, with only one command. Which is excellent for BASIC since it saves in CPU usage, and you do not loose to much speed. Even though running fine in the beginning, almost too fast. When you add features to the game main loop, it is very noticeable how the game slows down, and the delay constant DE needs to be set to lower, to run at the same speed. At the end I was running into a limit, since if the delay is too small, you cannot decrease and decrease the delay during the game, since there would be not much to decrease. Going to Assembly, would be an obvious next move. The ability to very simply set the extra layer is a very nice feature. The layer is hardware, so it does not slow the game down at all, and you can overlay semi static information like the score. Sprites: There are so many sprites on the X16, this game is not utilizing them at all, so there is alot of room for improvement for the visuals when it comes to that. Most design goals were also marked by the fact that the reason why the game is simple, is that it uses PETSCII, and PRINT. I wanted to keep that look and feel, so only minimal use of graphics, to spice it up only a little. The future. This game will probably be possihed a while more, since it is fun to do, but that will not be part of this tutorial. However feel free to watch the download section / games, to see the next version being worked on. Have fun, and thanks for reading! Especially thanks to all who helped me with my questions, when creating this short (medium sized ;)) tutorial.
  5. 1 point
    Glad to see that a highly desirable community computer is about to be born. I would like to buy one (or a kit) once its finished. The big problem is that I'm in Europe (Germany). That means everything worth more about 25$ that comes from overseas must pass the customs. Everything electrical must have a CE-label otherwise the customs will either send it back or destroy it. Are there any thoughts on getting a CE-label? Basically it is a self declaration of the manufacturer/seller that the item meets all rules that apply in the EU. There are no really ways to circumvent this, but one trick is to find an importer in a EU country. So the end user buys it from there, thus passes no customs. The next thing is that the video out seems to be NTSC only. A PAL version would be great, this would let the EU users use their old CRTs. Are there thoughts on other character sets other than us? I don't bother about the power supply, that is something one can buy here or DIY.
  6. 1 point
    I heard about this project by following David's 8-bit YT channel. My main hobby is ham radio (call sign DL6MFJ ), but I also do some analog synthesizer stuff and have a collection of old and/or scientific pocket calculators. At the time I'm doing a restoration of an old CBM 3032. All the best for 2021 and the X16!
  7. 1 point
    Yes and no. It’s wired up such that it can. But at the moment there are no burst routines. Sent from my iPhone using Tapatalk
  8. 1 point
    The word on having bit banged serial was when the UART on the Vera was dropped because they needed the pins for more register addressing. If the board is now booting up, hopefully they can start work on that so we'll know what speed we are talking about. But for testing device drivers and such in hardware, 9600bps 1.2KB/s, so 16KB in around 13 seconds, and it might be 19200bps, so 16K in under 7 seconds. The Centronics parallel is just the pinout given of the User Port on the second prototype board ... I wouldn't automatically expect Kernel code to support that, but the VIA pins connected would mostly support an EPP parallel port. But at 8MHz, even if it was 50 clocks per byte, that's 160KB/s..
  9. 1 point
    Hi All, I'm new to retro computing Ha ha ha I've worked on ancient machines for today's standards in the 90's only to find out now that what I was doing back then is now called retro computing Well, I had to make things last for the longest time as money was scarce back then I'd squeeze every little bit of performance and use out of my PCs from the 8088 XT Turbo to the 80286 AT, 80486 SX, Pentium MMX, Pentium II, Pentium III, Pentium 4 ....... to the latest machines today But seeing all these retro computing online from our 8 bit guy made me so nostalgic I still have all those gear back home Did not ever occur to me that they'd be worth something today or still be worth using Computers and IT eventually became a lifelong passion for me I missed out on these Amigas as they where prohibitively expensive when I was in high school Glad to be a part of this movement I hope to one day grab my hands on to this Commander X16 but if I was to name it it would have been Admiral 128 Ha ha ha I hope you guys know what I mean by this But Commander X16 it is I hope to get two sets One for me and another one for my Niece and Nephew I want them to experience retro computing too Regards to everyone, Marlou Jasmin Madrio
  10. 1 point
    slithymatt micro-optimizing a t shirt/desktop picture Then again Jimmy's version is compatible with 6502 systems so there's that!
  11. 1 point
    I have already created a pull request to add HEX$ and BIN$ https://github.com/commanderx16/x16-rom/pull/176
  12. 1 point
    Yes, it would really help if the Commander DOS functions were backed up by BASIC commands. MKDIR, CHDIR, RMDIR, COPY, DELTE, and SEEK. I'd also like to see some more numeric conversion and math functions. Specifically, we need HEX$ and BIN$ functions and the MOD operator. Right now, it takes about 10 lines of code to display a number to hex, when it really should just be something like PRINT HEX$(A) There are also still open feature requests for banked memory management and a few other things, as well... so there's still a long way to go on these kinds of things. Maybe if you have the skills, you can jump in and lend a hand. Now that I'm starting to get a handle on assembly for the Commander, I may step in and add some of my own commands (specifically, the ones I just mentioned.)
  13. 1 point
    I'm wondering.... Why are we trying to mimic the C64 OS here ? I'm thinking that if I want to have a better C64, we know there are (mainly there is) far better alternatives. But is looks like a C64, you can say. Yes, true. On the software side. But that's mainly because it was the easiest path to go. No need to rewrite everything. That being said, back to my initial question. As we are more or less making the thing, we can choose to do whatever we want. And we may go for ways more explicit than DOS"P"+CHR$(8)+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0), don't you think ? Something as simple as a DOS SEEK, for instance......
  14. 1 point
  15. 1 point
    Y gets set from your feeling of self-importance. X is loaded with zero just to publicly emasculate it.
  16. 1 point
    The file-based assembler project can now be found in its own github repo: https://github.com/irmen/cx16assem
  17. 1 point
    I like it. Couple of bugs, though: ldx, but indexing on y -> No idea what offset you'll be grabbing Never increments the index register -> Infinite loop Might also be considered a bug that the string length is limited to 256 characters. Here's a few alternatives. Arbitrary-length, null-terminated string (for up to a 16-bit address space): CHROUT = $FFD2 lda #<Msg sta loop+1 lda #>Msg sta loop+2 loop: lda Msg beq end jsr CHROUT inc loop+1 bne loop inc loop+2 bra loop end: rts Msg: .byte "Hello, World!", 0 String length less than or equal to 256 characters, null-terminated: CHROUT = $FFD2 ldy #0 loop: lda Msg,y beq end jsr CHROUT iny bne loop end: rts Msg: .byte "Hello, World!", 0 String length less than or equal to 256 characters, length-prefixed: CHROUT = $FFD2 ldy #0 ldx Msg loop: lda Msg+1,y jsr CHROUT iny dex bne loop rts Msg: .byte $0d, "Hello, World!"
  18. 1 point
    If this is about getting software onto, and data off of, the X16 from (for example) a PC, without reaching around to the back of the X16 to get at the SD slot and saving wear and tear on the card and the slot... aren't there a bunch of X1541 derivatives out there with IEC on one end and variously parallel, 9-pin serial, or even USB on the other end? This could free up the X16's user port for modem or printer connections.
  19. 1 point
    Yeah I thought this is what you may have been referring to. It could be more fun to use than say the Arduino IDE's serial monitor and such. Could even perhaps do simple graphing of logic states? One of the 6502 computers David reviewed had some nice to haves for this sort of thing, really bridging the gap between microcontroller and computer in a cool way. I think this would be a wonderful use of the X16 myself, yep!
  20. 1 point
    I don't think that there is an implication that EVERYONE need to or want to transfer files in and/or out of their CX16 at speed faster than the built-in serial port allows, but coming up with use cases for SOME people to want to do so is not hard. (1) Because for many people, the easiest backup for the SD-card will be to write it out to some folder in a PC's mass storage (2) It doesn't REQUIRE cross development, but many people will do cross development. (3) Some people have things they'd like to do that exceed their budget for bespoke hardware and see a way for an existing PC to be used as a resource to fill the gap. (4) The amount of GPIO and freedom to program to the bare metal makes the CX16 attractive as a bench computer for some kind of work, and you'd like your bench computer to be able to talk to your laptop.
  21. 1 point
    The VERA has PSG registers located from $1F9C0 to $1F9FF. I think the best solution is to have the PETSCII character set moved to $1F000, so that bank 0 now holds enough capacity for 64 KB worth of tiles. $1F9C0 onwards has no longer been general-purpose video memory ever since the VERA 0.9 changes got put in place. Palette and sprite registers used to be in separate bins, but now they hog the very end of VRAM.
  22. 1 point
    Expansion hardware is a great point. I still think between all the options discussed across the forums that one of them will stick So I have to imagine we'll have some sort of file copy solution - other than Sneaker Net. I'm just not sure which one. I would imagine the simplest one will be the first one that works (and that sounds like some sort of user port solution is my guess - or perhaps the IEC port). I think I'd be less bothered by SD cards if they weren't so small and were more purpose made for frequent insertion and removal. Something between an SD card and 3.5" would have been nice, with slots intentionally made for the purpose. Micro-SDs are even worse - I've lost several already behind my desk and that's where they're staying. I have to swap SD cards between devices several times a week and it ends up being a pretty big annoyance for me and they definitely do wear (both the SD cards and the readers) if you swap cards a lot.
  23. 1 point
    Good point. The only thing where this might be problematic is developing (for) external hardware. Is there an API in the emulator that allows us to simulate external hardware (like expansion cards and/or hardware on the user port)? If not, is it planned to add it at some point? Or are there arguments against it? (Except developer time, which is of course always short. I guess this feature would be relatively far down on the priorities list, at least until the hardware is more or less finished.)
  • Create New...

Important Information

Please review our Terms of Use