Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Ender

  1. Yeah, I noticed that too. The issue is, they removed "sty r2h" toward the beginning, without removing the "ldy r2h" toward the end. Removing that should fix it. The calls to vtui_print_str in the examples also need to be updated to set A to $80 instead of 1, but that's a separate issue.
  2. This is really cool! I'd really be curious how fast this can get. Skimming the assembly CC65 generates, I see a lot of JSR's. So much branching certainly would slow it down. It should be interesting to see how much faster it could be written directly in assembly. Compiling with -O is noticeably faster as well. As a fun sidenote, running this with the emulator in warp mode, it's practically a playable game
  3. Looking good! A couple of minor things I see: Line 27 in acme-ex01.asm is "lda 0", you probably want "lda #0". The ".org" line in ca65-ex01.asm is unnecessary, the "CODE" segment already handles putting the code at the correct address. Can't wait to see more stuff use this, your screenshots look good.
  4. I think that's 48 on the back porch, and a total of 160, not 210? Which is 53 clock ticks total: 16 for the back porch, and hsync+back porch is 48. If we assume an average of 4 ticks/instruction, that's 4, 12, or 13 instructions.
  5. Ah right. SCAN_WIDTH is 800 and the SCREEN_WIDTH is 640. Yeah, that's unfortunate, then. But as @Guybrush says, the real hardware will be different anyway. I wonder how hard it would be to more accurately emulate the real hardware? Based on his description it seems doable, but it would be a big rewrite.
  6. That can be configured in the VERA by setting the lower 4 bits of the IEN register ($9F26). If you set bit 2, then it will trigger at the end of a line. Looking at the emulator code, it looks like it's right when you are hoping, when it is done drawing the visible area of the line.
  7. I think SCREEN $80 mode was heavily inspired by GEOS (with some code taken directly from it), and if you take a look at GEOS it's set up the same way as SCREEN $80 mode currently is. That's probably the main reason why it is the way it is. It would be pretty simple to alter things slightly to be as kelli requested, as was shone. It's just a matter of aesthetics.
  8. I'm not sure what you mean exactly? Like, the maximum size that could be loaded into lower memory all at once without overwriting anything essential? Probably from $400 to $9F00, so around 38.75KB. If you write an algorithm to, for example, read one byte at a time and copy them into RAM as you do, it would be that 38.75KB plus the 2MB of maximum RAM, so 2.03875MB. Of course, it would be dangerous to assume you have all 256 RAM banks available, as some, or most, users wouldn't actually have that much installed in their machine.
  9. If you really want to compile it yourself in Windows for Windows, I've done it inside of MSYS, although I had to make some changes to the Makefile. Compiling things for Windows is easier in MSYS than Cygwin because you don't have to worry about cross-compiling. If you're interested I could dig through what I've done and post more about it later (I mostly forget what I did off the top of my head).
  10. Screen 128 mode ($80) is a bitmap mode where you can do various BASIC drawing commands that have been added in the X16. You can also call them from assembly. It has a lot of 2D drawing functions similar to yours such as drawing lines, rectangles, text, images, etc.
  11. This is pretty neat! Just curious, is this much different from screen 128 mode? Is it doing a similar thing where the resolution is 320x200?
  12. Doesn't the VERA support NTSC? It does with the current spec/emulator at least.
  13. A little bit of googling found this: https://www.masswerk.at/nowgobang/2020/commodore-basic-variables The location in memory of those pointers (TXTTAB, VARTAB, ARYTAB, etc.) are different on the X16, but I think it works the same way. A quick grep from basic.sym shows this: Hope that helps.
  14. As long as layer 0 is enabled it will treat color 0 as transparent. You should see it that way, so if you aren't then you're doing something wrong. You can test it easily in BASIC with something like "POKE $9F29,$31:COLOR 1,0:CLS" and you'll see text on top of layer 0 as you type (although layer 0 will be glitchy and full of garbage initially without any setup).
  15. Yeah, all that needed to be done was removing the call to open.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Honestly it missing from the tutorial section sounds like a bug to me. Maybe we should ask @MattGrandis?
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...

Important Information

Please review our Terms of Use