Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Ender

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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).
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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).
  16. 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.
  17. 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?
  18. Doesn't the VERA support NTSC? It does with the current spec/emulator at least.
  19. 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.
  20. 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).
  21. Yeah, all that needed to be done was removing the call to open.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...

Important Information

Please review our Terms of Use