Commander X16

Regarding the name, I wouldn't think it would cause backlash if it's clearly labeled Lightweight and UNIX-like, but UNIX is still a registered trademark. Don't know if this will affect how the word can be used?

Edit: I just remembered what GNU stands for, so I guess it's ok to use the word as long as no claim is made that the product is UNIX.
Maybe if "lux" stood for "Lightweight UNIX-Like Command Shell"?

In the Linux world there are projects like BusyBox for tiny/embedded systems that supply tiny versions of most UNIX tools. I think it would be understood that a tiny UNIX-like shell for the x16 would be even more tiny.

Too bad you can't call it "tux"

Dacobi wrote: ↑Tue Aug 15, 2023 6:40 am Too bad you can't call it "tux"

I am going to be up at night trying to figure out a way to call it that, and have a logo with a child sized penguin.

Naw, I'm happy with "lux" and I'm 99.9% sure all I have to do is have:
"UNIX is a registered trademark of The Open Group" in the docs to make the Open Group happy.

I think you're fine naming your project "Lux", and then describing it as "a Lightweight Unix-like Command Shell" (note "Unix-like", not all-caps).

What would cause problems is, if you were literally trying to include the "UNIX" mark (all-caps, which is the registered trademark) as part of your project's name, like if your project were literally named "Lightweight UNIX for Commander X16".

The phrase "Unix-like" (again, not all-caps) seems to be accepted (at least historically and right now) as a non-trademark-infringing way to describe software as such, and the community sometimes goes even farther with "*nix", "Un*x", etc.

DragWx wrote: ↑Tue Aug 15, 2023 5:03 pm I think you're fine naming your project "Lux", and then describing it as "a Lightweight Unix-like Command Shell" (note "Unix-like", not all-caps).

What would cause problems is, if you were literally trying to include the "UNIX" mark (all-caps, which is the registered trademark) as part of your project's name, like if your project were literally named "Lightweight UNIX for Commander X16".

The phrase "Unix-like" (again, not all-caps) seems to be accepted (at least historically and right now) as a non-trademark-infringing way to describe software as such, and the community sometimes goes even farther with "*nix", "Un*x", etc.

Absolutely. Open Group specifically says use of the word "unix" must be in the generic, so I'm going to go with "Unix-like" in the name. I need the capital U to tie into the acronym, but it must in general be... generic and non specific. I'll also explain upfront what the terms mean in the project to avoid having people think EVERY unix command would be magically implemented, or something equally ridiculous.

An important detail... This isn't solely for the X16. I'm just using the X16 as a development platform because it's perfect for that. It has the 65c02, the VERA module, and a fat32 implementation. Ultimately, I want to make a dedicated hardware platform for it that makes better use of FPGAs and has a more base RAM centric memory map. But there are a LOT of learning curves I can get through with this hardware first.

As I increase my understanding of the X16's KERNAL and fat32 implementation, I also plan to "pay it forward" by contributing to the X16's continued development and maintenance. Up to this point, I haven't felt sufficiently confident in my understanding of the system to do that, but that is changing very fast.

I get the studying to "PAY IT FORWARD". I've got about 5 more projects planned in the Back of my Mind.

If I do get through all of those I'm looking at taking a charge at PAS65 and making it more of a viable Development
tool for the X16. I just absolutely took to Pascal when I discovered it in the 90's but it's kind of put me off that
there doesn't seem to be any active Development on PAS65 for X16. (In my dreams FPC should output 65C02 code)
but the FPC thing is really kind of a fantasy. You would have to Neuter it severely to get any code small enough.

Just musing......... I'll see where it goes. I've got enough projects in my Que for probably at least 1 year.

I've been working on optimizing the code for my game, which gave me enough free memory to move my PCM buffer from BANK_RAM to normal memory and doing so removed the "pop" I'm hearing, when the menu is first loaded, when I first launch my game.
Also it only happens when you start the game, not when finishing a race and returning to the menu.

The only code change is: to and then in my load_audio function "sample_point" is no longer set to BANK_RAM.

Can anyone tell me why this would happen?
I'm now on r44 btw.

I'm grasping at a straw, here... but:
Are you loading stuff when you start the game?

Of course that question is rhetorical, when else are you going to load stuff? You could be running afoul of The kernal's need for RAM bank 0 when it needs to access the SDcard.

As a test, start the music after the loading is all done.

I should probably have clarified this, but from my codes perspective there's no difference between the first time the menu and intro music are loaded and then returning to the menu from a race.

I'm not home right now, but when I'll get back I'll try and change the order in which things are loaded.

Edit: Also I can't remember off the top of my head, but I'm pretty sure I only start PCM playback after I enable AFLOW interrupt, which means after everything is loaded from SD card.

Edit2: However, there's a good chance that I open the PCM audio file and fill my buffer/the FIFO before I load the bitmap and font sprite, I'll check when I'll get back.

It doesn't make any sense... Opening the PCM file and filling the buffer and FIFO is the last thing I do after loading the other files from SD card and before enabling the Display output, but the "pop" still happens, only the first time the menu is loaded.

Are you fìlling the PCM buffer before setting the audio rate? If you set the audio rate with no data in the buffer you'll hear a pop.