Jump to content

StephenHorn

Members
  • Posts

    467
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by StephenHorn

  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.
  16. While there are some things I expect would be lost in the transition, I somewhat expect that the forum posts would, in their majority, be preserved. Things I would expect to be more difficult to translate to phpBB would be the Downloads section, its comments, and its associated bits of metadata. I expect that's also where the bulk of the effort will end up going in order to preserve the site's functionality, but honestly I'm not sure if it'll be possible to preserve the downloads, or how the site will manage downloaded content in the future (to say nothing about "try it now"). And things I expect would not translate to phpBB at all are the individual user "awards" and "achievements", and the "leaderboards". Maybe I'm wrong, maybe these are available in some form via phpBB extensions.
  17. Turned out, that was a couple of bugs. First, Box16's option menu wasn't correctly translating between an internal value an an external one with that RAM value, so it was possible to save invalid values into the ini file. Second, Box16 was enforcing all the limitations to parameters when reading the ini file, which it attempts before reading the command line options (so the command line can then override it). I've made some tweaks to fix the UI issue in the options menu, and hopefully improve the behavior of overriding ini file options on the command line so that a bogus ini file option can be overridden without Box16 exiting early.
  18. If there's only one player, we obviously don't need to figure out which one, because there can only be one. <cue "Princes of the Universe" by Queen> The question is: Why does it matter which bullet struck the player? If the player dies instantly, just kill the player and not the bullet. If every bullet deals the same amount of damage, just deal the damage and give the player some invulnerability frames so they can get clear of the bullet and/or the bullet can get clear of them. If the type of bullet matters (normal bullets deal 1 damage, huge bullets deal 2 damage, or something), then you can still just deal the damage and give the player some invulnerability frames, but you'd want to change the definitions of your groups to be something like this: %0001 = player sprite %0010 = enemy bullet or sprite dealing 1 damage %0100 = enemy bullet or sprite dealing 2 damage In all of those cases, it doesn't matter which sprite collided with the player. It only matters what type of sprite collided with the player. If you are absolutely adamant that an enemy's bullet goes away the moment it touches a player, then you're correct that the VERA helps you very little. There could be hundreds of bullets on screen, especially if you're doing something like sprite multiplexing to try and exceed the normal 128 sprite limit of the VERA. In these cases, the VERA cannot tell you which bullet collided with the player. You'll have to check on your own, using some clever algorithm.
  19. The way I see it, the VERA was setup to help determine very simple, arcade-like collision cases where you don't necessarily need to know which sprites collided, only which kinds of sprites collided. For instance, the player sprite might be group %0001, enemy projectiles (and enemies themselves) might be group %0010, and your collision logic is then, essentially: Et voila. Pixel-perfect collision with as many enemy projectiles and/or enemies as you can force the VERA to draw, no further collision logic needed. You can even make the player out multiple smaller sprites, such as in the case of a number of Sega Genesis titles that constructed a player out of animated orbs or something similar. If the player has multiple hit points, I could see a game grouping enemy sprites by damage dealt, as well, so the game can quickly sort out how much damage to apply from up to three possibilities. Of course, this assumes the sprite or projectile that's hitting the player doesn't need to be deleted by the act of colliding with the player. Basically, the VERA's detection quickly becomes unfit once you need to know exactly which sprite, or sprites, collided. From a game design perspective, I think it's perfectly fair for enemy projectiles to stick around in a shmup or a shooter, provided the player either instantly dies or has an invulnerability period. Even a game like Ninja Gaiden really doesn't need to destroy enemies or their projectiles when they make contact with the player. So this interface has cases which can still take a lot of computational burden off of the CPU, leaving it free to devote it's time to the other half of that equation -- dealing with player projectiles striking specific enemies, in which case you'd need to know exactly which projectile instance struck which enemy. But hopefully that's a much smaller problem since the player isn't the one creating a bullet hell for the enemies to deal with.
  20. Sorry I haven't had more time to keep following this thread. Sounds like you've been able to find most of the answers for yourself, but I'll go ahead and chime in anyways. That message simply means Box16 didn't detect any MIDI input devices (e.g. didn't detect any MIDI keyboards or the like that would provide MIDI control data). Box16 supports taking MIDI input and mapping it to playback on the emulated YM2151 and VERA PSG. You can find it under Windows -> MIDI Control. That said, it's a fairly experimental feature and I'm not sure what condition it's in since the latest sound fixes to prevent stuttering in the emulator. Because of how the emulation works and how sound data is queued up for playback, the MIDI interface is "last bite at the apple" and may end up seeing a significant delay, or have other behavioral quirks that haven't been addressed recently due from disuse. Really, I'd prefer to implement MIDI through using the X16's expansion ports, but I don't know how those interfaces are supposed to work. :3 This means "ram" command-line option or ini file option was set, but not set to a proper value. x16emu and Box16 both expect a clean power of two for this parameter. My personal advice is to not depend on this undocumented value, because it's going to change with each version of the ROM. If you need to hook into interrupts, copy the address of your IRQ handler into $0314, which is documented and will not change. If you then need to gracefully run the default system interrupt handler, make a copy of the address in $0314 before your program clobbers it and then jump to it at the end of your IRQ handler. Sticking to documented addresses and interfaces will always improve compatibility and reduce the amount of boiler-plate work that needs to be performed between ROM versions. Exiting from interrupt is always ply, plx, pla, rti. A jmp only saves you 2 bytes per location (6 bytes instead of 8 ) and costs an additional 3 cycles, and is unnecessary if you're invoking the default IRQ. Also, this too is an undocumented location and is subject to change with any new or modified version of the ROM. Thanks, I'm flattered you feel that way, but it would be negligent of me not to acknowledge the contributions of akumanatt and @ZeroByte. Natt, in particular, has done a lot of tweaking to the UI. And, of course, the project originally started as a fork of x16emu, so it likely wouldn't exist at all without Michael Steil's foundation.
  21. Building with latest code from the depot, try launching with `-vsync none` in the command line.
  22. Correct, at least based on the emulator implementation.
  23. Someone on the unofficial Discord server reproduced this issue and appears to have discovered a fix. I'll probably get to it this weekend, unless someone beats me to it and submits a PR. Turns out this is probably a driver issue with OpenGL sync primitives (think "vsync"), so I was looking in the wrong place.
  24. You could potentially set one of the VIA timers, but they are not implemented yet in either x16emu or Box16.
  25. Right now, I'm not aware of any general-purpose access to the I2C bus that will be exposed. VIA#1 will be used to communicate with the RTC and SMC, using I2C protocol, but I don't know of any other I2C access or components on the system. (Note that the plan seems to be to run the keyboard and mouse through the SMC, so querying those for state would happen via I2C. This is because the team has had problems maintaining stable PS/2 communication straight through the VIAs.)
×
×
  • Create New...

Important Information

Please review our Terms of Use