Author Topic: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...  (Read 31899 times)

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
I'm loving C::B, particularly its code completion system, which I haven't really found anywhere else in a "choose your own toolchain" setting.  Many thanks for that, because I just can't code anymore without parameter and member prompting.

For some entirely silly reasons, I've decided to do some goofing around with cross compiling to the C64.  I'm trying to satisfy my teenage self, who always wanted to make a Car Wars game for his (my) C64, but didn't have the skills or tools for it.  25 years later, I've got both (I hope  :lol:)

So, there appear to be two approaches I could take to get cc65 running under C::B.

1. cc65 comes with a compile and link tool called cl65.  Usage looks roughly like:
        cl65 -g -Oi -Ln project.LBL -o project.PRG main.c another.c more.c stuff.c
I tried wedging that under the Tools menu with this command line:
        -g -Oi -Ln${TARGET_OUTPUT_DIR}\${TARGET_OUTPUT_BASENAME}.LBL -o
        ${TARGET_OUTPUT_DIR}\${TARGET_OUTPUT_BASENAME}.PRG ${ALL_PROJECT_FILES}
The problem is that it passed my .h files in as well, and cl65 doesn't know what to do with those.  Is there a variable that I can use to pull out all of the .C files?  I'm not sure how such a "variable" would be expressible in the generic case, but C and CPP files are common enough that I thought it might be special cased.

This is probably the easiest to get working, but the least slick.  If all else fails, I could manually modify the tool parameters whenever I added or removed a code file (I don't expect to write a lot of separate C64 apps).  But however I do it, I have to remember to save everything myself first (which I'm notoriously bad at), and it appears I need to go through the menu instead of having a hotkey.  But that may just be issues of my complete newbieness with C::B.

2. I could make a custom compiler toolchain.  This should be much slicker.  So I've gone down this path:
    Compiler settings / Other options: -g -Oi
    Linker settings / Other linker options: -t c64 -Ln ${exe_dir}\${exe_name}.LBL
    Search directories: compiler and linker pointed at my cc65\include and cc65\lib directories, respectively
    Toolchain executables:
        C compiler: cc65.exe
        Linker for dynamic (and static) libs: ld65.exe
        Debugger: x64.exe (from WinVICE -- a C64 emulator with monitor/debugger built in -- uses the .LBL file)
        Make program: none
        Additional Paths: the path to WinVICE so x64.exe can be found.
So I try to build with that and I get: "cc65.exe: Unknown option: -c" and it aborts.  I see where the problem comes in, by looking through the (English) manual and seeing how the variables are used for compilation:
"3.5  Compile single file
$compiler  $options  $includes  -c  $file  -o  $object"
That -c appears to be hardwired into C::B and not adjustable through any of the config settings.  Is that correct?

I suppose I could make a batch file or some simple console app that would shuffle arguments around and discard the -c, but that's a moderate headache if there's a simple fix that I'm just not seeing.  I say "shuffle arguments" because I think cc65 needs the input file to be the last argument in the list.

Any help would be appreciated.  Many thanks,
DM

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7588
    • My Best Post
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #1 on: May 13, 2010, 06:32:27 pm »
Unless your Compiler is very much like an preexisting compiler setup you will need to write your own compiler code which is two files if I recall right.

The other option to get started quickly is to use an custom makefile option in C::B.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #2 on: May 13, 2010, 06:36:10 pm »
Thank you Tim.  I suspect that the "unlike other compilers" is my problem.  Where could I find docs for writing my own compiler code?  Are these config files, or scripts, or some kind of compiled plugin?

Thanks!
DM

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7588
    • My Best Post
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #3 on: May 13, 2010, 07:42:33 pm »
Thank you Tim.  I suspect that the "unlike other compilers" is my problem.  Where could I find docs for writing my own compiler code?  Are these config files, or scripts, or some kind of compiled plugin?

Thanks!
DM

