Jump to content

Ender

Members
  • Posts

    166
  • Joined

  • Last visited

Everything posted by Ender

  1. Yup, I was relieved to see that. I was about to say I'm still a little skeptical that that's actually what he meant based on the wording in the screenshot that's been circulating, but I did some searching on the Facebook group just now, and apparently they've come to the same conclusion, and I'm sure they would have been corrected by David or Frank there if it wasn't true (since they both seem to regularly post there). Don't get me wrong, the X8 does sound cool, and I would probably buy one at some point, but I'd just feel better if the X16 came out first.
  2. Most people have shrugged it off, but I still worry about having two incompatible systems out there, competing for software development resources, especially if the X8 comes out first. I'd much rather have a X16 FPGA solution come out first instead. It would be fine if the X8 were to release eventually (although once the X16 comes out I don't really see the point), once the X16 software ecosystem has matured a bit.
  3. If you look at the source code of VPOKE, all it does is put the first argument in to $9f22, the second argument into $9f20 and $9f21, and the third argument in to $9f23. So yes, you can use VPOKE to set the increment, and arguably it's faster than doing three POKEs to set up the address, since you're parsing and executing two less BASIC commands.
  4. If you're using the initial VPOKE just to set up the address, that won't work since it will increment on that write as well, and it will end up starting at P+1 on the next line. You need to start at P-1 (assuming that it's ok to put a 0 there), or somehow VPOKE only on the first actual data write that you do.
  5. The bank number comes before the address. Like "m 1A000"
  6. Oh no, our upvote score is gone! Now we're all ranked "newbies".
  7. Correct me if I'm wrong, but you have SPRITE_64_BY_64 set to 196+48, which is 244, which I believe is 0b11110100 in binary. This results in a palette offset of 0b0100. I'm guessing that's not what you want since your palette_offset is 0. I think what you want is 240 for the dimensions.
  8. Right, but the bug is that it will always use the first two bytes of the file for the address, so if it's 0, it will try to load it to 0. Only if you're using an SD card image though.
  9. From what I can tell, it just uses the kernel LOAD function to do the loading. Are you on R38 and using an SD card image per chance? That has a bug where it ignores the address passed in and always uses the header for the address.
  10. I've currently got a Cooler Master Masterkeys MK750 with Cherry MX brown switches. I'm pretty satisfied with it, it's my first mechanical keyboard. I was kind of afraid to get keys that were too loud, but after having some experience with a mechanical keyboard and watching a bunch of videos on blue keys I kind of want to try buying some blue keys for it and see how I like it.
  11. You can see VRAM with the "v" command. Like "v 10000". It hasn't been added to the documentation yet, probably because it originally came from a pull request.
  12. Have you tried actually using the emulator debugger to look at what's in VRAM? Sounds like that could be helpful to you.
  13. I think it's definitely possible to do a simple (well, "simple"), line-by-line converter that detects when you're writing to a C64-specific area and converts it to an equivalent X16 area. The same for converting graphics calls to equivalent VERA calls, etc. The only thing is, as people pointed out, in a lot of the more complex cases, such as demo scene stuff, that would probably end up being slow, since the various techniques to accomplish things on the C64 would not always be the best way to do things on the X16. So it's definitely possible, just that it would have a limitation of being slow in a lot of cases.
  14. I'm not sure what your question is. Do you mean is there a way to load an SD card image after you've started the emulator? There isn't currently a way, no. That's just a limitation of the emulator. If you want to load a different SD card image, you have to restart the emulator with a different command line.
  15. Well, David describes in his post that it would require renting storage to store all those cases, and a lot of manpower and time to package all of it, and he just doesn't have the time or money to do all of that. I guess when he initially formed the idea he wasn't thinking they would have to deal with 1,000 units all at once.
  16. I would think that a license like that, (that is, one that makes you credit the author but not copy the license) kind of defeats the purpose, wouldn't it? Because let's say someone derives from your work and credits you but doesn't copy your license. Then someone else can derive from their work, but since there was no license, they don't credit the author. Then it can spread from there, with no credit to the author being given. I think the copying of the license kind of needs to happen, for it to have any effectiveness.
  17. @BruceMcF Are you saying then that the range of CPU RAM directly maps to the VRAM from a hardware perspective? That makes sense, I didn't know that. The way I imagined it was just how I interpreted David's wording in the original post, but I don't know a lot about the hardware side, so your way probably makes more sense. (Technically though, you could use it as CPU RAM if you really wanted to ).
  18. I have a C128 too actually. It's from when I was a kid and I have no idea if it still works (it hasn't been powered on since the mid 2000's I think), but I could finally dig it out and see if it still works if you want another beta tester!
  19. Wow, congrats. I wish I'd thought of that first, I'd be psyched to work on something like this (although I don't have much experience working on the C128). I kind of want to ask David for the source code anyway, mostly just because I love looking at other people's code and seeing how they do things and learning from it, and I'm sure the PETSCII Robots code is interesting.
  20. As far as I understand, it affects both. The changes to the window in CPU RAM are mirrored onto VRAM, and where these changes are mapped to in VRAM can be controlled by a register.
  21. Not really sure what you already know, and what you're asking for, but I can summarize it from a software standpoint (no idea about the hardware side/feasibility of setting up the X8 to act like the X16). On the X16, the way you write to the VERA is to write to specific addresses ($9f23/4). When you write to these addresses, the data is automatically transferred to the VERA. You can set the address on the VERA it's written to by writing to the addresses $9f20-2. The VERA also has a feature where you can set it to auto-increment the address for you so you don't have to worry about that. On the X8, there is a 256-byte window that you can write to that is mirrored to the VERA, rather than writing to the two addresses. You control where on the VERA this 256-byte window maps to. This is convenient for loading right from disk into the window, for example. Besides that though, (and I haven't thought about this a whole a lot so take this next part with a grain of salt), but from a VERA user's point of view, implementing a game or something, it doesn't seem that much different to me, besides that you're incrementing the address you're writing to yourself as you write into the window, rather than letting the VERA handle that for you. You also have to worry about changing the window address every 256 bytes. So honestly, it seems more complicated to implement for than the X16 to me.
  22. Before the deal with Cloanto was made and it was iffy whether they'd be able to continue using the current kernel, they started integrating the open-roms solution into the project. From what I remember it was mostly usable, but pretty buggy. One downside to it would have been that, since open-roms needs it to be clean of any influences of the original licensed kernel, no one who's seen the original source code can work on it, which means Michael wouldn't have been allowed to work in the areas of code that it covered, and we would have been dependent on outside developers fixing bugs in a separate project. There's still a switch in the Makefile to compile it rather than the CBM kernel, but it's been broken for a while. I think the integration of Frank's DOS and FAT32 implementation may have broken it.
  23. I'm not sure. I still get a bad feeling about releasing the X8 now. I'm not so concerned about the team's support for the X16 as much as the community. Let's say they release the X8 now, and a lot of people are excited about making something for X(anything), and so jump on writing software for the X8. Then a couple years down the line the X16 finally comes out. A LOT can happen in just a couple of years, software-wise, from what I've seen on these forums. By then probably a lot of games will have come out, written for the X8. And I can't help but feel that a lot of the hype may have gone down by then. And with the X16 being slower, and the interface to the VERA being a bit more tedious to deal with, will all that many people really be excited to port their stuff to the X16? Sure, people will start to develop things for the X16 at that point, but I feel like it will always be behind the X8. Also, a lot of people may feel their games and whatnot should support both the X8 and X16, which means not being allowed to use too much RAM or VRAM, which means a lot of developers not taking full advantage of the X16's capabilities. Again, this is just a worry, I could be totally wrong. I hope I am. But I feel like I have to put it out there.
  24. I'm kinda bummed people are voting to have no phase 2. It's honestly what I would probably get, since it's still customizable (you can add RAM, etc.) but it will be smaller and cheaper than phase 1 (if I'm understanding correctly). I'm not all that interested in soldering a phase 1 myself, or spending a lot of money to have it soldered, and the phase 3 seems kind of boring to me, like others said, you might as well just use an emulator with a RPi. As for the X8, it seems really neat, but I'm too worried about it diluting the software ecosystem. It seems a bit too incompatible as it is now. I'd say either make the the addressing of the VERA more compatible with the X16 (even then, having only half the VRAM is a big limitation compared to the X16) or, as @David Snopek said, release the X8 at some point in the far future after the X16 is well-established (but maybe release the X8 emulator so that we (read: I) can play around with it ).
×
×
  • Create New...

Important Information

Please review our Terms of Use