MSX 2 emulator with debug features | MSX Resource Center (Страница 1/2)

By santiontanon

Paragon (1639)

09-12-2021, 03:40

Hi albs_br, does the openMSX_debugger not offer any of the features you need?

By albs_br

Champion (386)

09-12-2021, 04:39

I'm not sure.

Actually I'm having a really hard time dealing with sprites on 9938.

The sprites are drawn on screen differently accordingly to the position they are on Atrributes table.

For example:

TestSpriteAttributes:
    ;   Y, X, Pattern, Reserved
    db  50, 120, 0 * 4, 0
.size:  equ $ - TestSpriteAttributes

Works fine.

If I put some dummy data on the first entry of SPRATR, it blows up everything:

TestSpriteAttributes:
    ;   Y, X, Pattern, Reserved
    db  220, 0, 0, 0
    db  50, 120, 0 * 4, 0
.size:  equ $ - TestSpriteAttributes

Does it make any sense?

The sprites are OR-color prepared, should they behave this strange way?

By albs_br

Champion (386)

09-12-2021, 04:44

Example code here:

https://github.com/albs-br/msx-tests/blob/master/test-sprite...

The second sprite wont show, don't know why.

By Daemos

Paragon (1983)

09-12-2021, 09:48

Try the openmsx debugger. If you cannot find out whats going on with that tool. The alternatives probably won't help you either. Just set the speed to 1 and keep waiting until your sprite dissapears. Then pause the emu and see whats going on on the registers of your vdp. You can then step back and find out which line outed the wrong register and why.

By theNestruo

Champion (351)

09-12-2021, 10:15

Not an MSX2 code myself... but I think that in MSX2 you need to set the sprite color data per sprite plane

By Grauw

Ascended (10604)

09-12-2021, 10:28

Yes, I think theNestruo is right. You only set sprite colour for sprite plane 0, when you add another sprite it will be on plane 1 with an unspecified colour (probably 0, transparent).

By aoineko

Champion (484)

09-12-2021, 12:12

Besides the specific problem of Albs_br, it would be so great to have a tiles and sprites viewer in the OpenMSX debugger like the one we have in Mesei or Emulicious (but only for MSX1).
It saves so much time when creating a game!
I know the answer to that question is "just do it", but I don't have the knowledge (nor the motivation to acquire it, to be honest).

Emulicious:

Meisei:
http://msxvillage.fr/upload/meisei.jpg

By albs_br

Champion (386)

09-12-2021, 15:24

OMG. That's it, the colors are for the 32 sprite planes, not the 64 (or 256) patterns.

I have very little msx2 experience. Tonight I will make the changes but I'm sure that's the error. Thanks a lot.

By sd_snatcher

Prophet (3512)

10-12-2021, 21:55

aoineko wrote:

Besides the specific problem of Albs_br, it would be so great to have a tiles and sprites viewer in the OpenMSX debugger like the one we have in Mesei or Emulicious (but only for MSX1).
It saves so much time when creating a game!
I know the answer to that question is "just do it", but I don't have the knowledge (nor the motivation to acquire it, to be honest).

Emulicious:

Meisei:
http://msxvillage.fr/upload/meisei.jpg

I second this. It would be a dream to have proper screen-2 to screen-4 support on the openMSX-debugger VDP->Bitmapped VRAM window.

That and a better watchpoint support for VRAM reads/writes. I try to workaround this with some TCL juggling, but usually it only breaks on the subsequent VRAM writes. For bulk-write blocks this is fine, but for single byte writes it can be a headache.

By Manuel

Ascended (18868)

12-12-2021, 00:11

Why not use the VDP-> Tiles in VRAM viewer? Better than nothing, right?

There's a sprites viewer option as well, but unfortunately, it just opens the Tile Viewer.... So, I guess that was never implemented.