Jump to content

SlithyMatt

Members
  • Content Count

    322
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by SlithyMatt

  1. WSL would definitely work, too, pretty much the same as it does on plain old Linux.
  2. Now that you've gone through this exercise, you should try doing it with Binary-Coded-Decimal (BCD). It is natively supported by the 6502. You simply set the decimal bit (SED) and then ADC and SBC work in a different way to make this process much faster. I have several routines here for going back and forth between binary values and decimal strings: https://github.com/SlithyMatt/x16-makewave/blob/master/makewave.asm
  3. My latest video on YouTube looks at how to use ca65 for another system: the Atari VCS/2600:
  4. You can certainly do just that, use mon to write the code and then the emulator debugger for actual debugging. You will have to kick off your program from BASIC to start running, and then you can use the debugger to set breakpoints and step through it.
  5. If you're modulo-ing by a power of 2, it can be done much faster with an AND: 10 A = 111 20 REM MODULO 4 IS JUST THE LOWEST TWO BITS 30 M = A AND 3 40 PRINT M
  6. No problem! It's a common beginner mistake because it's so counter-intuitive. But, MOS had their reasons, I suppose.
  7. https://www.youtube.com/user/slithymatt I missed that instruction for language-65asm. If that works, then you don't need the file-types package in this case. You could certainly make emacs have a lot of Atom features, if you're an emacs sort of person. Atom is much more of a modern text editor and has a really nice interface with git and GitHub, which is all I need.
  8. VERA doesn't actually support an 80-character wide mode. The default mode is 128x64 character tiles, but the viewable part is only 640x480, so you only see the upper left corner of the tile map at scroll position 0,0. So there are actually 48 hidden characters at the end of every line, and 4 hidden lines past the visible bottom. If you change the scroll position, you can see these parts of the tile map.
  9. A line buffer is just adding overhead. VERA has two data ports specifically for use cases like this. So, you can use for port 0 for reading the next line, and port 1 for writing it to the line above. Assuming that the text is at the top of VRAM (as it is by default), you can do it with a very simple and fast loop. stz $9F25 ; set VRAM address 0 to start of second line stz $9F20 lda #$01 sta $9F21 lda #$10 ; stride of 1 byte sta $9f22 lda #1 sta $9F25 ; Set VRAM address 1 to start of first line stz $9F20 stz $9F21 lda #$10 ; stride of 1 byte sta $9f22 ldx #$00 ; set XY to number of bytes in text field before last line ($3B00, or 15,104 = 128x59x2) ldy #$3B copy_loop: lda $9F23 sta $9F24 dex cpx #$FF bne check_end dey bra copy_loop check_end: cpx #0 bne copy_loop cpy #0 bne copy_loop clear_bottom: ldx #128 clear_loop: stz $9F24 dex bne clear_loop
  10. 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")
  11. I would contend that splitting up the code into multiple files is generally more readable than one big assembly file. What I have done with most of my projects is rather than linking separate object files is to just have an include tree starting from the main file, and then you only need a single cl65 call to build the whole thing. This will preclude you from using any C code in your project, but if you are going all assembly it has some nice side effects. Most notably, the machine code listing file (generated with -l) for the main will contain everything in your include tree, showing effectively where every bit of code and inline data will be loaded in RAM.
  12. 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.
  13. This is what tells ca65 to create the BASIC SYS instruction at the beginning. Don't kill yourself to roll it on your own! Just use that in your assembly "main" and then you can link in other stuff from there. I would still recommend using cl65 for the linking step. Using ld65 on its own doesn't really give you much. You can use ca65 to build all your object files, and then cl65 to link them together and get your PRG. If you are letting the link automatically place all the object files where it wants in the CODE segment, you don't even need .segment statements in any other assembly file, as CODE is assumed. You can also have data put in the CODE segment in between subroutines - the 6502 police won't arrest you!
  14. 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.
  15. You can set the PRG name in the makefile to whatever you want. The language-cc65 package is what you want for Atom.
  16. Beta Version 0.8 is now available. You can see the release notes on GitHub: https://github.com/SlithyMatt/x16-xci/releases/tag/v0.8b And on YouTube I go through how I made the KQ5 "Rickroll" demo using some of the latest features in XCI:
  17. Can't VS Code work with a makefile? That would seem to be a pretty basic feature. Atom has the atom-make package. VS Code must have something similar.
  18. You can do it with VS Code or Atom, but it's going to take some more setup. For me personally, I don't care about using multiple terminals. I prefer to have a persistent shells for building and running.
  19. Were you able to get make to run from outside the Cygwin terminal? It may depend on being inside the bash shell, I haven't tried it outside. When I'm running on Windows, I keep the Cygwin terminal up for building and Git Bash for running the pre-built emulator and doing any Git command line operations that can't be done in Atom (I avoid the DOS command prompt whenever possible). But I would generally recommend developing inside Linux. You can use either a VM (VirtualBox with Ubuntu running inside the VM works great!) or using the Windows Subsystem for Linux.
  20. That was my point, that the old versions are still there, just not part of the current download version. You can't actually permanently delete anything from Downloads without admin intervention.
  21. The old versions are still there even if you "delete" them in the current file space. You can always browse the history to retrieve those old versions, so deleting them when uploading updates is the proper process.
  22. Nope, X and Y are untouched. I use this for a reference: https://sta.c64.org/cbm64krnfunc.html It's not 100% accurate, especially with the X16 kernal, but it's close enough. In the case of the X16 kernal code, X and Y are automatically preserved on the stack.
  23. Developing with C for Windows is a bad comparison to cc65 and the X16. By necessity it is much, much simpler. You'll want just a single PRG and just link everything to that. If you use my makefile, you are all set to create a set of .c and .h file with a sinlgle main function and link it all together. You won't need to link a bunch of libraries in, as the basic clib and X16 kernal stuff is automatically linked in if you reference it. And I'm not sure what you mean by "ALL of C". Do you mean a particular C standard, like C18? C is by its very nature a systems language, so its use is tightly constrained by your target system. In this case, it's as simple a system as you can realistically use C for. So, no heap, no floating point math, and no structs on the stack. But otherwise, anything that you would do with a C program is possible, and that pretty much covers what you can do with the X16, anyway. BASIC does give you floating point, but at an enormous cost because it's for everything all the time. What you will get with cc65 is the ability to have named pointers, structs and scalar variables. And those names can be larger than 2 characters! You can easily reference strings and binary data blocks anywhere in memory and use the standard C functions with them. Doing that stuff in BASIC is a complete nightmare and completely negates the "ease" of BASIC programming relative to C. Just some things to consider, as you obviously want to create a very involved game, and I'd hate to see you stymied by something that is easily overcome.
×
×
  • Create New...

Important Information

Please review our Terms of Use