Switching to R43 frustration

[ch4rl3sb]

It took me two days to find the changes from R38 to R41 that weren't listed in the changes log when I switched.
Then I just found out we switched from github/commanderx16 to github/X16community because I was hearing people talk about r43 and could not find it. I don't know how long I was out of the loop for that.

Now, I can't figure out what changed to break my code from r41 to r43. It's been almost two weeks and it doesn't seem to be stuff in the changes list. I'm getting frustrated and demoralized and feeling stupid and not wanting to code anymore.

[desertfish]

Changes like the move of the git repositories, stuff regarding the forum, and the releases of the emulator + roms are always detailed in the "Official Announcements" forum. So it helps to closely scrutinize that one.

As for changes that break your code, the maintainers do try to make a changes list but it is sometimes a good idea to check the closed issues or merged PR's on github too if you want all the details.

That said, without any specifics on what doesn't work anymore in your code it's impossible to assist..... please help us to help you

[StephenHorn]

It took me two days to find the changes from R38 to R41 that weren't listed in the changes log when I switched.
Then I just found out we switched from github/commanderx16 to github/X16community because I was hearing people talk about r43 and could not find it. I don't know how long I was out of the loop for that.

Now, I can't figure out what changed to break my code from r41 to r43. It's been almost two weeks and it doesn't seem to be stuff in the changes list. I'm getting frustrated and demoralized and feeling stupid and not wanting to code anymore.

The move from commanderx16 to x16community was regrettable, but the owner of commanderx16 had been incommunicado for an extended period of time with no ETA for a return, and critical issues were being held up as a result. I've used what power I have to point folks from the old repos to the new ones, but there are repos under commanderx16 that I can't touch. I'm really sorry this has been a point of frustration, I think we're all disappointed that the commanderx16 repo failed "the bus test".

As for unlisted changes and breakages moving forward... So far, it's been our practice to only list version changes to the emulator code itself; not kernal, BASIC, or other ROM changes. Perhaps we should consider adding ROM changes to the list when we make a new release, because I suspect these are the changes that weren't listed.

Can you share what code is failing, or describe what you're trying to do that isn't working? We might be able to help you get back on your feet with r43/latest.

[ch4rl3sb]

The things that are happening at the time are keyboard scan, joystick scan, printing the intro text and checking the flag from the vsync irq. I shut them off one at a time, and it seems to be related to the irq.

[ch4rl3sb]

"So far, it's been our practice to only list version changes to the emulator code itself;"

One of the previous issues I had was KERNAL commands. The new ones have documentation, but the existing ones from commodore 64 are just listed: no indication of what info to put into the parameters, or what will be returned in each parameter. i.e. how to use it.
It took me hours and hours to find any info online to use just a couple of them. and I couldn't find any comprehensive list for them all. (Edit: after posting this, I managed to find a link for these that I wasn't able to find over a year ago when I started.)

And the math library: everything uses FACC, but there is no indication what that means. It seems to assume I already know. I tried to study it, I have no idea how to use any of it.

[desertfish]

The positive thing is that the CBM / C64 kernal routines have been unchanged for around 40 years now and will remain so forever

But yeah, it is a known problem that the Commander X16 documentation is lacking here.
However, because those routines are compatible with the original CBM/C64 kernal, you can (should) use the old resources from the CBM line of machines to see what they're doing.
Personally I use several resources for this:
- https://sta.c64.org/cbm64krnfunc.html
- http://unusedino.de/ec64/technical/proj ... g_c64.html
- https://www.pagetable.com/c64ref/c64disasm/

The Floating point routines are taken from the C128 FP library and that has its own documentation as well: http://www.zimmers.net/anonftp/pub/cbm/ ... 7_Oct).pdf

