from the first post in this thread:

VDPX is the project name for the design of a new graphics processor for the MSX, from the ground up, using a powerful FPGA chip.

As for sprite modes / sizes and linking: I have decided to drop multiple sprite sizes alltogether. The system sprite size remains to be 16x16 and each sprite will support rotating/flipping.

Later on, when it's time for the command engine to be built, I will create sprite commands that do the eventual aggregating. For instance:

LD BC, #A070
LD DE, #0088
LD HL, #4020
OUT (C), B    ; Set Sprite Coords, no rotate, no flip x, no flip y
OUT (C), D    ; Starting at sprite 0
OUT (C), E    ; For a sprite array of 8 x 8 sprites
OUT (C), H    ; Left at #40, X Low byte
OUT (C), D    ; X High byte
OUT (C), L    ; Top at #20, Y byte

This sequence would update the attribute table to have 64 sprites in an 8x8 fashion positioned at a top left of 64,32 on screen. Using this sprite command it is easy to keep supporting flip and rotate as I have all the needed information at the start of the command (number of sprites in X and Y direction to aggregate) Basic equivalent:

SETSPRITE0,(64,32)-(8,8),0,0,0

Good solution.

I not thinks so!

MagicBox: sure. a vdpx basic is good to see.

Quote:

I not thinks so!

Umh, OK, so stay with v99xx things...

Quote:

Quote: I not thinks so! Umh, OK, so stay with v99xx things...

I thinks that he just back to the fixed blocky mode... and it is less flexible than .... but anyway, just BASIC needs thinks like that.... for assembly is just 4 OUTs more per sprite...

There is nothing unflexible about it. With your CPU you can arrange any sprites in any direction in any size and any configuration the way you want. The sprite command example arranges 64. Yes, 64 sprites in one go with those few OUTs. You could do 2x2, 4x2, 2x4, 8x8, 1x16.. anything you want. The 16x16 sprites are just building blocks for larger sprites.

Relative sprites won't work well with flipping, so I won't be putting in the extra effort. There are other ways to accomplish sprite linking, either by coding it or some sort of sprite command The only other option is that flipping/rotating will only apply to the individual 16x16 sprites and not the aggregated collection of linked sprites. This means that you still have to update portion of the SAT to perform a flip. Another thing that makes it borked is that the hot-spot changes around as explained earlier in the topic.

 0
1234
 5

Here you have a fancy spacecraft. Where's the hotspot? That would be the top-left of the leading sprite which is 0. Now flip this space craft. All in a sudden the hotspot has a different relative location. You would have to compensate in game code for that. For the flipped version you'd have to set the flip bit for each individual sprite, but you also have to update the relative X/Y's to the leading sprite for 5 linked sprites.

In the end setting X/Ys for a number of sprites using the CPU hardly costs any time with VDPX, especially when special sprite commands are added. A sprite command where you can set a starting sprite and then just issue X/Ys to a register with sprite auto increment. If you do this in V-blank or during normal screen drawing, sprites will not break as the SAT is cached just before drawing the screen.

In other words, VDPX will get creative commands to perform useful actions on sprites, patterns and palette.

Quote:

There is nothing unflexible about it. With your CPU you can arrange any sprites in any direction in any size and any configuration the way you want. The sprite command example arranges 64. Yes, 64 sprites in one go with those few OUTs. You could do 2x2, 4x2, 2x4, 8x8, 1x16.. anything you want. The 16x16 sprites are just building blocks for larger sprites. Relative sprites won't work well with flipping, so I won't be putting in the extra effort. There are other ways to accomplish sprite linking, either by coding it or some sort of sprite command The only other option is that flipping/rotating will only apply to the individual 16x16 sprites and not the aggregated collection of linked sprites. This means that you still have to update portion of the SAT to perform a flip. Another thing that makes it borked is that the hot-spot changes around as explained earlier in the topic. 0 1234 5 Here you have a fancy spacecraft. Where's the hotspot? That would be the top-left of the leading sprite which is 0. Now flip this space craft. All in a sudden the hotspot has a different relative location. You would have to compensate in game code for that. For the flipped version you'd have to set the flip bit for each individual sprite, but you also have to update the relative X/Y's to the leading sprite for 5 linked sprites. In the end setting X/Ys for a number of sprites using the CPU hardly costs any time with VDPX, especially when special sprite commands are added. A sprite command where you can set a starting sprite and then just issue X/Ys to a register with sprite auto increment. If you do this in V-blank or during normal screen drawing, sprites will not break as the SAT is cached just before drawing the screen. In other words, VDPX will get creative commands to perform useful actions on sprites, patterns and palette.

No, I means, that the unflexibility is just that allways it is SQUARE o rectangle, you will to waste extra sprites this way if you are not doing BIG BOSS likes....

Thinks, like "the TETRIS pieces form"... maybe I don´t want a configuration like 4x1, 2x2, 1x4 but i want 4x1 + 1 at the second column....

