I did a few tests on my Canon V-20 MSX1 regarding reads from unmapped or uninitialized areas. Could others do these tests too, to see whether or not it's consistent? Post results and MSX brand/type.

my results:

read from unmapped I/O: last opcode byte OR 9
- from Basic: PRINT HEX$(INP(any unmapped port)) -> 79h
- in a,(0d3h) -> 0DBh
- in h,(c) -> 69h
I don't know where the 9 is coming from, it's not from any internal register
(including F, IFF1/2, MEMPTR).

read from unmapped memory (like an empty cartridge slot): last opcode byte
- ld a,(XXYYh) -> XXh
- ld a,(hl) -> 7Eh

read from uninitialized Z80 RAM:
It depends on the location, if I do this after power on:
FOR I=&h8000 to &hFFFF: PRINT PEEK(I);:NEXT
The pattern seems to be a bunch of 255, followed by a bunch of zeroes, followed
by a bunch of 255, etc. I haven't figured out the exact pattern yet
(the number of 255s and 0s is not always the same).

read from uninitialized VRAM: 0 on even addresses, 255 on uneven addresses
Test in Basic, like: FOR I=&h1000 to &h17FF: PRINT VPEEK(I);:NEXT
If VRAM was in use, it'll take a long time to completely revert
to its initial state, even after power off/on.

I've heard that on some MSXs the databus is not pulled-up to the VCC. This would result in unstable data when reading an address that is not connected. I don't think there is a common pattern to find. The results will be influenced by the instructions that where executed. There are probably other influences, but for the rest it might be random.

Of course no software should depend on this. If you want to check on this, try the UMR feature of openMSX.

You're right manuel, I don't expect that any software actually depends on this. But when software crashes due to a bug in it, you'd want it to crash in exactly the same way on an emulator.

Kwik: These open bus reads are consistent and predictable on my MSX1, not random. Not counting the weird OR 9, the behaviour is one of the options I expected.

They might seem predictable and consistent, but you cannot be sure. They might - for example - be influenced by spikes on your power supply. Also, inserting other hardware in the cartridge port might influence the results.

Quote:

These open bus reads are consistent and predictable on my MSX1,

...but they might be different (though consistent and predictable) on someone else's MSX.

I agree, inserting a cartridge may give different results.

Quote:

...but they might be different (though consistent and predictable) on someone else's MSX.

That's why I asked others to test too, any volunteers? (the initial RAM/VRAM values tests are very easy to do)

hap, the problem is that it may depend on the actual RAM chips that were used. So this can vary a LOT indeed.

Probably, though one type might be more common than the other, we'll never know until we test it on different MSXes. eg. my VG8235 MSX2 VRAM is filled with $FF. Its RAM values are strings of $00 and $FF similar to my MSX1.. unreliable though, since that's been upgraded to 256KB.

The choice of emulators:
openMSX: RAM filled with $FF, VRAM filled with $00
blueMSX: RAM filled with $FF, VRAM filled with $00
NLMSX: RAM: filled with $FF, VRAM: filled with $FF

manuel, you work on openMSX, what's the reason RAM is filled with $FF, and VRAM is filled with $00? Was this tested to be the most common situation, or is it based on an assumption?

hap> You're way to deep here. My experience is that you see alternating $00 and $FF blocks in RAM. But since memory is not explicitly initialized, the contents could be anything at start up. Which is definitely true for a warm reboot. I think the emulators just made a choice and didn't do heaps of research. At the end of the day, it's just completely unimportant.

These are obscure details, probably completely unimportant indeed with the different types of MSXes. I brought up this topic since my experience with NES emulation taught me that some games on it do rely on initial RAM state and open-bus behaviour. Of course, NES != MSX1, but they've got a similar general architecture like other 8-bit computers from that era.

For the VRAM, this is a piece of VDPVRAM.cc:

// Initialise VRAM data array.
// TODO: Fill with checkerboard pattern NMS8250 has.
memset(&data[0], 0, data.getSize());

We haven't modelled the VRAM chips used in openMSX, so we probably don't emulate this correctly in all cases.
On the other hand, this might indeed be a bit too much detail. But ideally, it should be emulated correctly indeed. And yes, some programs have bugs which make them work on some MSXes and not on others and this should be emulated. To find those programs, I wrote that UMR detector, so you can see if it is at least a bug in the program.

Ideally, the initial RAM state would be part of the hardwareconfig.xml that describes a particular MSX model in openMSX. It would be a big effort though to collect this information for all MSX models and no-one has done that yet. But if the initial memory state of a significant number of models is known, I wouldn't mind implementing support for it.

That's the spirit, suits well with the MSX emulator that aims for perfection

Totally agree here