Jump to content

Ender

Members
  • Posts

    171
  • Joined

  • Last visited

Everything posted by Ender

  1. I think the problem is, regardless of the negative look-ahead at the beginning, the second part still matches the criteria. Maybe something like this? I don't have Atom in front of me right now to test it though:
  2. As far as I understand it, the glue code intercepts GEOS's load calls and translates them into something the fat32 driver understands. It's not general D64 support, it just allows GEOS to load from the disk. You can see it in dos/geos.s in the rom code.
  3. It does work, though. I tried it again before making my post. There's glue code in DOS specifically for supporting GEOS.
  4. ld65 doesn't but cl65 does. That's one of the reasons to use cl65, it does a lot of these things for you, whereas ld65 it's pretty much all manual.
  5. You should be able to mount it by just running the emulator with "-sdcard APPS64.D64". Keep in mind though, GEOS is only in a semi-working state right now. All the apps from DeskTop fail to load with disk read failures, at least, in my experience.
  6. I'll add on to Elektron72's post with a little more advice. A good place to see how to use cc65 is to look at the X16 kernal's cfg setup in their github (it's basically how I learned cc65, in addition to the documentation). https://github.com/commanderx16/x16-rom/tree/master/cfg It uses the preprocessor of cc65 to process those cfgtpl files into cfg files. Like Elektron72 said, you probably don't want to define a code segment for banked RAM if you're just planning on loading data there. The way people typically do it is to just compile them into their own data file, then in their code use the kernel load routine to load them into whichever memory location they need. If you really want to understand it though, you can see in the kernal rom, the way it does banked memory is to simply define the $C000 segments multiple times, for example. The bank it's assigned to is determined by the order they appear in the cfg file. The way it works in the X16 rom in particular, they create a .bin file for each banked rom module, which all start at $C000, then they just concatenate the .bin files together to make the .rom file. One more thing, you should take a look at cl65 if you haven't already. It's designed to make a lot of this stuff simpler, without having to worry about cfg files. That file you looked at, cx16-asm.cfg, cl65 uses that file for it's compilation. With that you can simply use those predefined segments, such "ZEROPAGE", when you want to use the zeropage. https://cc65.github.io/doc/cl65.html
  7. I think the screen 128 mode was first written before the VERA was set up the way it is now with the PSG registers, and it simply hasn't been changed to adjust for it. Although I'm not really sure how you could easily fix it besides just making it one scanline less, so it's 320x199. The only other thing I can think of would be to move the character data for layer 1 so that you could start the layer 0 data lower in memory.
  8. A fun experiment you can do is download pigdevil2010's conversion of Famicommodore for the X16, and then go to SCREEN 128 before running it with SYS $1000. You can see the pixels changing on the bottom right. https://drive.google.com/file/d/1H7Wp9FrNjfMwUkp2Nx1wFE9mZPICn5Q2/view
  9. So one thing I noticed a while ago is that in screen 128 mode, the layer 0 data actually overwrites the PSG registers. This means theoretically you could create sounds by drawing in screen 128 mode. Sure enough, if you do a certain pset, you can turn up the volume of the PSG: You'll notice that makes a pinkish pixel towards the bottom right, and also makes a buzzing sound. You can also change the other registers, to make whatever sound you want, like a simple square wave.
  10. Just to be clear though, in "screen 128" mode, it's scaled to 320x240, but then the bottom border is made bigger, so it cuts off the bottom 40 pixels. If it was scaled to 320x200 it would probably look a little squished, hence having the black border on the bottom.
  11. Ah right, it's 2 x's not 3. Sorry about that. Are you sure about the secondary address on the X16 though? It doesn't seem to be used in the SAVE function in the emulator, and, as far as I can tell, in kernal/cbm/channel/save.s, the SA gets overwritten at the beginning and it's not saved beforehand and used later on (unlike in load).
  12. Yup, calling the reset kernal routing is another way. Would line 20 actually be needed in that case?
  13. With SETLFS, A is the logical number, I don't think it actually matters what it is in this case. X is the device number, that should be 8. Y is the secondary address. I actually took a look at the code in the emulator and the ROM, and it seems as though the secondary address isn't even used. In the original C64, 0 meant save as a BASIC program, 1 meant do a raw save, and 2 was for saving to a data casette. But from what I can tell in the X16, it doesn't matter for saves. So the reason it wasn't working for you is because you didn't set X. Y and A don't seem to matter.
  14. A few things I'm seeing.... First of all, I'm not sure how you're calling the code, but if you're doing it with "SYS $2F00" for example, this will not behave as expected, since your filename definition is at the beginning. It should be moved to the end, after the "rts". Secondly, as pointed out, your secondary address should be 1 when calling SETLFS. 0 saves it as a BASIC program, 1 does a raw save, which is what it looks like you're trying to do. Third, the length of your filename is 11, not 10, so A should #$0B when you call SETNAM. Edit: Nevermind what I said about the SA needing to be 1 when calling SETLFS. I took a look at the code in the emulator for non-sdcard saves, and the ROM for sdcard saves, and it seems the SA isn't even used by the X16 for saving. Edit edit: I was wrong about the third thing too
  15. You can fix it by turning off layer 0 with: Or you can just fill the screen with a background color that isn't 0, such as:
  16. This sounds more like a software problem than a hardware problem. If you just install a PETSCII font on your system, you should be able to get PESTCII characters (assuming that one exists, I haven't looked it up). A special keyboard shouldn't even be necessary, besides the convenience of looking down and seeing what the key will type before typing it.
  17. The one that you get with -debug and typing F12 is pretty close. You can see memory (including VRAM), the registers, flags, disassembly, all that stuff. The only thing it's missing is the ability to inject your own code in.
  18. If you're asking how much memory is available in lower memory for a BASIC program, I believe from 0x0801 to 0x9EFF is free. BASIC programs always start at 0x0801, and I believe a table with variables/arrays are stored at the end of your program. For optimizations, I'm not 100% sure, but I don't think the code for the original set of BASIC instructions has been touched much. I know there have been talks about optimizing the garbage collection to use the method from later versions of BASIC, but beyond that I don't know. However, the CPU in the X16 is 8MHz, which is around 8x faster than the C64 was.
  19. You can load into VRAM by setting the A register to 2 or 3 when you call load. 0 for no verify, 1 for verify, 2 for loading into VRAM bank 0, 3 for loading into bank 1.
  20. I think technically 1 would be the fastest since it's just changing one value in memory and the VERA should pick it up for the next frame. However, 2 and 3 are also very fast. They're probably nearly the same speed, since RECT essentially does 3, but it has the added overhead of parsing the BASIC command (which probably equates to just a few milliseconds).
  21. Yes, pretty much. Another thing you could do is fill $10000-$1F9FF with something other than 1 in a for loop or something, but that would be really slow. Edit: Actually Greg King already suggested it, but making a rect that fills the screen is the fastest and easiest way. Also.... is there a way to remove a quote once you've hit the quote button? I can't seem to get rid of it.
  22. Looks like the code in kernal/cbm/channel/load.s saves the SA in to the X register, sets SA to something else for the serial routines, then tries restoring the old SA later on when it goes to check if it should load from the disk address, except that by that point X has been changed by the routines called in between and the old SA is lost. Good catch! I just put in a PR for a fix for this.
  23. I think what you're looking for is something like this. You want it to keep waiting until A$ isn't "".
  24. Definitely learn BASIC. The thing runs on a BASIC interpreter. You need to know how to make the machine do things outside of just loading in your compiled program and running it. Writing some BASIC programs to play around with graphics, etc. is a good way to get a feel for how the machine works and the ways to make it do things. For C, honestly? Not a lot of people are using C right now. Probably 90% of the people messing around with the X16 are using BASIC or assembly. I think I've seen one game written in C (there are probably more though). cc65's X16 support is a bit shaky. As development of the ROM continues (although I think the major breaking changes are over/close to being over) cc65's X16 support will break and you'll have to keep waiting for fixes or fix them yourself. For assembly, though, support doesn't break since it's just dependent on the 65C02 instruction set. I think also, in order to understand what your program is doing, or why your program will have to do a lot of seemingly random placing of values into certain memory addresses, it's good to learn the assembly first so you can understand what the heck is going on in a X16 C program. For threads, I'm pretty sure it's possible but it would be very tricky to do. It's definitely something the 6502/65C02 wasn't designed for, and not something natively supported in the C.
  25. Are you making sure to set the ROM bank to 0 first? I took a look at what the RESET command does, and it pretty much just sets the ROM bank to 0 and jumps to ($FFFC), so I'm not sure why it wouldn't work for you.
×
×
  • Create New...

Important Information

Please review our Terms of Use