Re: [cc65] cc65 and VICE

Date view Thread view Subject view

From: Ullrich von Bassewitz (
Date: 2000-01-20 16:19:26


> I encountered a problem: VICE (Version 1.2) under Win32 complains
> about an unexpected token at the end of each line of the token file.
> It's CR/LF sequency which VICE does not like, since VICE always uses
> Unix style line terminator (LF); so, currently, the label file is not
> usable at all unless the file can be converted to unix style (which I
> did for testing purposes with the help of Linux, and it worked well).

I would say that this is a VICE problem, not a ld65 one. The label file
and all other macro like files in VICE *are* text files, so VICE should
treat them as such and expect the correct line termination for the
operating system it runs on. If VICE expects a simple LF, it is not
possible to generate a macro or label file using a text editor under
Windows, something that would be useful.

The VICE people may of course have a different view of the problem:-) I
will send them a mail, they are usually very responsive.

> Is there an option I did not find or is it even planned to generate
> further debugging information, i.e., a mapping of code lines to
> memory addresses, so that there would be the option of doing something
> like a source level debugging? (Yes, I know, VICE lacks the functio-
> nality 'til now, but I want to know of cc65 itself does something like
> this)?

Here is what I have currently in mind (this does mean that I have put some
thoughts into it - it does not mean that the features will be in one of
the next versions):

  * I will add a type for the generated symbols. This will allow a
    debugger to distinguish between memory labels, zero page locations and
    other constants. Currently all debug symbols are equal, and VICE uses
    the first symbol it finds to display memory reference - this often

  * Symbols will have an associated range, that says for which code
    addresses the symbol is valid. Currently local symbols are placed in
    the global address space and are visible from eyerywhere. This leads
    to a symbol table pollution.

Both things are possible with the current compiler, but they are not
supported by VICE. So, to make them usable, I will have to propose an
extension to the VICE monitor.

  * Write a debugger that resides on the PC, has knowledge about all
    debugging information and connects to the real machine via a serial
    link using a small cc65 module that has to be linked to the
    This would mean that it is possible to develop the debugger
    independent of VICE, and that it is possible to support all platforms,
    not only the platforms that are emulated by VICE (the Plus/4 comes to
    mind, since it already has a 6551 UART).
    If have put some work into serial support lately to lay the ground for
    such a debugger, but it is a lot of work, so don't expect this to come
    soon. Currently it's just an idea.

A source level debugger (as suggested by you) will not be possible with
the current compiler, since the RD parser does not generate an abstract
intermediate code. This means there is no chance to keep the debug/line
information intact while the optimizer works on the generated assembler

> I hope I will enjoy cc65.

I hope that, too:-)



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET