Jump to content
IGNORED

Placing data at a specific address in the ROM with SDCC?


Pixelboy

Recommended Posts

I'm currently working on a way to compile a 64K version of Jewel Panic, and I'm wondering if there's an easy way (with SDCC) to specify at which address (in the resulting ROM) tables of data should be positioned.

 

For example, let's say I have this small table:

 

static const byte jewel_color[] = { 0x00, 0x30, 0xA0, 0x60, 0x90, 0xD0, 0x70, 0xF0, 0x40 };

 

I would like this table of 9 bytes to be placed at address 0xC000 in the final ROM. Is there an easy way to do this with SDCC?

 

Thanks in advance for any help. :)

Link to comment
Share on other sites

Follow-up: I discovered PkK's post here, which looks like what I'm looking for, but can I place functions as well as data in the different banks?

 

EDIT (Follow-up #2): I saw the reference to alekmaul's instructions here (thanks nanochess!). I'm using an Activision PCB, not a MegaCart, but the differences are minimal. I know my way around C for the most part, but I've been using CCI3 to compile up until now and fiddling around with compiler options is not something I'm used to... I guess I'll have to figure out how to make my own compile scripts... (*sigh*) :)

  • Like 1
Link to comment
Share on other sites

I'm currently working on a way to compile a 64K version of Jewel Panic, and I'm wondering if there's an easy way (with SDCC) to specify at which address (in the resulting ROM) tables of data should be positioned.

 

For example, let's say I have this small table:

 

static const byte jewel_color[] = { 0x00, 0x30, 0xA0, 0x60, 0x90, 0xD0, 0x70, 0xF0, 0x40 };

 

I would like this table of 9 bytes to be placed at address 0xC000 in the final ROM. Is there an easy way to do this with SDCC?

 

Thanks in advance for any help. :)

 

You might want to look up the keyword __at in the sdcc manual.

 

Philipp

Link to comment
Share on other sites

  • 2 weeks later...

Okay, I'm back again with some questions. :)

 

Alekmaul has been helping me compile the 64K bankswitched version of Jewel Panic, and it's not too far from working, but I'm not quite there yet.

 

First of all, I'm a bit puzzled by what I'm seing in the generated crtcv.map file. As an example, here are the lines associated to bank #3:

 

     0000C000  _init_initials_screen              jp_bank3
     0000C000  _init_initials_screen_start        jp_bank3
     0000C164  _PAT1_DANIEL                       jp_bank3
     0000C164  _init_initials_screen_end          jp_bank3
     0000C3BE  _PAT2_DANIEL                       jp_bank3
     0000C67D  _PAT3_DANIEL                       jp_bank3
     0000CA56  _PAT_ALPHA_BANK2                   jp_bank3
     0000CB8A  _COL1_DANIEL                       jp_bank3
     0000CCF1  _COL2_DANIEL                       jp_bank3
     0000CEF6  _COL3_DANIEL                       jp_bank3
     0000D1A9  _NAM1_DANIEL                       jp_bank3
     0000D216  _NAM2_DANIEL                       jp_bank3
     0000D28F  _NAM3_DANIEL                       jp_bank3
     0000D32A  _SPR_GAME_BANK2                    jp_bank3
     0000D488  _manage_initials_screen            jp_bank3
     0000D488  _manage_initials_screen_start      jp_bank3
     0000D8BE  _manage_game_over                  jp_bank3
     0000D8BE  _manage_game_over_start            jp_bank3
     0000D8BE  _manage_initials_screen_end        jp_bank3
     0000D9B3  _manage_game_over_end              jp_bank3
The problem I see here is that init_initials_screen (a function) isn't actually located at the beginning of my C source file. I define all data (mostly arrays of bytes like PAT1_DANIEL) before the first function in my source code, so I'm starting to wonder what SDCC is actually doing at compile time with a bank-referenced source file that contains both data and code. Logically, init_initials_screen should appear after SPR_GAME_BANK2 in the list above. That is, unless there's something about the "--codeseg" and "--constseg" compile flags I should know about?

 

Secondly, from the analysis I've done on the ROM generated by Alekmaul's tool (which replaces the OBJCOPY.EXE program used by CCI3.EXE) the banks seem to be in the wrong order. Bank 0 is placed last:

 

From 0x0000 to 0x3FFF = bank 1 (I assume, not 100% sure)

From 0x4000 to 0x7FFF = bank 2

