Jump to content

Search the Community

Showing results for tags 'assembly'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Commander X16 Forums
    • Introductions
    • X16 Discussion Lounge
    • X16 Help & Support Lounge
    • Off-topic Lounge

Categories

  • Official Software
  • Official Docs
  • Community Downloads
    • Games
    • Productivity Apps
    • Graphics Apps
    • Audio Apps
    • Demos
    • Networking Apps
    • Dev Tools
    • Tutorial Apps
    • Misc Apps

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 11 results

  1. Ghost Crusher View File In this game you need to crush ghosts between walls before the ghosts catch (touch) you. Red walls can not be moved, but green walls can be pushed around. Be careful as ghosts can walk diagonally. --- At the moment there are only 4 levels. In level 4 you will encounter a poltergeist. Poltergeists can only be killed against a static (red) wall. Let me know what you think about the difficulty level. For each level I can control: Number of walls and static walls Number of ghosts and their speed Number of poltergeists and their speed Number of portals and how long it takes before they let a dimensional ghost through. Submitter JimmyDansbo Submitted 10/20/20 Category Games  
  2. JimmyDansbo

    Ghost Crusher

    Version 0.5b

    6 downloads

    In this game you need to crush ghosts between walls before the ghosts catch (touch) you. Red walls can not be moved, but green walls can be pushed around. Be careful as ghosts can walk diagonally. --- At the moment there are only 4 levels. In level 4 you will encounter a poltergeist. Poltergeists can only be killed against a static (red) wall. Let me know what you think about the difficulty level. For each level I can control: Number of walls and static walls Number of ghosts and their speed Number of poltergeists and their speed Number of portals and how long it takes before they let a dimensional ghost through.
  3. UPDATE: This is now available on GitHub: https://github.com/natenorrish/enhanced-basic-transpiler I've recoded the script completely to parse and output as a tokenized PRG. I'm also planning to add inline ASM directives to use BASIC, but enabling the option to optimize parts of the program - this will be an experimental feature ------------------------------ Hey all, My retro programming background is more Qbasic than BASIC, so for me getting used to the first 2 characters only being used for variables was quite painful for me. I'm also not a fan of using line numbers, and would prefer to use subroutines as with Qbasic. I created a script (which I'll no doubt continue to develop) which converts Qbasic style code into BASIC with line numbers (please see screenshots) The BASIC output isn't pretty, and I may work on that at some stage. Features: @LABEL: Create labels using @LABEL: - this will be automatically converted to a line number, and anywhere in the code that references @LABEL will be converted to the line number Variable names: can use alphanumeric characters with underscore (I know not valid in Qbasic). Script will convert variable names to a unique 2 letter variable. This eliminates the worry of having to chose your variable names. Line numbers: automatically added in and whitspaces / blank lines are removed Comments: Qbasic style comments with single quote ' Planning to add in sub routines which auto handle variables. Anyone interested? Nate Commander X16 2020-10-06 17-12-21.mp4
  4. I wanted to ask : is assembly language and monitor covered in the x16 manual?
  5. Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  6. So I started to make my Scary Forest program more Roguelike... and the first thing I did was implement a "fog of war" on the map. It's a great idea: don't draw the map! Saves time! Only draw new bits when you get within, say, 4 moves. And then you can "see" monsters... and they can see you... and start lumbering towards you. I mean this is a win-win, right? So I'll tell you: it DOES improve the feel of the game... a LOT. It adds some suspense. It adds an exploration element to the game. So there's emergent gameplay that I didn't realize was there. Once I add treasure, it'll be a whole new ball game. ...BUT... ...What I've found is that even drawing a 9 x 9 map from a 2D array, then handling player and monster movement, is too slow. Yeah, even with the Commander X16, it's too slow. I optimized. I went memory-lazy and use an array of floats instead of ints. I got rid of newline printing and went all cursor controls. Up, down, left, right. It helps. But... it's still slow. It turns out that adding a line of logic here and there really add up fast... and this is just PETSCII! So I'm fishing for suggestions. I've started asking myself what assembly language I can write to get the most speedup for the least amount of pain. Maybe the map drawing routine: fairly straightforward, no funny checking of data and switching around, so not a big chunk of code. I guess I'd POKE the map into a bank, and the ML would use ZP indirect indexing to find the right data, do a PLOT, and render the PETSCII. Next square. Do it from x-4 to x+4, y-4 to y+4. Maybe? Or maybe I should use sprites for the player and monsters? They would sit "on top" of the map, so I wouldn't be drawing over it; surely that might help? Anyone got better ideas?
  7. File Loader Tutorial View File Introduction Here is a little demo of how to dynamically load files in RAM bank in assembly. It's very simple to do but I think that it can be helpful for someone who don't know how to do this right away. In fact I personally would love to see more of this kind of programs in the download section How this loader works ? First thing to do is to tell the Kernal that we want to use a logical file. For this we need to use the SETLFS subroutine. From the "C64 Programmer Reference Guide" : Since we want to load from the disk (or filesystem) we'll need to use the device number 8. The logical file is not important so we use the file 0. Also, as we want to relocate the program into a bank at $A000, we'll set the Y register to #0 to activate secondary address mode. Next step is telling the Kernal which file we want to load. For this we'll use the SETNAME subroutine. From the "C64 Programmer Reference Guide" : For this we'll need to store our file names somewhere in our program so we write at the bottom of our file the names as a string of petscii characters. We then prepare our registers with the size of the filename to load, and then the address. Our final step to load a file is obviously the LOAD subroutine. From the "C64 Programmer Reference Guide" : As the Reference guide said, we want to load a file so we set our A register to 0 and since we want to load to banked RAM ($A000) we enter the address in our X and Y registers. One last thing that we need to do just after each of our LOAD calls, is to verify that our file has been successfully loaded. For this, we'll need to use the READST subroutine. From the "C64 Programmer Reference Guide" : As usual, following the Reference guide, all we need to do is call this subroutine just after our LOAD call, and check the content of the Accumulator. If zero, the load was successful. And that's all ! You can chain file loading as much as you need, and even you just need to call SETLFS once at the start of the chain. Note that you'll need to switch the bank between file loads to prevent overwriting previously added program. And since Bank 0 is also reserved you'll need to first switch to bank 1 and start from here. At the end you can also load a file in place of the loader, just avoid overwriting memory where the code is currently being executed. You can for example leave this kind of code in your first bank and at last run it to load a program from $0800 to $9EFF. Kernal Subroutines full documentation : https://www.pagetable.com/c64ref/kernal/ Post Scriptum If you have any suggestions for the code or even want to change things in this description, don't hesitate to tell me ! Submitter VincentF Submitted 07/19/20 Category Tutorial Apps  
  8. Version 1.0.0

    26 downloads

    Introduction Here is a little demo of how to dynamically load files in RAM bank in assembly. It's very simple to do but I think that it can be helpful for someone who don't know how to do this right away. In fact I personally would love to see more of this kind of programs in the download section How this loader works ? First thing to do is to tell the Kernal that we want to use a logical file. For this we need to use the SETLFS subroutine. From the "C64 Programmer Reference Guide" : Since we want to load from the disk (or filesystem) we'll need to use the device number 8. The logical file is not important so we use the file 0. Also, as we want to relocate the program into a bank at $A000, we'll set the Y register to #0 to activate secondary address mode. Next step is telling the Kernal which file we want to load. For this we'll use the SETNAME subroutine. From the "C64 Programmer Reference Guide" : For this we'll need to store our file names somewhere in our program so we write at the bottom of our file the names as a string of petscii characters. We then prepare our registers with the size of the filename to load, and then the address. Our final step to load a file is obviously the LOAD subroutine. From the "C64 Programmer Reference Guide" : As the Reference guide said, we want to load a file so we set our A register to 0 and since we want to load to banked RAM ($A000) we enter the address in our X and Y registers. One last thing that we need to do just after each of our LOAD calls, is to verify that our file has been successfully loaded. For this, we'll need to use the READST subroutine. From the "C64 Programmer Reference Guide" : As usual, following the Reference guide, all we need to do is call this subroutine just after our LOAD call, and check the content of the Accumulator. If zero, the load was successful. And that's all ! You can chain file loading as much as you need, and even you just need to call SETLFS once at the start of the chain. Note that you'll need to switch the bank between file loads to prevent overwriting previously added program. And since Bank 0 is also reserved you'll need to first switch to bank 1 and start from here. At the end you can also load a file in place of the loader, just avoid overwriting memory where the code is currently being executed. You can for example leave this kind of code in your first bank and at last run it to load a program from $0800 to $9EFF. Kernal Subroutines full documentation : https://www.pagetable.com/c64ref/kernal/ Post Scriptum If you have any suggestions for the code or even want to change things in this description, don't hesitate to tell me !
  9. I've started assembly that draws a beveled box in PETSCII on the screen. The user POKEs in left,top,right,bottom, and the code does the work. I just remembered that there are KERNAL routines to position the cursor on the screen. I should use those, shouldn't I? The routine starts by pre-computing the height and width, and then it positions the cursor: Then, it prints the top line: That's what I have so far. Next steps are to print the vertical bars and the bottom of the panel frame. Now for the print_x_spaces I have: And for the horizontal bar, I have: I guess I want to verify I'm doing things correctly, if there's a better way, and perhaps if this has already been done.
  10. So in my other post here: I wanted to make a programming language and a IDE to be used in the X16. So for creating the text box I have 2 options: 1. Using the GNU Readline library pros: Allows me to program in c cons: May not work on the X16, Lack of documentation, Might need to be ported to the X16 2. Directly editing the video memory pros: Gives me full control over graphics, Wont require extra code to be ported, cons: Even though I do have experience in assembly(x86 and 6502) it will be very hard to get right. So I have chosen to interface with the video memory directly. I'm having a bit of trouble understanding the Vera video card. I have read through parts of the unofficial documentation but I have a couple questions: 1. How do you switch to text mode? 2. How do you add characters or etc to specific parts of the screen? As development continues more questions may arise if so they will be added on to the list of questions. Thank you and have a nice day!
  11. Hi all, Just trying a few things before starting on a basic game. One thing I'm up to is loading a file into VRAM. I see this is supported in BASIC, but is there any existing code to do this is ASM? I can see how to implement this myself by opening the file, reading it a byte at a time and using the auto-increment of both the file handle and the vera, pipe it through. But, is there a repository of helper functions to do things like this? Cheers Troy
×
×
  • Create New...

Important Information

Please review our Terms of Use