@MagicBox:
VDPX may issue a number of different interrupts. Do you think to take advantage of hw interrupt ack from z80 or IM2 mode or you will stay to the old rst38h?

VDPX should issue a number of interrupts!

1) command executed
2) line reached
3) sprite collision
4) what else ?

Ofcourse it will. As for Z80's interrupt vector mode, it would require special programming. The original VDP's interrupts must be turned off for this (it doesn't support a vector value) and any new interrupt routine should be calling the original RST38 interrupt handler to make the MSX continue to function in basic. Even in normal interrupt mode, the original VDP's interrupt bits must be turned off; you want to be in sync with VDPX, not VDP

Just thinking.. should VDPX get a BASIC ROM too?

Quote:

Just thinking.. should VDPX get a BASIC ROM too?

to do?

VDPX programming in BASIC

Edit: I also made a modification to the sprite engine. The SAT is no separate memory any more and is now cached from VRAM as well. This both made the sprite engine less complex and it will allow you to use the blitter on the SAT too whenever you wanted to do that in the first place.

Instead, I'm now going to have to write the Cache Controller, which reads the VRAM and stuffs the Sprite Engine memory (SAT & SPT). This thing is going to be reasonably complex

However, Verilog is a great hardware description language and the source files aren't all that big either.

Quote:

VDPX programming in BASIC Edit: I also made a modification to the sprite engine. The SAT is no separate memory any more and is now cached from VRAM as well. This both made the sprite engine less complex and it will allow you to use the blitter on the SAT too

Umh, if the CPU write the sat, when you plan to cache the sat data? at vblank?

The caching is done a couple scanlines before the first content scanline (Y=0). That means you have plenty time to update the SAT any time during drawing and in V-blank. The entire caching is fast though, the SAT and the current sprite patterns are cached in about 1 - 1.5 scanline.

Quote:

The caching is done a couple scanlines before the first content scanline (Y=0). That means you have plenty time to update the SAT any time during drawing and in V-blank. The entire caching is fast though, the SAT and the current sprite patterns are cached in about 1 - 1.5 scanline.

Ah, OK.

For caching of the pattern do you mean that you cache the all sprite definition pattern of the unique sprite number from the 128 maximum sprites ?

(To clarify: you have 100 sprites on screen but all 100 are only using 5 different pattern n. -> does it mean that you only cache 5 patterns?)

GREAT.

Quote:

Sprite Mode has been implemented in the Sprite Cores at no performance penalties ^^. Like described, the following modes are now supported: 00: 128 16x16 01: 64 16x32 10: 64 32x16 11: 32 32x32 Sprite X/Y flip continues to work on all sprite modes.

I'd like to suggest an alternative for these 4 fixed sprite modes: In the sprite attribute table, have one bit that
indicates "the coordinates of this sprite are relative to the coordinates of the previous sprite". This allows to chain an arbitrary number of sprites and in an arbitrary configuration. And you can still move the whole chain by only changing the coordinates of one sprite.

Though I'm not sure how well this would work in combination with the flip X/Y bits.

Quote:

Quote: Sprite Mode has been implemented in the Sprite Cores at no performance penalties ^^. Like described, the following modes are now supported: 00: 128 16x16 01: 64 16x32 10: 64 32x16 11: 32 32x32 Sprite X/Y flip continues to work on all sprite modes. I'd like to suggest an alternative for these 4 fixed sprite modes: In the sprite attribute table, have one bit that indicates "the coordinates of this sprite are relative to the coordinates of the previous sprite". This allows to chain an arbitrary number of sprites and in an arbitrary configuration. And you can still move the whole chain by only changing the coordinates of one sprite. Though I'm not sure how well this would work in combination with the flip X/Y bits.

mmm your idea is better... so, instead of have fixed chaining you can to have a BIT that indicates that the XY coord are not absolute, but are offsets of the XY FINAL RENDERED value of the sprite that is chained.... so, you can to do player on blocks of 2x8 chaining 16 sprites, thinks in STREET FIGHTER by example

@PingPong:

128 patterns are cached; not the unique patterns in use. When I would have to see if a pattern was already loaded, I would have to build a list of already loaded patterns. I would have to remember pattern start addresses (in cache) for each sprite. Building and checking lists is a dynamic thing both in time and processing which makes this much more complex.

Digital logic is unlike a CPU, you can't easily build lists, scan them to see if something already exists etc. Adding to, and scanning a list costs a dynamic amount of time, as is with CPU execution. Digital logic however follows a fixed pattern, both in processing and time. VDPX isn't acting like a CPU. (To clarify, a CPU is ofcourse digital logic, but unlike the program, the atomic operations (the individual instructions) are not dynamic, except for a few repetitive operations like LDIR and OTIR. It's the program that runs that makes the whole thing dynamic)

This means that patterns are loaded for all 128 sprites, even if all 128 sprites use the same pattern. You won't have to worry about losing blitter time though, loading 16KB worth of data like said is done in a mere 1.5 scanline, leaving you over 250 scanlines of time to blit stuff around.

----

Sprite linking: This is something I can look into, but will be difficult to implement if at all because there are 4 processing cores, 4 sprites are processed at once. In this context, the "previous" sprite is 4 sprites back. I will have to find a way to allow you to set the 'leading' sprite, and for relative sprites, which leading sprite they would belong to. I may get it to work, but with limitations like: Only every 4th sprite can be a leading sprite (0, 4, 8, 12 etc) AND any relative sprite MUST be a higher number. Sprite 3 can not be relative to leading sprite 8 for example, as sprites are processed from 0 - 127, 4 at a time, in just one pass. At sprite 3 I won't know the coords of sprite 8 yet. Perhaps flipping may still work (negating the offsets for the relative sprites and flipping the sprites themselves)

I thinks, the most programs beneficied by the 32x32 block or the linked sprites SYSTEMs are BASIC programming....because they are slow, as to use seven or eight PUT SPRITE n+x,(x,y),pttrn and you sometimes will see frames width the character repositioned partially

Offcourse that if the access to sprite's att table are fast, and for machine code is just some LD (),a or OUT(),a on a VBLANK the linking or blocky system is good, but can be done without it anyway....


Now, obvious, the leading sprite must be with a most top rendering number .... but, Is better that there wiill be just one BIT per sprite indicating that this is linked with the NUMERIC - 1.

When i readed to _wouter I figured out this:

How hard can be.... at att table

Sprite 0 = abs XY
sprite 1 = link = enable, offset xy (meaning only and ONLY linked to sprite 0 offcourse)
sprite 2 = link = enable, offset xy (meaning only and ONLY linked to abs result sprite 1 offcourse)
sprite 3 = link = enable, offset xy (meaning only and ONLY linked to abs result sprite 2 offcourse)
sprite 4 = link....

and in that way goes the chain

so, in the game code

one can set sprite 1 offset 0,16
sprite 2, offset 0,16
sprite 3, offset 0,16

in that way you define a sprite block of 0,64 size

obvious offsets values must be signed.

thinks in a SKANE a live SKANE.... rounding & rounding each part relative to the its predecesor sprite

To link sprites of arbitrary NUMBER is just USELESS and fULL MORE COMPLEX....

Leaving sprites at 16x16 pixels and having more sprites is a lot flexible than having less sprites with a bigger size.

If you want a bigger sized sprite just aggregate more sprites....

if you had a bullet of 3x3 pixels it's a huge waste of sprites using a pattern of 32x32 pixels.
I do not see any limits in 16x16 pixels sprites. The Sega SMS and NES sprite size was limited to 8 pixels....

@MagicBox:about digital devices and CPUs. I know both at the very low level since i've studied them, but my knowledge is about digital logic of the '80, so things like VHDL or Verilog appears to me as wonderful. In digital circuit degign i'm 'accustomed' to think about logic ports, flip-flops, latches, .... in terms of discrete components. I do not know the limits or features of those circuits.

To be designed manually even a simple old VDP sprite engine with 4 sprites units (like TMS) is yet at a good level of complexity.

Quote:

Sprite linking: This is something I can look into, but will be difficult to implement if at all because there are 4 processing cores, 4 sprites are processed at once. In this context, the "previous" sprite is 4 sprites back. I will have to find a way to allow you to set the 'leading' sprite, and for relative sprites, which leading sprite they would belong to. I may get it to work, but with limitations like: Only every 4th sprite can be a leading sprite (0, 4, 8, 12 etc) AND any relative sprite MUST be a higher number. Sprite 3 can not be relative to leading sprite 8 for example, as sprites are processed from 0 - 127, 4 at a time, in just one pass. At sprite 3 I won't know the coords of sprite 8 yet. Perhaps flipping may still work (negating the offsets for the relative sprites and flipping the sprites themselves)

@MagicBox
You already told the sprite attributes are read in some buffer somewhere at the beginning of a frame. Wouldn't it be possible to adjust this buffer while fetching it from RAM (with only a couple of clockcycles delay)? That way the rest of the sprite system (e.g. the split-up in 4 processing cores) remains unaffected.

Anyway, just an idea, use it as you see fit.


Edit: And yes, as flyguille clarified, you can only link to the previous sprite number.