cc65 wait_vsync breaking between r40 and r41

[totodilespy]

Hi,

when I switched to using r41  from r40 my programs that used cc65's waitvsync started freezing on the first frame (presumably because the function never exited).

Looking at the functions source code

I would think that maybe the jiffy counter got disabled between versions?

If it helps, TIMER is = $A03B in banked RAM

 

 

The help is greatly appreciated

[ZeroByte]

Here's what you do:
in C files that need waitvsync() - make this declaration:
extern void __fastcall__ vsync();

Then include this as an assembly source: (e.g. vsync.asm)
RDTIM := $FFDE

.export _vsync

.code
.proc _vsync: near
  jsr RDTIM
  sta lastjiffy
keep_waiting:
  jsr RDTIM
  cmp #$FF
  lastjiffy=(*-1)
  beq keep_waiting
  rts
.endproc

 

[desertfish]

cc65 is reading private kernal variables here and these change every rom revision. It's not a good solution.

You should roll your own routine for now, I think.  Depending on your exact needs, you could perhaps use the WAI instruction or use the official RDTIM kernal routine to access the jiffy counter.

Edited August 5 by desertfish

[ZeroByte]

I really should make a PR to cc65 to replace the source for waitvsync() with this code, which will work forever, as it uses the standard Kernal API.

[Edmond D]

On 8/5/2022 at 2:25 PM, ZeroByte said:

I really should make a PR to cc65 to replace the source for waitvsync() with this code, which will work forever, as it uses the standard Kernal API.

Yes, you should. Thanks for doing it.

[ZeroByte]

On 8/5/2022 at 4:34 PM, Edmond D said:

Yes, you should. Thanks for doing it.

I've been avoiding monkeying around with my installation of cc65 since it often breaks when things change and once I get it working, I'd rather not add the compiler to my list of headaches. However, you've motivated me to get involved.

PR pending to update the source with future-proof compatibility.

If they accept it, I may move into making a set of CommanderX16-specific Kernal call wrappers e.g.:
int __fastcall__ cx16_k_macptr(unsigned char count, void* buffer);

[totodilespy]

On 8/5/2022 at 5:24 PM, ZeroByte said:

Here's what you do:
in C files that need waitvsync() - make this declaration:
extern void __fastcall__ vsync();

Then include this as an assembly source: (e.g. vsync.asm)
RDTIM := $FFDE

.export _vsync

.code
.proc _vsync: near
  jsr RDTIM
  sta lastjiffy
keep_waiting:
  jsr RDTIM
  cmp #$FF
  lastjiffy=(*-1)
  beq keep_waiting
  rts
.endproc

 

Yeah, this is basically the routine I ended up writing, except with the cool trick.

[Edmond D]

On 8/5/2022 at 3:54 PM, ZeroByte said:

I've been avoiding monkeying around with my installation of cc65 since it often breaks when things change and once I get it working, I'd rather not add the compiler to my list of headaches.

Completely understandable. I didn't realize that cc65 could be so fragile; having a working stock platform is important. Perhaps a virtual machine for extending cc65 would be the way to go. The library would be a nice addition, but might become a timesink of epic proportions.

I've yet to dive into cc65 development; there's a greenhouse I have to finish first. It's kinda like coding, in that I design, then build, then design around the flaws that I've constructed.  If I could only easily "undo" things I'd be finished last year when I started. Perhaps it's akin to the CX16 hardware development, but the first greenhouse HAS to be made to work, a "do-over" is just not practical. Sorry for the diversion of topic - 3 AM sleep issues. 

[TomXP411]

On 8/7/2022 at 3:40 AM, Edmond D said:

Perhaps a virtual machine for extending cc65 would be the way to go. The library would be a nice addition, but might become a timesink of epic proportions.

Actually, I think it's being done the best way possible: anyone can download the libraries and compile their own, fixing the issues that spring up from version to version. 

The emulator includes symbol tables that list all the labels used by the operating system. If an entry point gets moved, you can look it up in the symbol table and fix the library. Or you can even re-write routines to use the fixed, public APIs where needed. That stuff is usually fairly simple to do. I have written a few system access functions for both cc65 and Kick C myself. They are actually all very simple, and usually just a wrapper for the KERNAL functions. 

Here's the source for cc65: https://github.com/cc65/cc65

 

[ZeroByte]

On 8/5/2022 at 4:34 PM, Edmond D said:

Yes, you should. Thanks for doing it.

They've merged my change - waitvsync() shall henceforth work for all future revisions of X16 emulator and Kernal.

I also spotted an oopsie in cx16.h and cx16.inc that assigns YM2151.status  to $9F40 instead of $9F41. I made a PR to fix that too. Minor, but hey, they're welcoming submissions, so I'm happy.