From 0x8000 to 0xBFFF = bank 3

From 0xC000 to 0xFFFF = bank 0

 

Perhaps this is a side-effect of trying to link a 64K Activision PCB project with a tool that was designed to handle a MegaCart project, so that part can probably be fixed, but my real problem is that, regardless of where bank #0 is located within the ROM, it doesn't start with 0xAA55 or 0x55AA within the ROM file, which means it can never work on a real ColecoVision. I'm still trying to figure out what's going on there.

 

Any help at this point would be appreciated. Thanks in advance. :)

 

EDIT: By the way, Alekmaul, I haven't used the makefile you gave me yet. I'm still using my old makefile with some minor modifications which mostly matches your makefile.

 

EDIT #2: I just tried something that gave me interesting results: I set the starting address of bank 0 at 0x8000 in my makefile, and this makes the crtcv.map file "correct" in terms of the position of each bank:

 

bank 0: 0x8000

bank 1: 0xC000

bank 2: 0xC000

bank 3: 0xC000

 

This only applies to the crtcv.map file, it makes no different in the final ROM file (bank 0 is still placed at the end of the ROM). Before I made this change, bank 0 was seemingly appended to the RAM block (immediately after the variables starting at 0x7000).

 

Also, I don't know what happens with the crtcv.rel file with this new setup, or the "lib" files for that matter. I can't seem to set the position of the ROM header. I'm not sure what to do here... Has anyone else even been in this situation?

Link to comment
Share on other sites

Bank 0 is the last one because it is copied at reset to 0x8000. Just found this information in FAQ of Megacart.

I think crtcv.s i used for my example was modified to read the 0xff value and then switch the bank 0,

Yes, that seems to fit with my findings.

 

After careful analysis, I believe I've identified the problem: When I don't tell the compiler to treat bank #0 as an actual bank, the generated cvcrt.map file shows that everything in bank #0 is appended to the RAM block which starts at 0x7000. This makes the RAM block go well over 0x8000 and it's obviously incorrect.

 

On the other hand, if I define bank #0 as an actual bank within my makefile, and set that bank's starting address at 0x8400 (to make room for the crtcv header and libraries between 0x8000 and 0x83FF), then the crtcv.map file is correct (as far as I can tell) but your cvmkcrt program doesn't behave very well, and I'm currently examining why.

 

More to come later (I hope)... ;)

Link to comment
Share on other sites

On the other hand, if I define bank #0 as an actual bank within my makefile, and set that bank's starting address at 0x8400 (to make room for the crtcv header and libraries between 0x8000 and 0x83FF), then the crtcv.map file is correct (as far as I can tell) but your cvmkcrt program doesn't behave very well, and I'm currently examining why.

 

 

That's really strange, it seems to work fine for my example with some bitmaps displayed on screen. Each bitmap was in a diffenrent bank and they were displayed ok...

Link to comment
Share on other sites

That's really strange, it seems to work fine for my example with some bitmaps displayed on screen. Each bitmap was in a diffenrent bank and they were displayed ok...

My bank setup is more complicated, but not so complicated that it can't logically compile:

 

- Bank 0 needs to contain the basic coleco libraries (crtcv, etc.) in addition to my own code for bank 0 (which includes main(), nmi() and all the basic stuff).

 

- Bank 1 is a complement to bank 0, in the sense that when bank 2 and 3 are not being used, the volatile bank should always be set to bank 1 during actual gameplay.

 

- Bank 2 contains raw data and functions related to the title screen and menu screen (and also the data for the in-game graphics which are included in the menu screen graphic data).

 

- Bank 3 contains raw data and functions related to the "game over" display and initials entry screens.

 

So essentially, I've got both raw data and functions in every bank (which is something you apparently don't have in your MegaCart bitmap test program) and the game only switches to bank 2 and 3 for the title screen, menu screen, game over and initials entry screen. The rest of the time, bank 1 is used.

 

Nothing terribly complicated, but it could be just enough to confuse SDCC. ;)

Link to comment
Share on other sites

Here's what I've been told privately:

 

In the Activision cart, the first bank (bank 0) is located at $0000-$3fff of the physical ROM file, fixed mapped into $8000-$bfff.

 

In the Megacart, the last bank (bank 3 in a 64K ROM) is located at $c000-$ffff of the physical ROM file, fixed mapped into $8000-$bfff.

That would explain a few things...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...