Jump to content

Ender

Members
  • Content Count

    98
  • Joined

  • Last visited

Community Reputation

54 Excellent

Recent Profile Visitors

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

  1. Looks like the emulator updates at 60fps. That's basically updating the window title every 5 seconds and calculating the percent based on 300 frames having passed (which means 60fps). So it would make sense that an external factor limiting it to 58 would cause it to be slower than what it expects.
  2. The in-browser emulator seems to run fine, no stuttering, I forgot to mention that. Changing the desktop resolution doesn't seem to matter (which surprised me. what the heck is going on?!). I even tried turning off HDR since this TV supports it so I had turned it on. Still no difference. Edit: OK, so I think I figured it out. After I got this TV I messed around with my NVIDIA control panel settings, and I had set the max fps to 58 for some reason (since I don't have HDMI 2.1 yet I can only do 60hz refresh rate). Limiting it in this way seems to have made the emulator run slightly slower than it would. I don't think I need this since I think it's mainly for G-sync and I have that turned off right now (yet again I'd need HDMI 2.1 for that). Once I turned that off it seems to be back to normal.
  3. Seems like it. I'm just surprised that the resolution of the window doesn't seem to matter. Also, games seem to still be fine, when running at the same resolutions I played them at before. It's only the emulator I've had any sort of issue with. For the record, this PC is a bit old at this point, it definitely can't do games at 4K. I still only have a GTX 1070 (which I'm planning to upgrade soon) and an Intel Core I7-6700K @ 4.00GHz. However, I'd at least expect things to run like they did before if it's at the same resolution it was at previously.
  4. Maybe I should just make a github issue for this, but I thought I'd see if anyone here has any ideas first. The emulator has run smoothly for me until recently, when I got a 4k TV as a monitor. It usually ran at 100% no issues, with minimal occasional audio stuttering. But since I got the TV it usually runs at around 97% and the audio stutters. It's still the same resolution window as before, I usually run with "-scale 2". It's also happening without the "-scale" option. This is happening for both the emulator release downloaded from the github repo, and one that I've compiled myself.
  5. Honestly it missing from the tutorial section sounds like a bug to me. Maybe we should ask @MattGrandis?
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. The vector table is copied into ZP at bootup. This is how it's accessible from any bank.
  12. I think there's currently a bug with the FAT32 driver in the kernal that LOADing "$" causes it to freeze. DOS"$" should work though.
  13. 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.
  14. 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).
  15. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use