Msx1 race engine

Pagina 1/4
| 2 | 3 | 4

Door smx

Resident (42)

afbeelding van smx

08-08-2020, 12:47

Hi, I'm in the process of building a racing game engine Msx1 Race engine
Top Screen
To do this I change the VDP 2 register to change colors, so that the result is very fast. (colors are fixed for all process and all screens and VDP 2 change value of name table)
When I switch screens instead, I use a RAM to VRAM load
I come to the question: is it possible to change the value of the VDP register in a completely independent way (to obtain 50\60 screen per seconds) and leave the loading of the screens separately even if slow?

Thanks

Aangemeld of registreer om reacties te plaatsen

Van santiontanon

Paragon (1093)

afbeelding van santiontanon

08-08-2020, 22:08

Looking pretty nice! How may different frames does the "moving forward" animation have?

As for changing the VDP register in a "completely independent way". I'm not sure exactly what do you mean. But, do you mean changing the register in the interrupt handler (that happens 50/60 times per second), and transfer the name tables in your main loop?

Van Sandy Brand

Master (196)

afbeelding van Sandy Brand

09-08-2020, 00:43

Nice effect! Smile

Yes, technically, you can change any of the VDP registers and/or VRAM bytes at any point in time and in any order.

However, when the VDP is 'drawing' the screen from left-to-right, and from top-to-bottom, any changes made to VDP registers and/or VRAM will take effect more or less immediately. So you will have to be careful as to when to change VDP registers, and ideally not write into VRAM that is currently 'being drawn' as otherwise you might see 'tearing' or other visual glitches.

So, as santiontanon suggested, it is usually best to do this in the V-blank interrupt handler (H.TIMI at $FD9F) as the VDP is at that moment not drawing anything on the screen.

I assume that in your case it might take the CPU too much time to copy the new data into VRAM and it will not fit in the V-blank? However, it will be perfectly fine to handle the animation by changing VDP 2 in the V-blank interrupt, while outside the interrupt handler you are copying new data into VRAM: you can change VDP 2 halfway through writing to VRAM without any problems.

(I presume you are using a 'front' and 'back' buffer in VRAM to make sure you don't get any glitches on screen while writing into VRAM?)

Note: From your description it is not clear if you are just using BIOS functions or if you are directly writing to VDP registers yourself. If you are doing it yourself, you need to make sure that no interrupts occur while you are changing a VDP register: this usually takes 2 (or 4) OUT opcodes and these should not be interrupted with other OUT opcodes, otherwise data might reach the VDP out-of-order and the results might be unpredictable.

Van thegeps

Hero (555)

afbeelding van thegeps

09-08-2020, 17:36

I used the same technique in a basic game for a 10line contest. You can hook in ISR the register update easily. Doing so you haven't to worry about interrupt occurring (you are already in one interrupt) so you don't have to di and ei when writing into reg

Van Grauw

Ascended (9342)

afbeelding van Grauw

09-08-2020, 18:18

On TMS9918, iirc changing VDP registers also alters the VRAM pointer address, because the VRAM pointer low byte is also used by the VDP to store the register value temporarily.

So if you want to change a VDP register on the interrupt, you need to make sure to cut your VRAM transfers into small enough chunks (e.g. 256 bytes), disable interrupts during the transfer, enable interrupts briefly inbetween transfers to allow the interrupt to occur, and re-set the VRAM address for the transfer of the next chunk.

On V9938 you do not need this, because it has a separate buffer for the VDP register value, although there the buffer is shared with the palette port, so when updating the palette you need to take similar precautions if there is an interrupt handler which changes registers.

(Of course if the VRAM transfer or palette change happen on the interrupt as well, there is no issue.)

Van santiontanon

Paragon (1093)

afbeelding van santiontanon

09-08-2020, 18:25

Also, thinking more about this, transferring a name table is small enough information that it can be done in a single frame (even whole screen name table transfer, which is just 768 bytes). So, you should be able to fit a whole name table copy + change VDP register in one frame without problems, no?

Van thegeps

Hero (555)

afbeelding van thegeps

09-08-2020, 19:41

Indeed. Probably he has to redefine dynamically a certain number of tiles, I suppose, so this need time

Van Sandy Brand

Master (196)

afbeelding van Sandy Brand

09-08-2020, 20:03

Grauw wrote:

On TMS9918, iirc changing VDP registers also alters the VRAM pointer address, because the VRAM pointer low byte is also used by the VDP to store the register value temporarily.

Oh wow, I didn't know this!

I assumed that as the V9938 is backwards compatible, that no such limitations existed in the first place.

Wrong assumptions then Sad

Van Grauw

Ascended (9342)

afbeelding van Grauw

09-08-2020, 20:46

You can in theory use it to your advantage in some situations to get a little faster random access (e.g. when accessing the SAT). However because it is not upwards compatible with the V9938 (and possibly not all TMS9918 clones either, I forgot), I would not recommend it. Also you need to reset it of course after use, pretty sure a in (99h) does that but not sure an out (98h) will... Edit: it does according to my post in the thread I mentioned below.

Van PingPong

Prophet (3555)

afbeelding van PingPong

09-08-2020, 20:38

Sandy Brand wrote:
Grauw wrote:

On TMS9918, iirc changing VDP registers also alters the VRAM pointer address, because the VRAM pointer low byte is also used by the VDP to store the register value temporarily.

Oh wow, I didn't know this!

I assumed that as the V9938 is backwards compatible, that no such limitations existed in the first place.

Wrong assumptions then Sad

the devil is in the details ;-)

I do not think neither yamaha nor texas worried about those implementations details.

Van Grauw

Ascended (9342)

afbeelding van Grauw

09-08-2020, 20:48

Ah, I found the thread about it.

@PingPong If someone would test it on the YM2220 (Yamaha's first TMS9918 clone) that would probably tell whether Yamaha was aware of it and purposely upgraded it on the V9938 or if they always implemented it like this.

Pagina 1/4
| 2 | 3 | 4