Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Ender

  1. 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.
  2. 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.
  3. 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.
  4. 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 ).
  5. This would probably be a good thing to create an issue for on the kernal github repo. Michael's probably more likely to see it that way, and they can track it in github.
  6. This is pretty handy! Although, I seem to have run in to a bug where it gets stuck loading forever. I stepped through the code and it looks like, with my file, the last character is 13, so it keeps reading that and treating it as EOL, but never reaching the EOF part of the code. I've attached it in case you're curious. It's basically just the three-line example you gave in the original post. TEST.BAS
  7. Michael's already ported that project for the CX16, when there were legal questions about whether the Microsoft BASIC 2.0 could be used. It's suffering from bit rot (won't compile) right now though, since it turned out not to be needed.
  8. Yup, there's a lot of crazy stuff people have done with redstone in Minecraft. I remember a while ago Sethbling posted a video of an Atari 2600 emulator he'd created in redstone and was able to run a couple games on it. (Of course, it ran at like 1 fps, but still...)
  9. I'm doing it using MSYS2 currently. From what I remember, it only required some changes to the Makefile. In MSYS, you'll have to install mingw and SDL2, yes. The ROMs aren't required for building the emulator. I think the other people that compile it on Windows have a setup with VS. I found the post about using VS2019 here:
  10. A while ago, like early April, Michael was active again and had seemed to plan to have R39 out soon at that time (I think he said something like he planned to have it out that weekend). However, it looks like there may have been some sort of hang-up, since there doesn't seem to have been any activity since then.
  11. It's true you couldn't take advantage of the increment with continuous VPOKE's. The only way you could is if you did one VPOKE, and then POKE'd to $9f23/4 after that. I just thought I should point out that when you use VPOKE, the first argument is indeed changing the increment and that that's what's happening when you set something in the upper nibble, since all it's doing is storing the first argument to $9f22.
  12. One thing to note, the upper 4 bits of the value you pass for the bank is used as the increment value for the VERA. So the upper 4 bits can be any value 0-15, and the only valid value for the lower 4 bits are 0 and 1. Also, it looks like the behavior when you try to set the lower 4 bits higher than 1 is that it simply uses the lowest bit of whatever value you set. So if you were to set it to 2, it would make the bank 0, 3 would make it 1, etc.
  13. Blue screen means it's the wrong version of the ROM. If you're building the most recent commit of the emulator, then you also need to build the most recent commit of the ROM. I've attached it here, but if the emulator updates further and you compile it again and it goes back to a blue screen then you'll need to recompile the ROM. rom.bin
  14. This is the change it's referring to: https://github.com/commanderx16/x16-rom/commit/62e10e1b9d97cc4e56fdb422c863aaf7582c3fd0 Looks like they changed them from being two pixels wide to one pixel wide. From what I can tell, the $65 and $67 are referring to the character tile values (screen codes), not the PETSCII codes. So you would see it by doing something like this. CLS : VPOKE 0,0,$65 : VPOKE 0,2,$74 As you can see, comparing $65 to $74, $74 is twice as wide, whereas they used to be identical.
  15. Well, as someone who is probably younger than a lot of people here (I was a kid of the 90's) I can say it is possible to get into this sort of stuff as a kid way after its prime. My circumstances were different from most 90's kids though, who were playing Doom or Commander Keen on their 90's computers. My parents were always very late/hesitant adopters of technology when I was a kid (not so much now) and so we never even had a computer at my house until probably the late 90's. However, my uncle was a Commodore buff and my earliest memories of computers was playing games on his C64. I was also introduced to BASIC through him and I found it fascinating. And then, for my 10th birthday (which would have been in '97) he gave me one of his C64's (which he took back and gave me a C128 a year later). I spent many hours playing games and typing in programs from books on the C64. My parents got a Windows 98 computer at some point, but I never really had an interest in using it much outside of school work. Then in 2002 my family finally got the internet, and from there my interest finally went over to "modern" computers. I never really used the Commodore much after that, and now it's in a box in the basement. I want to say, then, that it's possible to get a young kid interested in programming with BASIC like I was, but things are different now. I'm honestly not sure I would have taken as much of an interest in the C64 back then if my family had had the internet from the start . I'd like to think I would though, since I remember thinking BASIC was really cool, and I just found the act of typing a thing into a computer and then seeing it do the thing you wanted amazing.
  16. I mean, if you want to run it on the server itself without installing a GUI, you can install the X11 and SDL2 library files on their own. I think that's all you really need to run a GUI application. Whether your machine is powerful enough to actually run the emulator smoothly is another matter.
  17. In addition to what AndyMt said, you can also run it within the emulator by running with "-prg X16ROBOTS.PRG -run" as arguments from the command line. Or you could type 'LOAD "X16ROBOTS.PRG"' within emulator. These are assuming you have the Petscii Robots files in the same directory as the emulator.
  18. Unfortunately, this has been a bug with SD cards for a while. You can still see the directory listing with: DOS "$"
  19. Yes, but they utilize an area of VRAM for each sprite. Sprite 0 uses $7800-$87FF, sprite 1 uses $8800-$97FF, etc.
  20. There's a couple functions in kernal/drivers/x16/sprites.s that are used in some places in the kernal. Now that I look, they're in the Programmer's Reference Guide as well, "sprite_set_image" and "sprite_set_position". By the way, I was tired last night and didn't do much testing before I submitted the PR and then of course found it was pretty buggy right after. Turns out there's a lot of places in the graphics routines that assume we're always in bank 1 of VRAM, and the various places addresses are calculated don't take the 17th bit into account or hardcodes it to 1. I've already started going through and fixing these, but I put the PR on hold for now. Hopefully I'll be done soon.
  21. I decided to try putting in a PR to move the character tile data to $4000, in addition to changing screen 128 mode to actually be 320x240 now that we have more free space. It now starts at $C800. There's also a sprite API I hadn't known about that previously utilized $7800-$F7FF, I changed it to $4800-$B7FF.
  22. I currently do it using MSYS2. A lot of people might not want to bother to download and set that up, however. I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile. Maybe this is easy with WSL too, I haven't looked into it too closely. It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.
  23. Are you on R38 or the newest github version of the kernal? There's a bug in R38 with SD cards where it always uses the header of the file for the address. It should be fixed in the current github version though. The device used to be 1 on older versions, but it's 8 now. As for the first argument, I'm not sure that really matters? I haven't dug into it too much, but I couldn't find it being used anywhere in LOAD. The third argument is what lets it know to use the passed-in address vs. the header.
  24. I believe that section of the documentation is out of date, and there's no official documentation, unfortunately. However, it's pretty straightforward, as ZeroByte's example shows: The "bank" argument actually gets loaded into the ADDRx_H register of the VERA, so you could give a value for the increment there as well.
  25. Looking around the cc65 source, it doesn't seem like there is a vload to me. So you would have to do something like (note I didn't test this and I haven't really done any C with the X16 so something might be wrong): The first argument to cbm_k_load() would be 2 for bank 0 and 3 for bank 1.
  • Create New...

Important Information

Please review our Terms of Use