After some more investigating it looks like this may have something to do with the ihx step in the linker. It appears that the extended addressing (which seems to control the larger address space) is only enabled for `TARGET_IS_8051` and `TARGET_IS_6808` (see http://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/sdas/linksrc/lkihx.c#l150 )
Gonna fiddle with this a bit to see if that's the culprit for why the address space is wrapping for gbz80. This is grasping at straws though... Karl On Thu, Oct 29, 2015 at 2:44 PM, Karl Kirch <karlk...@gmail.com> wrote: > Oh, forgot to mention, using version - `SDCC : > mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 > 3.4.0 #8981 (Oct 26 2015) (Mac OS X x86_64)` > > On Thu, Oct 29, 2015 at 2:39 PM, Karl Kirch <karlk...@gmail.com> wrote: > >> Yeah, this is really like day 2 of me looking into this so I'm not super >> familiar with how all of this is setup. >> I figure really what I'm missing is how to set the memory location for >> the start of a bank. I would think `-Wl-b_CODE_1=0xnnnn` would do the trick >> but apparently not :/ >> >> On Thu, Oct 29, 2015 at 2:23 PM, Alan Cox <a...@lxorguk.ukuu.org.uk> >> wrote: >> >>> On Thu, 29 Oct 2015 14:02:16 -0500 >>> Karl Kirch <karlk...@gmail.com> wrote: >>> >>> > Currently trying to get SDCC up and running on some gameboy dev and am >>> > trying to get multi bank support working. >>> > I can get code up and running in a single bank and can get the >>> compiler to >>> > generate the correct code segment code using `#pragma bank 1` (will >>> > generate `.area _CODE_1`. >>> > The problem I'm seeing is at the linking stage. I want to put the bank >>> 1 >>> > code outside of the 0xFFFF address space so that it can later be >>> swapped in >>> > by the MBC. When I go to set the location via `-Wl-b_CODE_1=0x10000` >>> all >>> > this does is wrap the code location back to 0x0000. Even when I don't >>> set >>> > the location explicitly I end up getting a location of 0xC131 which >>> causes >>> > makebin to explode because the rom size is > 32kb >>> > >>> > Am I missing something here? or are >32kb roms just unsupported by >>> SDCC? >>> >>> I never managed to figure that out for gbz80 either, however if they are >>> not then I've got some small patches to the compiler that handle full >>> transparent code banking for Z80, plus some disgusting hacks to the >>> linker. If it turns out gbz80 doesn't support > 32K ROM then I'd be happy >>> to work with you as someone who knows the gameboy dev stuff to fix my >>> patches/hacks to work on gbz80 as well. >>> >>> Some day I'll submit the bits to SDCC proper but right now while the >>> compiler patches are clean the linker stuff is not fit for submission. >>> >>> Alan >>> >> >> >
------------------------------------------------------------------------------
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
