Displaying sprites and SAT and SATB confusion

[Pokun]

So I've finally read through the dev docs and think I have a good basic understanding of how to use the hardware. I have succeeded in making a "Hello World" HuCard program on my PC Engine, and also had fun programming my own waveforms for the PSG.

Right, now I'm trying to display sprites but it just doesn't work. Here's the things I've done:
* I've initialized about every CPU, VDC, VCE and PSG register there are, and also all RAM, VRAM and the internal SATB memory. Not the PSG's internal waveform registers though.
* I've uploaded one sprite attribute to SAT (I put it in VRAM $4000) properly.
* I've uploaded my sprite pattern in the proper format in the SG (VRAM $4100).
* I wrote $4000 to R13 of the VDC (VRAM-SATB DMA register) to setup SAT base address.
* I've enabled VRAM-SATB Repeat flag, so I guess this is enough for SATB to be updated.
* I've enabled sprites via the sprite blanking bit (I forgot which register it is).

The sprite pattern shows up in Mednafen sprite debugger so it is in the correct format. My SG starts at VRAM $4100 so if my calculations are correct the Pattern Code is $0104 for the first pattern. I assigned this number to sprite 0 in SAT. I also setup its coordinates and priority bit so that it should be visible.

Is there something I'm missing, or anything in general that you need to think of? I can upload my source code later when I'm home.


And finally a question about SAT and SATB which makes things even more confusing for me.
In the dev docs and in the Develo Assembly book (which seems to have ripped out parts of the official Japanese development documents) it seems to be quite clear to me that SAT is for sprites, much like BAT is for background characters, a part of VRAM where you assign your 64 sprite entries that are currently to be showed on screen (visible or not). But unlike BAT the data in SAT must be copied to an internal memory of the VDC called SATB And this is done via the DMA channel called VRAM-SATB DMA (the English translation replaces all instances of DMA to "Block Transfer" though). So SATB is probably 512 kB like SAT.

But on about every documentation I can find online, people have the terms SAT and SATB mixed up. Even Mednafen's debugger seems to use SAT for the internal VDC memory.
I guess because VRAM acts like a buffer for the internal VDC memory it makes sense that SATB (Sprite Attribute Table Buffer) would be the VRAM area.

Is it Hudson that are using confusing terms or did I completely misunderstand the dev docs?

[touko]

Hi, SAT and SATB are the same,the main difference is their location .
SATB is a buffer which sit in VRAM,the SAT is the true sprite table attribute which sit in a VDC's internal buffer and cannot be accessed directly(it's the VRAM-SATB DMA  which doing the job ).
If you modify some sprites in the SATB(in VRAM), they will not be updated until VRAM-SATB DMA  occur (in the 4 very first scanlines of vblank)  .

[elmer]

SATB is a buffer which sit in VRAM,the SAT is the true sprite table attribute which sit in a VDC's internal buffer and cannot be accessed directly.

The official English documentation uses the opposite names for the areas.

SAT is the one in VRAM, and SATB is the 512-byte buffer in internal VDC memory that the VDC's sprite hardware uses to actually display the sprites during the frame (saving memory bandwidth).

And finally a question about SAT and SATB which makes things even more confusing for me.
...
But on about every documentation I can find online, people have the terms SAT and SATB mixed up. Even Mednafen's debugger seems to use SAT for the internal VDC memory.
...
Is it Hudson that are using confusing terms or did I completely misunderstand the dev docs?

You understand the basic process ... don't get hung up on the naming.

Hudson are consistent in their naming within the documentation, but the English docs have only been "public" for a short time, and people are just used to calling things by the opposite names.

It doesn't really matter what the names are ... you could reasonably consider either location as the "original" and the other as the "buffer", it's just a naming convention.

The important thing is how the 2 copies work in practice, which you already understand.

But you've got the Pattern Code calculation wrong ... VRAM $4100 -> Pattern Code $0208.

It's a divide by 32, not the divide by 64 that you'd expect given that a 16x16x4 sprite is 64 words of VRAM memory.

I'm guessing that they originally designed the addressing to allow for a 4-color-sprite option.

[fragmare]

SATB is a buffer which sit in VRAM,the SAT is the true sprite table attribute which sit in a VDC's internal buffer and cannot be accessed directly.

