Unknown Reality 2.0

por MSX Resource Center en 17-12-2011, 10:59

Unknown Reality is NOP's first mega demo. All music was done by by Compjoetania. Unknown Reality requires a MSX2 with at least 256KB memory. Several parts of the demo require a MSX-Audio compatible cartridge with 256KB samplememory. Unknown Reality may be installed on harddisk. This version had some memory fixes and disables the R800 mode of the Turbo-R.

AdjuntoTamañoDescargasÚltima descarga
Unknown Reality1.53 MB1511hace 18 horas 4 mins

Comentarios (18)

Por Yukio

Paragon (1541)

Imagen del Yukio

30-09-2006, 20:20

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

Por Yukio

Paragon (1541)

Imagen del Yukio

30-09-2006, 23:03

This demo don't work in Philips computer with only 256KB RAM [128KB Main RAM + 128 KB Video RAM].
It need 256KB user RAM + 128 KB Video RAM.
[Totaling 384 KB RAM]
Optionally, it would work with MUSIC-MODULE or MSX-AUDIO ... 32KB RAM to 256KB Sample RAM would be recommended.
Also could works with MSX-MUSIC chip.
This ( mega ?) demo would requires 256 KB User RAM + 256KB Sample RAM + 128 KB Video RAM = 640KB RAM !?

It is possible to use this with more drivers too ... Like 2º and 3º Drivers or even some sort of Hard-Disk or Memory Card! Even more RAM would be needed in this case ...

Por Low_Profile

Champion (425)

Imagen del Low_Profile

31-03-2007, 00:44

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 Smile

Por Manuel

Ascended (15822)

Imagen del Manuel

31-03-2007, 10:26

No, it really needs 256kB USER RAM, as the 2nd part explains. If you only have 128kB RAM, you only get the replayer.

(Yukio, in MSX land we always talk about USER RAM when we talk about RAM. VRAM is always considered separately.)

Por Retrofan

Paragon (1214)

Imagen del Retrofan

03-06-2012, 11:31

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?).

Por Meits

Scribe (5651)

Imagen del Meits

03-06-2012, 21:37

Philips confused customers with adding both 128k main ram and 128k video ram into 256k ram... mean them...

oh... you resurrected a dead topic Tongue

Por sd_snatcher

Prophet (3092)

Imagen del sd_snatcher

14-12-2015, 00:20

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).

Por sd_snatcher

Prophet (3092)

Imagen del sd_snatcher

20-12-2015, 00:16

The part that has the audio scope scope with a blue background with text swinging on the left has a bug on Panasonic and Sanyo MSX2+ machines. The screen keeps rolling as if the TV had an incorrect vertical adjustment. If you press the hw PAUSE button, it stops rolling.

I tested it on a Sony MSX2+ machine on exactly the same TV and it works fine.

The problem seems to be related with the slower CPU->VDP access that the machines with the T9769 engine have.

It's that old story: MSX isn't a plataform for "run against the raster" algorithms, because those will always have an implicit race condition bug. Different machines have different timings, so the bug will be triggered.

Probably the bug will also show up on other machines that have the T9769 engine, like the Panasonic FS-A1F and Sanyo PHC-55FD2.

Por Grauw

Ascended (8515)

Imagen del Grauw

20-12-2015, 00:44

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… Smile

Por sd_snatcher

Prophet (3092)

Imagen del sd_snatcher

20-12-2015, 00:59

Quote:

while waiting X number of cycles with the CPU before changing the vertical scroll register again halfway the screen, and repeats.

Yes, this is exactly the "run against the raster" approach. On MSX, it's to ask for trouble.

Quote:

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

I tested on openMSX-0.12.0 and it runs fine on a Panasonic FS-A1WSX. openMSX doesn't seem to emulate either the waitstates imposed by the T9769, or the extra waitstates imposed by the gate-array when the turbo is activated.

Por Grauw

Ascended (8515)

Imagen del Grauw

20-12-2015, 01:22

sd_snatcher wrote:

Yes, this is exactly the "run against the raster" approach. On MSX, it's to ask for trouble.

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 Smile).

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.

sd_snatcher wrote:

I tested on openMSX-0.12.0 and it runs fine on a Panasonic FS-A1WSX. openMSX doesn't seem to emulate either the waitstates imposed by the T9769, or the extra waitstates imposed by the gate-array when the turbo is activated.

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

Por sd_snatcher

Prophet (3092)

Imagen del sd_snatcher

20-12-2015, 01:35

Grauw wrote:

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 Smile).

Yes, line splits are very useful. And the VDP offers both an interrupt and a flag so you can keep things in sync. This way everything will work fine regardless of CPU speed variations.

Grauw wrote:

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.

Yes, software delays never play well in the MSX standard, exactly because they cause race condition bugs. When developing have to keep in mind that many things caused slowdowns amongst MSX generations or regions, like

- The CPU clock is allowed to vary from -1% to +1%
- I/O waitstates that allow the machine to run more stable
- Added code to the interrupt handler
- CPU has a clock that isn't in sync with the VDP
- PAL-M machines that have a slightly slower clock, but still inside the allowed 1% range

Thus, the very same variety that allows the MSX standard to be so beautiful and flexible imposes us some restrictions that don't happen on other computers where all machines are just clones of one another.

sd_snatcher wrote:

I tested on openMSX-0.12.0 and it runs fine on a Panasonic FS-A1WSX. openMSX doesn't seem to emulate either the waitstates imposed by the T9769, or the extra waitstates imposed by the gate-array when the turbo is activated.

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

Agreed 100%!

Too bad openMSX also doesn't emulate PAL-M machines at their real native clock speed. That would also help developers with their testing.

Por Grauw

Ascended (8515)

Imagen del Grauw

20-12-2015, 01:51

sd_snatcher wrote:

Yes, line splits are very useful. And the VDP offers both an interrupt and a flag so you can keep things in sync. This way everything will work fine regardless of CPU speed variations.

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.

Por sd_snatcher

Prophet (3092)

Imagen del sd_snatcher

20-12-2015, 02:31

Quote:

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.

In fact, the T9769 adds a very subtle delay on each I/O instruction. I tested many real machines for their VRAM access speed. You can check their results here.

Note: keep in mind that 50Hz and 60Hz will react differently to the test, as the pixels are drawn slower on 50Hz machines. This means that the "chronometer" used to measure time runs slower on 50Hz.

Por Grauw

Ascended (8515)

Imagen del Grauw

20-12-2015, 13:08

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

Por Louthrax

Prophet (2093)

Imagen del Louthrax

24-06-2017, 14:58

Manuel wrote:

No, it really needs 256kB USER RAM, as the 2nd part explains. If you only have 128kB RAM, you only get the replayer.

You also only get the replayer if you have... 4MB or RAM! I guess the code stores the 16KB pages available count in an 8bit register Smile

Por Meits

Scribe (5651)

Imagen del Meits

25-06-2017, 03:53

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

Por msd

Paragon (1372)

Imagen del msd

25-06-2017, 08:00

So far I only had problems with UR With 4MB