Jump to content


Popular Content

Showing content with the highest reputation since 09/22/20 in all areas

  1. 12 points
    Hi all, I've spent that much time rummaging through documentation for vera trying to find how to set things up and which blasted $9f!*'@! did what, I thought I'd make myself a crib sheet with all the info on a single page (well, most of it!). I've attached a .png and a .pdf here for anyone to download and use if you want. I'm working exclusively in tile mode at the moment, so this crib sheet only covers that - I might do another one for bitmap mode when I start trying that. Hope it's useful to someone else! vera register info sheet.pdf
  2. 4 points
    Hello everyone. I'm Daniel from Sweden. I'm a network engineer with ten years experience but I'm currently trying to steer more towards development. I have started taking som colleague classes in programming and found assembly to be great fun. I figured Commodore was a great platform to learn more about it and I was very excited to learn about the Commander x16 project as it seems like the perfect platform for what I want to do. I've also started to learn to solder and about digital circuitry, and I've picked up some old Commodores and Amigas that need some TLC. I was slightly too young to learn any programming on our C64 as a child so I'm eager to learn this time around. If I can I would love to contribute in some way. I am not yet proficient enough with anything besides Python to be of any real use, but I'll get there :) Please let me know if there's anything I can do to help, perhaps cloud infrastructure or translating anything to Swedish? Thanks!
  3. 4 points
    Hello everyone! My name is TechUr, I am a streamer on Twitch, electronics hobbyist, and collector of vintage games (primarily Atari products). I found out about the CommanderX16 from The 8-Bit guy, as would be expected. I felt I missed out on the Microcomputer era, so it was exciting to hear about this project! My intention on this forum is to learn more about creating programs for the CX16. I have some experience in BASIC, but I'm hoping to learn more high level programming on the platform. I wish the best for this project, especially considering the world is on fire right now, and for everyone involved to making the CX16 a reality!
  4. 4 points
    Hi all, Drawing bug is fixed, and I've added the "only draw the hexes that have already been visited" thing. So now you start with a blank map with no idea where anything is until you start exploring! Next on my to-do list is to implement tracks, rivers and walls drawing routine. The entire map is 64 x 64 hexes - 4096 hexes in total. I've managed to encode rivers, tracks and walls into 1 byte per hex, 4kB for the whole map
  5. 4 points
    You need to use SEC before SBC, not CLC
  6. 4 points
    I have covered most of the topics you are asking about in the series of tutorials on my blog: https://www.8bitcoding.com/p/commander-x16.html I go pretty deep into explanations on how VERA works, different video modes, sprites, sprite animations, scrolling, layers and even some simple libraries to add music to your programs. Examples are written mostly in BASIC and some in Assembly but of course all the hardware related subjects are applicable to all programming languages.
  7. 3 points
    Hello everyone, my name is Mike. Retired software engineer. First computer was a Tandy TRS-80 model 1. Went to college with it. I still have it sitting on a shelf here. Owned Amiga systems for many many years and loved them. I am looking forward to the release of the X16 ("Take My Money, Damnit" lol lol). I miss the days of simpler fun computers. The retro guys (8-bit, Perifractic, etc) are making me look at recapping and refurbishing my model 1!
  8. 3 points
    Yes, it worked with both PRG-files in a zip-file and it chose the right one automatically, but if it chooses wrong you can edit it afterwards.
  9. 3 points
    My latest video on YouTube looks at how to use ca65 for another system: the Atari VCS/2600:
  10. 3 points
    The next version is going to introduce an exiting new feature: It can actually compile the exact same program for both the C64 and the CommanderX16. As long as you stick to using generic kernel subroutines and Prog8 library subroutines. And don't hardcode 40x25 screen size Many of Prog8's example programs can now be compiled for both systems by just flipping a compiler command line option.
  11. 2 points
    Hi I looked at the language-65asm package, but missed some things.. So I created my own grammar file based on that. This grammar file now highlights labels and symbols as well as registers and separates the # sign from the following constant/label. I attached the ca64.cson file, that you need to put into your language-65asm/grammars folder. Then restart Atom and the new grammar file can be selected. You can also define it for your filetypes as default in your config.json file. To enable all colours, you need to change the base.less file in your syntax-theme to refer to the new values, as not all of them are honored in all syntax-themes. I will create a specific Syntax-theme, that does include only the required variants and makes it specific to cc65. Attached find a example how it could look like: ca65.cson
  12. 2 points
    Be aware that C is not a good language for the C64/X16/6502 in general. It is very heavy on all the calls and context switches, where the 6502 is not very good at. The stack is also only 8 bit and only 256 bytes in total and cannot get extended. So you need to create a software stack (which is exactly what cc65 is doing) and that is really slow to use. Yes you can program in high languages - and it will be faster than interpreted basic. However I assume (not tested) that compiled basic would be faster than any C code.
  13. 2 points
    Simplest Sound Effects Library for BASIC programs View File Usage Because of its simplicity the library can be stored in a 1K space below basic programs, starting at $0400. Save the EFFECTS.PRG program in the directory where your BASIC program is stored, which would typically be in the same directory from where you are running the emulator. Load library with LOAD command: LOAD”EFFECTS.PRG”,8,1,$0400 Since this routine after the first run adds a new interrupt handler it is good practice to only load it once. It is therefore recommended to do a simple check: IF PEEK($400)=0 THEN LOAD”EFFECTS.PRG”,8,1,$0400 And that is it. Now you only need to call the needed sound effect from the BASIC program with a simple SYS command. We have four different effects so four different addresses can be called: SYS $400 PING Is designed for events like picking coins or rewards. SYS $403 SHOOT Effect that can be used for shooting the gun or other weapon. SYS $406 ZAP Electricity zapping or perhaps a laser gun sound. SYS $409 EXPLODE Long explosion for when we successfully blow something up Alternative binary named EFFECTSHI.PRG that loads into memory at $9000 can be downloaded. Of course calls are then $9000 for PING, $9003 for SHOOT, $9006 for ZAP and $9009 for EXPLODE. Full source code and walk through is available at my blog: https://www.8bitcoding.com/p/simplest-sound-effects-library-for.html Demo video: Submitter DusanStrakl Submitted 08/12/20 Category Dev Tools
  14. 2 points
    I haven't tried, but I assume you add both PRG in the same Zip file. When uploading you can specify which PRG shall be started first. That one then has to load the others.
  15. 2 points
  16. 2 points
    Tiled Map Editor BASIC DATA export View File This file is a JavaScript extension for the Tiled Map Editor. It will export your Tiled map as BASIC DATA statements. Inspired by Johan Kårlin export files. When exporting it will prompt for the starting BASIC line number. The script will output a few data statements about the map. Then the tile data will be output in DATA statements with 16 elements. Submitter Justin Baldock Submitted 09/24/20 Category Dev Tools
  17. 2 points
    *facepalm* thanks so much. thought it would be something dumb!
  18. 2 points
    Hey guys! So, I am starting to upload my code here: https://github.com/sebassco-dp/x16tutorial I have not started with the wiki section, but I hope to do so after I finish the BASIC guide. Since I ran into some trouble at work, my throughput has been a little affected, but hopefully I can make up for that this week. You will see most of the source files have the same examples than the ones on the C64 guide, but I have made some twists to some of them. After finishing to understand memory management, I will upload some stuff of my own there Hope you like it!
  19. 2 points
    New Version 0.4: Some gameplay changes: Level is lost when bottom enemy progresses to shields/fortress. You then fall back to the previous level and can try to advance again. If you fail level 1, then the game is over, too (or all lives lost). Enemy movements get more difficult with each level. They move faster, they advance faster. Patterns still the same Player sprite now has more realistic lag, when changing direction. Let me know what you think about this one. It was just unrealistically fast with the mouse, so I made it more difficult. Other improvements: More Levels! The background story is now more complete. The descriptions for levels > 2 don't yet match the description in relation to enemy behavior or motherships etc. Different enemy sprites I experiment with different enemy styles now. Most will probably be replaces later again. I like the martians, though ... Sprite animation for player sprite Player spaceship now shows thruster plumes and tilts when moving.
  20. 1 point
    I use vim too... I don't discriminate I use nano and pico to edit unix config files when I'm too lazy to install vim. I reserve emacs for *real* development All I need now is a console-based X16/6502 debugger... I am seriously considering converting my Apple ][ text-only emulator into such debugger... xdb
  21. 1 point
    I'm developing in C (cc65) for my games, too. The X16 is fast enough, for C - with a little bit of care in coding style. And - Matt's video is an excellent start.
  22. 1 point
    @SlithyMatt has you covered, boo: His example hello world files are located at https://github.com/SlithyMatt/x16-hello-cc65
  23. 1 point
    Hi all, Remarkably, I've managed to write an assembly routine that displays the value of a byte, in decimal, at a specified location on screen, and it works! (Got all my sec's and clc's the right way round and everything! I'm feeling very chuffed with myself and my over-inflated ego deems a hearty round of applause is in order ) I didn't google any examples, I wanted to have a bash at writing it myself from scratch as a learning exercise as much as anything. I know this is re-inventing the wheel and all that, but I wanted to write it specifically for the CX16 to be efficient as possible. It uses four bytes of zp memory (2 bytes for required x,y tile/cell position on screen, 1 byte for required colour attribute, and then the actual number to be written in decimal). It compiles down to only 74 bytes (excluding setting the vera stride, which is assumed to be 1 before calling the routine). Downside of this method is that it always displays leading zeroes. (eg, if the number is 26, it displays 026 etc) I presume this is a routine that all proper programmers have written hundreds of times in their sleep, is this the best way of doing it? It only has to display 0-255. ; vera stride needs to be set to 1 previously ; write the number to be displayed into display_byte ; pass the required x,y cursor position to the routine in decimal_x and decimal_y ; set colour to the attribute byte required for the number colour ; this example uses zp $20 - $23 but could be any free zp values display_byte = $20 decimal_x = $21 decimal_y = $22 colour = $23 lda decimal_y sta $9f21 ; set the vera y-cursor lda decimal_x asl a sta $9f20 ; set the vera x_cursor (has to be x *2 - two bytes per cell to allow for attrib. bytes) ldx #0 ; use x to count up the number of hundreds, tens and units lda display_byte sec hundreds_loop ; hundreds first sbc #100 bcc do_tens inx sta display_byte jmp hundreds_loop do_tens jsr display_digit ; display the hundreds digit (also reset x) tens_loop ; count up the tens sbc #10 bcc do_units inx sta display_byte jmp tens_loop do_units jsr display_digit ; display the tens digit (+ reset x) units_loop ; count up the units sbc #1 bcc finish inx sta display_byte jmp units_loop finish jsr display_digit ; display the units digit rts display_digit txa ; put the decimal column digit from x into acc clc adc #$30 ; $30 is the screen code for the number 0 sta $9f23 ; write out the number onto the screen lda colour sta $9f23 ; write out the attrib byte onto the screen ldx #0 ; reset x lda display_byte sec ; get ready for next column subtractions rts
  24. 1 point
    Hey, no problem at all. I'm happy to help. In my 40 year career (thus far), about 25 years is in embedded systems, on many different CPU platforms (Z80, 8088, 6809, 6502, 80186, AVR, ARM, HC11, MicroBlaze, etc.) I have written many PC and cloud apps in various languages (and created several custom languages), but I like small-platform embedded stuff the best, because I like having control of the entire machine, and figuring out how to do things with limited resources. That's why this Commander X16 project interests me. It brings back good memories!
  25. 1 point
    Absolutely. I was just showing the generic way to do MOD when not having the operator available. I totally agree to using AND whenever possible. Thanks for highlighting that. I have always enjoyed doing bit-fiddling stuff, so I truly get into the AND, OR, NOT, XOR, etc. side of things. I once wrote the entire windowing system for a touch-screen based printer. After writing all of the window operations and window message handling in C++, including per-pixel transparency of overlapping windows, I decided that it was just too slow. So I rewrote the "blitter" operations in ARM assembly language, and (WOW) what a difference in speed!
  26. 1 point
    If you have a project that requires several prg-files, can that use the "Try it now" button on this site? How do you do that? I have e.g. ARITM.PRG that could load EFFECTS.PRG at $400.
  27. 1 point
    Thanks! I am now reading Machine Language for Commodore Machines. And am typing in code now Also thanks for your youtube Hello World video and answering my questions there
  28. 1 point
    12-bit palette script for Aseprite View File Aseprite script that converts the current palette into a 12-bit (4096 colour) palette, i.e. 4-bits per channel. To install in Aseprite, go to File -> Scripts -> Open scripts folder Then drop the script into that folder and restart Aseprite. You might also want to assign a hotkey to the script via Edit -> Keyboard Shortcuts. It's also useful for things like creating gradients. Just create a gradient in the normal way, then run the script, and each colour in the palette will be nudged into the closest CX16 colour. Submitter izb Submitted 07/17/20 Category Dev Tools  
  29. 1 point
    Oh boy - should have checked for updates before I posted .
  30. 1 point
    Microsoft BASIC 2 never shipped for any platform that could make use of a CD-ROM or an ISO file. If you want the special Commodore (aka PETSCII) characters, the most reliable way to get them is to use VICE, a Commodore emulator. This is the main download site for the Windows version. Get the "Download zip no-cpuhist" version. https://vice.pokefinder.org/ And you can get other versions here: https://vice-emu.sourceforge.io/ You might also look at the TheC64 or TheC64 Mini, which are stand-alone computers running the Commodore 64 and VIC-20 environments. The full size TheC64, with built in keyboard, is releasing in the US in November, here: https://www.amazon.com/C64-not-machine-specific/dp/B08GMTJYXJ/ref=sr_1_3?dchild=1&keywords=thec64&qid=1600880449&sr=8-3 and is already available in other parts of the world.
  31. 1 point
    I've just released the new 4.3 version with those improvements! Download links in initial post.
  32. 1 point
    No problem! It's a common beginner mistake because it's so counter-intuitive. But, MOS had their reasons, I suppose.
  33. 1 point
    Not sure what you mean, but the X16 comes with a version of Basic v2, so you can check the Downloads section for the emulator and ROM, it's all freeware.
  34. 1 point
    Thanks DusanStrakl. I’ve read and reread several of your tutorials. They are excellent. A few things I was not quite sure of, but with the X16 docs, answers to specific questions and your guides I think I might be able to make a game.
  35. 1 point
    My daughter (11) is hyped up and excited about the 6502 revival but mostly, she just likes the novelty of play on my 4032 (Weather War) with her dad. Also I'm giving her STEM classes, beginning with basics of... um... Basic. Spend about 45 minutes once a week talking about it and doing little exercises. Last week we printed to my vintage 4022 dot matrix. I've opened the hood to show her the CPU, memory, connections to input/output and discussed the external connectivity (everything in the context of what she knows; iPad, USB, etc.) This next week we get into PetASCII, she will like that. Sometime over holiday break, I'll present her with a graduation present... SunFounder Mega kit that I bought in part (fully) for my Ben Eater 6502 build and I'll move on from there to teach her JavaScript. I do believe the most basic foundation of computers is still the most basic computer; CPU, input/output, memory, storage so this is time well spent. But I don't expect that she will remember the specifics when she goes off to College in 8 years or so but I do firmly believe that as an educational tool, the early machines give a good grounding the many miss; where students in High School today start with Robotics and Arduino. Console? Not a terrible idea but content is going to be a problem. It's taken about 10 years for Arduino to find it's way into commodity education that you can buy on Amazon for $20. I can't see something that costs even as little as $100 being viable without either a pile of content like the entire catalog of C64 education programs or a time machine to go back in time and remove all iProducts from the map. The Leap company pretty much bridged us from home the home computer to the iProducts. Between, CompUSA (in the states) and Toys 'R Us have perished. It's been a blur. But I'd be interested to have a view of anything you come up with, more is always good, I just don't see a viable platform without content and so much has already been done.
  36. 1 point
    Sounds good! I hope you're going to explore the C (CC65) route -- for some reason, that's the route that seems best to me. When I dive into this, that's probably the route I'll go. I need some good tutorials though to get started.
  37. 1 point
    It is sort of a nonsense instruction, but it is valid syntax wise. Effectively, it will turn it into a LDA from the zero page, using the lower 8-bits of address as the ZP address. So, you could have this: CHROUT = $FFD2 .org $44 zp1: .byte "a" zp2: .byte "b" .org $80D lda address jsr CHROUT lda <address jsr CHROUT lda >address jsr CHROUT ; lda #address -- Don't do this. The assembler will fail. You need to specify a single byte to load lda #<address jsr CHROUT lda #>address jsr CHROUT .org $4445 address: .byte "c" When you run, you will get the following output: CBAED We get this trickery by using addresses that can all be interpreted as ASCII/PETSCII characters So, you can see that the actual data is: $44: 41 ("A") $45: 42 ("B") $4445: 43 ("C") And if we get rid of the "address" symbol and the operators, our LDA instructions (with CHROUT calls also removed) become: lda $4445 lda $45 lda $44 lda #$45 (immediate "E") lda #$44 (immediate "D")
  38. 1 point
    The AFLOW interrupt happens when the buffer gets down to 25%, so you can play continuously as long as you have the PCM data in memory to feed the buffer. Playing back a long file from "disk" may be difficult, but if it was stored in small enough segments, you could keep on feeding the PCM indefinitely.
  39. 1 point
    It's pretty dead simple, and pretty much how I have shown it in my videos. For all my projects, I use Atom as my "IDE", because everything I do is hosted on GitHub and it provides really nice integration for that. I use the following "community" packages that are specifically for my development: * file-types - This is how I set up specific rules for determining what syntax highlighting to use for different filename patterns by adding statements to the config.cson file. * language-65asm - This provides syntax highlighting for multiple 6502 family assemblers, including ca65, which I use as the target file types in the config * language-xci - My very own package for XCI source highlighting! It opened my eyes to just how easy it is to publish a community package, which is both exciting and terrifying So, to set up the config, I added this to config.cson (accessible by going to Edit->Config...): "file-types": "*.asm": "source.assembly.6502.cc65-toolchain" "*.inc": "source.assembly.6502.cc65-toolchain" So, as you can see, I use *.asm because *.s just seems weird and wrong to me. To each their own! I am running Linux, so the build environment is within the Bash shell and my projects use Bash build scripts, GNU makefiles, or both. I simply call all of these from a terminal window, usually with multiple tabs so that I can switch between different working directories and have separate histories where I do the same few commands over and over again. Generally, I'll have one in the directory where I build from, and another in the directory where the build is placed and I can then run it in the emulator. I know some folks really want to have the workflow extremely streamlined so that the build is happening within the IDE, but I just prefer a dedicated terminal tab. You could totally create a button or hotkey within Atom that will call your build script or makefile and then launch the emulator with what was built, but that's not something I really feel the need to have. I'm a Linux/Unix person, and I like to use my terminals.
  40. 1 point
    And I managed to get up on YouTube tonight:
  41. 1 point
    I'll try to answer your questions to the best of my ability, everyone is free to correct me on any point . 1. There are 128 sprite definitions, and there is a hard 128 sprites per raster line limit, but there's no 128 sprites per screen limit. Sprite definitions can be changed during the frame, so you can reuse sprites in the same frame, further down the screen. a) Yes, but as stated above, that data can change during the frame b) No, the number of sprite animation frames is limited only by the available video memory (128K total). Each sprite definition points to a location in video memory containing the sprite pixel data, so you can just change that pointer in each frame (or even more often) c) Yes, absolutely 2. a) Yes b) There is no performance penalty besides the sprite limit per scanline (which also depends on the sprite size and the sprite no#) c) 256 colors is possible in 320×240 max for bitmap layers without resorting to raster interrupt tricks; for tiled layers it depends on the amount of memory needed for the tile data (e.g. 1024 16px×16px tile definitions takes 256K of memory, so that's out of the question, but if you don't need many different tiles you can use really big maps) 3. a) Yes, but it requires using raster line interrupts b) Sure, but it would start repeating the layer after 256 lines. But you can also use 64 tiles vertically and just use an empty tile (tile with all pixels using palette index 0) for all the tiles in the bottom half 4. I'm not very familiar with Genesis or SNES so... maybe. But i believe Mode 7 would be pretty hard to emulate.
  42. 1 point
    quick answer : You cannot read the VRAM with a monitor, nor with PEEK. The reason is, that the CPU cannot acces the VRAM at all. Instead you need to use the VERA registers to read from or write to the VRAM (VPOKE or VPEEK are implementing that).
  43. 1 point
    As one of the folks using C for the X16 I'd say don't discount it. There are a couple of C examples in the x16-demo repo (https://github.com/commanderx16). I've done a Lode Runner port and a utility library in C (https://github.com/CJLove/x16-LodeRunner). The number of available registers on the 6502 don't make it a great cpu for compiled languages like C. But just like the X16's higher clock speed enables a lot more to be done in BASIC that couldn't be done on the C64 it gives a margin for cases of less than stellar code generation by CC65.
  44. 1 point
    Maybe this is not the best example, but I develop the Commander X16 ROM using the ca65 assembler from the cc65 project. Unlike assemblers like acme, the ca65 assembler requires separate assembly and link steps, but since it's designed as the backend of a C compiler, it is extremely versatile. For debugging, my setup is probably the most uncommon: I exclusively use the -trace function of the emulator. It prints one line for every assembly instruction executed, with the label, bank, address, disassembly and register contents. In this mode, the emulator is about 10x slower than normal, so I have to script the emulator (-bas, -run, ...) to reach the interesting code as quickly as possible. I pipe the output of -trace into the Unix less tool, so I can search for symbols ("/") – the equivalent of breakpoints. I can search for the next ("n") or previous ("N") instance, and search for the point when code returns to the caller by searching for the bank and the first two digits of the caller address (e.g. .,02:de if the address of the caller is .,02:de24). If I missed the correct spot, I can always rewind – after all, it's all one big text file with all CPU history. Instead of less, I can also use grep, wc, uniq etc. to get statistics.
  45. 1 point
    Hello everyone! My name is Michael Steil, and I'm a member of the X16 development team. I am the lead developer of: the X16 ROM the (advanced) KERNAL operating system our version of the Microsoft/Commodore BASIC interpreter our MONITOR the DOS for the SD card the GEOS port the X16 character sets the X16 Emulator the X16 Reference Documentation I'm thankful for any help on these projects, all of which are Open Source projects on GitHub: https://github.com/commanderx16/x16-rom https://github.com/commanderx16/x16-emulator https://github.com/commanderx16/x16-docs (Edit: Or via this website's Support page: https://www.commanderx16.com/forum/index.php?/forum/17-x16-help-support-lounge/) Technical discussions on these projects should happen in the form of "Issues" on GitHub, but I'm happy to discuss more generic topic here in this forum! Michael
  46. 1 point
    To answer your question about different key switch types, I would highly recommend taking your next move carefully lol. Once you feel mechanical switches under your fingers, you can't ever really go back and enjoy membrane keyboards . For somebody that types all day, I would actually recommend a switch that allows you to feel the tactile point of actuation such as Blues. It's much more satisfying in my opinion and they generally are regarded as the best to type with. Red switches don't have a tactile feel for the actuation point and so they just slide until they bottom out. A more silent version of the Blue switch would be Brown switches and are sort of a happy medium between the two as they aren't super clicky clacky, but still have that tactile feel when depressing the key. However, regardless of the switch type, if you are plunging the keys hard enough to bottom out with every stroke, no mechanical keyboard will be truly silent. When at home I use Blue switches as the sound makes my heart happy and the feel is the best out of any switch type I own. I personally use Brown switches when in an office environment and I have never gotten any complaints from co-workers. I know that this is a lot of words to not really answer your question, but I hope to give you some things to think about that videos sometimes don't convey about different keyboard types since mechanical keyboards aren't inexpensive. Hope this helps!
  47. 1 point
    Your auto-correct mangled Joe King.
  48. 1 point
    G'day. I'm not sure how I got this far without it, but I'm getting to a stage where some form of debugger would help. I'm a complete newbee when it comes to assembly programming, so this might be obvious to others. Currently, I've been resorting to outputting raster numbers, or hard-coding a brk. But, I've not found a reliable way to set a breakpoint and query registers or memory addresses. I assume due to my game using RAM or VRAM needed by the monitor when it breaks out. "There must be there a better way?" *I'm in black and white, my hair all frizzy* Those who are developing games in assembly... how are you debugging them? Cheers Troy
  49. 1 point
    The emulator does have a built-in debugger. Just run it with the "-debug" option and hit F12 to see the debugger. The emulator doc has the list of commands.
  50. 1 point
  • Create New...

Important Information

Please review our Terms of Use