Gandara Speed

Enlighted (4156)

03-02-2018, 17:23

Here is gandhara for nec pc 88
https://www.youtube.com/watch?v=2UQS-EWOtw8
Here is msx 2 version...
https://www.youtube.com/watch?v=JPrbWQ-JJLg

Honestly i cannot believe how a simple machine with a 4Mhz z80 and without graphics acceleration and a not so cpu friendly VRAM arrangement can scroll faster than the MSX2 that has VDP.

Am i missing something?

Для того, чтобы оставить комментарий, необходимо регистрация или !login

By DJANGO

Champion (271)

03-02-2018, 18:09

english version by DJANGO

https://www.youtube.com/watch?v=ibjfD-lYF2E

By sd_snatcher

Prophet (3675)

03-02-2018, 18:12

I noticed that people tend to emulate the PC-88 @8MHz, otherwise it's too slow and the tearing is very noticeable due to the lack of page flip. Are you sure this isn't the case?

If it is, then the MSX2 should be compared when running with at least a 7.14MHz turbo.

What is also sad is that this game has FM sound on the PC-88, and only PSG sound on the MSX2.

By PingPong

Enlighted (4156)

03-02-2018, 18:22

sd_snatcher wrote:

I noticed that people tend to emulate the PC-88 @8MHz, otherwise it's too slow and the tearing is very noticeable due to the lack of page flip. Are you sure this isn't the case?

If it is, then the MSX2 should be compared when running with at least a 7.14MHz turbo.

What is also sad is that this game has FM sound on the PC-88, and only PSG sound on the MSX2.

Not so sure, but watching is does appear that msx2 version is a port of nec (same graphics)
should be nice to know if they used cpu or vdp to do the gfx on msx2....

By Grauw

Ascended (10821)

03-02-2018, 19:55

Screen 7 with nearly full screen scroll… just the scroll alone is a lot of data for the VDP to copy, then the player, enemies… I’m not surprised at the scroll speed.

By PingPong

Enlighted (4156)

03-02-2018, 20:05

Grauw wrote:

Screen 7 with nearly full screen scroll… just the scroll alone is a lot of data for the VDP to copy, then the player, enemies… I’m not surprised at the scroll speed.

the problem is that pc88 also had a 48k of vram to move and a single z80...
it is fast on this machine.

However i agree, the game should be done in screen 5, no so much gain to make in screen 7. in sc5 you have nice aspect ratio and the more pages

By sd_snatcher

Prophet (3675)

03-02-2018, 20:47

Most PC-88 games were lazily ported to the MSX2, just like the ZX-Spectrum ports to the MSX1. Most of the time the graphics were kept at 8 colors, with a slightly modified and less saturated palette to disguise it. Sometimes without even a aspect correction. This also explains the use of screen-7 instead of screen-5 or screen-8.

Sadly, Snatcher (not SD Snatcher) was also another of those lazy ports. It even uses the sprites to cover some parts of the screen, instead of using the blitter to erase those areas.

By DarkSchneider

Paragon (1030)

06-02-2018, 11:33

Z80 is a cheap CPU, usually slower than the PC ones. The problem is that original code is linear, I mean, compute frame, draw frame, and cycle again. For single task, the PC CPU probably is faster than ANY MSX chip, the MSX VDP architecture was intended to use parallelism, not used by almost any software due to the multi-platform of the code.
Not using parallelism, you have the VDP taking most of the frame time drawing the frame, giving very small room to the CPU, which is most of the time idle, to compute. We can see the effect of this on Tower of Gazzel on TurboR, how with the same VPD, giving the CPU enough room the game runs nicely. So, the VDP is fast enough for drawing at good speed, but we have a bottleneck. The problem, Z80 is slow, and it is most time idle...slow running.
Probably at that time development was not adavanced enough for thinking on things like parallelism.

It is really not hard to use parallelism in a easy way, drawing with 1 frame delay, simply shadow copy frame data for async composition, and copy full scroll block (usually the playable size minus 8 px) at start just before computing the current frame logic, that copy will be for free, and then compose the new parts (reallocate characters and draw new border tiles). Only redraw what it changes.

The problem is that probably these techniques were not much extended at that age, as said. They usually did:
- Compute logic.
- Compose the whole frame block by block (8x8 px sized).
The CPU idle simply sending small copy command to the VDP and waiting them to finish. A waste.

By maxis

Champion (512)

06-02-2018, 12:02

DarkSchneider wrote:

Probably at that time development was not advanced enough for thinking on things like parallelism.

Entirely agree that on any platform advanced, performance oriented programming gets quickly very steep in terms of required knowledge. It's not a surprise that programmers who was coding for ATARI 2600 would be more efficient than ppl grown up on BASIC. Also this disconnect of commercial 'lazy' vs amateur 'smart' gave a great motivation to create a demo scene.
Unfortunately, IMHO, it's a typical trend (or a popularity index) for a given HW platform where the good halve of SW is ported or written with the only motivation to knock off a couple of bucks from the user. More of a philosophy or religion...

By Grauw

Ascended (10821)

06-02-2018, 12:20

DarkSchneider wrote:

But the PC-88 uses a Z80 just like the MSX, so this argument does not fly...

(p.s. The PC-98’s 8086 isn’t that much faster than the Z80... arithmetic looks to be faster, but memory access seems very slow [1]. Certainly does not come close to the speed of the R800.)

By DarkSchneider

Paragon (1030)

06-02-2018, 12:49

Grauw wrote:

DarkSchneider wrote:

But the PC-88 uses a Z80 just like the MSX, so this argument does not fly...

(p.s. The PC-98’s 8086 isn’t that much faster than the Z80... arithmetic looks to be faster, but memory access seems very slow [1]. Certainly does not come close to the speed of the R800.)

With direct access to frame buffer (AKA VRAM) I think. Probably direct access software copying small chunks (8x8) could be even faster than so many VDP commands on the MSX architecture. When used I noticed that ocuppying the master bus is the slower for that system and must be avoided at any cost.
Could be also that operations are done using BIOS calls as intended to be, but are inter-slot operations. The correct way would be set BIOS in slot-0 (interrupt or any other way you like) and doing all the copies within that window.