The official English documentation uses the opposite names for the areas.

SAT is the one in VRAM, and SATB is the 512-byte buffer in internal VDC memory that the VDC's sprite hardware uses to actually display the sprites during the frame (saving memory bandwidth).

And finally a question about SAT and SATB which makes things even more confusing for me.
...
But on about every documentation I can find online, people have the terms SAT and SATB mixed up. Even Mednafen's debugger seems to use SAT for the internal VDC memory.
...
Is it Hudson that are using confusing terms or did I completely misunderstand the dev docs?

You understand the basic process ... don't get hung up on the naming.

Hudson are consistent in their naming within the documentation, but the English docs have only been "public" for a short time, and people are just used to calling things by the opposite names.

It doesn't really matter what the names are ... you could reasonably consider either location as the "original" and the other as the "buffer", it's just a naming convention.

The important thing is how the 2 copies work in practice, which you already understand.

But you've got the Pattern Code calculation wrong ... VRAM $4100 -> Pattern Code $0208.

It's a divide by 32, not the divide by 64 that you'd expect given that a 16x16x4 sprite is 64 words of VRAM memory.

I'm guessing that they originally designed the addressing to allow for a 4-color-sprite option.

Perhaps that option becomes useful when sprites are planar compressed 2:1 and 2x2bpp sprites are packed into a 4bpp sprite area?

[Arkhan]

Have you checked out some of the MagicKit macros/library code?  You can dig around a little in there and see how some of this stuff works, and may have various "Aha!" moments while doing so.  For other things too, not just sprites.

I wouldn't get too hung up on naming either.   Things sometimes get lost in translation, especially because IIRC, documentation isn't just going from JP to English.  It's also going to French, ... I think.

and everyone calls things different things.  It gets confusing sometimes.   

[Pokun]

Yeah I guess someone mixed up SAT and SATB long ago and then this naming just stuck.

I think the official naming makes sense though:

Code: [Select]

VRAM
 ---------
 |       | $0000
 |  BAT  |             (attributes for background characters)
 |       |
 |-------|
 |       |
 |  CG   |             (pattern data for background characters)
 |       |
 |-------|
 |       |
 |  SAT  |             (attributes for sprites)
 |       |
 |-------|
 |       |
 |  SG   |             (pattern data for sprites)
 |       |
 |-------|
I mean SAT matches BAT, and has similar usage.

Yeah I think Magickit library is good for learning. Some things like Backup RAM doesn't seem to be mentioned at all in the dev docs, the only place I've found a description of the save file format is in the Magickit library.

You understand the basic process ... don't get hung up on the naming.

OK, so it seems I understood it correctly at least.
I think I'm ready to move on from this shock.

I'm guessing that they originally designed the addressing to allow for a 4-color-sprite option.

Yeah the dev docs describe that if you are using 4-dot mode via MWR, you'll be limited with 4-color-sprites.
But according to Charles McDonald, PC Engine is using very fast VRAM chip already so there is no need to use slower than 1-dot mode.

you've got the Pattern Code calculation wrong ... VRAM $4100 -> Pattern Code $0208.

It's a divide by 32, not the divide by 64 that you'd expect given that a 16x16x4 sprite is 64 words of VRAM memory.

Alright this was the problem. Now it works as expected!

Thanks everyone for the replies!

[touko]

I mean SAT matches BAT, and has similar usage.

No, the BAT is unique and start at $0000 in VRAM and can be directly accessed(no need to copy BAT somewhere), the VDC use directly the BAT in VRAM .

SAT or SATB in fact you don't care about the name IMO, the important thing is there are two SAT, one in VRAM that you can modify as you want, and one in the VDC updated from that in VRAM by the SATB-DMA .

[Pokun]

Yes that is what I meant by "similar usage" instead of "identical usage".
They are both VRAM areas that can be modified as you want. Although SAT has an arbitrary base address while BAT is always $0000.

If I understands it correctly, CG, SAT and SG can technically be anywhere in VRAM, even inside BAT, as long as CG and SG are aligned properly for Pattern Codes to work. The model I drew up is from the dev docs, and I guess it represents the typical VRAM map.

[touko]

Yes your understanding is correct .