What if V9938 never existed?

Page 3/6
1 | 2 | | 4 | 5 | 6

By hit9918

Prophet (2867)

hit9918's picture

26-05-2019, 03:41

https://www.youtube.com/watch?v=Za9tPEgOAgk
whoops, an MSX2 in 256 color mode!!!
the tiles dont need vram. they are in main RAM.

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 09:34

Quote:

I think V9958 it's still a more limited that Amiga custom chips. V9958 can only address 128KBytes of VRAM while FatAgnus and Denise can address 512KBytes of Chip memory in OCS, so Amiga graphics chips can deal with more information. We must think that 128KB VRAM are no too much information for games with long stages and many sprites with many poses. Without DMA, V9958 would need CPU code to transfer more information to VRAM. Most of MSX2 used to have 128KB of VRAM + 128KB CPU RAM.

Again you missed the point. I've not even told that V9958 can compete with Amiga in terms of blitter power.
Instead i've told the opposite.
My point is that V9938 designers gone in the same direction that amiga designers did.
Instead of pushing hw sprites to the limit by extending colors, numbers etc. they give more power to sw ones, by assisting CPU with blitter. Because they realized that is was the way to go.
The difference between V9938 in terms of philosophy does not exists.
Both system have a sprite system that is more limited when comparing with bitmap graphics.
However the amiga blitter is at least an order of magnitude faster than V99x8 due to some inefficiencies on the latter.

Quote:

Amiga sprites had only 3 colors + transparent, with a palette for sprites for odd number and other one for sprites with even number, but Copper was able to change color of sprites without CPU cost.

The presence and the need to use copper, only proves that hw sprites were too much limited compared with sw ones.
Otherwise similar results cannot be achieved.

Quote:

Did V9958 have an internal 8 or 16 bits bus for accessing VRAM?

Again the bus width question: It does not count as you think for example the z80 had a 4bit (!) ALU and 6502 and 8 bit one so there is a ALU internal bus of 4 bit in z80 vs a 8 bit one. But z80 is a lot faster in logic/arithmetic operations than 6502 at the conventional speed of the era.

Quote:

On the other hand, sprites and blittering were able to be combined without any restriction.

there is nothing stopping you to use both hw and sw sprites combined in v9938 . there are games using it
Of course as on the AMIGA using sprites and blitter causes more slowness on the latter, while on the amiga doing heavy use of the blitter can cause some sprites disappear.

Quote:

I think MSX2+ wasn't rival for A500.

Never told this.
I'm only told that if V9958 where the MSX2 videochip things would have changed a lot because it opened up the ability to use the blitter for things like sw sprites that on the V9938 is not possible to do.

Quote:

The story would have been different with V9990, a VDP much more powerful. A MSX with R800 and V9990 can compete with many 16 bits computers.

the v9990 is another philosophy. For example, you cannot use the full power of blitter in modes that have good hw sprite support and if you want good blitter support you need to drop hw sprites.

Basically the V9990 gives you specific modes addressing a specific task.
Do you need game oriented features?
you go for P1 or P2 mode. It gives you hw sprites and tile mode that reduces a lot the weight of VRAM size to manage. But it introduce a penalty about the blitter speed.
Do you want a bitmap and sw sprites?
Bx modes have a lot more of blitter power, but forget about tiles and hw sprites. It is up to you to implement that.

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 09:52

Quote:

https://www.youtube.com/watch?v=Za9tPEgOAgk
whoops, an MSX2 in 256 color mode!!!
the tiles dont need vram. they are in main RAM.

OK, but it does sacrifice the blitter to compensate for the lack of hw horizonal scrolling.
Let's imagine this on V9958 that does not impose similar trick, because the blitter is free you can also do sw sprites, combined to hw ones.

A little OT, here there is a link showing a more in depth analisys of the Amiga OCS,
i've posted it because most people tend to spot abilities of this chip vs another without weighting up the drawbacks.

https://translate.google.it/translate?hl=&sl=it&tl=en&u=http...

In this doc it is already pointed up how was the amiga sprite system weak when compared with bitmap gfx

By Juan Luis

Resident (46)

Juan Luis's picture

26-05-2019, 11:02

hit9918 wrote:

https://www.youtube.com/watch?v=Za9tPEgOAgk
whoops, an MSX2 in 256 color mode!!!
the tiles dont need vram. they are in main RAM.

MSX2 screen 8 256 colors is not a tile mode. The transfer of the bitmap tiles from main memory in that game can be done just on time because the scroll is slow and CPU has enough to send the information.

Do you believe that MSX2+ was able to do this at same speed and with the same music in 1988?
https://www.youtube.com/watch?v=ZwkrOy9CcYQ

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 11:44

Juan Luis wrote:
hit9918 wrote:

https://www.youtube.com/watch?v=Za9tPEgOAgk
whoops, an MSX2 in 256 color mode!!!
the tiles dont need vram. they are in main RAM.

The transfer of the bitmap tiles from main memory in that game can be done just on time because the scroll is slow and CPU has enough to send the information.

The CPU does not send anything here. As is proved by the very low cpu usage.
Plus about the speed every platforms have this limit. the actual scrolling run @ 60FPS. Fast as screen refresh.
and the amiga fast scroll is not due to hw sprites, display list, tile modes or whatever, only due to blitter.

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 11:38

