Re: [cc65] library header bug correction - and some compiler hazzle

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-02-12 15:56:46


Hi!

On Tue, Feb 12, 2002 at 12:08:52AM +0100, groepaz wrote:
> i found the time to sit down on my cc65 related stuff again and while
> i was writing some other little example proggy (good old "fire"
> effect) i noticed a little error in the _sid.h headerfile....
> corrected version listed below.

Thanks, I've added the missing register.

> another thing is, that i kindof got sick of hunting down errors in my
> code which turn out to be compiler bugs/limitations on the long run
> (no offence ullrich, other than that i *love* the cc65 package!) and
> so i started porting the testsuite that comes with the lcc
> compiler....

This is a good idea and I would love to have such a test suite myself.
Copyright may be a problem, at least if the test suite is to be distributed
together with the cc65 source.

> however, i also thought about knocking up a very very simple
> c64-emulator-alike-thing which would be basically a cpu-core plus
> memory emulation (just ram/rom, no i/o) so it can run programs that
> dont depend on the hardware (like the testsuite).

I had that idea myself for some time, but since I'm already wearing too many
hats, I haven't started such a project. But since I've already thought about
it, I have a few suggestions:

  1. Write it in clean ANSI C and keep it portable.

  2. Make it very limited. Just cover the features not covered in enough depth
     by the existing emulators. While such a 6502 emulator would be useful for
     many things that are difficult with the current machine specific
     emulators, there is no sense in duplicating code and effort. "Limited"
     would also mean no support for illegal opcodes, time synchronisation or
     other fancy stuff.

  3. Within it's limited range, make it configurable. Allow ROM and RAM
     regions and the address of the "kernal trap" subroutine to be specified
     in a config file. Design the config file syntax to be extensible. This
     would also make it possible to offer limited support for simple 6502
     peripherials later.

  4. This emulator system could be a separate cc65 target machine with library
     support.

Apart from being able to use a real test suite, and test platform independent
code (like heap routines or similar things), this sort of emulator would be
useful for something I'm missing a lot: Source level debugging. The current
problem is, that none of the existing emulators has such a feature, and, since
the feature is not really needed for a C64, Atari or [insert your favourite 8
bit machine here] emulator, the chance to add it and keep it current is pretty
low. Besides that, having source level debugging in VICE would not help the
Atari or Apple people.

So my idea is to add

  5. very, very limited debugging support. That means,

       a. Allow to start the program at a specific address.
       b. Allow to interrupt the program (assuming it goes berserk).
       c. Allow to read and write memory cells or ranges.
       d. Add up to 10 breakpoints.

     d. could actually be solved by using c. (insert a BRK instruction plus
     some code), but it simplifies things if d. is an extra feature.

All these things should be done using a command interface. The command
interface would be very simple, unfriendly, and optionally routed via a TCP
socket or a similar mechanism. This in turn would make it possible to write a
front end that is user friendly, may have a GUI, and allows source level
debugging while talking to the emulator over the socket (I would prefer a TCP
socket over some other mechanism, since this would work on any platform, even
on Windows, which some people seem to prefer for reasons unknown to me).

Having separated the frontend and the backend (the emulator), one could for
example attach the frontend to a slightly modified version of Markos prlink to
debug programs on a real machine. Or, as another example, the VICE people may
decide to add such an interface to VICE, so the front end could be used for
debugging programs in VICE.

As an additional advantage, people writing code for embedded hardware could
use this emulator at least partially to test code.

This were the reasons, why I've thought about writing such a simple emulator.
Your reasons may vary, and you may of course choose to ignore anything I
say:-)

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de 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 : 2002-02-12 15:56:53 CET