Jump to content

Ender

Members
  • Posts

    181
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Ender

  1. Ender

    codex

    A while ago Michael moved the code for the "TEST" command there, which tests various BASIC commands used in SCREEN 128 mode.
  2. The onus is on the authors of the software to update their software to be compatible with the newest kernal/emulator, not the other way around. It's in active development right now, so it's expected for things to be broken for a while. Eventually things will stabilize again, but for any developers that are now inactive, their stuff will probably not work unless/until they come back. I agree though that maybe the site should put into a separate section any software that's not updated for the newest version, or at least put some message that it's out of date, just so it's clear to users that this software might not work on the newest version. This could probably be done automatically (authors select the version of the kernal they support when they upload it, and when the newest version changes their stuff is automatically marked as out of date until they update it). Similar to how browser extensions work maybe.
  3. Ender

    codex

    I'm seeing a bug at the newest commit where it freezes when I try to view the disassembly at $0801. It also seems to make it crash if I try to view it at $0.
  4. It's true, the current debugger doesn't show labels, which is a bit of a hassle. I think a pull request was made at one point that completely revamps the debugger and allows you to load a symbol file that adds them, but it hasn't been accepted yet. Usually I just look at a symbol file to see the address for the labels and go by that (if you're using ca65 you can create one by compiling with "-Ln file.sym"). I just think the F12 debugger might be useful for you because you can see VRAM as you're debugging with the v command, ("v <address>" and then scroll up/down with pgup/pgdn).
  5. When I'm debugging I usually just use the debugger that you can get to with F12. I usually find it more useful to interactively debug things than to look at a log afterwards.
  6. He made a post about it here. As Scott says, it's not that he doesn't come here anymore, it's just that he never came here much to begin with. It seems this forum was mostly Perifractic's pet project, and now that he's left the team and turned it over to the community, it's mostly a fan forum now. Which is fine, but it's not too surprising if the team isn't active on a fan forum.
  7. Honestly I don't have a preference, but Tom seems to prefer to switch, and if he's not worried about the dev. time/effort, then I'm not, so I just say go for it.
  8. Looks like rnd is defined in code25.s in fplib. You call it at address $fe96 and this is the comment associated with it.
  9. Looking in the source for the emulator, it returns a random number when you read from the via registers $9f04,5,8 and 9, but that's just because the timers haven't been implemented yet.
  10. Thanks everyone for stepping up! I was a little worried after I saw David's post the other day, but it looks like we'll be around for a while yet!
  11. I don't believe there's a program that currently does this, but it's certainly possible to make your own version of the emulator that's integrated into an IDE environment that uses CC65 as the compiler. Something like this would be a fairly involved project to do though.
  12. Yup, the emulator supports the YM2151. Quickly perusing the Audio Apps section of the downloads area, it looks like this is a program that uses the YM2151, although the web player doesn't work with it. It may not be compiled for R38.
  13. Actually I downloaded this and it seems to work fine for me with R39. I think it may actually be made for R39 not R38, unless it's made for both. I haven't looked at the source.
  14. I thought I'd seen something about how collision detection in Sonic worked, and looked around some and came across this. Looks like it could be interesting to you: https://info.sonicretro.org/Sonic_Physics_Guide In particular, https://info.sonicretro.org/SPG:Solid_Tiles and https://info.sonicretro.org/SPG:Slope_Physics
    Whoa. This makes me want to see the whole game for the X16 haha.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. The bank number comes before the address. Like "m 1A000"
  20. Oh no, our upvote score is gone! Now we're all ranked "newbies".
  21. 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.
  22. 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.
  23. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use