SpritesMind.Net

Posted: **Tue Dec 22, 2009 2:27 pm**

I am wondering wich is the relationship between the VDP & Kernel mode.

The facts that happen with Gens are:

- If I do not go to user mode nothing is painting on screen.
- In user mode I can not modify main VDP registers, it have no efect. For example X resolution.

Since I am waiting for EPROMs I cann't test it on real hardware.

¿That means that Kernel mode is some kind of non-paint mode, as long as you stay on it nothing paints, and user mode enables VPD? Or what...?

In the same way I found an error in MDKit since it tries to modify main registers in user mode. It works because they are set previusly in asm file. Well, I think... I am a newbe on MD programing... so if I'm wrong just tell me.

Thanks for your info!

Posted: **Tue Dec 22, 2009 2:54 pm**

User mode should not make a difference regarding VDP, I've not really messed with it as there's no need to be anywhere else than in Supervisor/Privileged/Kernel mode in MD stuff...

Posted: **Tue Dec 22, 2009 3:36 pm**

Sorry I am wrong in one thing, I can modify VDP registers even in user or kernel mode.
MDKit works OK, sorry.

BUT if I not leave kernel mode nothing displays in Gens & Kega Fusion, and Gens KMOD not shows my palettes (¿??), shows only black colors (I confuse that with VPD registers

).

Posted: **Tue Dec 22, 2009 8:53 pm**

User/Supervisor mode makes no difference on the Genesis. Everything I've seen runs in supervisor mode. Just remember that the user stack pointer and supervisor stack pointer are not the same thing. While in super state, you have to do "MOVE An,USP" to set the user stack pointer. If you don't, the stack pointer won't be set to a known value when you switch to user mode.

Posted: **Tue Dec 29, 2009 1:04 am**

It seems that your are right. The problem came from this code:

* user mode
move.w #0x2300,%sr

which I believed blindly. The 0x0300 activates certain level of interrupts. And the 0x2000 set the ISP as the stack pointer, so it always uses the same stack. Right?

Another questions:

In KEGA if I turn off the display (set 0 to the adequate bit in register 1 of VDP) I continue receiving VINT. Is it correct in real hardware?

When can I turn off the display (or when it takes effect), only in VBlanks or anytime?

If I move large amount of data to the DSP with the DSP activated, I see a corrupt data on screen (a line of titles not shown), should I turn off the dsp before?

Thanks for your help.

Posted: **Tue Dec 29, 2009 2:05 pm**

eteream wrote:It seems that your are right. The problem came from this code:

* user mode
move.w #0x2300,%sr
which I believed blindly. The 0x0300 activates certain level of interrupts. And the 0x2000 set the ISP as the stack pointer, so it always uses the same stack. Right?

I don't know exactly what it does but if you don't do it you won't have any interrupts.

eteream wrote: Another questions:

In KEGA if I turn off the display (set 0 to the adequate bit in register 1 of VDP) I continue receiving VINT. Is it correct in real hardware?

Yes.

eteream wrote:I
When can I turn off the display (or when it takes effect), only in VBlanks or anytime?

You can disable the display at any time but I think it takes effects at the next VBLANK. (I might be wrong about this).

eteream wrote:I
If I move large amount of data to the DSP with the DSP activated, I see a corrupt data on screen (a line of titles not shown), should I turn off the dsp before?

Thanks for your help.

Posted: **Tue Dec 29, 2009 4:38 pm**

thanks!! It helps a lot!

eteream wrote: If I move large amount of data to the DSP with the DSP activated, I see a corrupt data on screen (a line of titles not shown), should I turn off the dsp before?

I don't know when it happens, random.
The problem is in plane A memory. No HINT enabled. If I move data with DMA all works. But if I move word by word this is what happens.

¿Must I look for a DMA or VDP busy bit before accesing VDP memory?

UPDATE: RESOLVED

I know what is happening, is the VINT: I always update sprites on this interruption, so when a VINT is triggered it overwrites current move operation address.

Last question:

The DMA-FILL operation for 16bits (a word) works on real hardware? It does on Gens, but seems to not work on
KEGA Fusion.
Documentation doesn't speak about it.

Posted: **Tue Dec 29, 2009 6:12 pm**

DMA fill is 8 bits only for VRAM, i'm surprised Gens does 16 bits fill but if it's the case; it's a bug in Gens :-/

Posted: **Tue Dec 29, 2009 11:38 pm**

That's what I do:

Code: Select all


