Jump to content
SpiceWare

DPC+ bB player0 graphics in other banks

Recommended Posts

12 minutes ago, Lillapojkenpåön said:

here's some more source material 

 

Nice!  I'll pass on adding a 2nd player tonight then since you already have a good example.  @TwentySixHundred - check that out and if you have questions post them in that topic.

  • Like 2

Share this post


Link to post
Share on other sites

Speaking of missing features, it would be nice to roll 64k with DPC+. I was told it's not possible, but I still don't believe that.

 

  The ARM code can be altered (and recompiled) to set aside the additional memory on the Harmony Encore.  Stella complains because the thumbulator artificially limits the size to 32k, but it works fine with real hardware.  (Meaning I can boot a 32k bBDPC+ game with the new C code and 64k set aside, but not used.)

 

Unfortunately, a real 64k cart can't be loaded, because the (still closed source?) Encore cart doesn't have a bankswitching scheme.

Edited by orange808
Added clarification

Share this post


Link to post
Share on other sites

We normally don't enable extra functionality in a bankswitching scheme in Stella unless/until it is either working on real hardware, or someone wants to use Stella to help get real hardware working.  IOW, an implementation in real hardware determines what goes into Stella, not the other way around.  Even more succinctly, once the Harmony Encore or Unocart has it, we will look into adding it to Stella (if possible).

  • Like 1
  • Confused 1

Share this post


Link to post
Share on other sites

The issue for me is there's not a way to make a stand-alone Encore game like you can with the Melody board for games based on the specs of the original Harmony.  I'm not interested in writing a game that can't be produced in cartridge format, so I've not pursued it.

 

If that changes, I would definitely look into expanding CDFJ to take advantage of the additional resources. I don't have source for the DPC+ driver, so I wouldn't be able to do anything with it.

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, SpiceWare said:

I'm not interested in writing a game that can't be produced in cartridge format, so I've not pursued it.

I feel the same way; I'm not interested in creating a scheme for Stella that will never be realized in hardware.  Honestly, I don't want games created that work only in emulators.  I don't believe in that approach, and wouldn't want to expend any resources on it.

  • Like 3

Share this post


Link to post
Share on other sites
4 hours ago, stephena said:

We normally don't enable extra functionality in a bankswitching scheme in Stella unless/until it is either working on real hardware, or someone wants to use Stella to help get real hardware working.  IOW, an implementation in real hardware determines what goes into Stella, not the other way around.  Even more succinctly, once the Harmony Encore or Unocart has it, we will look into adding it to Stella (if possible).

 

Just to clear up misunderstanding, I wasn't asking for any features to be added to Stella.  My post was about the fact that the Encore cart accepts setting aside an additional 32k for "cart rom", but the Encore fladh cart itself doesn't have a bankswitching scheme to load a 64k rom as a DPC+ game.  Not sure what to make of your response, so we can leave it at that.

 

Spiceware says the Encore has capabilities that are beyond the boards for individual carts, so the lack of interest and support makes sense.

 

Share this post


Link to post
Share on other sites

My response was to the phrase "Stella complains because the thumbulator artificially limits the size to 32k, but it works fine with real hardware."  I responded that we do that because the currently released bankswitching scheme dictates to do that.  So it's not an arbitrary decision.  If/when a bankswitching scheme is released that allows 64K with DPC+, we will extend Stella to do that too.  That was my only point.

Share this post


Link to post
Share on other sites
9 hours ago, SpiceWare said:

 

It would be written in actual C.  No assembly required.  

 

SpiceC is not useable yet, so there is no tutorial for it.  I do have a few blog posts about it:

Do note that the forum upgrade messed up some of the formatting, and I've not gone back to fix the entries.

 

The C to ARM compiler is Linaro, you'll follow the instructions in Start Here, found in the General forum of the Harmony/Melody Club, to set up a Virtual Machine to use it.

 

9 hours ago, SpiceWare said:

 

Nice!  I'll pass on adding a 2nd player tonight then since you already have a good example.  @TwentySixHundred - check that out and if you have questions post them in that topic.

Thanks for all your help it's much appreciated, ill check out the other thread and make sure to keep a close eye on the development of SpiceC 👍

  • Like 1

Share this post


Link to post
Share on other sites

