Commander X16

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.

 

Awwwww...  Did you have to ruin my fantasy of hundreds of retro-enthusiasts frantically hacking towards getting this completed?

?

Still, 2-3 a day is pretty good!

19 minutes ago, DigitalMonk said:

Awwwww...  Did you have to ruin my fantasy of hundreds of retro-enthusiasts frantically hacking towards getting this completed?



?



Still, 2-3 a day is pretty good!

I suspect it is 9000+ total commits over the lifetime of the project on the master branch (or whatever the main branch is called). And agreed, any project with multiple commits per day is pretty active. Hopefully good in that they aren't continually breaking new things and having to fix them with subsequent updates. ?

They seem to be _VERY_ strict about there unit and integration testing.  No Pull Requests are allowed unless they are covered by an existing test or include new ones.  All code has to follow the LLVM coding and quality guidelines.  None of that stops errors getting in, of course, but it should severely limit the "quick hack" kind of coding that leads to fix/re-fix/fix-again/no-this-time-really/argh commits...

I am incredibly stoked that there are so many C compiler efforts out there now for 6502:

• 
  cc65, of course, which is pretty rock solid but unfortunately generates (by far) the slowest/largest code.  But it always works.
  


• 
  gcc-6502 has the GCC front end goodness, but still some backend issues, and is pretty much dead unfortunately...
  


• 
  KickC is quite active and the lead developer is responsive and helpful.  Very cool if you want to mix and match with KickAssembler
  


• 
  NutStudio has been mentioned in another thread here.  I had good luck in my initial forays with it.  He's not ready to release, but is open to beta testers
  


• 
  LLVM-MOS which appears to be very serious about the whole effort
  

2 hours ago, DigitalMonk said:

Awwwww...  Did you have to ruin my fantasy of hundreds of retro-enthusiasts frantically hacking towards getting this completed?



?



Still, 2-3 a day is pretty good!

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.

1 hour ago, Serentty said:

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 think Linux actually gets far more commits, but it is harder to see because it is such a hierarchical organization that many of those commits never make it directly into the master branch of the "root" repository. The LLVM-MOS team is much smaller (I assume) and thus most things go straight to their "root" repo.

Or so I guess.

On 6/26/2021 at 6:01 PM, Serentty said:

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.

I would be very interested in the details of your tweaks. Did you make an X16 target alongside the existing 64 target, or did you just modify the 64 files into X16 files?

I'm trying to make my little game for the 128, 64, VIC, and PET, and they all put BASIC in different places...  64 works, of course.

I'm trying to get 128 working next.  My first attempt modified files directly in the 'build' directories.  I copied the 64 source directory and renamed it to 128.  I modified the ldscripts/link.ld to use the 1c01/1c0d addresses needed on the 128.  I renamed 64.cfg to 128.cfg and tweaked the comments (the actual commands didn't appear to need modification).

Got a valid PRG.  Tried to autostart it in VICE and it exploded.  Automounted it instead so that I could list it, and it was "7773SYS2061", so the basic header didn't autoadjust to the linker start point (I got lazy with KickC, because it generates the basic header on the fly). 

Realizing that I'd been hacking on output files instead of editing inputs, I moved out to the actual source code directories.  Did the equivalent edits from above to the source.  Then I adjusted various CMakeLists.txt files to include the new directory.  I modified the lib/basic_header.s to use 7181 (1c0d) in the SYS command.  Ran ninja to rebuild and I get

```

[0/1] /usr/bin/cmake -S/home/mac/games/llvm-mos-sdk -B/home/mac/games/llvm-mos-sdk/build

CMake Error at cmake/modules/AddObjectFile.cmake:10 (add_library):

  add_library cannot create target "basic_header" because another target with

  the same name already exists.  The existing target is created in source

  directory "/home/mac/games/llvm-mos-sdk/commodore/64/lib".  See

  documentation for policy CMP0002 for more details.

Call Stack (most recent call first):

  commodore/128/lib/CMakeLists.txt:6 (add_object_file)

```

I'm not much of a CMake or ninja user, just following steps and extrapolating what I can.  I don't quite see why the 128's basic_header is conflicting with the 64's basic_header.  They should be in separate directories.  But they only have one target machine under each "brand" of computer, so there may be some assumption buried somewhere that I'm just missing.  I think I looked at all the CMakeLists.txt from the root down and I can't see it, but that doesn't surprise me, really...

I, also, don't understand why CMake doesn't recognize that they have different paths.  However, I worked around it by renaming the new header -- output -- file to "cx16_header".  (It needs to be renamed in both a CMakeLists.txt file and the link.ld script.)

*SMH*  D'oh!  

Thank you for that...  Just got jammed into my mental rut...

OK, all four platforms at least build and link now.  They load and (except for the VIC) have the correct BASIC SYS command waiting.  Now I just have to be more careful about linker files and where I'm placing my fonts and graphics and where the stack goes, and so forth ('coz they CPU JAM "immediately" if I run them ? )

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.