GhostWriterP, can you be a bit more specific on what kind of crap (more precisely what apps are you running)? 2.7.1 is the latest version btw.There is a bug (I believe) in the moonsound code (in the fm 4-op part) and it is fixed in the latest openMSX.
That bug has been there for ages, and I was very suprised hear it's been fixed.
So when will blueMSX be updated?
Hmm, there has been a 4-op bugfix last year (21 May 2007), in revisions 6503 and 6504. So, maybe it wasn't ported back into blueMSX yet.
GhostWriterP, can you be a bit more specific on what kind of crap (more precisely what apps are you running)? 2.7.1 is the latest version btw.I think GhostwriterP uses Realfun. You can download a version of Realfun here. The 'crap' is pretty obvious with the song 'dancemaster'.
I'll update the opl code in bluemsx for the next release then. Thanks for pointing it out.
where can i get my own realfun?
where can i get my own realfun?Check the link sjoerd posted on March 09, 16:36CET.
I've discovered what can be possibly a bug in BlueMSX. Perhaps it is a bad implementation of the original MSX BIOS, but I'm not sure about it, so I'm asking it here.
In order to test the compatibility of a MSX development, I created a BlueMSX machine with only BIOS on slot 0 and 8 KB RAM on slot 3, from E000-FFFF. When the machine is booted, it indicates 28815 bytes free. If I ask for a PRINT FRE(0) it gives the same result. But, of course, if I type a BASIC line, it isn't stored. I mean:
10 PRINT "Hello World"
list
Ok
[]
I guess that the emulated machine does not realize that it only has 8 KB. Perhaps there is a problem in the emulation of RAM, because I think that CHKRAM (0000h) BIOS routine is prepared to handle such eventualities.
It also happens if I set a 16 KB RAM machine. It still indicates 28815 bytes and does not work properly.
I must say that I haven't tested it on openMSX because it is not that easy (point'n'click) as in BlueMSX and I was in a hurry. I know that the Casio PV7 has only 8 KB, but I don't know if it is supported and, in the other side, I don't owe their ROMs.
Any idea regarding this? Kind of weird.
Ok. I've conducted the same test using openMSX (Windoze) and it works perfectly. I've created a new XML specification of a brand new MSX with only 8 KB of RAM in slot 3, and it displays the correct amount of free RAM, 4,239 bytes (whoa, more than 4KB available for your delight).
Therefore, I can formulate only two different explanations for BlueMSX problem:
(a) The included BIOS has been patched or is a badly coded one that expects 64 KB of RAM, not more, not lesss.
(b) There is a problem with regular RAM emulation that prevents the correct detection.
And of course, a third one, for sake of completeness:
(c) I'm a total n00b and I'm not doing it properly.
No one?
I haven't had a chance to test it yet. I really don't think (c) is an option, so either a or b. all sizes of memory are emulated but maybe there is a bug in the emulation. I'll let you know, and if it is a bug it will be fixed in next release. It sounds like a very minor one.
