Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Ender

  1. Probably a bogus virus report. They pick up on false positives all the time. Lots of people use cc65, people that are smart with computers. I'm pretty sure if it had a virus someone would have noticed. Not to mention, it's open source. The only way I can see it having a virus was if your computer was already infected and it injected itself into cc65 after you downloaded it, but you probably would have noticed before now if that was the case.
  2. I looked at your cfg file. This probably isn't it, but just to rule it out, I noticed that the two BRAM10ADDR lines you added start with tabs, not spaces, and the cfg files could be picky about that, so I would try replacing those tabs with spaces.
  3. The layer1 map is $1B000 now. The character tile set is at $1F000. The layer 0 map base doesn't have a default value, but space is available for it at $00000 now. The palette is still at $1FA00.
  4. I'm not sure. You could try loading that file in the emulator directly and then looking at the disassembly in the debugger. Anything past you returning from the function would be the extra data.
  5. Looking at your screenshot, it looks like the first two bytes are the address to load to (00 A0). This is normal for the PRG format, so I guess the compiler just treats it like a normal PRG file. So when you're doing your copying, you would start at byte 2, not byte 0.
  6. Hmm sorry, I'm not sure. From what I can tell trying it myself, fgetc() is always returning 0. Although I can tell looking in agi.cx16.05 that there's data in there. I don't have a lot of experience with C on the X16, but the usage of fgetc() looks OK to me, and stepping through it I didn't see any obvious problems, it's just simply grabbing 0's for some reason... Can anyone confirm if fgetc() is working with the newest kernal?
  7. Just guessing from looking at it, but shouldn't that be "*(BANK_RAM + i)" that you're writing to? As is, it would just change the value at A000 over and over.
  8. I think you could just do "PRINT CHR$(0F)" at the beginning of your program and type your program in ISO mode, and just be sure to type BASIC commands in all upper case. Alternatively, you could just do shift+the letters in PETSCII mode, which would print what looks like gibberish, but in ISO mode looks normal, so when you run your program it looks fine.
  9. When you specify segments, all you're really doing is telling the compiler where in memory labels are supposed to point to. So if you had something like then that tells the compiler to replace references to "data" with $22. You still have to copy the data there yourself. When you load a program, you're just loading it into $801 (usually). It can't be loaded into multiple places at once. Now, it is possible to tell cc65 to fill a segment with a value before it loads code into it, and then a segment that follows will automatically start at that address (assuming you config file is set up properly), but you definitely wouldn't want to do that with the zero page since the kernal uses a lot of stuff in that area.
  10. I'm pretty sure there isn't a kernel API for the map base, you just have to write to $9F2E for layer 0 or $9F35 for layer 1. Same for reading the configuration, you just have to read the values at the VERA registers. The map height and width can be any of combination of 32, 64, 128, or 256 tiles. The width/height of tiles can be 8 or 16 pixels. All this info is in the VERA programmer's reference https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md
  11. Ender


    A while ago Michael moved the code for the "TEST" command there, which tests various BASIC commands used in SCREEN 128 mode.
  12. 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.
  13. Ender


    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.
  14. 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).
  15. 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.
  16. 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.
  17. 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.
  18. Looks like rnd is defined in code25.s in fplib. You call it at address $fe96 and this is the comment associated with it.
  19. 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.
  20. 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!
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  • Create New...

Important Information

Please review our Terms of Use