Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 02/28/21 in all areas

  1. 2 points

    Version 1.0.0

    56 downloads

    I played this game with my friends in grade school on the PET. Though unable to find the original, I found a stripped-down VIC-20 version -- which showed me the program's essential structure -- and the later 1986 version by Commodore, mainly designed for the Commodore 64. I used both to create this version, which retains the original algorithms, and tries to emulate the older PET version. It uses very little X16-specific code -- exactly, SCREEN and COLOR. It relies on the 40 x 25 screen, and it uses just about all 25 of those rows. The rest is all PETSCII and BASIC 2.
  2. 2 points
    Yeah but I linked to a specific comment in that topic, which mentions GeckOS - a text based OS.
  3. 2 points
    Never heard of that. Interesting concept. Pro-tip: Call this port FuziX16, to let people know that this is a Commander X16 port.
  4. 1 point

    Version 1.3.0

    199 downloads

    Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey
  5. 1 point
    That is an interesting idea. Sometimes "good enough" is good enough and we can think of a different symbol name to satisfy the assembler.
  6. 1 point
    GeckOS looks(ed) interesting but struggles due to limited ram of the 64 (feels weird typing that) Could be great if an X16 port leveraged bank switching.
  7. 1 point
    And https://www.c64-wiki.com/wiki/Operating_System#Third_Party_Operating_Systems I like Contiki...
  8. 1 point
    Particularly, my favorite video game music is the SNK Neo Geo one. (Which is the reason why I chose the YM2610 chips for my dream computer, even going as far as picking three of YM2610B's (plus pairing up with four SIDs (6581 to be exact), the 4-channel PCM 8-bit 50kHz LMC1992 and a Seta X1-010 as well. https://en.m.wikipedia.org/wiki/Yamaha_YM2610 (then, take a look about YM2610B) How would all of them sound like according to you? But now, let's go on topic, I would recommend instrumental pieces, like Metallica's classics such as The Call Of Ktulu and Orion. (or the #1 hit ballad Nothing Else Matters) Or to get best of both worlds, try glam metal, such as Moety Crüe.
  9. 1 point

    Version 1.0.0

    7 downloads

    After seeing others post conversions of classic basic programs, I remembered this one where the computer plays an animal guessing game with you. It tries to guess your secret animal by asking questions about it, and if it doesn't know the animal, it asks about your chosen animal so it knows about it the next round! (It's basically building a binary search tree) note: all knowledge is lost when the program exits. (maybe I'll make a future version where it can save/load the animals and questions) Source code is here: https://github.com/irmen/prog8/blob/master/examples/animals.p8
  10. 1 point

    Version 1.0.0

    565 downloads

    A demonstration of the use of BASIC, sprites, and banks to create a tiled map. Everything is quite primitive right now. The response time is slow. The map is 256 x 256 and stored in banks 10-17 (it's 64k). My plan is of course to make it larger. Use the cursor keys to move about the map.
  11. 1 point

    Version 0.1b

    63 downloads

    Bernie is an unassuming guy, so sometimes he can be hard to find. See if you can pick out the curmudgeonly Senator as he tries to hide in different crowds.
  12. 1 point
    The key to all of this is that limitations breed creativity. Embrace the limits. Then find ways around them. Very often the end result is something greater than if you had done it the easy way.
  13. 1 point

    Version 2020

    273 downloads

    A sequel to my demo from Christmas 2019, but refactored to work with the R38 emulator and using new music and graphics. You can play it here, on your emulator, or just watch it on YouTube: Also available on GitHub: https://github.com/SlithyMatt/x16-xmas/releases/tag/2020.0
  14. 1 point
    I have improved two of the ld65 configure files ("cx16-asm.cfg" and "cx16-bank.cfg") because of your questions. You should update your copy of the cc65 project's files. Answer about the original question 1: There are two available regions in the zero-page. Each one should have its own definition in the MEMORY section of your .cfg file. And, each one should have its own segment. See how I did it in the new "cx16-asm.cfg" file. You would start by putting your zero-page variables in the first segment. When you tried to build your program, ld65 would complain that the memory area is too big; it would tell you how much too big. Then, you would count that many bytes back from the end of your ZP variables, and insert a ".segment" line that names the other zero-page segment. Answer about the original question 2: You should use the ".res" method of defining those variables. You should create a second file that has the same name as your zero-page source file, but with a suffix of ".inc" instead of ".asm". That header file will use the .globalzp directive to export/import all of your ZP variables. Your ZP source file will ".include" that header. And, any other source file that needs to use those ZP variables will include that header. That's one way that you can pass the names and locations from file to file. Other answers: "__LOADADDR__" and "__EXEHDR__" come from the system library. (Their purpose is to force ld65 to link in some objects from that library.) You don't write any code for them -- I already did that. You tell ld65 about them by putting the library's name as the last one on the ld65 command line: ld65 -C x16-asm.cfg -o HELLO.PRG hello.o cx16.lib ld65 will find those names in that library, and it will link in the stuff for the main load address and the BASIC SYS stub. Your main program should start with the "CODE" lines. (As Ender wrote, cl65 gives the library name to ld65 for you; you don't need to remember it.) You're correct about Matt's "hello.asm" file. ".org" lines must not be there!! And, the ".segment" lines aren't needed by you -- because you aren't using "cx16.cfg". Yes, the cc65 project's "cx16-bank.cfg" is like "cx16.cfg". It is written for C programs. But, you can use it as an example template when you create the bank things in your .cfg file. __BANKRAMADDR__, also, would be imported from the system library. But, you might create your own version of the "bankramaddr.s" file. Therefore, don't put that line into your .cfg file. __HEADER_LAST__ and __ONCE_RUN__ are generated by ld65 because of "define = yes" attributes on some of the lines. __HEADER_LAST__ is the address of the next byte after the actual end of the HEADER memory area. Therefore, MAIN will start immediately after HEADER. __ONCE_RUN__ is used as another way to create an overlay. It is the address where the ONCE segment is put in RAM. Therefore, BSS will be put on top of ONCE; that part of RAM will be reused. The ONCE segment is useful for C program initiation, you don't need to care about it. The BSS segment is used for ".res" variables that you don't put into the zero-page. RODATA is for data that never is changed (messages, for example). DATA is for ".byte", ".word", and similar variables that must have specific values when the file is loaded, but that will be changed by the program. Again, that separation mainly is for C programs, but Assembly code can use them, too. ca65 has convenient nicknames for those ".segment" directives: ".zeropage", ".code", ".rodata", ".data", and ".bss". I recommend that you put the "__EXEHDR__" line in your .cfg file (if you haven't already). (It will provide the BASIC SYS header.) I saw a $D000 in your .cfg file. That's for the C64, not the X16! I use the symbol name __HIMEM__ (high memory) to set the proper address -- you should do it as I did it.
×
×
  • Create New...

Important Information

Please review our Terms of Use