One chip MSX improvement project

Pagina 12/110
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17

Van SaebaMSX

Hero (533)

afbeelding van SaebaMSX

06-05-2008, 12:19

They use evolution versions of same driver. Ilusion city is lasted and it's the unique can be replay songs by the rest.

So you mean that with Illusion City version of the driver can play songs from the other Microcabin games, but not the opposite. Nice to know that. :-)

Van SaebaMSX

Hero (533)

afbeelding van SaebaMSX

06-05-2008, 12:32

- 256x212 256colors with 65k colors palette

That would be really cool for gfx artists, but of course, that wouldn't be a MSX anymore.


Method of correcting right CHOP problem Smile
CONSTANT OFFSET_X : STD_LOGIC_VECTOR( 6 DOWNTO 0) := "0101101"; -- = 45

(vdp_package.vhd)

You are close... that is very good! Smile

Van [D-Tail]

Ascended (8239)

afbeelding van [D-Tail]

06-05-2008, 12:36

SaebaMSX: I believe that Manuel Pazos made a MicroCabin music driver [MCM.COM, which is a TSR], that could play MicroCabin musics in the background. I have it somewhere on my MSX HDD, along with a selection of music of these games. Also, MSX Computer Club Enschede has made MicroMusic, which is a similar thing, but with a nice interface.
I guess both programs use a [modified] version of the Illusion City driver.

Van wolf_

Ambassador_ (9816)

afbeelding van wolf_

06-05-2008, 12:40

That would be really cool for gfx artists, but of course, that wouldn't be a MSX anymore.Most of all: there are probably no gfx artists left who would draw for such a mode anyway. There's a shortage of good (and active) gfx artists in the scene, most of 'em focus on MSX1 lately..

Van SaebaMSX

Hero (533)

afbeelding van SaebaMSX

06-05-2008, 12:49

I believe that Manuel Pazos made a MicroCabin music driver [MCM.COM, which is a TSR], that could play MicroCabin musics in the background.

Ah yes, I remember it!

Most of all: there are probably no gfx artists left who would draw for such a mode anyway. There's a shortage of good (and active) gfx artists in the scene, most of 'em focus on MSX1 lately..

This is always the same problem with new specs... that happened with v9990 before...

Van HRA!

Master (223)

afbeelding van HRA!

06-05-2008, 13:10


That would be really cool for gfx artists, but of course, that wouldn't be a MSX anymore.

Of course.
The interchangeability of MSX2 + and turboR is top priority.
It is likely to think about the new feature if there is free LEs in FPGA
after maintaining interchangeability.
However, I do not think that there is free LE in FPGA Tongue

Van MicroTech

Champion (384)

afbeelding van MicroTech

06-05-2008, 15:13

Hi everybody! First of all thanks to HRA! and all of you for your efforts in improving OCM LOL!
I wish to ask/propose an improvement for OCM vdp which, I hope, takes little LEs and can enhance vdp capabilities without loosing backward compatibility.

I'm now going to introduce the concept of "Buffer Descriptor", BD for short, which is explained in chapters 14.5.1 and 20.2 of this document.
(I couldn't find a smaller one *_*)
BD are (substantially) a data structure enabling a coprocessor to be instructed to work without cpu intervention (in this case vdp could execute commands without cpu feeding)

In my idea, vdp should be allowed to work in "continuos mode":
when enabled vdp can be feeded consecutively with commands,
cpu should not care about testing if previous command has finished because
each command will be stored/queued by vdp in vram (an extended zone, beyond traditional 128/192K)
in a BD-like infrastructure.
When execution of a command terminates, vdp will first check if another ready BD
is available and will proceed to execute the new command until all BDs are processed.
BD and related data can be placed in VRAM.

Pro:
- compatible with actual vdp/MSX software
- if enough vram is dedicated to BD's and related data, more than one "BD chain/draw list"
could be stored. Pieces of screen could be stored
once and drawn simply by setting BD start pointer and vdp in continuous mode

What do you think about this
Thanks for your attention

Van HRA!

Master (223)

afbeelding van HRA!

06-05-2008, 16:13


I'm now going to introduce the concept of "Buffer Descriptor", BD for short, which is explained in chapters 14.5.1 and 20.2 of this document.

What do you solve by using BD?
New feature? Bug fix? Question

Van [D-Tail]

Ascended (8239)

afbeelding van [D-Tail]

06-05-2008, 16:16

MicroTech, as far as I understand the idea, I think at one hand it is a smart and useful enhancementm on the other hand I think it is impractical [when BD is treated as a queue that is]. Example: in a game, there is not always determinism to the action sequence. Let me clarify this: the player might move to the right, enemies might move at the same time, so it makes sense to transfer all these copy commands to the VDP, which will execute them when it is available. But what if the player suddenly decides to invoke the option menu, overlayed on screen? That would mean the BD queue must be invalidated.
In general terms, there is much more complexity needed than just adding data to the BD structure.

Van HRA!

Master (223)

afbeelding van HRA!

06-05-2008, 16:49

If I improve VDP-command.... (It doesn't do. Tongue )

The VDPcommand completion interrupt function is added.
And, the queue is achieved by CPU program.

I want to solve the interchangeability problem ahead of that.

Pagina 12/110
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17