Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Community Answers

  1. 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.
  2. 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.
  3. 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:
    A: $030C
    X: $030D
    Y: $030E
    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.

  4. 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.
  5. SlithyMatt's post in 256 color 16x16 tiles was marked as the answer   
    That's correct. You'll want to change the tileset address for layer 1.
  6. 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.
  7. 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.
  8. 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.
  9. SlithyMatt's post in doing something dumb in assembly... was marked as the answer   
    You need to use SEC before SBC, not CLC
  10. 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.
  11. 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
  12. 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.
  13. 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:
    Segment list:
    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
  14. 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.
  15. SlithyMatt's post in cc65 Newbie Questions / Mistakes was marked as the answer   
    If you add this at the beginning:
    .org $080D
    .segment "STARTUP"
    .segment "INIT"
    .segment "ONCE"
    .segment "CODE"
    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!
  16. SlithyMatt's post in What happened with bits 4:0 in the sprite address was marked as the answer   
    Not only are they assumed, they are required to be all zeros. So, you have to align your sprite in VRAM accordingly, at 32-byte boundaries.
  17. 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.
  18. 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.
  19. SlithyMatt's post in Expansion slots was marked as the answer   
    This has been posted here already: 
  20. SlithyMatt's post in vera: character sets was marked as the answer   
    By default it is placed at $0F800, so right at the end of bank 0
  21. 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:
    POKE $9F61,1
    LOAD "DATA.BIN",8,1,$A000
    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:
    VLOAD "GFX.BIN",8,0,$0000
    This will load to 0:0000 in VRAM, also continuing into bank 1, if necessary.
  22. SlithyMatt's post in Debugging in the emulator was marked as the answer   
    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.
  • Create New...

Important Information

Please review our Terms of Use