Okay, I guess a video says more than words. Here's the #MSX #ROM of #PacMan running on my #rc2014 - it's a #RomWBW machine with a #TynemouthSoftware #Joystick module and the latest #TMSemu by @shieladixon - no other MSX-related or otherwise "non-common" modules on the system.
What the video shows is that #MSX8 is actually doing its stuff, running the original MSX game. But as you can also see, the player (Pac Man) is always moving up.
I can make it go down, but as as soon as I release the stick, it goes up again. Also, I can only move up and down and this is done by moving the Joystick to either the left or the right.
I have checked the MSX8 bios.asm code for the MSX8CPMRC2014 build of MSX8 BIOS and while it should be working, it isn't.
I did hard-code the address of my joystick module ($01) at line 4848 in bios.asm to get the input from it, but somehow the mapping of the MSX specific "keys" or "inputs" like Up/Down/Left/Right is not properly working. Oh, and it seems that Fire Button 1 is always pressed as well.
So, long story short: it should be possible to make MSX8 work without the need for special modules, but right now I'm a little lost as to how to modify the code to get proper input readings.
P.S.: you can modify the bios.asm code to use W/A/S/D instead of a joystick jumping to KBDJSTK instead of JSTK. But even then the controls behave in the same insane way as explained above.
Any help or even cooperation is welcome, let's make MSX games rock on RC2014 !!
=> More informations about this toot | More toots from Wintermute_BBS@oldbytes.space
@Wintermute_BBS @shieladixon Can it be that PacMan is not using the bios for reading the joystick? Maybe it's taking the input straight from the I/O port?
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@bitsofbas @Wintermute_BBS MSX software and games should make bios calls for those things, but I guess there's no telling whether they do or not without searching the game code.
=> More informations about this toot | More toots from shieladixon@oldbytes.space
@shieladixon @Wintermute_BBS Many of them don't. Especially early games ran into problems by not using the bios.
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@shieladixon @bitsofbas some uplifting news: I've tried "Track And Field" and while the sprites looked a little "offset", I was actually able to play the game!! Wow!
So it indeed seems like non-BIOS calls to the joystick ports seem to be the problem with Pac Man and Dig Dug ...
=> More informations about this toot | More toots from Wintermute_BBS@oldbytes.space
@Wintermute_BBS @shieladixon Haven't looked at the code, but Konami tends to "properly" use the BIOS.
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@Wintermute_BBS @shieladixon Offset as in that their horizontal position is about 32 pixels wrong? If that's the case, it could be the EC ( early clock ) flag on the sprite attribute table isn't implemented properly in the emulation.
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@bitsofbas @shieladixon hmm ... not sure. maybe. it looks like this:
=> More informations about this toot | More toots from Wintermute_BBS@oldbytes.space
@Wintermute_BBS Oh, yikes! Nope, that's something else then!
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@Wintermute_BBS @bitsofbas I think a 'little offset' is an understatement. EC bit should be observed correctly but there's a lot wrong there, both in horizontal and vertical, and colours. I'll try to reproduce and look into it.
=> More informations about this toot | More toots from shieladixon@oldbytes.space
@shieladixon @Wintermute_BBS Yeah, totally. I thought EC from your first description, but looking at your screenshot, that's just something completely different.
These ARE sprites, they are in the correct place with the correct color, but they are the wrong index.
No idea what happened there!
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@bitsofbas @Wintermute_BBS I'm thinking a missed byte when attribute data was being sent. Are you running at 7.3 Mhz, Wintermute?
=> More informations about this toot | More toots from shieladixon@oldbytes.space
@shieladixon @bitsofbas that's correct!
=> More informations about this toot | More toots from Wintermute_BBS@oldbytes.space
@Wintermute_BBS @bitsofbas Well that was an interesting one. (well I find it interesting!) The 'name' value in the attribute table should be a multiple of 4 for 16x16 sprites (which makes sense because you can also have 8x8 sprites). However, the values in this game are multiples of 4, plus 2! I guess the logic of the real TMS chip just takes the bits it needs. My emulator was multiplying the name byte by 8, giving an incorrect lookup for the sprite data in this case. Masking off the lower 2 bits (when sprites are 16x16) did the trick! I can't see anything in the documentation that makes this clear. I guess one of those times where the developer does something weird but it stays in because it works.
=> View attached media | View attached media
=> More informations about this toot | More toots from shieladixon@oldbytes.space
@shieladixon @Wintermute_BBS Oh wow, interesting! Sloppy on Konami's behalf! But if it worked, it worked! π
=> More informations about this toot | More toots from bitsofbas@mstdn.social
@Wintermute_BBS I don't think the Tynemouth joystick is going to work unless MSX8 is modified especially to read it. In that case the joystick just modifies bits on a particular port. The MSX system is way more complex and reads ports provided by the AY chip. I guess if you have an AY module connected, with nothing connected to its i/o ports then those will be floating, leading to 'always up' type behaviour.
=> More informations about this toot | More toots from shieladixon@oldbytes.space This content has been proxied by September (3851b).Proxy Information
text/gemini