enum xxx{
ADDR_PLANE_B		= 0xE000,
PLANE_SIZE		= 0x1000, // 64x32 tiles
};

#define DO_DMA_FILL(destination,size,value) _DoDMA16Fill(destination,(u16u8)(u16)((size)>>1),value)

static volatile u16* const g_pCtrlPort16 = (u16*)0x00C00004;

inline void _DoDMA16Fill( u16 destination, u16u8 size, u16 value )
{
	// Wait for last dma end,until I make a queue
	while( (*g_pCtrlPort16) & VDP_DMABUSY_FLAG ) asm("nop");

	// Setup DMA length
    *g_pCtrlPort16 = REG(19) | size.byte0;
    *g_pCtrlPort16 = REG(20) | size.byte1;

    // Setup DMA operation (VRAM FILL)
    *g_pCtrlPort16 = REG(23) | 80;

	// Setup destination
	*g_pCtrlPort16 = 0x4000 | (destination & 0x3FFF);
	*g_pCtrlPort16 = 0x0080 | (destination >> 14);

    // Set up value to fill
    *g_pDataPort16 = value;
}

...

DO_DMA_FILL( ADDR_PLANE_B, PLANE_SIZE, 0x0000 );

...

and works as intended in Gens (It shows first title on all the plane B), but not in KEGA.

Big thanks to all you!

Posted: **Wed Dec 30, 2009 1:06 am**

if the thing does not behave same in all decent emulators, it will not behave on real HW either...

Posted: **Wed Dec 30, 2009 8:43 am**

eteream wrote:That's what I do:
Code: Select all
...
and works as intended in Gens (It shows first title on all the plane B), but not in KEGA.

Big thanks to all you!

What about the value of the increment register (register 15 if i remember correctly) ? I guess you set it to 2 if you want to do word fill ?
If you can't test on real hardware, post your bin here, i'm sure someone can test it for you but again, i know DMA FILL works as byte operation on VRAM so Kega is probably correct here.

Posted: **Wed Dec 30, 2009 8:34 pm**

Stef, I set this value to 2 at the very begining of my code. My first intention was to always work with 16bits, and don-t change it. Now I find that is not posible. So, now I will work with 8bits with dma-fill, and change this value acording with the operation.

I began to read about MD internals few weeks ago, so all is new for me.

I expect that the eproms arrives shortly, if not I will post the bin here, thanks!

Posted: **Thu Dec 31, 2009 8:48 am**

eteream wrote:Stef, I set this value to 2 at the very begining of my code. My first intention was to always work with 16bits, and don-t change it. Now I find that is not posible. So, now I will work with 8bits with dma-fill, and change this value acording with the operation.

I began to read about MD internals few weeks ago, so all is new for me.

I expect that the eproms arrives shortly, if not I will post the bin here, thanks!

For someone which are in MD stufff since few weeks, you're going quite well !
I wrote a mini dev kit which can help you to speed up yours dev and even if you don't use it directly you can at least use it as source of informations :

viewtopic.php?t=14&start=0

Posted: **Thu Dec 31, 2009 7:46 pm**

You can get Stef's Mini Devkit at the link in library format, usable with gcc toolchains. That was easier for me than trying to include all the different files in the makefile.

libmd.zip

Posted: **Sat Jan 02, 2010 8:14 pm**

Stef wrote: I wrote a mini dev kit which can help you to speed up yours dev and even if you don't use it directly you can at least use it as source of informations :

Of course!, I'm using it to retrieve information in a fast way. Yeaahhh! reading C is faster thant natural languaje...

But I'm using main own code to understant how MD works at 100% (or that is my intention), but apart from this, it is very similar to yours.

Chilly Willy wrote:You can get Stef's Mini Devkit at the link in library format, usable with gcc toolchains. That was easier for me than trying to include all the different files in the makefile.

libmd.zip

Thanks! It's realy fantastic: MD development in few seconds. Thanks Stef!

The only thing that is mising is a C compiler for Z80... and well, a method to share real address between the two compilations (for music mapping from Z80 to ROM).

I'm tring the SDCC compiler for C for Z80, but it generates some king of hexadecimal code, i'm working on it...

EDIT:

Now I see that since there is no kind of timers on the z80, the timing of cicles of instructions are used to do the 'timing'. Well, you can use VINT as a timers, if you find music at 60hz... So doing it with C sounds crazy... well, unless you modify the compiler...

Stef, are you the creator of gens?

SpritesMind.Net

Relationship between VDP and User/Kernel Mode?

Relationship between VDP and User/Kernel Mode?