Jump to content

Ender

Members
  • Content Count

    140
  • Joined

  • Last visited

Community Reputation

75 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. 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...)
  4. 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:
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Unfortunately, this has been a bug with SD cards for a while. You can still see the directory listing with: DOS "$"
  14. Yes, but they utilize an area of VRAM for each sprite. Sprite 0 uses $7800-$87FF, sprite 1 uses $8800-$97FF, etc.
  15. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use