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

Date view Thread view Subject view

From: groepaz (
Date: 2002-02-12 16:47:43

Hello Ullrich,

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

mmmmh, dunno about that (nor do i really care :=P) but i took that
testsuite from some lcc-distribution .zip (jolze's 65816 port
actually) so i guess its under gpl aswell..... i have seen some parts
of that suite (eg the floating-point test "paranoia") in other
testsuites aswell so i dont think its much of a problem.

however, since the testsuite is probably not interisting for most ppl
anyway (except taking its programs as examples for own work) it
shouldnt hurt to distribute it seperatly anyway. (actually makes a lot
of sence, since i have wrapped all modifications required to compile
on cc65 in #ifdefs it may be useful for other "small c"
compiler-developers later on aswell.)

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

sure thing, all my tools are like this :o)

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

yes ofcoz, i am not willing to spend any time on a vic or sid or
whatever machine-specific emulation either..... i thought just about
taking an existing cpu-core (marat f.'s used to be nice) and throwing
the necessary ram/rom stuff around it. actually, we did this some time
ago for driving a simple sid-emulator on the psx....prolly i can just
take that code and recompile (dont remember how many psx-specific
hacks are in there though)

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

mmmmh yeah could do this aswell.....

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

mmmmh :=P THAT doesnt really make sence for me :=) how would that be
of any use (more than an emulator that behaves like an existing
machine that is) ?

thats actually one of the things i still dont understand with GDB....
that "simulator" target is just useless kindof :o)

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

sourcelevel debugging is one of the things i keep nagging the VICE
team with ;=P hehe

however, actually another project of mine is a retargetable debugger,
which WILL have support for sourcelevel debugging with cc65 (and
possibly one or two other c64 compilers/assemblers) some time in the
future..... look at if you want to
see how it looks like atm (win32 only atm though) .... this debugger
actually is also ment to feature that kind of "simpliest" emulator
sooner or later (so you can do so-called "ice breaker" debugging,
tracewalk etc)

oh btw, on that site is also the rs232 module i hacked for use with
the silversurfer...... polling mode, inefficient, and buggy :=P lol
(actually i didnt understand the api you defined in all its details
and so i made have done some things wrong...... my plain asm driver
works neato :o))

UvB> So my idea is to add

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

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

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

yeah except the breakpoint, thats pretty much the minimal requirement
for an emulator isnt it? :o)

"real" breakpoints are easily implemented though (and possibly also
good help to debug the emulator itself) so why not....

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

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

mmmh since my knowledge in programming any network stuff is less than
zero, some other guy gotta implement this :=P

the frontend/backend seperation is a good idea though i guess..... i
am just heading for a simple commandline-driven tool though, such
mechanisms are to be done from someone else than me :)

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

THAT is a good point (and answer for my question from above ;D)

now my question is, WHAT embedded hardware is that with a 6502 inside?
i know its still in use in some toys from asia, and i'd like to see
one :o) (and i bet it would be helluva funny to rip such a thing apart
and make it act dull by writing own software :=))

Best regards,

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 : 2002-02-12 16:48:08 CET