MSX Turbo-R : Unexpressed potential?

Page 2/3
1 | | 3

By AxelStone

Prophet (3057)

AxelStone's picture

23-10-2021, 17:15

MSX Turbo R has a monster CPU, so for sure you can do a lot of CPU-intensive stuff. The VDP is the same (old) one from MSX2+, so in terms of visuals you can't do nothing extra not possible in MSX2+.

About memory, nowadays all MSX can be easily expanded, so this advantage no longer exists.

By Sandy Brand

Master (245)

Sandy Brand's picture

23-10-2021, 17:32

gdx wrote:
Sandy Brand wrote:

The command speed is rather irrelevant here. What the system needed was a better VDP with better character modes that are more tailored to games. If you look at console hardware around that time you can clearly see the trends there and for good reasons. Instead of issuing complex VDP commands that it needs to wait on for completion, the CPU then only needs to manipulate character IDs in video memory, which is much faster and less convoluted to code.

You are wrong, V9938/58 commands are not complex, just slow. Fast copies (or at least tiles) and better sprites are essential when the CPU is a slow 8bit to make games.

You are missing the point Smile
Many games on MSX 2 that wanted to make use of the higher graphics modes have had to implement their own version of 'tiling' in software using the VDP commands. A proper hardware solution for this would have been much more efficient.
The VDP commands are not 'complex' perse, but it makes the coding convoluted: extra code to compute the parameters, having to issue multiple OUTs for setting the parameters (during which interrupts need to be disabled), having to wait for them, etc. All this stuff starts to add up and creates bottlenecks.

gdx wrote:

Anyway, there are obviously plenty of things that could have been better, but that doesn't answer Journey's question.

Well... it gives explanation to his question Smile

By PingPong

Prophet (3793)

PingPong's picture

23-10-2021, 18:19

Sandy Brand wrote:
gdx wrote:
Sandy Brand wrote:

The command speed is rather irrelevant here. What the system needed was a better VDP with better character modes that are more tailored to games. If you look at console hardware around that time you can clearly see the trends there and for good reasons. Instead of issuing complex VDP commands that it needs to wait on for completion, the CPU then only needs to manipulate character IDs in video memory, which is much faster and less convoluted to code.

You are wrong, V9938/58 commands are not complex, just slow. Fast copies (or at least tiles) and better sprites are essential when the CPU is a slow 8bit to make games.

You are missing the point Smile
Many games on MSX 2 that wanted to make use of the higher graphics modes have had to implement their own version of 'tiling' in software using the VDP commands. A proper hardware solution for this would have been much more efficient.
The VDP commands are not 'complex' perse, but it makes the coding convoluted: extra code to compute the parameters, having to issue multiple OUTs for setting the parameters (during which interrupts need to be disabled), having to wait for them, etc. All this stuff starts to add up and creates bottlenecks.

gdx wrote:

Anyway, there are obviously plenty of things that could have been better, but that doesn't answer Journey's question.

Well... it gives explanation to his question Smile

tiled mode: a false problem : the problem is not tile vs bitmap mode. Even amiga did not have tiled mode.
if the vdp blitter was fast as v9990 or amiga blitter one who needed for complex sw tiling ? no one.
if i can issue a full screen vdp copy moving the entire screen 1 px on the left and this take 1 frame to execute why i should bother on differential tiling?
Plus: having the v9958 smooth scroll support i do not even need the blitter for scrolling and i can use the blitter to do more flexible sw sprites trading number for size or trading size for fps etc.
hw sprites and tile mode are a rather limited solution in order to deal with slow 8 bit cpu not having fast blitter.
Even the amiga had hw sprites but they are very limited compared to blitter-based sw sprites .
the way to go was a fast blitter. unfortunately we got a bit of all but nothing at a decent level:

