Hi guys,
Is there a MSX 2 emulator with good debug features (I mean VRAM debug features)?
I like the tools found on Emicious, unfortunately it is only a MSX 1 emulator.
Login or register to post comments
Hi guys,
Is there a MSX 2 emulator with good debug features (I mean VRAM debug features)?
I like the tools found on Emicious, unfortunately it is only a MSX 1 emulator.
Hi albs_br, does the openMSX_debugger not offer any of the features you need?
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?
Example code here:
https://github.com/albs-br/msx-tests/blob/master/test-sprite...
The second sprite wont show, don't know why.
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.
Not an MSX2 code myself... but I think that in MSX2 you need to set the sprite color data per sprite plane
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).
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:
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.
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:
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.
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.
Don't you have an account yet? Become an MSX-friend and register an account!