Quote:

Do you believe that MSX2+ was able to do this at same speed and with the same music in 1988?
https://www.youtube.com/watch?v=ZwkrOy9CcYQ

Anyway the point is that this scroll works @256 color without limitations in pixels colors. Even a more powerful AMIGA chipset cannot do this.

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 11:42

Quote:

MSX2 screen 8 256 colors is not a tile mode.

IT's not.
of course hit8818 is referring to sw tiles.
tile modes are like hw sprites or other older (ANTIC like) tricks to overcome hw limits of the era.
Neither Amiga used tile modes.
And again all is done with blitter, being able to do more flexible things than hw sprites or display list, if powerful enough.

By Juan Luis

Resident (46)

Juan Luis's picture

26-05-2019, 12:19

PingPong, I have read the article of your link. It's very interesting. There are several point I want to clarify. The memory in A500 works with a frequency twice than CPU frequency (7Mhz aprox.) , i.e. 14 Mhz. Amiga blitter can work at 7Mhz or 14Mhz in Blitter nasty mode (a flag in a port). In this mode, CPU is starved of memory and has to wait for Blitter ends its work.

Floppy disk information is processed by the sound chip Paula designed for 3,5" low density floppies and Amiga 4000 has the same Paula but it has a 3,5" HD like PC. That's the reason for reading HD floppies at half speed than a PC. Commodore didn't evolve Paula in AGA generation.

The palette registers of OCS, ECS and AGA are compatible. AGA has 8 banks of 32 color palettes. Commodore added a new port to select the bank, by default bank 0 is selected.

The author says that the longest sample that Paula can reproduce is 128KBytes. I don't remember but I believe it's true. A few moths ago I was programming Moonsound OPL4, and I have to say that the longer sample Moonsound can reproduce is 64 KBytes. When Paula ends the sample reproduction interrupts CPU giving the opportunity of reprogramming Paula registers to reproduce another piece of sample. Moonsound only interrupts MSX CPU when OPL timers expire. If you want to reproduce a sample with more than 64KB in a Moonsound, you have to calculate the duration of the 64KBytes sample piece taking account the played frecuency. Although Moonsound have two timers with different resolutions (80 microseconds, and 323.1 microseconds). You have to do some calculations and it can be hard to reproduce a long sample without cuts. Paula does this kind of things easier.

One very important thing about Amiga blitter that it is not mentioned by the author is the Amiga blitter only supports copies of rectangular sections with vertical flip (with negative modulus), but Amiga blitter doesn't support horizontal flip :-D. Graeme Cowie or McGeezer, the author of Amiga version of Rygar stores all the poses of all characters looking in both directions because he doesn't have other better option. However, MSX2 blitter can do flip X and flip Y, reducing memory consumption Smile

By ARTRAG

Enlighted (6247)

ARTRAG's picture

26-05-2019, 12:39

PingPong wrote:

The CPU does not send anything here. As is proved by the very low cpu usage.
Plus about the speed every platforms have this limit. the actual scrolling run @ 60FPS. Fast as screen refresh.
and the amiga fast scroll is not due to hw sprites, display list, tile modes or whatever, only due to blitter.

Actually the z80 is pretty busy in filling the borders while the vdp is copying the screen slice by slice.
The scroll speed is up to 1 pixel per frame at 60Hz
For faster speeds you need to move the frame rate to 30Hz (not sure about the gain) or you stay at 60Hz but you move to screen 5 (tested on field up to 4 pixels per frame at 60hz)
All enemies and bullets are sprites with up to 3 colors per line defined on fly

By PingPong

Prophet (3448)

PingPong's picture

26-05-2019, 13:13

Juan Luis wrote:

A few moths ago I was programming Moonsound OPL4, and I have to say that the longer sample Moonsound can reproduce is 64 KBytes. When Paula ends the sample reproduction interrupts CPU giving the opportunity of reprogramming Paula registers. Moonsound only interrupts MSX CPU when OPL timers expire. If you want to reproduce a sample with more than 64KB in a Moonsound, you have to calculate the duration of the 64KBytes

I do not know moonsound at all, but my opinion is: instead of the way the interrupt the CPU, what is more important is the ability to work in a circular buffer way, that is instead of waiting until the last byte is played and fill an entire block, is there a way to incrementally fill with a small but more frequently sent buffers?
This way allowed to play continuosly an arbitrary length of songs, limited only by amount of ram available.
Neither 64Kb or 128 are a long buffer. If you play in mono at 12Khz and 8 bit for example you use 12Kb/sec. and this is not a so high quality.
By contrast, having a kind of system that allows continuos fill in a similar circular fashion can simplify things a lot.
There is a mp3 cartridge for msx where the decoder is periodically filled in with data from z80 and plays continously songs. Even if we are speaking of compressed data (handled obviously by the mp3 hw) the principle is the same.

About the blitter hog it has its own drawbacks, even if more faster than cpu one could not want to sacrifice the entire cpu for the blitter.
It does depend on the situation.

Page 3/6
1 | 2 | | 4 | 5 | 6