openMSX bugs

صفحة 13/13
6 | 7 | 8 | 9 | 10 | 11 | 12 |

بواسطة gdx

Enlighted (5508)

صورة gdx

09-07-2021, 09:36

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.

بواسطة Grauw

Ascended (10581)

صورة Grauw

09-07-2021, 13:30

gdx wrote:

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.

بواسطة gdx

Enlighted (5508)

صورة gdx

09-07-2021, 13:54

Ok, I thought that the BIOS initializes also the reserved variables but that it isn't. It's annoying.

بواسطة Bengalack

Hero (580)

صورة Bengalack

17-10-2021, 19:07

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

بواسطة Bengalack

Hero (580)

صورة Bengalack

24-10-2021, 07:55

ok, made an issue on github instead.

بواسطة Manuel

Ascended (18792)

صورة Manuel

24-10-2021, 08:13

Sorry, completely missed that. Replied on GitHub.

بواسطة Manuel

Ascended (18792)

صورة Manuel

29-10-2021, 23:11

For those who wonder: there was no bug in openMSX, but in the used start up script.

بواسطة gdx

Enlighted (5508)

صورة gdx

25-04-2022, 11:27

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.

بواسطة wouter_

Champion (484)

صورة wouter_

25-04-2022, 14:03

gdx wrote:

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?

بواسطة gdx

Enlighted (5508)

صورة gdx

25-04-2022, 14:32

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.

صفحة 13/13
6 | 7 | 8 | 9 | 10 | 11 | 12 |