Jump to content
  • 0

cc65 wait_vsync breaking between r40 and r41


totodilespy
 Share

Question

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

image.png.3cbe33daaea9d76b60f54bb9f5d81041.png

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

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0

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

 

Link to comment
Share on other sites

  • 0

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 by desertfish
  • Thanks 1
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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);

  • Thanks 1
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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. 🥱

Link to comment
Share on other sites

  • 0
  • Super Administrators
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

 

  • Thanks 1
Link to comment
Share on other sites

  • 0
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.

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

  • 0
On 8/10/2022 at 12:52 AM, ZeroByte said:

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.

Hello ZeroByte - very very new to this - how do I call waitvsync() what h file do I include ?  if i search in cx16.h I cannot find this - working with V 2.19

And I want to check my logic as well.

I use waitvsync so I can set timing in my game - so my game will not run as fat as the CPU but as fast as the screen can draw?

thx

Link to comment
Share on other sites

  • 0
On 10/23/2022 at 12:51 AM, Collin said:

Hello ZeroByte - very very new to this - how do I call waitvsync() what h file do I include ?  if i search in cx16.h I cannot find this - working with V 2.19

And I want to check my logic as well.

I use waitvsync so I can set timing in my game - so my game will not run as fat as the CPU but as fast as the screen can draw?

thx

wiatvsync() comes with cbm.h

And yes, it's typically used as a quick and easy way to time software with the 60hz screen refresh, for instance some animation that should only update once per frame, your loop can have waitvsync() in it to ensure that it only executes once per 60hz frame. It's less useful for things like avoiding tearing because your code won't get to execute until after the VBLANK interrupt has finished which may or may not be after the VBLANK period is over (i.e. into visible raster time).

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use