Strange VRAM behaviour with SCREEN8

Page 2/2
1 |

By Grauw

Ascended (8369)

Grauw's picture

30-06-2018, 15:07

Can’t BlueMSX’s VRAM viewer (which I assume is a debug UI?) just check the mode bits for screens 7 & 8 and adjust the VRAM presentation accordingly? Or have a toggle option for that.

Tho tbh being a debug inspector, I guess it isn’t a huge problem if it shows the physical layout, though it might be a bit inconvenient depending on what you are using it for. Probably openMSX does the same.

By gdx

Prophet (2976)

gdx's picture

30-06-2018, 15:11

I think it's to gain speed.

BlueMSX has not been updated for a long time. It will end up becoming obsolete. The bugs are numerous.

By Metalion

Paladin (1004)

Metalion's picture

30-06-2018, 16:41

Maybe it is indeed BlueMSX problem ...

But as a user and a developer, I find it very troubling to view VRAM and have a behaviour that's totally undocumented ! It's the first time in 15 years of emulation usage that I stumble upon something so confusing. It does not allow you to confirm or to better understand how things work. On the contrary it makes you doubt everything you've read.

By Grauw

Ascended (8369)

Grauw's picture

30-06-2018, 17:59

I wouldn’t exactly call it common knowledge, but I’ve been aware of it since the 90s. I would load pictures in screen 5, and then if I switched to screen 7 page 1 I would see a striped version of that same picture. So it’s not an unknown thing.

From a programming perspective it isn’t very relevant in general, because the VRAM access is also remapped so everything still appears linear to the programmer. It becomes relevant when you mix screen 5 and 7 in the same program, e.g. with a screensplit, or say gameplay in screen 5 and a menu in screen 7, then you’ve got to be careful with how you allocate your VRAM usage.

In the data sheet it is reflected by the CAS0 and CAS1 outputs on the pinout on p.113 and p.114, they select between the two 64K VRAM banks (so no A16). The burst access is referred to as “page mode” cycles on p.123 and p.125. In the application manual the only reference to it is for R#2 on p.47 / p.51, otherwise it’s not discussed as all CPU access is linearised to keep the burden of the interleaving away from the programmer.

Page 2/2
1 |