Jump to content

Ender

Members
  • Content Count

    128
  • Joined

  • Last visited

Community Reputation

64 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In addition to what AndyMt said, you can also run it within the emulator by running with "-prg X16ROBOTS.PRG -run" as arguments from the command line. Or you could type 'LOAD "X16ROBOTS.PRG"' within emulator. These are assuming you have the Petscii Robots files in the same directory as the emulator.
  2. Unfortunately, this has been a bug with SD cards for a while. You can still see the directory listing with: DOS "$"
  3. Yes, but they utilize an area of VRAM for each sprite. Sprite 0 uses $7800-$87FF, sprite 1 uses $8800-$97FF, etc.
  4. There's a couple functions in kernal/drivers/x16/sprites.s that are used in some places in the kernal. Now that I look, they're in the Programmer's Reference Guide as well, "sprite_set_image" and "sprite_set_position". By the way, I was tired last night and didn't do much testing before I submitted the PR and then of course found it was pretty buggy right after. Turns out there's a lot of places in the graphics routines that assume we're always in bank 1 of VRAM, and the various places addresses are calculated don't take the 17th bit into account or hardcodes it to 1. I've already started going through and fixing these, but I put the PR on hold for now. Hopefully I'll be done soon.
  5. I decided to try putting in a PR to move the character tile data to $4000, in addition to changing screen 128 mode to actually be 320x240 now that we have more free space. It now starts at $C800. There's also a sprite API I hadn't known about that previously utilized $7800-$F7FF, I changed it to $4800-$B7FF.
  6. I currently do it using MSYS2. A lot of people might not want to bother to download and set that up, however. I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile. Maybe this is easy with WSL too, I haven't looked into it too closely. It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.
  7. Are you on R38 or the newest github version of the kernal? There's a bug in R38 with SD cards where it always uses the header of the file for the address. It should be fixed in the current github version though. The device used to be 1 on older versions, but it's 8 now. As for the first argument, I'm not sure that really matters? I haven't dug into it too much, but I couldn't find it being used anywhere in LOAD. The third argument is what lets it know to use the passed-in address vs. the header.
  8. I believe that section of the documentation is out of date, and there's no official documentation, unfortunately. However, it's pretty straightforward, as ZeroByte's example shows: The "bank" argument actually gets loaded into the ADDRx_H register of the VERA, so you could give a value for the increment there as well.
  9. Looking around the cc65 source, it doesn't seem like there is a vload to me. So you would have to do something like (note I didn't test this and I haven't really done any C with the X16 so something might be wrong): The first argument to cbm_k_load() would be 2 for bank 0 and 3 for bank 1.
  10. If you set SA (secondary address) to 0 with SETLFS, it will use the X/Y registers as the address to load to, instead of the first two bytes of the file. There was a bug where this wasn't working with SD card images, but it should be fixed now with the latest changes.
  11. From what's been said repeatedly by the dev team, the hardware and design is pretty much set in stone at this point. It shouldn't change anymore from where it is now, except to fix critical issues. Mostly we'll just see software changes from here.
  12. Well, there is a "signature" starting at $FFF6 in bank 0, that's set to "MIST", after Michael Steil's online handle (mist64). On a C64 this is set to "RRBY", which is apparently the initials of two of the main engineers that worked on the C64. Looking in VICE, on a C128, this is just set to $FF,$FF,$24,$E2.
  13. I don't really know how to use it, but have you thought about using the floating point library in the kernel to do multiply with fraction part? It's possible it might be faster than your implementation. Although it might involve costly conversions which would balance it out anyway... (I honestly have no idea, I haven't done any research into it, just throwing it out there).
  14. Using kernal/no kernal is the same as using "host fs" vs SD card image. All that means is, when you run the emulator without the "-sdcard" argument, and you call LOAD in your program, the emulator detects the call to load, halts execution of the kernal, does the LOAD code itself, pops the return address off the stack, and resumes execution where it was called from. Thus, it's not using the kernal to do the loading. However, if you're using an SD card image as your filesystem (like it would be in the actual hardware), the kernal actually is handling all loading and saving, there's no interception from the emulator. Unfortunately, there's a couple bugs in the kernal implementation. Namely, you can't specify the load address using X/Y, and the banks won't increment automatically if you're loading into high RAM. There's no bugs with the "host fs"/non-SD card code (except saving across multiple banks apparently).
  15. That looks about right. The secondary address being 0 case is broken right now, but only for SD card images (which actually uses the kernel). It should work fine if you're using the host filesystem, which uses a bypass in the emulator to handle it. As Greg King pointed out above, there is a PR for this bug, but since Michael Steil hasn't been active lately, it hasn't been accepted or reviewed yet.
×
×
  • Create New...

Important Information

Please review our Terms of Use