SapphiRe

And now, a video of MSXVR running ColecoVision QBIQS rom: Min. 3:14. The audio is in Spanish, sorry for the inconvenience.

Yesterday I attended 56th MSX user meeting in Barcelona (Spain). There we could saw (and test) the upcoming MSXVR, which is a new RPI based computer, with integrated keyboard and MSX slots. But not only MSX, because they will include different "cores" to play Spectrum, Amstrad and another old machines. https://msxvr.blogspot.com/p/info-en.html Some days ago, they announced the ColecoVision MSXVR core, and I contacted them to test the core on the MSX User Meeting. Also I asked about using a ColecoVision original pad with the MSXVR, and they checked hardware compatibility: Well, bring one with you and we will check it here". So I saved the ColecoVision QBIQS rom on a pendrive and took a ColecoVision pad. And yesterday we plugged them on the MSXVR. They launched the core to play the ROM and it worked without problems. There were some issues with the sound, so they will try to improve the ColecoVision core. So the MSXVR can use ColecoVision pads and also can play ColecoVision games. As the MSXVR will include some developing tools, it can be a good developing machine to create new games for MSX and Coleco.

Will try to change TV settings while playing the game and check if it works. Many thanks!

Nope, I will search it and test it.

As promised, here's a picture of QBIQS showing that green tones look identical. The design of green squares is the same as the red and blue ones. I have no idea why is this happening. Will try on a different tv ASAP.

Actually the game was coded since 2010 for MSX ? I have two HX-10 (MSX1 PAL), but changed the VDP of one of them to a 9928. So the BIOS says it's a PAL computer, but the VDP is NTSC. In order to ensure all machines could play the game in same conditions I used this detection routine. It's independent from BIOS and it works on MSX, Coleco and Sega Master System (and probably more, but not tested).

Thanks a lot. The gameplay is not affected because it's synchronized with the vblank. The NTSC/PAL detection is based on counting how many times an instruction is executed between two consecutive vblanks. PAL is 50hz that means 0,02 seconds, wich is more than 0,016 seconds on NTSC. As I said, the Z80 of MSX and Coleco has an extra cycle for each memory access, so NOP is actually 5 cycles instead of 4 cycles. If this has been incorrectly implemented on the core, means that the instructions execute faster than expected, so more instructions are executed between two consecutive vblanks and the routine detect the console as PAL, not slowing the music. This also explain why the sample is played at a higher speed: the cycles between sound outputs are not correct. In fact this weird behaviour gave me the hint on what could be the problem. I will add this to github (after creating an account) on Monday, it's hard to reply using just a cellphone. Tomorrow will take a pic of the game to show that (at least on my Phoenix) the greens are the same. Maybe it's a incompatibility of my tv with the Phoenix, will try to test it on a different tv.

Just plugged in QBIQS and switch Phoenix on. It works great with no sound glitches. But I see some problems: -QBIQS uses sprite masking to hide shoots and target over the bar. As F18A is set to display 32 sprites/line, the sprite masking has no effect. This behaviour was known. -Also noticed that I can't distinguish between green colors. On the level 1of QBIQS there are some RGB cubes and the red and blue ones show three different tones, but the green cubes are displayed as a plain green hexagon. Not sure why is this hapening. -As Phoenix is NTSC, QBIQS should detect it and slow music. But the music plays faster than composed, so the NTSC detection doesn't works. As it works perfectly on emu (and on real MSX) I must check if it's a code problem or not. -Related to last one, there's a voice sample for GAME OVER. It also plays faster than expected. But the replayer takes into acount the cycles of instructions. AFAIK, the Coleco has the same extra cycle when accessing to memory than MSX, has been this correctly implemented on the core? As the NTSC detection is related to cycle calculations, an incorrect number of cycles could be an answer for the music and samples going faster than expected. Besides those problems, I'm very happy with my Phoenix. Great work!! ???

Hi!! My CollectorVision Phoenix just arrived home 10 minutes ago!!! Exactly 1 year after I purchased it. Serial no. 000196. Will test it ASAP with QBIQS and Sydney Hunter ?????

Whoooooaaah!! ???

Duplicated post... Sorry

Thanks!! But shipping cost is 15.95$ to Spain. Will continue looking on local dealers, but is good to know where to find heatsinks, maybe buying a large quantity will make shiping costs more affordable.

JL, I have a 9928 for you. If you come next Saturday, the 9928 will be there. Btw, do you know where to buy a heatsink of the correct size for those vdp? Need one for one of my HX-10...

Done!! :grin:

Aas soon as I will be in front of a computer, I will place my preorder too. Tried using my cellphone, but it sucks...