From: groepaz (groepaz_at_gmx.net)
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 www.webnova.de/rust/silversurfer/ 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, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-02-12 16:48:08 CET