Denial

I'm finally putting out a call for help.

Over the past few years I have been trying, on and off, to get some code that I was working on prior to Uz passing the CC65 maintenance on.

Initially I had issues with actually building the program, as the config file changed, and way custom startup code changed. But after looking at the examples of others, I finally got my program to build again. The problem was that it no longer functioned correctly.

I think I've narrowed the problem down to the cprintf() function. Now I know you're going to say don't use that as it bloats the code, but I've been using it to print out debug information as I'm developing.

Has anyone else encountered a problem with using cprintf() in VIC20 programs?

As far as I can tell, by debugging within VICE, the self-modifying code that formats the different data types is not jumping to the correct location and hanging or exiting the program early.

Any ideas?

Hawk

I don't remember having a problem with cprintf (although as you say it bloats the code so I stopped using it quickly).
Is it one of the cprintfs at the bottom of lesson2.c that is failing? Which one?

Thanks for the reply Kweepa.

If I uncomment them, it's the first one the code comes across in main().

This code is a mishmash of ideas that I've been working on for the past few years. It was me learning how to program for the VIC-20 hardware.

i very much doubt cprintf is the problem - it works fine

however, there is a lot of things in this code that could cause problems.... the custom crt0 is one, and various other direct memory accesses - a lot of things changed in cc65 during the years, so you'll probably have to review all the custom stuff and adjust it accordingly.

i'd get rid of the custom crt0 first, and use the one that comes with cc65, and disable the custom stuff one by one. besides that i dont see anything that shouldnt work fine

Thanks for the pointers, I think I worked out what the problem was...either way I got it working again.

I think the problem was that I didn't leave a memory block in the CFG file for the relocated screen RAM, so when I wrote to the new screen I trashed the program. I found the problem by looking at Robert Hurst's Quickman CFG file.

My program is now back where it started umpteen years ago. Now I'm back to deciding how to output to the screen...direct memory access, or use cc65 library routines. I've discovered that you can't use both as they give you different results.