a) we have screen4, ok, fast because tiled, :-) but we need to left out smooth scrolling (horizontal), and no blitter support
:-(
b) we have hw sprites, (not so commmon), ok, great, :-) but we have rather limited multicolor support.... :-(
c) we have full bitmap modes no colour clash great :-) the ability to do sw sprites with more flexibility and we can use the blitter for some effects :-) but it is extremely slow :-(

as you can see the v9938 have a bit of all, but nothing at a decent level to do games.

By erpirao

Paragon (1230)

erpirao's picture

23-10-2021, 19:58

Hello good evening
first thing: sorry for what google has translated,
As far as turboR is concerned, it is evident that it has great potential to be exploited, if we use the a1st as a base (I suppose the best-selling one), on a standard msx2 +, we have the following improvements
1.- r800
2.- 256KB RAM
3.- 32KBSram for games
4.- PCM, which to get performance is going to be problematic
Much has been written about the r800 and I do not think I can contribute anything else, simply that doing a calculation on the z80, we get a cpu of approximately 4.6 / 5 MIPS, and with this "brute force" it can give interesting things
as an example I have put a link of the improvement of the AKIN that is one of the most demanding MSX2 games, brought to the r800, other excellent examples are the valis 2 patch, or the sonyc.
In other words, we have a quite capable cpu, a very little capable VPD (it was already little capable in 1988 when it was launched with the msx2 +), and an amount of memory that without being that of an a500 or an atariST 520, it can be interesting.
I have made reference to these two machines because I would place the A1ST, precisely between the two, since the turboR has some better performance than the ST but many undoubtedly inferior to the a500.
is yes, it must be made crystal clear: The TurboR is not a Snes or a Megadrive, in fact I put it below the PCE.
Now, how can you get performance out of the machine?
There are ideas that may not have been taken into account for, for example
use 128KB as an extended VRAM, the use of the ram as VRAM in an msx2 is inefficient, both for speed and quantity, in an msx2 / 2 + we do not have more than 64KB as a minimum (there are models with more memory but no are the norm), however the turboR if we have a usable amount of memory
As I said when comparing the atariST with the turboR, with the ST we have more memory, a real 16-bit cpu, DMA, and more functions a priori, better than the turbo, however, it also sins of a "less powerful" sound chip On the humble YM2413, the A500 with its 4 pcm channels goes a long way from the turboR, but like everything else, it has its penalty and in this case, it would be memory consumption.
As we can see, "what the man gives us, the man takes away from us", with the turboR, as with other machines we have advantages and disadvantages, it is also true that "no one" has been interested in getting its potential, but there is enough evidence on the internet of their capabilities.
the multi-plex, the moonlight saga, the sonyc, the raycasting routine of artrag (when I showed it to some friends user of "AMIGA" from Spain, they did not believe it), the r800 with its 256KB can give a lot of play, no we are going to see a thunderforce III from megadrive or an Alexay from snes, but if improved and enhanced versions of KYOKUGEN. I don't see much of a problem seeing a "shadow of the beast", "gods" or "Wrath of the Demon Longplay" in turboR, (actually with certain settings even on msx2 +).
and that without taking into account new techniques to access from the cartridges.
good evening.
edit: video link, multiplex, raycasting from artrag, valis2 Enhanced

By ARTRAG

Enlighted (6569)

ARTRAG's picture

23-10-2021, 21:00

Erpirao be aware that 99% of the tricks to get that framerate are from Wouter who has been able to interleave CPU math with vdp I/O avoiding as much as possible pauses. The fact is that in order to get these results you need a lot of acrobatic coding, nothing that you would normally do while coding a game.
If you do not interleave the vdp I/O with other tasks the CPU will spend a large part of its time waiting for the vdp.
In the end it is a very unbalanced machine, with a fast CPU but with a video bandwidth about the same as the previous msx2. The general performance, thus, is about the same of an msx2+ unless you do sadic tricks to interleave CPU tasks with video I/O

By erpirao

Paragon (1230)

erpirao's picture

23-10-2021, 21:09

ARTRAG wrote:

Erpirao be aware that 99% of the tricks to get that framerate are from Wouter who has been able to interleave CPU math with vdp I/O avoiding as much as possible pauses. The fact is that in order to get these results you need a lot of acrobatic coding, nothing that you would normally do while coding a game.
If you do not interleave the vdp I/O with other tasks the CPU will spend a large part of its time waiting for the vdp.
In the end it is a very unbalanced machine, with a fast CPU but with a video bandwidth about the same as the previous msx2. The general performance, thus, is about the same of an msx2+ unless you do sadic tricks to interleave CPU tasks with video I/O

Are you referring to Enhanced patches, or to the raycasting routine?

By ARTRAG

Enlighted (6569)

ARTRAG's picture

23-10-2021, 21:12

Raycasting demo

By erpirao

Paragon (1230)

erpirao's picture

23-10-2021, 22:05

That raycasting demo is a real marvel, as I said, the people of amiga I know were impressed.
There is no such thing but using v9990, right?

By ARTRAG

Enlighted (6569)

ARTRAG's picture

23-10-2021, 23:45

Using v9990 would have simplified the code
If I remember correctly there is a raycasting demo also for v9990...

Yes, it is here
https://youtu.be/BMELZufV_6s

By gdx

Enlighted (4818)

gdx's picture

24-10-2021, 04:43

Sandy Brand wrote:

The VDP commands are not 'complex' perse, but it makes the coding convoluted: extra code to compute the parameters, having to issue multiple OUTs for setting the parameters (during which interrupts need to be disabled), having to wait for them, etc. All this stuff starts to add up and creates bottlenecks.

You are confusing VDP commands with VDP access. It is necessary to disable the interrupts to access the VDP only. When the CPU is fast, VDP bits testing are feasible during interrupt. If the commands were fast we could make more than one during an interrupt. In fact, you should say that it is unfortunate that we can read only status bits from VDP MSX1 directly, the others are readable only via register 15. I agree that V9938 was poorly designed. Yamaha did some tinkering.

PingPong wrote:

the problem is not tile vs bitmap mode. Even amiga did not have tiled mode.

Yes, because tiles exist also in bitmap mode on several machines but not on MSXs, and Amiga is not comparable. It has a different architecture.

Page 2/3
1 | | 3