As SpiceWare said a while back in another thread, SpiceC isn't that huge of a jump from BASIC. I also have to mess with CSS on my web site and that's full of semicolons, so all of those semicolons won't be a shock for me either.

 

If it's OK with SpiceWare, I'll probably have a SpiceC page on my web site that is similar to the bB page or the 7800basic page.

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, Random Terrain said:

If it's OK with SpiceWare, I'll probably have a SpiceC page on my web site that is similar to the bB page or the 7800basic page.

 

It's OK with me.

  • Like 2

Share this post


Link to post
Share on other sites
10 hours ago, Random Terrain said:

As SpiceWare said a while back in another thread, SpiceC isn't that huge of a jump from BASIC.

 

Found them - reply #2 has a couple other examples.

  • Like 2

Share this post


Link to post
Share on other sites
On 1/27/2020 at 4:28 PM, SpiceWare said:

The DPC+ bB routines use some ARM/C code that you can find in bB/includes/custom/main.c:

  // fill color from player0, wrapping if necessary...
  //my_memcpy(queue+(dfhigh(0)<<8)+dflow(0),
  my_memcpy(queue+get32bitdf(0),
            flashdata+(RIOT[player0color+1]<<8)+RIOT[player0color], RIOT[player0y],
            RIOT[player0height]);

  //my_memcpy(queue+(dfhigh(2)<<8)+dflow(2),
  my_memcpy(queue+get32bitdf(2),
            flashdata+(RIOT[player0pointerhi]<<8)+RIOT[player0pointerlo], 0,
            RIOT[player0height]);

 

queue = Display Data RAM

flashdata = ROM

RIOT = 6507 ZP RAM

 

so those memory copy instructions can only copy data from ROM into RAM.  I found the RIOT to be interesting, apparently bB passes some, or all, of 6507 ZP RAM to the ARM routines as the ARM has no access to RIOT. I didn't see where this occurs, but didn't spend much time looking.

It gets copied during VBLANK right before calling main.

 

I have tried to find out what ram gets copied exactly numerous times by looking in DPCplusbB.h and main.c

And now I'm gonna get to the bottom of this..

 

DPCplusbB.h:

RAMcopybegin = SpriteGfxIndex
RAMcopylength = *-RAMcopybegin    ; gets the number of bytes from SpriteGfxIndex to and including player0pointerhi

 

C_function = FETCHER_BEGIN    ; (0x40000C00 + 0x1A4)
CcodeData = C_function + 4    ; (0x40000C00 + 0x1A8)

 

main.c:

unsigned char *C_function=(unsigned int *)(0x40000C00 + 0x1A4);
unsigned char *RIOT=(unsigned char *)(0x40000C00 + 0x1A8);

 

 

DPCplus_kernel.asm:

     ; copy RAM to fetcher for C-code
     lda #<(CcodeData + RAMcopylength)
     sta DF0LOW
     lda #(>(CcodeData + RAMcopylength)) & $0F
     sta DF0HI


     ldx #RAMcopylength-1    
copy2fetcherloop
     lda RAMcopybegin,x   
     sta DF0PUSH
     dex
     bpl copy2fetcherloop

 

     lda #255
     sta CALLFUNCTION

 

     ; copy modified data back (just need first 6 bytes, which is sprite sort data)
     ldx #256-19
copyfromfetcherloop
     lda DF0DATA
     sta RAMcopybegin+19,x
     inx
     bmi copyfromfetcherloop

 

 

It makes sure not to overwrite the four C_function bytes (it only needs to not overwrite the first one I think)

It's used for the function switch and is set to zero before this so it won't enter a function,

 

in bB you also call main when you use a function like pfpixel or pfscroll etc. so it doesn't wait for this call,

probably because some functions took to long for VBLANK?

but it seems like that was the initial plan.

 

So it accounts for RAMcopylength since the stream will decrement for each push

and copies from player0pointerhi to and including SpriteGfxIndex.

 

Got it, finally.

I wonder if you could copy more RAM without messing everything up?

 

 

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, Lillapojkenpåön said:

Related DPC+ question, how would one load data from tables in different banks with "(Indirect),Y" ?

 

You don't.  If you need data from another bank you would need to call a subroutine in the other bank.

  • Thanks 1

Share this post


Link to post
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.

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...