Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Ender

  1. I took a quick look at the monitor source, and it looks like the load/save functionality has been disabled for now like I thought (the fa, sa, etc. variables are all set to $1111). I think the fixing of it has been a lower priority because it supposedly will get replaced with @mjallison42's assembly environment eventually. If you want to stick with a native environment, another alternative could be @Ed Minchau's META/L assembly language editor.
  2. I think for the second argument, the device, it needs to be two digits, so However when I try that, I just get "I/O ERROR". It may be that the monitor save function doesn't work presently. The last I knew, the monitor was in a buggy state since changes were made with the way banking works in the kernel.
  3. Yup, it just takes the value of the first argument and stores it into $9f22. (Though I think it would be decimal 16, not hex). Actually, taking a closer look at your code, it might not be less lines of code, given the way you're doing runlength.
  4. Actually, I don't think you could use VPOKE in this instance. Under the hood, VPOKE simply sets the address at $9f20-$9f22 and pokes the value into $9f23. Theoretically, you could set the first argument, the bank, to 16 to set the increment bit, since it's just poking that value to $9f22. However, the incrementing wouldn't work with calling VPOKE continuously since it's explicitly setting the address each time. I just tried it with an experiment and it didn't seem to increment. You could probably use VPOKE for the first piece of data though, to set the address, and just poke to $9f23 after that. It should in theory be a tiny bit faster since the setting up of the address is being done in assembly instead of BASIC. Less lines of code too.
  5. Kevin explained it in this video at around 8 minutes: Basically, it's as @StephenHorn said, the VERA's PSG serves the same function as the SAA1099, and since the VERA is not replaceable in the X16, as it was originally intended to be, due to the design of the kernal being fairly dependent on it, there's not much point in keeping it.
  6. The vector table is copied into ZP at bootup. This is how it's accessible from any bank.
  7. I think there's currently a bug with the FAT32 driver in the kernal that LOADing "$" causes it to freeze. DOS"$" should work though.
  8. If this is for the X16 emulator you can also just type it into a modern text editor and run the emulator with "-bas FILE.BAS" and it will input the file at bootup.
  9. Yup, you'd just set the carry flag, call $ff99, and it sets A, X, and Y. A contains the number of banks, and X and Y contain the address of the end of lower memory (which is currently $9F00). Or if you're in BASIC, you can just do "PRINT PEEK($25B)". The confusion in the other thread arose because Slithymatt hadn't set the carry flag first (if you don't set the carry flag before calling it, it sets the RAM bank number and address of the end of lower RAM to the passed in A, X, and Y instead of getting it).
  10. Ramtas currently does as desertfish says at bootup to probe all 64 possible banks to get the number of RAM banks. Taken from the ROM source, in kernal/drivers/x16/memory.s: Unfortunately, this routine also does a bunch of initialization stuff that you wouldn't want to call outside of bootup. However, the value gotten in the routine above is ultimately stored in $25B. As my post in the thread you linked says, memtop ($ff99) returns the RAM banks available in A by retrieving $25B, as long as you set the carry flag first. So, you can currently get the number of RAM banks by calling memtop, which is the safe way since its address is always guaranteed to be $ff99, or you can look at $25B directly, but this is less safe since kernal development is not over so this address could change. However, this is an easy way to do it in BASIC, and once development is over the address won't change. Sorry if this isn't what you're asking for. I'm a little confused, since memtop seems to fit your request.
  11. Well, as @SlithyMatt pointed out above, you can get it by peeking $25B, at least until the ROM is changed and things are shuffled around. That shouldn't be an issue in the future when things are solidified.
  12. Well, there is the "super monitor" X16 Assembly Environment that @mjallison42 is working on. It's still in the works, but it's largely complete already: https://sites.google.com/view/x16asmenv/home There's also an assembly language editor being worked on by @Ed Minchau that looks cool. He's mentioned on Facebook that it should be finished soon.
  13. The bug was specific to SD cards, where it would ignore the address being passed in and just use the address in the first two bytes of the file. So I checked with your program, and sure enough it seems to be loading into the address that the first two characters translate into (in my case it was "hi", so it would load into $6968). This is odd, because the BASIC LOAD command seems to work fine when using the host file system. Normally the secondary address (SA) is set with SETLFS, and it should be 0 in order to use the addressed passed in instead of the one in the file. I could see that your SETLFS was correctly setting it to 0, so I stepped through in the emulator debugger to see what was happening. It looks like OPEN is changing it to $60! So then I wondered how the BASIC LOAD command is working, and from what I can tell, it never actually calls OPEN (???). So as an experiment, I tried removing the OPEN line from your code, and it seems to work then. From everything I could find though, it says to use OPEN before calling LOAD so I'm a bit confused... Edit: After a little more reading, it seems you shouldn't call OPEN before LOAD. From https://www.pagetable.com/c64ref/kernal/#LOAD ^ Claims that LOAD calls OPEN. I went and looked at LOAD and it does seem to call OPEN itself, so that might explain it.
  14. Screen 128 mode is basically just a mode where you can use the GRAPH API, and in BASIC, you can use the extended X16 drawing instructions, such as LINE, RECT, etc. Those BASIC commands use the GRAPH API internally, but you need to be in screen 128 mode to use them. If your goal is to use sprites, I don't think there's a real way to use them with the GRAPH API, so you don't have to worry about it or screen 128 mode. I was just explaining those things in case you were wondering how to get your code in the original post to work (clear the screen and fill it with a color).
  15. SlithyMatt's game is a good example of how to use sprites in general and how to take full advantage of the VERA. The X16 kernal also supplies the GRAPH API that you're using in your code, but that's mostly a utility for doing simple drawing operations, such as drawing lines, shapes, images, or text, without having to worry about setting up layers or other underlying stuff. In case you're curious about what was wrong with your current code, I don't think you need to reinitialize GRAPH with GRAPH_init. I believe that's only if you want to switch the GRAPH API to point to a different framework than the default. You seem to also be missing switching to screen 128 mode, which you would generally do first, so you'd add something like: With that, you shouldn't need the code that configures the layers since switching to screen 128 mode does that for you. A good place to see the usage of the GRAPH API is in the code for the test command in the BASIC source: https://github.com/commanderx16/x16-rom/blob/master/basic/test.s Edit: One more thing, you're setting the color to $1C, but there's only 16 colors available in layer 1 with screen 128 mode.
  16. Right. Currently the kernal will always just use the first two bytes of a file as the address to load to, ignoring whatever is being passed in in X and Y, i.e. it's inadvertently throwing away the secondary address being passed in. So if Invaderz is calling the kernal load function to try to load the bin files into specific addresses, which it almost certainly is, then it wouldn't work. One way around this would be to set the first two bytes of the bin files to contain the address to load into, and load that way.
  17. Yeah, this is a bug in the kernal right now that ignores the address passed in. I put in a pull request to fix this a while ago, but Michael Steil hasn't been active lately so it hasn't been picked up yet. It doesn't happen when you're not using an SD card image because, in that mode, the emulator bypasses the kernal completely and loads the file into memory itself, and it properly handles the arguments being passed in.
  18. Ah yes you're right. I should have looked at the documentation before I said anything. And now that I'm looking at the kernal and emulator source, it seems it is just an emulator issue. I see support for it in the kernal, but not the emulator.
  19. Probably if you wanted to support it you would need to make changes in both the emulator and the kernel, yeah.
  20. Well, I don't know this for sure, but I'd assume it's because it's meant to mimic mouse support from the old days, and mice back then didn't have a middle button. On a more technical level, I think it's mainly because the mouse support is code pulled directly from the GEOS code, and since GEOS was written back when mice didn't have scroll wheels, it didn't support it.
  21. The X16 already has GEOS, although it's not totally in a working state yet. You just have to load the APPS image as an SD card and type "GEOS".
  22. All files either have to be in the same directory as emulator executable, or you run from within the directory of the program/bin files and call the emulator in its home area, like "..\..\x16emu.exe -prg blah.prg" I think it's the same deal if you have them in a SD card image, but it sounds like you probably just want to run them from the host file system.
  23. Is it feasible to just copy your interrupt code from your ROM bank into zeropage and then just change the FFFE/FFFF pointer to your code? Then you would just call the original interrupt handler at the end of it. I'm pretty sure that's what I've seen other people do. If you don't want to copy the whole interrupt handler, you could copy bridge code that saves the states of the registers and banks and switches to the desired ROM bank and calls it. For this sort of thing, it's best to have code in the zeropage that can be called from any bank.
  24. Well, you can also set the time Unfortunately with the emulator, it forgets the date and time every time you close it and open it again. https://github.com/cc65/cc65/blob/master/libsrc/cx16/settime.s Actually, that seems like a pretty doable feature for the emulator, to set the date and time when you start it to emulate a RTC...
  25. It should be fairly possible to do 320x240 at least. The main barrier to it right now is that the tile data (or character data) for layer 1 is at $F800-$FFFF in video RAM, which gives you only $10000-$1F9C0 for layer 0, which is actually slightly less than what is needed for an 8bpp 320x200 bitmap (thus the PSG registers being overwritten in screen 128 mode). This leaves the space between $4000-$F800 totally unused, but not big enough for anything. If the tile data for layer 1 were to be moved to $4000, then we would have $04800-$1F9C0 for layer 0, which is more than enough space for a 8bpp 320x240 bitmap. I don't really see any way of easily doing 640x480 since that is way bigger than all of the VRAM available, unless you made it 1 or 2 bpp.
  • Create New...

Important Information

Please review our Terms of Use