I noticed amazing something on OpenMSX and other emulators, when I enter PRINT PEEK(&HFFE8) on an emulated MSX1, I get 255. I get 0 on my real MSX1s (TMS9918A). I was thinking the BIOS writes 0 in reserved values but it seems not always the case.
I was thinking the BIOS writes 0 in reserved values but it seems not always the case.
The MSX1 BIOS does not initialise the VDP mirrors that only the MSX2 BIOS and up knows about. The simplest way to confirm for yourself whether the address is initialised by the BIOS is to boot the machine, POKE a value to it, reset the machine, and PEEK it. OpenMSX also has a setting which tells you when uninitialised memory is read from (outputs to system console).
The initial value on a cold boot depends on the brand & type of RAM chips used in the particular machine, and could be 0, 255 or something else, and could be constant or form a repeating pattern like 255 255 0 0 255 255 0 0. OpenMSX tries to emulate this on some machines, it has configuration for initial RAM patterns, but this is not defined (not known) for every machine and also may not be accurate for all revisions or batches of a machine.
Ok, I thought that the BIOS initializes also the reserved variables but that it isn't. It's annoying.
Issue: My FM-PAC detection routine "suddenly" couldn't find (external) FMPAC. I couldn't find much wrong, so I moved the "ext fmpac" out of the config-file, and replaced with "-ext fmpac" on the command line. Then it worked.
I tested "the game we don't mention" the same way. That game wont play FM-music either when the ext fmpac is in the config-file. Is this a known issue?
May not matter, but my detection routine runs from a (mega-)ROM-file and the machine used was Philips_NMS_8250/Philips_NMS_8255. Detection is done immediately on startup.
openmsx 17.0
ok, made an issue on github instead.
Sorry, completely missed that. Replied on GitHub.
For those who wonder: there was no bug in openMSX, but in the used start up script.
I tryed FDATE.COM with a DSK. It seems works fine, but when I try it in a folder as disk, it doesn't work properly. I use OpenMSX v0.15.
I tryed FDATE.COM with a DSK. It seems works fine, but when I try it in a folder as disk, it doesn't work properly. I use OpenMSX v0.15.
That's indeed the current behavior: dir-as-disk keeps the content of the files on the MSX- and on the host-side in sync but not (yet?) the file modification timestamps.
In part because modifying the host-file timestamp requires OS-specific code (e.g. different code for Linux and Windows). And at the time this didn't seem worth the extra effort.
Can you elaborate on how you discovered this missing feature and why you need it? Maybe we should reconsider and do spend that extra effort?
I translated FDATE using the source code and I tested it because I had to modify the program to be able to compile it. I also changed the date format to YYYY:MM:DD
.