Thinks, about doing a main player that is 3 sprite tall , but you use 2 sprites one per hand plus arm (or maybe one per arm plus one per hand), and in the lower 2 sprite one for each leg & foot (or maybe one per leg & one per foot), for the animation ones can to just change the sprite pattern index, it is offcourse not square, and you needs that the sprite can be overlapped, if you want to do this in BASIC, you just CAN`T in basic unsing the blocky system. But you can to claim that anyway the "put sprites" sentences must be execute to change the pattern numer, and YES, but maybe and THINKS in the slowness of BASIC, the programmer instead PUT SPRITE, switch to VPOKE because it is a lot faster just for to change the patern numer in SAT (having a BASIC variable with pre-recorder SAT ADDRESS of each sprite pattern register), so, that way, it will use vpokes for animation AND PUT sprite for global player moving around screen. For more realistic articulation, the sprites needs to be overlapped.

So, whan I first in this thread proposes the blocky system... but then when wouter_ post the idea of linking because it is wayyyyy more flexible of what you can do..... in one sentence for multiple sprite characters...


And by end , REMEMBER that here about blocky or linking system, WE ARE TALKING of TO EXPAND the posibilities of BASIC's GAMES PROGRAMMING.... where like TEN basic LINES is just the correct for the ANIMATION LOOP because 15 or 20 lines is just too slow and too much...

In basic programming, at default CPU speed, is an art to do games, imagine programming, control imput, IA, sound, collision checks , all between 10 basic lines (when ON SPRITE GOSUB is not triggered) in a way to have a decent FPS rate.

Sorry, but BASIC will not be a primary focus in that respect. Basic itself is too slow for any decent fast games, not necessarily the VDP. Also don't forget you will have 128 sprites, not 32. With 128 sprites you can almost fill an entire screen! All good VDPX games when they appear will be in assembly, like all the good cartridge games of the old days. And like explained, if you want to flip a large number of linked sprites, you have to update SAT like explained before. That's going to be a lot of PUTSPRITEs and VPOKEs.

Games like Streetfighter you'd have 8x4 sprites. To animate the whole bunch you still have to do 32 vpokes just to update the pattern number for 32 sprites. In assembly this is easy using a sprite command. There will be several. A sprite command for burst updating X/Y and a command for burst updating pattern numbers. In assembly that would be just an LD HL, LD BC and LD DE and one OTIR. Not so in basic.

Be glad that in basic you'd be able to use full color sprites already without a scanline limitation VDPX can not overcome the shortcomings of the slow BASIC interpreter.

Well as for progress, the sprite engine itself is now done and performs excellent. The Fmax for the circuit is over 270Mhz, meaning that I have plenty speed headroom for the design to grow. The more logic, the lower the maximum frequency for the internals. The Sprite Engine is now an 8-stage pipeline. (Speed can be boosted again by adding more pipeline stages at the locations where bottlenecks appear)

I have now made a start with the Cache Engine, the logic that will read the VRAM and stuff the sprite engine buffer memories (SAT/SPTs). Fun stuff

Quote:

Can you show us a movie of it? Or some pictures of the results and dev. board.

There is nothing to show yet, except for pictures of wave form test benches from the FPGA development environment. I doubt they will look interesting to you

The design still sits in the development/simulation environment and hasn't seen the light yet on actual hardware. However, today I ordered my Cyclone III starter kit and a 16.7M Color LCD module to do reallife testing with.

Ow, just another thing.. seeing as how popular megarams with SCC are, I'll just add that to VDPX too. Saves you a cartridge slot as well.

Here's food for thought!

Add a bit somewhere to change the SCC's volume register implementation so that it becomes logarithmic instead of linear, making it far more suitable to team up with a PSG..

Can I give you a hint on a very special SCC improvement?

It would sufficient:

1) allow the merge of the wave buffers of the channels.

Plain scc has 5 channels and 4 buffers of 32bytes.
It would be sufficient to have optional configurations with
a) 5 channels and 2 buffers of 64 bytes.
b) 5 channels and one buffer of 128 bytes.
Naturally if you plan to emulate SCC-I, consider also
c) 5 channels and one buffer of 5*32 bytes.

2) add an interrupt to be sent when the SCC channel X reaches sample Y in the wave buffer
(Maybe active only when in merge mode)

In this way the SCC will be able to play PCM audio in parallel to the normal z80 duties.
All you need to do is configure the SCC and, at interrupt, fill the buffer of 128 bytes

We already did such an application on plain SCC using vblank, and the aforementioned HW
facilities would have improved greatly the result.


[off topic1]
We developed (NIKKIRI initial idea, dvik development) a nice application for SCC that allows
to play PCM audio, relying on vblank interrupts, in parallel to the normal z80 code and music.

The ideas are simple:

1) four channels playing at frequency F can simulate a single channel at frequency 4*F if the waves of the channels have offsets in time of 1/F/4.

2) if 4*F is equal to vblank frequency, the vblank interrupt will fall exactly when the SCC is playing the end of last sample the current wave buffers, so, in the interrupt code, you can replace wave buffer content and reset the player to the beginning of the buffers.

[off topic2]
This code has evidenced a nasty HW bug in the real SCC HW, that no emulator support.
It seems that updating waves in channel 4&5 causes a random noise in the output.
The problem is not very well studied, but quite evident in the results.