Unknown Reality 2.0

Finally, I saw Unknown Reality in MSX Turbo R.
For Panasonic FS-A1ST , press 1 when booting MSX-BASIC.

I'm pretty sure it works on 128k ram... at least MY philips nms8255 was able to play it. I think you confuse 'recommended' with 'required' here

That's right. And if you want to load the demo from HDD using DOS2, you even need more. (>256kB USER RAM)

I played the demo with success on my Sony MSX2+ HB-F1XV internally expanded to 256kB User RAM with CF/DOS2. To run the demo I used my Playsoniq which can also act as memory mapper. You need to switch the Playsoniq to 2048kB instead of 4096kB using MAP2MB.COM, otherwise the demo will go into music replayer mode (maybe because of memory overflow?).

To be able to run this demo on MSX-DOS2 & Nextor, 512KB of memory mapper is required.

Since it reads the memory mapper I/O ports, it will only run on a Panasonic MSX2+ machine if the internal memory is expanded. (The Panasonic MSX2+ machines block the read of external memory mapper registers).

That section of the demo does a horizontal split (!) between the scrolling text and the scope. So it is quite timing-sensitive. I assume it synchronises on the hblank status register bit, sets the vertical scroll register, then fetches the next entry in the lookup table and while waiting X number of cycles with the CPU before changing the vertical scroll register again halfway the screen, and repeats.

But if the VDP I/O takes longer to execute due to wait cycles being inserted (does it?), it will probably miss the next hblank sync. A rolling effect sounds like what would occur.

I don’t think it makes assumptions about the CPU timing staying in sync with the VDP like the io demo does, or it would’ve failed on a lot more machines, and in a different way (judging by your description).

p.s. Worth trying if this also occurs on openMSX for those machines…

You can’t create line splits entirely independent of the raster though, it’s quite finicky. Regardless of whether a horizontally timed split is used or not (worst case the split would occur too soon) (btw UR is the only case of a horizontal split I’m aware of). And line splits are a legitimate feature of the MSX IMO (because they’re awesome and many great things can be done with them ).

What I mean with finicky is, because the CPU is slow, you always have to make some assumptions like “I can execute this many instructions within the hblank period”, or “before syncing to the next hblank, I can make this many”, based on some calculations and testing. But one should be able to take the MSX2 Z80 speed as a base line.

When an MSX becomes slower than the previous generation, then it’s trouble (of course), it’s a problem of the machine, IMO. You get slower, stuff starts to break, that seems obvious.

Those wait states from the T9769 are worth investigating then… I would have thought it did not add wait states outside turbo mode.

So I think UR uses this, so the worst case that should have occurred is that the split was misplaced. But as it does a lot within the time to display a single line, if things get slowed down there is trouble because it can’t catch the HR flag in time.

This is something which affects all types of screensplits, the amount of things you can do within a hblank and one line display is affected by the CPU speed, and deviations can cause the split to occur one line sooner or one line later. If you have an ISR responding to a line interrupt, the time for the ISR to reach your split code can vary and you have to be careful to prevent issues from this, either by creating a really tight ISR or setting a second line split in your ISR code and polling for it.

Also without using the line interrupt, when you want to do full screen line split effects (think copper bars, continuous sync & split for every line), the poll for hblank itself must not become slower or your code may not even be able to respond before the hblank period ends, and also as you need to read lookup tables and perhaps prepare other VDP registers etc, the time available between lines is also limited.

In other words, when any type of line split is involved, some level of dependency on CPU speed can’t be avoided and the programmer needs to be very careful there and test a lot. But one can’t test on all, and if the CPU is slowed down more than a percent or two, it’s unreasonable IMO. I don’t know how much wait states the T9769 adds and how tight UR’s code is, but if it’s anything like the turboR… ouch.

Is 50 Hz really slower? I thought the horizontal scanning frequency was the same, but there are just more lines drawn each frame.

There have been more reports of software going bananas if there's 4MB.