Jump to content

Ender

Members
  • Posts

    190
  • Joined

  • Last visited

  • Days Won

    1

Ender last won the day on May 22

Ender had the most liked content!

Recent Profile Visitors

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

Ender's Achievements

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. Ender

    codex

    A while ago Michael moved the code for the "TEST" command there, which tests various BASIC commands used in SCREEN 128 mode.
  11. 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.
  12. 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.
  13. 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).
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use