Requires the knowledge and ability to compile Code::Blocks from SVN
In SVN Compiler plug-in folder you will find about two files for each compiler toolset find the simplest or closest and copy that one and rename the files.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #4 on: May 13, 2010, 07:56:03 pm »
What you can (should ?) try first is to copy the closest compiler (I guess it's GCC) and change some of the commands in "Settings -> Compiler and debugger... -> Other settings -> Advanced options... -> Commands"

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #5 on: May 14, 2010, 03:53:09 pm »
Thanks everyone, but especially jens.

Going through the Advanced settings, it was actually easier to set up than trying to set it up through toolchain executables and options (since those weren't designed for what I was trying to do.  I'm not complaining about the normal compiler setup stuff, I'm just trying to brag on the Advanced settings for being pretty slick).

My biggest problem was getting my cl65 parameters right (I'm entirely new to the cc65 toolchain as well), and then remembering that I'd set my project as a console app, so I needed to fix the "Link into console application" instead of the "Link into application".

Anyway, my projects now compile just fine.

My current problem is that I'm not sure how to set up the debugger command line so that it will fire up x64.  The command line is pretty simple, just "c:\WinVICE\x64.exe MyProg.PRG".  I thought that would be the default behavior if I just put x64.exe in the Debugger entry for the toolchain executables, but that doesn't seem to be working (or else, I'm failing to start the debugger and mistakenly telling C::B to run MyProg.PRG, which definitely won't work :) )

Any further pointers are still welcome.  Once I've got all the bits up and running, I'll post all the necessary settings, since Google has already indexed this thread for "cc65 CodeBlocks" searches.

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #6 on: May 21, 2010, 07:06:32 pm »
[Edited 5/24/2010 to add KeyBinder plugin usage]
[Editing again on 5/24/2010 to add output parsing suggestions]

OK, as promised, here are the steps I took to give myself a "C64 Development IDE on a stick" (a USB stick).  This looks long, but that's just 'coz I'm trying to be explicit about everything...  You also don't have to put it on a stick, but it should be fairly obvious how to modify this for a permanent installation (or just set it up this way on whatever hard drive instead of a USB stick -- there's nothing magically stick-ey about any of this)

1. Install Code::Blocks (make sure to choose KeyBinder under the Contrib Plugins during installation!) and cc65.  Download and unzip WinVICE somewhere.
2. Copy C::B directory onto your stick.
3. Copy cc65 directory onto your stick underneath your C::B directory (exact placement may not be critical, but you'll need to adjust your paths accordingly in later steps if you put it elsewhere)
4. Copy WinVICE directory onto your stick underneath your C::B directory
5. Locate default.conf in your user Application Data directory (c:\Documents and Settings\{My User Name}\Application Data\CodeBlocks\default.conf (for XP) or c:\Users\{My User Name}\Application Data\CodeBlocks\default.conf (for Vista and Win7)), and move it onto your stick in the C::B directory (same directory that has codeblocks.exe)
6. Run codeblocks.exe from your stick.
7. Use menu -- Settings | Compiler and debugger...
8. Pick a compiler, I used GCC.  It's not critical given the hackish way I set up my commands and ignored some of the built in variables...
9. Press the Copy button and name your new settings something like "cc65 for C64".
10. With "cc65 for C64" selected, press "Set as default" (your option -- may not wish to do this if you're actively using this C::B for other kinds of projects, but I'm focused on C64 development)
11. Go to tab -- Toolchain executables
12. Set the "Compiler's installation directory" to ${CODEBLOCKS}\cc65
13. For the actual paths, it doesn't exactly matter what you pick (I'm going to hardcode them into the commands -- if you feel like being nicer later, you'll need to be more careful here).  Only the "C compiler" and "Linker for {whatever}" entries will matter for these instructions.  I've set ld65.exe for the two Linker lines and cl65.exe for everything else.  The main thing is that whatever appears on these lines MUST be present in the ${CODEBLOCKS}\cc65\bin directory, or C::B will complain about a misconfigured compiler.
14. Go to tab -- Other settings (it's off to the right)
15. Press "Advanced options..." button
16. With "Compile single file to object file" selected, press the "+" button and add "c" as a file extension, then make sure it is selected.
17. [EDIT: This will work, but is a horrible habit to get started.  See later posts for the RIGHT way to do this.]  Set "Command line macro" to:  cl65 -c -g -Oi -I ${APP_PATH}\..\cc65\include -L ${APP_PATH}\..\cc65\lib -o $objects_output_dir\$file_name.o $file
18. You can repeat steps 16 and (a modified) 17 to add ".s" for assembly files, but I'm not using those, so I haven't tested it yet.
19. Change the "Command" droplist to "Link object files to executable"
20. [EDIT: Ditto on horribleness and suggestions to read later posts]  Set "Command line macro" to:  ld65 -v -t c64 -L ${APP_PATH}\..\cc65\lib\ -Ln $exe_dir\$exe_name.LBL -o $exe_dir\$exe_name.PRG $link_objects c64.lib
21. Repeat steps 19 and 20 for the other "Link object files to console/native executable", if you feel like it.  If not, just make sure that when you make new projects, you set your project type to "executable" instead of "console executable" or "native executable".
22. Click on the "Output parsing" tab.
23. Click on "Compiler error" in the listbox
24. In the "Regular expression" box, delete the first pair of matched parentheses () and the colon : that separates the filename from the line number.  Then you'll have to wrap some escaped parens \(\) around the line number phrase.  Or just paste this in: ([][{} \t#%$~A-Za-z0-9_:+/\.-]+)\(([0-9]+)\):[ \t](.*)
25. Click on "Compiler warning" in the listbox
26. Same idea, but keep the [Ww]arning part in place.  Here's mine: ([][{} \t#%$~A-Za-z0-9_:+/\.-]+)\(([0-9]+)\):[ \t]([Ww]arning:[ \t].*)
27. Click on the Others tab
28. I cleared the check for "Supports PCH", but I'm not sure that it matters...
29. Press OK to close this dialog, then OK to close the other dialog.
30. Use menu -- Tools | Configure tools...
31. Press Add
32. Set Name to "Run it" (your choice)
33. Set Executable to ${CODEBLOCKS}\WinVICE-2.2-x86\x64.exe
34. Set Parameters to ${TARGET_OUTPUT_FILE}
35. Set Working directory to ${PROJECT_DIR}
36. Set the radio buttons to "Launch tool visible detached (without output redirection)" the last option.
37. Press OK to close this dialog, then OK to close the other dialog.
38. Use menu -- Settings | Editor...
39. Scroll down to "Keyboard shortcuts" and select it.
40. Expand the Tools part of the tree ("Run it" should appear)
41. Click on "Run it" in the tree
42. Click in the "New shortcut" text box and type whatever key sequence you want to use

You should be set up now.  You can create new executable projects, compile and link them into .PRG files with the single Build command (defaulted to CTRL-F9 for me), and run the program in the emulator with the Tools|Run it menu.

As a side note, in WinVICE, I like to go into the Settings menu and turn ON "Save settings on exit" and turn OFF "Confirm on exit", and then go into the Options menu and turn ON "Double size", but those are all just personal preferences.

I'd be ecstatic to hear from other users who have better/slicker setups.  In particular, I'd like to get WinVICE working as my debugger, instead of as a generic "tool", so that I could press one hotkey and have C::B save all my files, compile them, and start up the program.  The problem seems to be that I can't keep C::B from wanting to inject some command line arguments into the debugger command line.  But what I've got here is still pretty nice, and C::B is great (thank you code completion).
DM
« Last Edit: May 24, 2010, 09:03:58 pm by DigitalMonk »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #7 on: May 21, 2010, 09:14:26 pm »
OK, as promised, here are the steps I took to give myself a "C64 Development IDE on a stick" (a USB stick).
Harhar! This is damn cool! 8) My first PC was a C128. This brings back memories... POKE 53280,XXX... POKE 53281,YYY :lol:
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #8 on: May 21, 2010, 09:22:47 pm »
My first computer was a VIC-20.  The first computer I had that I did any reasonable amount of programming on was my C64.  The first computer I had that I did any GRAPHICAL programming on was my C128 (thank you CBM BASIC 7.0 for adding graphics commands).

Now that I've got a C compiler and a nice dev environment, goofing around in free time has let me get a scrollable zoomable map (just a simple grid for now) up and running (or walking, I suppose -- that 1MHz 8 bit processor doesn't really run anywhere)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #9 on: May 21, 2010, 09:27:16 pm »
The first computer I had that I did any reasonable amount of programming on was my C64.
Same here. I even learned a bit assembler (well... you had to if you wanted to do something speedy). That was really fun but never turned out to be something useful. Today I own this:
http://en.wikipedia.org/wiki/C64_Direct-to-TV
That brings back the stories like e.g. Mission Impossible... you know... the game with the nice speech processor... :lol:

Oh dear... I guess meanwhile I am so off-topic that I am violating our own forum rules myself. ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #10 on: May 21, 2010, 11:45:20 pm »
So, to get ourselves back on the rails :roll: :

Is it possible in C::B or with the key binding plugin to assign a hotkey to an entry in the tools menu?  That seems like it would be very useful (in my case for starting the program), but I can't seem to find it in the docs.  Maybe I'm just blind, though...

Sometimes I see references to a KeyBinder plugin, but my install (8.02) doesn't seem to have it -- and I can't consistently find reference to it.

Offline DigitalMonk

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #11 on: May 22, 2010, 12:01:52 am »
Oh, I'll also point out that C::B's code completion doesn't seem to like the way cc65 sets up hardware registers.  cc65 defines a structure that overlays the memory mapped registers (for instance, in _6526.h you'll find the structure definition for __6526, which is the CIA chip for the C64).  Then in c64.h, it sets up #defines like this:

#include <_6526.h>
#define CIA1   (*(struct __6526*)0xDC00)
#define CIA2   (*(struct __6526*)0xDD00)

So, in theory, you should be able to type "CIA1." and have code completion come up with suggestions like "ddra", "pra", etc (members of the __6526 structure).  This doesn't work, and I can see why the parser might not follow all those links...

I've actually replaced this for two reasons.  The first is that my replacement works better with C::B's completion, and the second is that I seemed to be having some issues with what I think was compiler optimizations (or maybe I was just doing something stupid -- I won't rule out that possibility).  When I tried to write "CIA2.pra |= 0x30;" or something like it, the result would be incorrect, as if the processor didn't actually read, or maybe didn't actually write.  (As I say, I may have screwed up something with the data-direction registers, instead, so take this with a grain of salt)

But since the improved code completion is quite nice, it doesn't really matter if the "correctness fix" part wasn't needed.  I've just got these simple #defines (I'll include 'em all, so you can just use 'em if you like).  They work great, and code completion understands them perfectly.  The only difference is that I have to use VIC_spr0_x instead of VIC.spr0_x, and I can live with that.  I #undef the symbols as defined by <c64.h>, since I'm not using them.

(Hopefully I'm still on (or near) topic, as this is a workaround for code completion issues)

#define REG(B,O) *((unsigned char *)((B) + (O)))

#undef  VIC
#define VIC 0xD000

#define VIC_spr0_x      REG(VIC, 0)      /* Sprite 0, X coordinate d000 53248 */
#define VIC_spr0_y      REG(VIC, 1)      /* Sprite 0, Y coordinate d001 53249 */
#define VIC_spr1_x      REG(VIC, 2)      /* Sprite 1, X coordinate d002 53250 */
#define VIC_spr1_y      REG(VIC, 3)      /* Sprite 1, Y coordinate d003 53251 */
#define VIC_spr2_x      REG(VIC, 4)      /* Sprite 2, X coordinate d004 53252 */
#define VIC_spr2_y      REG(VIC, 5)      /* Sprite 2, Y coordinate d005 53253 */
#define VIC_spr3_x      REG(VIC, 6)      /* Sprite 3, X coordinate d006 53254 */
#define VIC_spr3_y      REG(VIC, 7)      /* Sprite 3, Y coordinate d007 53255 */
#define VIC_spr4_x      REG(VIC, 8)      /* Sprite 4, X coordinate d008 53256 */
#define VIC_spr4_y      REG(VIC, 9)      /* Sprite 4, Y coordinate d009 53257 */
#define VIC_spr5_x      REG(VIC, 10)      /* Sprite 5, X coordinate d00a 53258 */
#define VIC_spr5_y      REG(VIC, 11)      /* Sprite 5, Y coordinate d00b 53259 */
#define VIC_spr6_x      REG(VIC, 12)      /* Sprite 6, X coordinate d00c 53260 */
#define VIC_spr6_y      REG(VIC, 13)      /* Sprite 6, Y coordinate d00d 53261 */
#define VIC_spr7_x      REG(VIC, 14)      /* Sprite 7, X coordinate d00e 53262 */
#define VIC_spr7_y      REG(VIC, 15)      /* Sprite 7, Y coordinate d00f 53263 */
#define VIC_spr_hi_x    REG(VIC, 16)   /* High bits of X coordinate d010 53264 */
#define VIC_ctrl1       REG(VIC, 17)      /* Control register 1 d011 53265 */
#define VIC_rasterline  REG(VIC, 18)   /* Current raster line d012 53266 */
#define VIC_strobe_x    REG(VIC, 19)   /* Light pen, X position d013 53267 */
#define VIC_strobe_y    REG(VIC, 20)   /* Light pen, Y position d014 53268 */
#define VIC_spr_ena     REG(VIC, 21)   /* Enable sprites d015 53269 */
#define VIC_ctrl2       REG(VIC, 22)      /* Control register 2 d016 53270 */
#define VIC_spr_exp_y   REG(VIC, 23)   /* Expand sprites in Y dir d017 53271 */
#define VIC_addr        REG(VIC, 24)        /* Address of chargen and video ram d018 53272 */
#define VIC_irr         REG(VIC, 25)      /* Interrupt request register d019 53273 */
#define VIC_imr         REG(VIC, 26)      /* Interrupt mask register d01a 53274 */
#define VIC_spr_bg_prio REG(VIC, 27)   /* Priority to background d01b 53275 */
#define VIC_spr_mcolor  REG(VIC, 28)   /* Sprite multicolor bits d01c 53276 */
#define VIC_spr_exp_x   REG(VIC, 29)        /* Expand sprites in X dir d01d 53277 */
#define VIC_spr_coll    REG(VIC, 30)   /* Sprite/sprite collision reg d01e 53278 */
#define VIC_spr_bg_coll REG(VIC, 31)   /* Sprite/background collision reg d01f 53279 */
#define VIC_bordercolor REG(VIC, 32)   /* Border color d020 53280 */
#define VIC_bgcolor0    REG(VIC, 33)   /* Background color 0 d021 53281 */
#define VIC_bgcolor1    REG(VIC, 34)   /* Background color 1 d022 53282 */
#define VIC_bgcolor2    REG(VIC, 35)   /* Background color 2 d023 53283 */
#define VIC_bgcolor3    REG(VIC, 36)         /* Background color 3 d024 53284 */
#define VIC_spr_mcolor0 REG(VIC, 37)   /* Color 0 for multicolor sprites d025 53285 */
#define VIC_spr_mcolor1 REG(VIC, 38)      /* Color 1 for multicolor sprites d026 53286 */
#define VIC_spr0_color  REG(VIC, 39)   /* Color sprite 0 d027 53287 */
#define VIC_spr1_color  REG(VIC, 40)   /* Color sprite 1 d028 53288 */
#define VIC_spr2_color  REG(VIC, 41)   /* Color sprite 2 d029 53289 */
#define VIC_spr3_color  REG(VIC, 42)   /* Color sprite 3 d02a 53290 */
#define VIC_spr4_color  REG(VIC, 43)   /* Color sprite 4 d02b 53291 */
#define VIC_spr5_color  REG(VIC, 44)   /* Color sprite 5 d02c 53292 */
#define VIC_spr6_color  REG(VIC, 45)   /* Color sprite 6 d02d 53293 */
#define VIC_spr7_color  REG(VIC, 46)   /* Color sprite 7 d02e 53294 */

#undef CIA1
#define CIA1 0xDC00

#define CIA1_pra        REG(CIA1, 0)   /* Port register A */
#define CIA1_prb        REG(CIA1, 1)   /* Port register B */
#define CIA1_ddra       REG(CIA1, 2)   /* Data direction register A */
#define CIA1_ddrb       REG(CIA1, 3)   /* Data direction register B */
#define CIA1_ta_lo      REG(CIA1, 4)   /* Timer A, low byte */
#define CIA1_ta_hi      REG(CIA1, 5)   /* Timer A, high byte */
#define CIA1_tb_lo      REG(CIA1, 6)    /* Timer B, low byte */
#define CIA1_tb_hi      REG(CIA1, 7)   /* Timer B, high byte */
#define CIA1_tod_10     REG(CIA1, 8)   /* TOD, 1/10 sec. */
#define CIA1_tod_sec    REG(CIA1, 9)   /* TOD, seconds */
#define CIA1_tod_min    REG(CIA1, 10)   /* TOD, minutes */
#define CIA1_tod_hour   REG(CIA1, 11)   /* TOD, hours */
#define CIA1_sdr        REG(CIA1, 12)   /* Serial data register */
#define CIA1_icr        REG(CIA1, 13)   /* Interrupt control register */
#define CIA1_cra        REG(CIA1, 14)   /* Control register A */
#define CIA1_crb        REG(CIA1, 15)   /* Control register B */

#undef CIA2
#define CIA2 0xDD00

#define CIA2_pra        REG(CIA2, 0)   /* Port register A */
#define CIA2_prb        REG(CIA2, 1)   /* Port register B */
#define CIA2_ddra       REG(CIA2, 2)   /* Data direction register A */
#define CIA2_ddrb       REG(CIA2, 3)   /* Data direction register B */
#define CIA2_ta_lo      REG(CIA2, 4)   /* Timer A, low byte */
#define CIA2_ta_hi      REG(CIA2, 5)   /* Timer A, high byte */
#define CIA2_tb_lo      REG(CIA2, 6)    /* Timer B, low byte */
#define CIA2_tb_hi      REG(CIA2, 7)   /* Timer B, high byte */
#define CIA2_tod_10     REG(CIA2, 8)   /* TOD, 1/10 sec. */
#define CIA2_tod_sec    REG(CIA2, 9)   /* TOD, seconds */
#define CIA2_tod_min    REG(CIA2, 10)   /* TOD, minutes */
#define CIA2_tod_hour   REG(CIA2, 11)   /* TOD, hours */
#define CIA2_sdr        REG(CIA2, 12)   /* Serial data register */
#define CIA2_icr        REG(CIA2, 13)   /* Interrupt control register */
#define CIA2_cra        REG(CIA2, 14)   /* Control register A */
#define CIA2_crb        REG(CIA2, 15)   /* Control register B */

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #12 on: May 22, 2010, 04:22:55 am »
Quote
#include <_6526.h>
#define CIA1   (*(struct __6526*)0xDC00)
#define CIA2   (*(struct __6526*)0xDD00)

So, in theory, you should be able to type "CIA1." and have code completion come up with suggestions like "ddra", "pra", etc (members of the __6526 structure).  This doesn't work, and I can see why the parser might not follow all those links...

As far as I know, the Current CC doesn't expand Macros, So, when you enter "CIA1.", CC only know it is a macro defined some where.

If you want  the members of __6526 structure prompted here, You just need to analyze the "(*(struct __6526*)0xDC00)" statement. Not easy to implement,  :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #13 on: May 22, 2010, 07:21:07 am »
Sometimes I see references to a KeyBinder plugin, but my install (8.02) doesn't seem to have it -- and I can't consistently find reference to it.
Keybinder would be the way to go. I am not sure anymore if it was included in the 08/02 installer (You are on Windows, right?! Please check all the contrib plugin choices at install time whether you really selected this plugin. The default install won't do that for sure.

If it's not included than you can try to compile C::B yourself (it's pretty easy after all) or you can try a nightly. As far as I know it should be part of the nightlies.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: cc65 (6502/6510) toolchain for hobbyist retro work -- need help...
« Reply #14 on: May 22, 2010, 10:35:09 am »
Sometimes I see references to a KeyBinder plugin, but my install (8.02) doesn't seem to have it -- and I can't consistently find reference to it.
Keybinder would be the way to go. I am not sure anymore if it was included in the 08/02 installer (You are on Windows, right?! Please check all the contrib plugin choices at install time whether you really selected this plugin. The default install won't do that for sure.

If it's not included than you can try to compile C::B yourself (it's pretty easy after all) or you can try a nightly. As far as I know it should be part of the nightlies.
It's included in 8.02 and in the nightlies.