Jump to content

SlithyMatt

Members
  • Content Count

    320
  • Joined

  • Last visited

  • Days Won

    21

SlithyMatt last won the day on September 24

SlithyMatt had the most liked content!

Community Reputation

303 Excellent

6 Followers

Recent Profile Visitors

314 profile views
  1. My latest video on YouTube looks at how to use ca65 for another system: the Atari VCS/2600:
  2. 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.
  3. 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
  4. No problem! It's a common beginner mistake because it's so counter-intuitive. But, MOS had their reasons, I suppose.
  5. 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.
  6. 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.
  7. 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
  8. 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")
  9. 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.
  10. 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.
  11. 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!
  12. 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.
  13. You can set the PRG name in the makefile to whatever you want. The language-cc65 package is what you want for Atom.
  14. 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:
×
×
  • Create New...

Important Information

Please review our Terms of Use