Jump to content

StephenHorn

Members
  • Posts

    467
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by StephenHorn

  1. On 3/30/2022 at 11:33 PM, Scott Robison said:

    Well, even a C64 didn't take a full school day. It's just my version of walking to school uphill in waist deep snow both ways.

    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

    • Like 1
    • Haha 3
  2. 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.

    • Like 2
    • Thanks 1
  3. On 4/12/2022 at 1:32 PM, Johan Kårlin said:

    And Stephen, Box16 seems absolutely great. There are debugging possibilites and other improvements that I have been dreaming about. Fantastic job. I will report if I find anything broken.

    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.

    • Like 1
  4. On 4/11/2022 at 7:52 AM, Johan Kårlin said:

    It starts without F-Secure complaining about it, there is some information in a first window but then a completely white and blank window opens and nothing more happens.

    Some more questions if you have the paticence:
    1. I have VS2022 so I upgraded the project. Maybe I have to install VS2019?
    2. Should I compile the latest version of the source files or go for the latest release from last year?
    3. Does rom.bin from the official release 39 of the emulator work? (It seems to work.) 
    4. If I get this working, is it compaitble with the official r39? After all, the reason for doing this is to upgrade my programs to work with this release.

    On 4/11/2022 at 12:37 PM, desertfish said:

    This has occurred for other people as well, usually it was related to incompatibilities in the integrated graphics card of a laptop. Are you on a laptop? Try forcing the use of the discrete graphics card for box16 (if your laptop has one of these)

    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™.

  5. 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.

    • Sad 1
  6. On 3/24/2022 at 5:21 AM, TomXP411 said:

    <@!62255158817468416>

    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.

    • Like 7
  7. 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.

  8. 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?

  9. 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.

  10. Quote

    The kickass assembler generates .vs files, which look like the following:

    image.png.ba69b34e7a236afc5feda0ff4bbd98f4.png

    As you can see, the al is a command, that allocates a "symbol".

    The normal syntax would be to have the address (a 4 digit hex number) immediately after the al command, but the kickasm creates a "C:" directive.

    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:

    image.png.4a539646a3dc55491370f7937d5f4543.png

    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:

    image.png.582113441e1368cd074af2f6fce22fca.png

    ...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.

    Quote

    each label has a dot (.) .

    Not sure if this was the desired effect.

    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.

  11. 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:

    Quote

    -sym <filename> will load a VICE label file. Note that not all VICE debug commands are available. (e.g. -sym myprg.lbl)

    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.

    • Thanks 1
  12. On 2/25/2022 at 6:30 PM, Snickers11001001 said:

    One caveat -- I do not favor any sort of 'badge' or special forum privileges for contributors.   If people can contribute $ that's great, but I don't want to see elevated status for donors since contributions to something like this can actually come in many forms, from pure enthusiasm, to coding, to moderating, to coding demos, to making videos, etc.   Just my take.    

    Tom, thanks to you and everyone else who stepped up on the site for all your work. 

    I wholeheartedly agree with this sentiment.

    • Like 4
  13. On 2/25/2022 at 3:38 PM, Edmond D said:

    I believe that forum has allowed the community to be successful. The Invision platform is perhaps the best forum software I've used. 

    Switching to a "free" platform that requires developer time to customize and also has a maintenance aspect is not really free. Consider your own wages and work that out to an hourly rate. At $800, how many hours would that buy? Would this be enough time to even start with a migration and customization? What's the estimates on the programmer hours to do the switch?  While you may have the skill to do a migration, would you rather spend the time on it or working on something that runs on the X16?

    When I joined the community I started to read every post. I'll admit that some material I skimmed over, as it didn't interest me at the time (and I can (currently) go back.) After finishing all the posts here, I considered diving Ito the previous forum, but the interface was a barrier. ( I can't even find it now!) I'm not sure of the quality or usefulness of those old posts since I haven't read them at any length. That jump presented a knowledge break, another one might do the same.

    Finally, there is a huge amount of knowledge in the forum. Most of it will be useful in the future, some of it became obsolete as design and decisions were made. I'd hate to loose it. Ideally the forum would be mined for relevant information which would be covered into documentation. I see great value in this task. Perhaps we should start doing this now? 

     

    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.

  14. On 2/22/2022 at 3:27 PM, svenvandevelde said:

    The problem was different. 

    In the roaming folder structure an ini file gets saved when you press "save options" in the menu. Unfortunately it stated in that ini file ram=4096.

    So every time box16 started, it loaded that ini file hidden in the roaming folders in apps data... regardless of -ram parameter given it would stop the program. 

    Check the picture where I was debugging the box16 to find the root cause. It's in the thread. Might be something to fix. 

    That being said, I would like to repeat, amazing work done on the emulator by all these people who contributed and who have put the foundation etc. 

    Thank you. 

    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.

  15. On 2/22/2022 at 2:52 PM, svenvandevelde said:

    That when a player sprite would hit an enemy bullet, then ISR would report %1001 ?

    And then it is the task to sort out which enemy bullet hit which player (which is only one...)

    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.

  16. 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:

    Quote

       lda $9F27
       and #$F0
       cmp #$00
       bne no_collide
       jmp player_died
    no_collide:
       rts

    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.

  17. 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.

    Quote

    MidiInWinMM::initialize: no MIDI input devices currently available

    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

    Quote

    The following ram are supported:
            8
            16
            32
            64
            128
            256
            512
            1024
            2048

    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.

    Quote

    What is the address of the

     // interrupt(isr_rom_sys_cx16_exit) -- isr_rom_sys_cx16_exit
        jmp $e034

    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.

    Quote

    I need to know the exact routine point in the zerobyte R39 rom where the interrupt exit routind is located.

    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.

    Quote

    The Box16 has a fantastic UI to follow vera ram, cpu and memory. Amazing. The creator of this should join the X16 team.

    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.

    • Like 5
  18. On 12/29/2021 at 2:48 PM, svenvandevelde said:

    I've installed the box16 on my pc, and downloaded the rom.bin and installed it at the root dir of the box16.

    But when i start the emulator, i get a blank white screen. Does somebody know what may be the issue?

    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.

  19. 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