Commander X16

Please freeze the design. Clean up whatever bugs you need to squash, declare victory, and call it the finished Commander X16, warts and all.

If you want to make updates to the ROM later to enhance the system in some way, great. But please, for the sake of the programmers, please stop making breaking changes. Add stuff which adds value if you want but don't break stuff that's already in place.

I've been programming hard for this computer since David Murray announced it way back in 2019. I've been making video demos and a machine language editor and a fairly complex SimCity type game set on an asteroid and a 3d first person shooter video game engine and shared a file with a set of functions for doing fast 8 bit math and another file for doing fast 16 bit arctangents.

With the announcement four years into the project that we'd be using the 65816 too, and the latest update to r47, most of my code doesn't work anymore.

I'm in the middle of rewriting my editor to handle both 65c02 and 65816 programming using either physical processor. It's going to take me months, as I can only work on this in my spare time and I have a full time job. After that I can return my attention to the game engine and the other game and so forth.

Every time there is a breaking change (like having to add @: to a filename if you want to overwrite; has that change really added value to the X16, or simply made it incompatible with modern DOS? I digress), I get set back by months.

The only reason people can still program for the C64 and other retro machines all these years later is that the ROM and design haven't changed. Code that I wrote for my VIC20 30 years ago will still work if I fire up the machine. Code I wrote for the X16 six months ago, won't.

Right now, the X16 is the best 8 bit computer ever made. It's great. So please, stop, and declare success.

Adding @: to a filename to make it overwrite made it compatible with legacy usage of other Commodore machines, which would NOT overwrite an existing file, and instead would give you a "FILE EXISTS" error. You can hook up a 1571 or 1581 to an X16 and it'll behave that way, so for the sake of consistency the SD card is now set up to behave that way as well.

here's a spicy.
consider it a bliss that it's evolving.

Sound system got multiple major -bug- features that still got push backs, with priority level as low as.

Not a complaint, an observation this is.


I fully understand the where would it ends fear.
The fear of eternity, how natural.
but it'll come to the final line eventually, as how things would.
Whether you like it or not, or push for it or not.
In the fullness of the time.
As some said it's the end of a system once updates are stopped, one's phone for example plays a great roles in setting this mind set into people.
it would be vital to realise this fact.
Added that, if updates were stopped, how would people settle for differences, would it splits the party making people move to projects that're still open?
These dangers repercussions would need to be considered.
besides, it need to point out the times of these changes is not as frequent as you think, it's just stacked.



I think before all that, we should think about how to mitigate this very real problem we're facing.
A auto bumper helper? maybe?
Or ROM downgrader maybe?

Or it's time to setup a inter-departmental committee to research all the possible.......

I need to lay off the Yes Prime Minister.'........

kelli217 wrote: ↑Mon May 13, 2024 9:47 pm Adding @: to a filename to make it overwrite made it compatible with legacy usage of other Commodore machines, which would NOT overwrite an existing file, and instead would give you a "FILE EXISTS" error. You can hook up a 1571 or 1581 to an X16 and it'll behave that way, so for the sake of consistency the SD card is now set up to behave that way as well.

Great, a case can be made that the change improved the machine. I'm not arguing against further improvements, additions to BASIC, etc.

I'm asking them to stop making breaking changes. We're coming up on 5 years of development. At some point the perfect becomes the enemy of the good.

Ed Minchau wrote: ↑Tue May 14, 2024 10:41 pm

kelli217 wrote: ↑Mon May 13, 2024 9:47 pm Adding @: to a filename to make it overwrite made it compatible with legacy usage of other Commodore machines, which would NOT overwrite an existing file, and instead would give you a "FILE EXISTS" error. You can hook up a 1571 or 1581 to an X16 and it'll behave that way, so for the sake of consistency the SD card is now set up to behave that way as well.

Great, a case can be made that the change improved the machine. I'm not arguing against further improvements, additions to BASIC, etc.

I'm asking them to stop making breaking changes. We're coming up on 5 years of development. At some point the perfect becomes the enemy of the good.

I'm a relative late comer Ed compared to you. I downloaded the r42 emulator at at the start and almost immediately upgraded to r43. I'm sure there were some issues there, but they really didn't effect anything I was coding at the time. First time I had issues was an improvement not a breaking change with the addition of MCIOUT at r45. I haven't seen any breaking changes between r45 and r47 so I think they are kind of onboard what your saying now.

ahenry3068 wrote: ↑Wed May 15, 2024 12:08 am I haven't seen any breaking changes between r45 and r47 so I think they are kind of onboard what your saying now.

Well, all software has to be compatible with both the 65c02 and the 65816 now. That's an enormous change. And my r44 Ben Hur video demo doesn't work in r47, so something in VERA changed, which I'm not going to be able to sort through for a while as I rewrite my editor. I'm not quite all the way back to square 1, but it's close.

Ben Hur is running fine on my r47 emulator. I'll give it a spin on hardware tomorrow.


I think I might have found your problem. If your loading the new Menu program it puts the machine in ISO mode.
Your video doesn't display properly in ISO mode only in PETSCII mode. So a configuration problem not
a VERA problem. You could idiot proof your code with two CHROUT's at the beginning restoring PETSCII/UPPER mode.

You need to send $8F then $8E.

I think you can pretty much ignore the 65816, at the very least. The X16 is always going to start up in emulation mode even if it's running on a 816, so you just need to avoid the rmb/smb/bbs/bbr instructions, which i have never used in my experience programming and werent on the original 6502 anyway. I think someone might have written some macros that recreated their functionality anyway, but I can't find them at the moment.

VERA changes can be a pain tho, admittedly

Replacement macros can be found here:
https://github.com/X16Community/x16-doc ... structions