Pixelboy Posted March 8, 2015 Share Posted March 8, 2015 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. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 8, 2015 Author Share Posted March 8, 2015 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*) 1 Quote Link to comment Share on other sites More sharing options...
alekmaul Posted March 9, 2015 Share Posted March 9, 2015 If you need help regarding compile script, just send me your source files, I will try to help you Quote Link to comment Share on other sites More sharing options...
PkK Posted March 9, 2015 Share Posted March 9, 2015 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 Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 9, 2015 Author Share Posted March 9, 2015 Thanks Philipp. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 22, 2015 Author Share Posted March 22, 2015 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? Quote Link to comment Share on other sites More sharing options...
alekmaul Posted March 23, 2015 Share Posted March 23, 2015 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, Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 23, 2015 Author Share Posted March 23, 2015 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)... Quote Link to comment Share on other sites More sharing options...
alekmaul Posted March 23, 2015 Share Posted March 23, 2015 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... Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 23, 2015 Author Share Posted March 23, 2015 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. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 23, 2015 Author Share Posted March 23, 2015 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... Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 23, 2015 Author Share Posted March 23, 2015 Muhahahahaaaaaa!!! I did it! I managed to successfully compile Jewel Panic as a 64K Activision-type ROM! Thanks Alekmaul for all your help! Quote Link to comment Share on other sites More sharing options...
alekmaul Posted March 24, 2015 Share Posted March 24, 2015 you're welcome ! nice to see that all things run well now ! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.