devkitSMS adopted in z88dk about devkitsms HOT 4 CLOSED

Great! Sure I'll check how you did it and I'll take some 'back' :)

I'm not sure if modifying PNTADDRESS, SATADDRESS, CRAMADDRESS is all it takes to move these things around in VRAM?

You can't move CRAM, you can move PNT and SAT location in VRAM only by instructing VDP about their 'new' locations, which are to be chosen from a list of (rather limited) possible values.

from devkitsms.

You can't move CRAM, you can move PNT and SAT location in VRAM only by instructing VDP about their 'new' locations, which are to be chosen from a list of (rather limited) possible values.

Cheers sverx.

What I've done is define some SMS-target variables that determine default locations for these things:

define(`__SMS_VRAM_SCREEN_MAP_ADDRESS',  0x3800)              # multiples of 0x0800 - affects devkitSMS
define(`__SMS_VRAM_SPRITE_ATTRIBUTE_TABLE_ADDRESS', 0x3f00)   # multiples of 0x0100 - affects devkitSMS
define(`__SMS_VRAM_CHARACTER_PATTERN_BASE_ADDRESS', 0x2000)   # 0x0000 or 0x2000

and then I define the devkitSMS constants in terms of those so that there is only one place where these things need to be changed:

define(`__SMSLIB_PNTADDRESS',  0x`'eval(__SMS_VRAM_SCREEN_MAP_ADDRESS + 0x4000,16))
define(`__SMSLIB_SATADDRESS',  0x`'eval(__SMS_VRAM_SPRITE_ATTRIBUTE_TABLE_ADDRESS + 0x4000,16))
define(`__SMSLIB_CRAMADDRESS', 0xc000)

For SMS_init() I change the 11-byte VDP initialization block to this:

__SMSlib_VDPReg_init:

   defb 0x04                   ; /* reg0: Mode 4 */
   defb 0x20                   ; /* reg1: display OFF - frame int (vblank) ON */
   defb ((__SMSLIB_PNTADDRESS & 0x3800) >> 10) + 0xf1  ; /* reg2: PNT at 0x3800 */
   defb 0xFF                   ; /* reg3: no effect (when in mode 4) */
   defb 0xFF                   ; /* reg4: no effect (when in mode 4) */
   defb ((__SMSLIB_SATADDRESS & 0x3f00) >> 7) + 0x81   ; /* reg5: SAT at 0x3F00 */
   defb ((__SMS_VRAM_CHARACTER_PATTERN_BASE_ADDRESS & 0x2000) >> 11) + 0xfb  ; /* reg6: Sprite tiles at 0x2000 */
   defb 0x00                   ; /* reg7: backdrop color (zero) */
   defb 0x00                   ; /* reg8: scroll X (zero) */
   defb 0x00                   ; /* reg9: scroll Y (zero) */
   defb 0xFF                   ; /* regA: line interrupt count (offscreen) */

and I think this makes the the screen map, sprite attribute table, and character patterns relocatable within devkitSMS.

However there is one thing I am not understanding: you've set the character/sprite patterns base address to 0x2000 by default (reg6 = 0xff) but the tile data is always using VDP addresses in the lower 8k.

For example, in SMS_loadTiles():

   ;; SMS_setAddr(0x4000|(tilefrom*32))
   
   add hl,hl
   add hl,hl
   add hl,hl
   add hl,hl
   add hl,hl
   set 6,h
   
	ld a,c
   INCLUDE "SMS_CRT0_RST08.inc"
	ld c,a

The VDP address is just the tilenumber * 32 which places it in the lower 8k. This despite reg6 having been initialized with the character pattern table beginning at 0x2000, the upper 8k.

I tried changing the character pattern table address to 0x0000 via the methods above and there was no difference at all.

There is something I am not understanding here. How is it that devkitSMS defines a character/sprite pattern table address of 0x2000 but its tile functions write character data into addresses less than 0x2000 and things still work?

The example program I am looking at is your split-screen example. It begins with:

  SMS_VDPturnOnFeature(VDPFEATURE_LEFTCOLBLANK);
  loadAssets();

->

void loadAssets (void) {
  // load the tiles for both pictures
  SMS_loadPSGaidencompressedTiles (p1__tiles__psgcompr, 0);
  SMS_loadPSGaidencompressedTiles (p2__tiles__psgcompr, 224);
}

SMS_init() has been called by the crt setting the character pattern address to 0x2000. Then SMS_loadPSGaidencompressedTiles() is loading tile graphics into addresses < 0x2000 because the tile numbers are < 256.

from devkitsms.

Problem solved; I had a misunderstanding of what the sprite pattern base address was doing. Misnaming it character pattern base address was a bad idea.

from devkitsms.

Sorry for coming back to you so late... well, I'm happy to see you got it by yourself - yes, that VDP bit just sets which of either halves of VRAM will be used for sprites.

from devkitsms.