Jump to content

StephenHorn

Members
  • Posts

    467
  • Joined

  • Last visited

  • Days Won

    25

StephenHorn last won the day on May 6

StephenHorn had the most liked content!

4 Followers

Recent Profile Visitors

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

StephenHorn's Achievements

  1. In the famous words of the Neutral homeworld's ambassador: I have no strong feelings one way or the other.
  2. What I find hilarious about this analogy is that my preferred bus stops for school were, in fact, on opposite sides of our family's house in the morning vs. the evening, and our house was, in fact, located on a hillside. So I did literally walk uphill (a very short, short ways) both going to the school (bus) and coming from it. And since I grew up in a snowy, wintry part of the world, that did sometimes mean braving waist-high snow (while trudging through our backyard), because it meant I could get home in time for the start of my favorite afternoon cartoons, rather than being stuck on the bus for another 30 minutes while it looped its way around. #firstworldproblemsforkids
  3. I committed a change to Box16 last night (or maybe this morning? It's high noon somewhere...) that will hopefully improve detection when my V-sync technique fails, and will disable V-sync entirely if no new frames are rendered within 5 seconds of it being enabled (or 5 seconds of the emulator being opened if V-sync is enabled with an ini file or command-line option). It could probably still use some iteration, but it's hopefully better than nothing, and will make "-vsync none" unnecessary. But I will also check out that thread @AndyMt, thanks for pointing that out.
  4. I appreciate that! And I'll be continuing to support Box16. Fixing the the vsync situation, in particular, is high on my list of bugs to fix. The problem is that I don't appear to have a good way of detecting when a driver doesn't support the API functions I'm depending on there, so I'll have to do something... creative.
  5. If "-vsync none" doesn't help, that's helpful to know as well.
  6. For now, try running box16 with the "-vsync none" command line argument. As for the questions: 1. The upgrade should be fine, I've got VS2022 installed as well and had no problems upgrading the solution. I'm dithering over whether to commit the upgrade into Github because it was so painless, but I probably should and just update the README.md to direct folks to install VS2022. 2. In general, I would recommend compiling from latest source, and the only reason I'd go back is if the latest source is broken for some reason (at which point, please let me know). 3. As I mentioned in my first, more hasty reply above, Box16 should be up-to-date to run the official rom.bin from r39. That's the rom I'm working with now. 4. I believe latest source code for Box16 should be fully compatible with r39. I need to roll new zips, tweak the README and a few other details, but I would plan to release nr39.3 soon™.
  7. If you grab the latest source code, Box16 should be fully compatible with r39's official ROM. That said, I'm still recovering from a fairly extended period of crunch, so I'm only 95% confident that it's fully compatible... mea culpa, the recent burst of activity has just had the worst timing relative to the demands of my dayjob.
  8. Lelz. That's me, by the way. I still expect I'm about a week away from having real time to work on x16emu and begin porting bugfixes and the like from Box16. But when I do have time, my plan is to go through existing PRs first, then port bugfixes and performance improvements from Box16. After that... we'll see. There are a truckload of issues in Github now, and we'd like to address some of them before releasing r39, I'll probably start working on those if nobody else beats me to them. Don't let me demotivate you, however! I have the power to accept PRs, and I'm totally happy to do so.
  9. Ahaha, well, if the SD card gets removed from the VERA, I wonder what would be freed up by removing the SPI interface from the VERA and whether that could add some other video-related functionality... XD
  10. Haha, yeah, that's quite the tectonic shift in the project. SD2IEC makes a lot of sense for Dave and Kevin, because they can reuse the working implementation from the C64 ROM instead of writing something from scratch. While Verilog and HDL are not entirely alien to me, I haven't been brave enough to jump into the VERA code myself so far. So I couldn't tell you how smart (or dumb) the VERA's SPI interface is, and thus where the error is likely to exist vis-a-vis the SD card. But from working on the emulation, it was my observation that the SPI interface was >95% kernal logic, so unless or until I can get my greedy paws on hardware, it'd be my guess that the issue lives there. So here's a fun question to open up: If the community were to make their own ROM, would we want to follow Dave's lead and continue to use the IEC interface instead of the SD card? Presumably, the SD card interface will remain part of the design no matter what at this point, the only question is whether the current problems are coming from the kernal, the VERA itself, or both.
  11. It was suggested on the Unofficial Discord server that the forums would be the place to discuss and debate technical details of the open ROM. I'm not sure what better way to start than to discuss how I/O should work, at least in terms of the API being presented by the ROM. I want to gather folks ideas. The C64 kernal presents different devices through different sets of functions. For instance, serial bus I/O is run through the TALK, TKSA, UNTLK, LISTEN, SECOND, UNLSN, etc. File I/O, meanwhile, is implemented through SETLFS, SETNAM, OPEN, CLOSE, CHKIN, CHKOUT, CHRIN/BASIN, CHROUT/BSOUT, etc. And there is also some concept of these existing in a unified context inside the kernal, as READST is used to indicate status for both serial and file I/O. I'm not familiar enough with the kernal to know for sure, but it also appears that at least some serial communication could occur through the file I/O interface to support printers. As far as the FAQ is concerned, the X16 supports the following I/O: SD Card (via the VERA's SPI interface, which is connected to the SD port) Two SNES-style controller ports (but we know the ports will not wire the "Data2" or "Programmable I/O" lines) PS/2 Keyboard PS/2 Mouse IEC-compatible (Commodore) disk drive port 13 general-purpose I/O lines (user port) Four expansion slots The first four are emulated in x16emu and Box16, I'm not sure if there's any emulator support for of the IEC disk drive port, and I know there is no emulation support for any user port or expansion slots. As for my own initial thoughts, I'm circling around the idea that we don't need to worry about serial communication support in an open kernal. And lacking emulator support for certain features, I'm not sure to what extent folks would be motivated to support Commodore drive support in the kernal, either. And I don't think we can really approach GPIO or expansion slots, for want of technical details about how those even work. Does that mean we want to provide an API that is, instead, focused on providing a FAT32-based file I/O interface? And then have special-case function calls for getting and setting state information about the keyboard, mouse, and gamepads?
  12. I'd previously been more of a fan of the retro videogaming subsection, having grown up beside a number of consoles from Atari, Nintendo, Sega, and Sony. In particular, I own at least one of every generation of Nintendo console, most of which were the original devices I had growing up (I sold the original NES and library as a child, and found the experience both unsatisfying and unprofitable, and I quickly came to regret it -- I have since purchased replacements, though my classic NES games library is still not quite what it once was). The 8-Bit Guy definitely catalyzed my interest in more general retro computing, however, and I've found his love of the Commodore 64 to be somewhat infectious. It's definitely a part of why I've been interested in the Commander X16.
  13. That is certainly unusual syntax, from my perspective. I haven't seen it before, and the VICE label file documentation for "add_label" is as follows: And I don't immediately see where VICE documents that an <address> can legally include a "C:" before the address. Is that a bank number? Some kind of command? The best documentation I seem to be finding is this: ...which makes no reference to anything that would allow "C:". Well, that's why Box16 doesn't handle the case, anyways. I can add that to the to-do list, but it's weird. Is that supposed to be a device reference? "C:" as in "CPU", as opposed to peripheral devices with separate 6502 processors and, consequently, their own instruction sets and memory ranges? Still appears to be an undocumented syntax, unless I'm referring to out-of-date documentation. I wouldn't call it a "desired" effect, as much as an "accepted" effect. Box16's parsing is very naive at the moment, and at the time that originally went in, my only test case was output from cc65, and I wasn't sure if there could be valid cases which were not prefixed with a dot.
  14. As @desertfish said, what Box16 understands is not so much "symbol files" from any particular compiler but a subset of Vice monitor commands. I do plan to expand the list of commands it understands, and it's not out of the question to try and identify some other common symbols-like file formats from the more common compilers. Calling the command line option "-sym" had more to do with my own misunderstanding of what cc65 was outputting with the "-Ln" option (documented as "Create a VICE label file"). This file conveniently contains nothing but al ("add_label") instructions for symbols in the generated program. The README.md at Box16's git repo documents the option like so: But I see that Box16's command line help is presently more ambiguous. In the short term, I can update the help text. Support for more file formats and VICE debug commands will have to be a longer-term feature.
  15. I wholeheartedly agree with this sentiment.
×
×
  • Create New...

Important Information

Please review our Terms of Use