Jump to content

Serentty

Members
  • Posts

    14
  • Joined

  • Last visited

Everything posted by Serentty

  1. The 6502 running at 3.4 GHz would be significantly slower than modern CPUs. You can check out this article where someone manages to emulate the 6502 at speeds equivalent to 15 GHz on a modern Intel CPU running at a clock speed less than a third of that. So modern CPUs do a lot more in a single clock cycle than the 6502. https://scarybeastsecurity.blogspot.com/2020/04/clocking-6502-to-15ghz.html The 6502 is also not very RISC-like. Its whole design assumes that accessing memory is fast. Something like the zero page, if not cached, would be horribly slow in the world of modern memory, which is not competitive with CPU registers for speed at all.
  2. That is an interesting point. I don't expect to see true clones (that is, clones of the entire machine, including its ports and extraneous features, that aren't general FPGA solutions that can easily replicate other systems as well, such as MiSTer) of the X16 for quite a while. Probably not until David and company are no longer making it, and even then, only if it's successful. If someone does make a clone right when the system is new, I can imagine there being significant backlash against someone trying to compete with a niche product which is mostly a labour of love. For the MiSTer issue though, while it will always be possible to simply use the original ROMs, I can definitely see a core author going to the trouble to try to make an unencumbered ROM using the Open ROMs code combined with the BSD-licensed code from the official ROM, for the simple reason that having such a ROM available and made the default heavily legitimizes the whole thing and takes a load off of David's mind.The MiSTer community is a fairly nice oone, and I can imagine people caring about that kind of thing. If I were the one writing an X16 core for the MiSTer, I know that I would try to do that for that reason. I think having unofficial X16 things (mostly FPGA cores, as opposed to full-board clones, which I don't expect to see for a very long time) try to play by the rules as much as possible does a lot to avoid conflict in the community and avoid splintering or hard feelings.
  3. As far as the ROM goes, I don't see why it would be too difficult (relatively—obviously it would take a fair amount of work) to simply write another one using the same entry points for the routines, similar to what Compaq did to avoid licensing the PC BIOS from IBM, who probably wouldn't have agreed to it. Cloning the whole BASIC interpreter would probably be a lot of work, yes, but if compatibility with BASIC programs isn't a priority then a clone could just focus on the KERNAL routines and run assembly programs, and let the user load a BASIC interpreter from disk. After all, PC clones generally left out the PC's ROM BASIC interpreter for the same reason.
  4. This makes me thankful how Rust divides its standard library between freestanding and non-freestanding parts, so huge swaths of it are already available on the Commander X16, and indeed even the VIC-20. I suppose I'm living up to the Rust programmer stereotype by taking every opportunity to praise it relative to C++. That's correct. There's an optimization pass which checks to see which functions are recursive (even if indirectly). If a function is not recursive, as most are not, then instead of putting local variables on the stack, it allocates memory statically for them. In the future, the plan is also to check to see if two functions can ever be running at the same time, and if they can't be, to make them share the same memory for their locals. It's all very fascinating stuff. But the effect of this is that if you call a function from an interrupt handler, you could very well be violating the assumption that there can't be multiple instances of that function running at once, and overwrite the locals of the instance. I actually have managed to write an interrupt handler in Rust for the Commodore 64 regardless, but only because the last thing my program did was set up a raster interrupt, and then just wait for it every frame, doing all further processing in interrupts. So interrupts are perfectly usable if you never have to come back from them. I managed to get a sprite bouncing around in the style of the old DVD screensaver. And then I increased it to eight at once.
  5. Oh yeah, with all due respect to @SlithyMatt (Hi, I love your videos!), I've been trying to push the limits of how high-level I can write my code and still have it compile down to the same assembly as if I had written it in a low-level style, and the sheer amount of optimization that LLVM does makes a lot of stuff which is higher-level than C useful without being slower. I just had a cool idea that worked out very well. Initially, I just wrote a simple copy_to_vram() function that copied blocks of data into VRAM using the autoincrement feature of the VERA. But then it occurred to me that this could be more general. Instead of making the function take data directly, I could instead make it take an iterator. Now, I can encapsulate the concept of writing something to VRAM with autoincrement, even if it's being calculated on the fly, without having to write code for autoincrement in the calculation code. The concept is very similar to passing in a closure or a generator. It goes without saying that the compiled assembly was the same when I tell it to iterate over an array. I've heard people talk about how powerful iterators are and how they're more than just a replacement for indexed loops, but this is the first time I've run into a situation like this where they're very handy. It allows me to separate the high-level calculations from the low-level bit fiddling and memory accesses, but have them compiled to be all mixed together the way you would writing the assembly by hand. I also write functions to set VERA registers which take lots of different enumerations, and constant folding can turn something like this: Into this: In terms of bad generated assembly, most of the limitations at the moment have to do with making the best use of the 6502's instruction set—it doesn't know about all of the NMOS instructions yet, and absolutely none of the CMOS ones. But that's something which isn't hard to fix, and is being worked on. So far I haven't run into a single case of bad assembly where the cause was my code being too high-level, and LLVM's optimization's not being able to make it lower-level, instead of the immaturity of the backend, and it not being able to make the best use of the instructions.
  6. This is what I put in the linker script for the X16 (at the bottom—the rest is the same as the C64). This should match the locations of the free zero page space. Also, since I haven't used banking yet, I placed the software stack (which doesn't get used that often thanks to the static stack optimization) in the banked area to give the maximum possible space for my program. I imagine that you would want this to be in low RAM in actual practice, though.
  7. I also edited the output files, making a copy of the C64 ones, but thus far haven't bothered to move those to the input files. It could be useful to try to upstream some of these configurations you've been working on! One important thing not to miss is the list of free zero page locations.
  8. Well, as long as they give it a chance, I'll be satisfied. The 65816 used to be a huge deal for me given the better high level language support, but the situation with the 65C02 has gotten better in only a few months, so I won't die if they don't use the 65816.
  9. Just thinking about this, I think I might have come up with a method for swapping out the zero page that's even faster than just getting the 65C02 to copy it at 8 MHz—store the other zero page banks in VRAM, and make use of the VERA's autoincrementing ports. I'm not sure of the exact cycle counts, but I would imagine you would save some cycles by only having to do one indexed access instead of two. I thought the 65C816 was still a consideration (just not making use of its banking features), but they weren't going to test it until the design is otherwise finalized, which seems like an oddly suspenseful way to do it compared to just occasionally checking if the 65C816 works in the current prototypes.
  10. Heh, I don't think even Linux gets that many commits. But yes, it's very active. I'm on the Slack group and they're constantly thinking of new optimizations. One that I saw mentioned (but I don't think is in there yet) is an optimization which turns loops with 16-bit indices into nested loops with 8-bit ones. They're also really innovative with their use of the zero page, and nearly never actually needing to use the stack. Generating assembly that resembles what people write for the 6502 by hand, which is very different from assembly for modern machines, is a big priority. Today I've been playing with writing stuff for the X16 with it, and it works fine there as well. I just had to tweak the C64 linker scripts to match the X16's memory layout. Regardless of improvements in optimization, we'll probably see around a 15% improvement in code size and possibly performance once they add support for the instructions added in the 65C02.
    I had the same result as Peon on Windows 10 (ARM edition, running it in emulation, but I don't think that's the problem). It crashes and exports an empty file. Two stars because the program seems like it would be very good if it worked properly.
  11. I'm not sure how it's calculating that number, but there have definitely not been 9,000 commits in one day. Here are the most recent commits. There are usually two or three a day.
  12. I've had a lot of fun writing software for the Commodore 64 in Rust with this over the past week. One nice thing about Rust is how it divides the standard library into three parts: completely freestanding, things that only require heap allocation, and things which require a full OS. So much of the standard library is already available on the C64, although I did end up replacing the formatting stuff with a third-party library in order to get smaller executable sizes. The LLVM backend is still not ready for making finished software yet, due to a few limitations such as not being able to handle code being called from interrupts, since it tries to statically allocate memory for functions instead of using the stack, which breaks down when interrupts get involved. Nonetheless, it's definitely ready for experimentation and writing fun things for 6502-based platforms. They have a Slack group that you can join from the link on their wiki.
×
×
  • Create New...

Important Information

Please review our Terms of Use