SpritesMind.Net

I saw this piece of code quite frequently on disassemblies of games I study (this is from "Shadow Dancer", but there's the same in "Psy-O-Blade"):
a3 is 0xC00004 of course.

I don't understand why the 2 last lines. Is there a reason not to code move.w #$0080, (a3) ? (timing ? if so, why not nops)

Yeah timing, because of slow rom (i guess) Sega recommended to always trigger the DMA from a RAM write or you may experience a faulty first word transfer in some case.

Thanks! Good to know.

Is it true also for long writes ?

The important thing is that the last write BUS operation which trigger the DMA is done from RAM, so same goes for long write yeah.
But anyway today with blazing fast EPROM, you don't need that anymore :p

Thanks

Another question, really dumb this one :

if I understood correctly :

* horizontal scrolling can be specified for a whole plane, or line (1 pixel height) per line, or cell (8 pixels height) per cell. So I assume it uses 2 planes * 2 bytes (case of whole plane), up to 2*1024*2 bytes (case of per line scroll, with max height of a plane = 128 tiles = 1024 lines?) in VRAM

* vertical scroll is similar, except you can only choose between full plane scroll and 2 cells scroll (= 16 pixels ?). That should use 2*64*2 bytes (max plane width = 128 tiles = 64 cells ?) in VSRAM

But the HSCROLL table seems to be 1024 bytes long and the VSRAM would be 80 bytes. So I misunderstood at least one thing...

Unless you specify only the scroll values for the lines and columns that are actually displayed (so 320 lines max and 240 columns, so 15 cells of 16 pixels ?). But numbers don't match either...

Another thing I don't understand : why is there a separate VSRAM and not a HSRAM ? Since the HSCROLL table is larger, it would have made more sense ?

The scroll tables only hold values for the visible display. The numbers don't add up because you have the vertical and horizontal resolution flipped. The display is 240 lines tall and 320 pixels high (in H40 V30 mode anyway). Also the horizontal scroll table isn't really 1024 bytes. It's max size is 960 bytes.

The reason VSRAM has a separate RAM comes down to VRAM bandwidth. You only need to read one value per line per plane for horizontal scrolling, but you need to read 20 times that for the 2 column vertical scroll mode. The Genesis VDP renders the display a line at a time in sync with the video output so VRAM bandwidth within a line is at a premium.

Mask of Destiny wrote:The scroll tables only hold values for the visible display. The numbers don't add up because you have the vertical and horizontal resolution flipped. The display is 240 lines tall and 320 pixels high (in H40 V30 mode anyway). Also the horizontal scroll table isn't really 1024 bytes. It's max size is 960 bytes.

Ouch, stupid confusion, sorry

The reason VSRAM has a separate RAM comes down to VRAM bandwidth. You only need to read one value per line per plane for horizontal scrolling, but you need to read 20 times that for the 2 column vertical scroll mode. The Genesis VDP renders the display a line at a time in sync with the video output so VRAM bandwidth within a line is at a premium.

It makes perfectly sense. Thanks

A related question concerning hscroll : couldn't the per-line scroll effect be achieved by modifying the whole plane hscroll value during hblank ?

tryphon wrote:A related question concerning hscroll : couldn't the per-line scroll effect be achieved by modifying the whole plane hscroll value during hblank ?

Yes, but it's a lot of overhead for no reason. That's the whole point of the hscroll table - to reduce the overhead needed for scrolling more than just the entire display. That allows you to spend that time changing colors on the fly instead.

Yes, of course! I had a different very specific goal in mind

There are many things I wonder if they are possible using HBLANK. For example, is it possible to draw more sprites than what is theoretically possible (80) by changing the y values during HBLANK ?

tryphon wrote:Yes, of course! I had a different very specific goal in mind

There are many things I wonder if they are possible using HBLANK. For example, is it possible to draw more sprites than what is theoretically possible (80) by changing the y values during HBLANK ?

You can, and games like Castlevania Bloodlines and Sonic 2 in split-screen mode reload the sprite attribute table mid-frame to do that.

I think there's some old forum posts explaining the difficulties involved with doing this, but I can explain it again if you'd like.

Thanks for the answer

I'd gladly get explanations, but I wouldn't like to take your time away. I made some researchs and suppose you're referring to this thread, it'll be a nice read.

While I'm at it, thank you for your genhw and genvdp documents, which are always a great help