SlithyMatt's post in Tile off to one side? was marked as the answer
Are you starting the files you load with a 2 byte header? It's required if you are using LOAD instead of OPEN/CHRIN, even if you specify an explicit address to load to. The Kernal still expects the default address to be in that header, and the data payload starts with the third byte in the file.
SlithyMatt's post in Question: Does "Try it now" support loading "drive 8" files? was marked as the answer
Yes you can, but drive 8 is default, so you don't need to specify it. Just use LOAD or VLOAD. For "Try in now", you need to make sure all your files are all-caps in your ZIP file, or it may not work.
SlithyMatt's post in Current cursor physical line number R38 was marked as the answer
The Kernal jump tables are recreated in the BASIC ROM, so it's not an issue. It will automatically bank switch for you. Like the C64, you can access the CPU registers and flags through RAM when doing SYS calls:
S (Flags): $030F
Carry is bit 0 of S, so you want to set that to have PLOT ($FFF0) return the position rather than set it. Then, after the call, the X register (ironically) will have the row, and Y will have the column.
SlithyMatt's post in Problems with FFD5 CBM LOAD API in X16 was marked as the answer
You can see the code, you just won't actually be stepping to it. The emulator traps out if you are using the host file system and does a native fopen/fread of the data and then dumps you back at the end of the LOAD subroutine. If you want to see the code, you can type D0D949 and you will see it in the debugger, but if you try to set a breakpoint, it probably won't work unless that code is actually getting executed. If you want to really go through that code, you need to use an SD card image.
SlithyMatt's post in Assembly BUG! I am stuck... was marked as the answer
It's perfectly OK to declare variables in the code segment, as long as it's outside the path of execution, as it appears here. RAM is RAM, and everything has to go somewhere.
But indeed, doing a ".res 0" for "pad" is not ok. You need to allocate the number of bytes you plan on writing there.
SlithyMatt's post in Joystick strangeness was marked as the answer
This behavior has been present in the emulator since the beginning. It is a scenario that's impossible with the real hardware, where you're always booting to BASIC and the user will need to hit the Enter key at least once before running anything. This flushes the joystick interface and once the program is running, it will respond to the first Start/Enter press.
SlithyMatt's post in How to use PCM audio was marked as the answer
On closer look, you are mixing up CPU RAM and VRAM. The PCM registers are in the former, so replace your VPOKEs with regular POKEs. The PCM doesn't actually use VRAM at all, despite being built into the VERA. The 4kB buffer is built-in, and not externally addressible.
SlithyMatt's post in Need help with BASIC/ASM access to VERA sound was marked as the answer
If you look in x16.inc I define the following constant:
VRAM_psg = $1F9C0
I use that as the basis of all PSG operations, using a fixed offset for the parameter being changed (e.g. volume is in the third byte of each channel, so I use an offset of 2) and then taking the channel number and shifting it left twice (to do a quick x4) to index into the channel's 4-byte section of VRAM (e.g. channel 2 starts at 8 bytes into the PSG registers, so 2 << 2 also gets added to the address).
So, say you want to max the volume of channel X of the PSG, the VRAM address you need to modify is $1F9C0 + 4X + 2. You need to read that in, then OR it with the maximum value (63 or $3F) and store it back to VRAM. The OR will prevent you from modifying the L/R channel bits in the same byte.
SlithyMatt's post in BASIC Command: Position the Cursor was marked as the answer
There is a better way, using the Kernal from BASIC. You can set register values starting at $030C: A,X,Y,P.
So, you can set X by poking to $30D, and Y by poking to $30E. Then you can call PLOT by jumping to $FFF0.
This code will plot "HELLO, PLOT!" to row 30, column 40:
10 POKE $30D,30
20 POKE $30E,40
30 SYS $FFF0
40 PRINT "HELLO, PLOT!"
SlithyMatt's post in VERA 0.9 640x480x8 - not enough memory was marked as the answer
That's correct, even though a setting is possible, it's not necessarily useful. Trying to do SVGA on the X16 will result in a bunch of garbage at the bottom. Now, you can do 80-column text mode with 256 colors, or 16x16 tiles with letterboxes to get the same pixel size. In general, graphics work best in 320x240 mode.
SlithyMatt's post in Generating a Memory Map "on the fly" was marked as the answer
The ROM build already generates maps, but not a single map, because the ROM is not just a single program. If you look in the build directory, you will see several .map files, one for each component. If you look in kernal.map, you will find the segment listing that starts like this:
Name Start End Size Align
ZPKERNAL 000080 000087 000008 00001
ZPCHANNEL 000088 00008F 000008 00001
ZPFONTS 000090 000091 000002 00001
KVAR 000200 000267 000068 00001
VARCHANNEL 000268 000293 00002C 00001
VARFONTS 000294 0002B9 000026 00001
KERNRAM 0002C4 0002E3 000020 00001
GDRVVEC 0002E4 0002FF 00001C 00001
KVECTORS 000314 000333 000020 00001
KVAR2 000334 00038A 000057 00001
KERNRAM2 00038B 0003C9 00003F 00001
KVARSB0 00A000 00A0EE 0000EF 00001
EDITOR 00C000 00C6F7 0006F8 00001
SCREEN 00C6F8 00C966 00026F 00001
KBDBUF 00C967 00CA99 000133 00001
SlithyMatt's post in Writing a "panel" drawing routine was marked as the answer
You want to use the PLOT routine in the Kernal to move the cursor. Just be aware that it confusingly switches the X and Y registers from what you'd expect. Put the row in X and the column in Y, and you're all set, no need to put out a bunch of spaces.
Alternatively, you can just poke the characters into VRAM, along with color info for each one. That will usually be the fastest method for rendering characters.
SlithyMatt's post in cc65 Newbie Questions / Mistakes was marked as the answer
If you add this at the beginning:
Then you can just do a regular LOAD and RUN from BASIC, no SYS call required.
After that, you need to add an inx so that you are incrementing the X register, then use bne or bmi instead of bcc for your looping branch. Also, you should count on CHROUT modifying X, so you should flank that jsr with phx and plx.
If you really do want the program in banked RAM, it gets a little trickier. You need to make sure the RAM bank register is set to something other than zero before writing to $A200, or you'll blow away the Kernal state. Generally, it's best to keep code in main RAM, and save banked RAM for data. 38k is a lot of space for code on the X16!
SlithyMatt's post in saving a ram bank in assembly was marked as the answer
I've run into the same issue before. It appears that, at least with R37, that the kernal does not support saving from banked RAM. I have had to copy data to low RAM prior to saving, by reserving the space needed for the saved file. I have posted that as an issue on GitHub, and hopefully that gets addressed with the next release.
SlithyMatt's post in Access to the character screen memory was marked as the answer
It's a bit hard to see at first, but the VERA doc does have it all documented. At boot, layer 1 is in text mode and layer 0 is not being used. So, you can peek at the layer 1 registers to see where the screen map and character set are, which thinking like tiles, are just a tile map and a tile set. So, if you do a PEEK($9F35) you will see the upper 8 bits of the 17-bit VRAM address of the beginning of the tile map, which by default is 0. There are no other bits for this address in the VERA I/O registers, which means that the tilemap has to be placed on 9-bit boundaries. So, by shifting 0 left by 9 bits, we still get zero, so we know that by doing a VPOKE 0,0,X will place the PETSCII character with the index value of X in the upper left corner. You can then set the background and foreground color of this character by pokeing the next VRAM address, $00001. Since it's by default white (1) on dark blue (6), we know the current value at that location is $61. Unless, of course, you haven't scrolled the startup logo past the top of the screen. At startup or reset, there is a magenta PETSCII triangle graphic character on a blue background, so at startup a VPEEK(0,1) will return $64 (or decimal 100) as magenta is color index 4.
Things change a bit if you switch to 256-color text mode by doing a POKE $9F34,$68. Then the odd VRAM addresses in the tile map contain 8-bit color indices from the complete 256-color palette, and the background color is always black. If you wanted other backgrounds with 256 color PETSCII, then you need to start setting up layer 0 with a bitmap, tiles, or more text, and set the backgrounds of different areas of the screen to be whatever color you want, even on a pixel-by-pixel basis.
I hope this isn't too much information, but I would recommend going through the VERA doc more carefully and trying out the different registers and seeing how they let you set up how VRAM is used and then start creating whatever you want on the screen.
SlithyMatt's post in Tricks for maximizing BASIC memory? was marked as the answer
You can load binary files directly into banked RAM using POKE and LOAD commands:
This will load DATA.BIN from the SD Card (or host FS if using the emulator) into RAM banks starting with bank 1. If the file is greater than 8k, it will automatically load across multiple banks.
If you need to load directly to VRAM, you can use VLOAD:
This will load to 0:0000 in VRAM, also continuing into bank 1, if necessary.