Jump to content

StephenHorn

Members
  • Posts

    440
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by StephenHorn

  1. Regrettably, this is not technically feasible, and would never have been. The VERA has always been 640x480 and only 640x480, it has never had the option of supporting multiple pixel clock speeds for multiple native resolutions. So our choices are "scaling with artifacts", "moving the display", or "doing nothing."
  2. I'm not sure what documentation you found, but as far as I'm aware the VERA has never been limited to 64KB of VRAM, and I went looking through the emulator code to build my own documentation as early as r27, which was the first publicly released version of the emulator. The VERA used to think in terms of 24-bit addresses, however, with the most significant byte acting like a bank switch. VRAM was then located in banks 0 and 1, while other memory-mapped registers were located in other banks. It would be easy to mistake this setup as "VERA only has 64KB of VRAM", if the author was forgetting about the entire second bank of VRAM. (Note that, even as early as then, there was no internal division between "the two banks of VRAM", so tilemaps, image data, etc. could overlap the bank boundary without causing any issues.)
  3. That's another good point in favor of including at least some sort of license.
  4. Ack, seems we both flubbed that. Of course I meant GPL.
  5. Honestly, the potential pitfalls and headaches are why I personally use simple licenses that are about as free as possible. My personal projects on GitHub are MIT, mostly because I didn't see "CC BY" or "CC0" in GitHub's list of baked-in licenses. MIT is a short, permissive license that basically says "You can do whatever you want with my code, just-- if you do use my code, keep my copyright notice with it (and, of course, the license). Basically the only thing forbidden is straight-up poaching it and pretending I had nothing to do with it. And liability - hell no I don't warranty my stuff with your random stuff, that's 100% user beware. And the liability clause is about the only reason I can think of not to just use CC BY or CC0. I'm actually not sure, either, to what extent GPL is still protecting or accomplishing their mission of "more and better free software for everyone". Being a bunch of soviet-style communists (you must also be communist or else) tends to scare people away, making it just another walled-garden fortress of the same sort their people claim to be against in the first place (and also claim is unhealthy for the progress of software everywhere). MIT's hippie-style, free-love for code license has no walls.
  6. Yes, the emulator uses the BSD 2-Clause license. It's an extremely permissive license. And yes, if you're going to submit a PR with someone else's work, you should ensure their license permits its inclusion into the emulator. This generally isn't too difficult, as long as you stay away from copyleft licenses, such as most licenses from the GNU people. Still, if there is any question whatsoever whether the author's code would be allowed to be used in this way, you should attempt to contact them and ask. I think you'll be surprised at how many people don't think terrible hard about their license selection and will reconsider the license, issue a one-off license for use, or otherwise permit their code to be used.
  7. Correct, you only need to include rom.bin. There are various symbol files generated by building the rom as well, but even though they've usually been included in the release packages, the emulator doesn't need them and can't load them besides (well, not until or unless the feature gets added).
  8. Huh. It should be using the built-in Clang toolset. I'd open the Visual Studio Installer and check whether that's been installed under the "Desktop development with C++" section. Looks like it's grouped with optional components, maybe I manually added it in. I remember moving to clang because I got tired of certain build warnings that msvc would glibly overlook, and then bite me when I submitted a PR.
  9. I looked into this for a couple of hours the night the update was posted, it was not as easy as I'd hoped, and I ultimately fell back to using my VS2019 setup.
  10. The Makefile is setup to do a cross-build, using MinGW to build a Windows .exe from Linux or iOS. The catch is, it is very specific to Michael's build environment, with hard-coded paths, at least one username, and other assumptions about the build environment, including a custom-built SDL2 implementation. It should be possible to clean some of this up, but we'd want to coordinate with Michael to make sure we don't break his ability to create release packages. It would be almost ideal if someone were to create a CMake script, but again we'd want to coordinate with Michael. In the meanwhile, there is no native Windows build configuration, nor a true cross-platform build configuration a la CMake. The best I can offer is that you can use the environment I setup for myself, using Visual Studio Community 2019: git clone https://github.com/indigodarkwolf/x16emu-vs2019 Enter the x16emu-vs2019 directory git clone https://github.com/commanderx16/x16-emulator Open x16emu.sln Press F5 to build Note that if Michael accepts the PR that reorganizes the emulator code files, that VS2019 sln will need to be updated accordingly. It's not hard, though-- basically, just delete all the entries under "x16-emulator" and then drag all the source files from the emulator back into that folder in VS2019.
  11. My only thought is that you've mismatched calls to DATA versus calls to READ, and are running out of space to store those DATA values.
  12. The more I'm thinking about it, the more I think alpha will be a non-starter for the VERA because there's no way around multiplies and division. Even if you're thinking "well, powers of 2, just bit-shift", the problem is that after you multiply the color components by their opacity, you add them to create a weighted value which is then divided to arrive at the final color component. So we're talking about 6 multiplies, 3 adds, and 3 divides, and that's just to calculate opacity between two color values. With three layers of sprites, not even counting the possibility of overlapping sprites within a single Z-layer, that's another 9 multiplies, adds, and divides. Even if the multiplies are converted into bit shifts, that's still 12 divides that can't be avoided with bit-shifty trickery. I just don't think that's in the cards, and even if it were I really think the math would be better spent on filling out in-demand audio features.
  13. Well, it is important that the emulator be running at full speed for an effect like that, but even a small timing glitch could cause flickering behavior, such as the thread being put to sleep for too long, or a particular frame taking unexpectedly long to execute. While an alpha channel isn't conceptually impossible to add to the VERA at some point, some of the real question is whether it can be fit into the FPGA's remaining logic units without having to shave functionality from somewhere else. On the technical side, it's worth pointing out, as well, that you probably don't want the alpha to apply to individual colors in the palette. But even if you did, what about layer and sprite alphas for fading out individual elements which may share palette colors with something else on the screen? And how would that potentially interact with an alpha channel on palette entries? Having alpha in the color channels also places a much greater emphasis on Z-ordering, in particular where sprites are concerned*. I suppose that's not a problem if you're calculating your own Z order and clobbering all sprite data every frame in order to apply it, but that sounds expensive. I haven't timed it out, I'm just saying that my gut instinct is to avoid that practice for more than a handful of sprites, if possible. * The Z-order of transparent objects determines which alpha channels have the greatest contribution to final color, with the smallest contribution coming from the object furthest in back. Transparency is a big deal in graphics programming, there have been a lot of papers written to try and solve various transparency-related problems in 3D graphics. Realistic "smoke" and "fog" effects, in particular, are extremely hard to make look good in a variety of circumstances, and lot of it has to do with Z-ordering issues. Perhaps one of the biggest appeals of realtime RTX on the latest generations of GPUs is that you don't have to worry (as much) about variously-expensive transparency effects, because you can choose to ray-trace instead.
  14. All well and good, but the emulator currently doesn't forward any of that from the emulated CPU. Feel free to submit a pull request to add it, though.
  15. Heh, conveniently Ben Eater has just covered PS/2 keyboards. Turns out the key repeat comes from the keyboard itself.
  16. I've never seen this, it is not represented in the emulator implementation, and it is not documented in the official VERA reference.
  17. Well, I'll admit I'm partial to the argument that it feels uncomfortable for PSG functions to be mapped to VRAM addresses. There are some conveniences since we can take advantage of auto-incremented addresses in the data channels for applying changes in bulk, but it's still "odd". But I respect that this ultimately derives from a cost-reduction and hardware-simplification strategy that avoids having to place a second FPGA on the board. Maybe there's an argument to be made over whether the "nominal purity" of the vision is worth the extra monetary and design cost of another FPGA, but I think there's also an argument to be made that if FPGAs are unavoidable, maybe it's better to try to consolidate them now and avoid inflating the price of the unit.
  18. Well, VERA has sprites, which are definitely a chore but they're also hardly unusual for an 8-bit machine. When I think of video processing chores that really start to separate the 8-bit era, I mostly think of hardware-based affine transformations and the first steps into 3D arithmetic. Hardware blitting into bitmaps probably also counts, but I was a lot less aware of that particular feature while growing up. So as far as I'm concerned, the VERA is still on the 8-bit side of that delineation.
  19. When I read "crackling" in a problem description with audio, my first thought is to ask: Was the emulator running at 100% speed? If not, it's possible that the audio output buffers created by the emulator are being exhausted.
  20. This is technically possible, but your caveat is that you won't be able to do this for arbitrary-sized payloads with the kernal, and you'll only be getting the data one bit at a time, and you'll be doing your own bit-banging to fetch each bit of data.
  21. https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md > The palette offset (in 'H-Scroll (11:8)') modifies the color indexes of the bitmap in the same way as in the tile modes.
  22. The emulator currently does not send commands from the machine to the peripherals. I'm not even sure if SDL2 supports that.
    What a brilliant, bald-faced, ridiculous, incredible lie. You, good sir, are a magician. A cheat and a charlatan. And I love you for it.
  23. My guess is that Frank made a mistake and accidentally made those repos public without meaning to, only fixing the error upon seeing they were forked. In addition, I would venture to guess that those projects are all stripped-down, minimalist implementations of the X16 features that Frank would have needed to develop the VERA and write test software that could be easily created in his minimalist environment and run directly on the prototype boards when and as they arrived. It's unfortunate to me that these are being publicized, doubtlessly against the wishes of the rest of the team, who do not want to see the X16 cloned or FPGA'd until they've had a first bite at sales and production. And if that's the case, then this is the kind of leak that could be quite damaging, depending on what, in all, is included in all the leaked materials.
  24. Additionally, the X16 team was targeting 8MHz because that was the fastest they'd been able to clock the chip on the board. So - just from a technical standpoint - it will probably go about as fast as they ship it.
×
×
  • Create New...

Important Information

Please review our Terms of Use