which, by the way, *is* linked in the commander x16 documentation page about the Math library. (https://github.com/X16Community/x16-doc ... Library.md)

[ch4rl3sb]

which, by the way, *is* linked in the commander x16 documentation page about the Math library. (https://github.com/X16Community/x16-doc ... Library.md)

Have you read that? Can you tell me where it says what FACC is and how to use it?
I did read a lot of that a year ago. And it still didn't tell me the one simple thing that you need to know to use it. What FACC is.
I looked at it again today and found "a" function that when interpreted, gives you a clue.

I have a couple hours in an evening a few times a week to tinker on a hobby. I didn't plan to study for a couple years to become a software engineer. Even though I spent weeks with Matt Heffernan's assembly tutorial series and many more pouring over the assembly opcodes, (http://www.6502.org/tutorials/6502opcodes.html#STA) I gave up on assembly development because it was tedious, and now I just want to write a few routines in assembly and do the rest in C where I'm comfortable.

Now, one of the *first* routines I wrote in assembly, (about 2 years ago,) was to set a flag when the irq was triggered.
"For applications to remain compatible between different versions of the ROM, they can rely upon:

the KERNAL API calls at $FF81-$FFF3
the KERNAL vectors at $0314-$0333"

And it's worked until I tried to switch to R43. Does any one have a clue why that's changed? I've tried changing the zero page location I store the flag.

I've spent a lot of time setting up Atom, Cygwin, using Bash, to have an environment to work in, but I don't understand those systems. (Except maybe Atom.) And now I'm probably going to have to figure out how to set up a git repository or something because I almost lost all my code to a crash a month ago. But I don't want to spend my time learning those systems. I just want to set up a useable platform to support writing some C code that I basically don't have to touch afterwards so I can do some hobby programming. I don't know how to use the Monitor or Debug, but I haven't found basic documentation to understand them, I've tried to find it.

[TomXP411]

which, by the way, *is* linked in the commander x16 documentation page about the Math library. (https://github.com/X16Community/x16-doc ... Library.md)

Have you read that? Can you tell me where it says what FACC is and how to use it?
I did read a lot of that a year ago. And it still didn't tell me the one simple thing that you need to know to use it. What FACC is.
I looked at it again today and found "a" function that when interpreted, gives you a clue.

That's the Floating Point Accumulator, as documented at C128 Developers Package for Commodore 6502 Development.

This link is present in the page you mentioned, so you must not have gotten down to the Notes section. I agree that this is a poor design, so I'll move this reference link to the top, to explain that the resource material is in the C128 book.

[ch4rl3sb]

That's the Floating Point Accumulator, as documented at C128 Developers Package for Commodore 6502 Development.

I was talking about reading the C128 Developers Package!

It would have been nice to have known what it was when I was reading the dozen or so functions without knowing what they were and reverse engineering what the FACC was over hours. If Something had said, "This is the Floating Point Accumulator and you don't have direct access to it's value, the functions allow you to load it and manipulate it." Then I would have read those dozen or so functions and understood what they were doing immediately!

I'm talking about "barriers to entry," here. Those things not explained that make understanding overly complicated when a simple example at the beginning would clear it up instantly. I've been watching Josh "Strife" Hayes videos on MMO's and replaying older games, and he talks about the "barriers to entry" for playing games when the interface, or game play isn't intuitive. The "Quit" moments when people aren't having fun and leave. And it applies to a hobby of programming as well. This is a hobby computer that anybody should be able to work with and understand with "a little" work. We should try to make the barriers and quit moments as minimal as possible. Or people will leave when it becomes too frustrating to figure out and you'll be left with a small group of hard core fans who are all practically software developers who make everyone fight to learn it like they did. this is a game reference but it fits here as well: "It get's better 100 hours in!" and then they complain that no one is making content for it with them when all the people who wanted to left because the start was so difficult.

[StephenHorn]

I'm talking about "barriers to entry," here.

If I may offer some folksy wisdom from decades spent in my craft: It is very easy for people, who are already familiar with an otherwise inscrutable concept, to completely glaze over its difficulty after years or even decades of experience with it. In the case of retro computing this is literally multiple decades, and even some of the more liberal definitions of many decades.

I've written documentation in the past that folks have found useful for the X16. (I was the author of the briefly semi-famous (Unofficial) VERA Documentation, which is now long out-of-date.) But unless I were writing the math library documentation myself, from scratch, with an eye towards complete and total newcomers to the field of programming as a whole, I would still have likely glazed right over the FACC. This is because my own multiple decades of experience made the concept completely obvious. That isn't meant to say it's obvious to everyone (or even should be), only that my own brain was already so familiarized with the idea that it didn't skip a beat. Knowledge and experience transferred with total transparency.

I'm sorry you struggled to figure out the FACC for a long time, and I wish you'd asked about it here on the forums or the Discord server sooner. Please don't hesitate to ask questions: Our first rule here is "Comment with kindness", so we take our positive attitudes and helpfulness seriously. And please feel free to help us identify documentation that needs to be written, or that is difficult to parse and understand. We're too close and too familiar with the project and its inner workings, we are going to miss things without help from folks who need the documentation the most.