new GFX card

Page 15/20
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17 | 18 | 19 | 20

By MagicBox

Master (198)

MagicBox's picture

23-09-2008, 21:38

I did for Z80, the Z80 would have to run at 8x 3.54MHz (28MHz) to get 2 read/writes to VRAM in per pixel clock. 2 Writes would take 6 VDPX clocks (4 for read) while there are 60 per pixel clock. Of these 60, 40 some are used for for processing by VDPX, leaving 20 'spare' clocks for CPU access and future processing.

I haven't taken R800 into account though, but if its bus cycle is the same as Z80, then R800 is covered as well, even at its increased speed

By PingPong

Prophet (3793)

PingPong's picture

24-09-2008, 20:22

@MagicBox: the R800 bus cycle is something different from z80 one. Unfortunately i have no info about it's timing. What i know is that the r800 avoid 1 T-STATE that is used on z80 to set the CAS or RAS signal (because on most msx architectures memory is arranged in a way that one of the two signals does not change for 256 bytes.) the r800 saves 1 cycle in opcode fetching comparing the last value of the higher address bytes with the actual, and if the high address bits are unchanged no extra cycle is added. However every 256 bytes there is surely and extra cycle added.

This is what i know about opcode fetch - opcode execution cycles, i do not know if even apply for data fetchs. I think no.... What's important here is that there is a signal that can provide memory syncronization. At least the R800 will have to wait shortly.... Not a big problem.

By MagicBox

Master (198)

MagicBox's picture

24-09-2008, 20:30

It works differently, that I do know. RAS/CAS is handled by the engine, not the CPU. The R800 will guaranteedly have an asynchronous write (setup address, setup data, assert MREQ assert WR for a certain period).

VDPX samples the bus activity and when it detects a write as above, it just picks it up. VDPX will have written the memory location way before R800's / Z80's write cycle has finished. Remember it runs at 200MHz. VDPX will never make the CPU wait for anything. In fact, VDPX will be made that it won't need to wait on the CPU. On a read, VDPX buffers the VRAM byte and just keeps it available for the CPU to read from while internal processing continues immediately after a mere 2 200MHz clock ticks.

Edit: To be sure, I'll try to find R800 timing diagrams. I don't expect any trouble though Wink

By MagicBox

Master (198)

MagicBox's picture

25-09-2008, 09:52

Just a bit more.. sprite attribute table now has a pattern index of 9 bits -> 512 patterns possible. Also each sprite has a "collision enable" bit so you can specify for which sprites collision should be detected Smile

By PingPong

Prophet (3793)

PingPong's picture

26-09-2008, 00:53

Having 1 statusbits for each plane could be good (like c64). Of course for c64 it's easy only 8 sprites -> 1 byte for all status bits.

By MagicBox

Master (198)

MagicBox's picture

26-09-2008, 01:07

I'm still sort of trying to figure out what would be a good collision detection system. More specifically, how the CPU could get to know which sprites collided. There is the basic method of "any two or more sprites have collided" but then the CPU still has to do a reasonable amount to figure out which sprites have collided. Setting a collision bit for each sprite helps in that, you'd only set it for the sprite that's player controlled. Take space manbow; you would not get collision events if enemies overlap/collide, only when the space ship hits another sprite.

If you'd go dual-player like Salamander cooperative 2-player, you'd set the collision bit for the 2 player space craft.

Cross sprite hitlists would be impossible (for each sprite a table of what sprite it is hitting). I was thinking more of a way for the CPU to "ask" the VDP if two sprites are hitting like is sprite 0 hitting sprite 1? and get a yes/no answer. Basically 2 outs and 1 in. It would be much faster than the average coordinate check (sprite rectangles overlap?). Then there's the problem that sprite rectangles may overlap, but the actual sprite images are not colliding. Using the rectangle overlap detection would report this as a false hit. Having the VDP figure it out for the CPU would be both faster and 100% accurate.

By RyJuZo

Master (236)

RyJuZo's picture

26-09-2008, 10:10

"If does, the sprite visible bit is then used to see if sprite is valid. "

Yes, sprites will have a visible bit in the attribute table Wink

#0: sprite x, bits 7 - 0
#1: sprite visible bit (bit 7), sprite x bit 8 (bit 0), (bit 6 - 1 reserved, not used)
#2: sprite y, bits 7 - 0
#3: sprite pattern bits 7 - 0

As for the device, I'm going to use a EP3C16Q240C8 device, a 240 pins flatpack IC from Altera.

dont forget the FLIP X/Y bits....very handy if available....(see GBA)

By MagicBox

Master (198)

MagicBox's picture

26-09-2008, 12:27

That would be easy to implement, but we'll have to make a trade-off soon; I do not want to exceed 32 bits of attribute data for a sprite. All bits would be used now:

l2, l1, l0, sv, fx, fy, ce, x8 -> means back to 256 patterns

l2 - l0 = layer priority, 0 - 7
sv = sprite visible
fx = flip x
fy = flip y
ce = collision enable
x8 = x coord 9th bit

Although, I can see if a 64 bit attribute array is possible with the design without negatively impacting Fmax. If it does, it makes things a lot easier as well. We'll get 8 bytes of attribute data then.

Sort of funny, the sprite engine processing bus will then be 256 bits wide Tongue

By RyJuZo

Master (236)

RyJuZo's picture

26-09-2008, 14:54

That would be easy to implement, but we'll have to make a trade-off soon; I do not want to exceed 32 bits of attribute data for a sprite. All bits would be used now:

l2, l1, l0, sv, fx, fy, ce, x8 -> means back to 256 patterns

l2 - l0 = layer priority, 0 - 7
sv = sprite visible
fx = flip x
fy = flip y
ce = collision enable
x8 = x coord 9th bit

Although, I can see if a 64 bit attribute array is possible with the design without negatively impacting Fmax. If it does, it makes things a lot easier as well. We'll get 8 bytes of attribute data then.

Sort of funny, the sprite engine processing bus will then be 256 bits wide Tongue

well it's my opinion as a gamedeveloper that the flip bit's are very practical. You'll only have to design animations for a 90 degrees corner and the rest can be done with hardware.

If it turns out that having both axes flipped is too much I would at least consider leaving the FLIP AROUND Y-AXIS which problably most used.

By MagicBox

Master (198)

MagicBox's picture

26-09-2008, 15:05

That would not entirely be true; for a 2d isometric view (bomberman) you have to design 3 directions. Left/Right indeed can flip. Up you see the player's back, down you see the player's front. Flip on X axis doesn't seem very practical at all.

Once you begin to create more advanced graphics (sprites that seem to have a lightsource shining onto them fron top left) will look very unnatural when they are just flipped.

Edit: Not to say you won't get flip bits, just pointing out that in a VDPX environment they hardly will be a true necessity..

Page 15/20
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17 | 18 | 19 | 20