Quote:

Memo: The speed of the Normal mode of 95% against the real thing. It is a little slow. The speed of a high-speed mode of 500% against the real thing. It is considerably fast

[/QUOTE]

Wow!!! Thanks HRA!!!! This high-speed mode for the blitter will be really awesome! Now I'm even more happy to have ordered my own OCM. I hope to receive it soon.

Is it also possible to have more than 128KB of VRAM? As far I can remember, if all the bits of the register #14 where used, up to A21 could be reached. This means that up to 4MB of VRAM could be addressed. If the expanded VRAM is also added to this mix, more 4MB of VRAM backbuffer (no raster access) could be added. 8MB of VRAM on a MSX!!

Of course for screens<=5 the pattern and color registers would have lower addresses limitations, but for this modes the amount of VRAM where never a restriction. Screens from 7 to up suffered a lot with the low amount of VRAM. Just look at Xak-1, that has no page-flipping because of this.

If you come to think about it, with a blitter 500% faster and 4MB of VRAM, the RicBits dream of a TMNT on SCR10 would become easily possible.

Best regards, and thanks again for your excellent improvements!
FRS

Quote:

Good luck with that! ;-)

Thanks.
VDP has timing in which the H-SYNC interrupt is automatically cleared.
In a general circuit, the processing cleared by the automatic operation is not
put.
The designer of genuine VDP seems not to have known this common sense.

[H-SYNC interrpt occur] --> [enter CPU interrupt process] --> [VDP automatic clear] --> [CPU S#1 read]
CPU becomes a panic at such timing.

Quote:

Is it also possible to have more than 128KB of VRAM?

It is possible.
It makes it to at least 1MB.(700000h...7FFFFFh on SD-RAM)

However, the register of ESE-VDP has only a necessary bit.
A lot of corrections are necessary for a capacity increase.

Quote:

It is possible. It makes it to at least 1MB.(700000h...7FFFFFh on SD-RAM) However, the register of ESE-VDP has only a necessary bit. A lot of corrections are necessary for a capacity increase.

1MB of VRAM it's very good!!!

Do you think it would be possible to get a special new SCREEN for OCM?

for e.g.

- 512x212 256colors 1MB VRAM with 65k colors palette
- 512x424i 256colors 1MB VRAM with 65k colors palette

or

V9990 compatible screens?

Quote:

Do you think it would be possible to get a special new SCREEN for OCM?

It is impossible in OCM.
The bandwidth of DRAM doesn't suffice.

If it is a mode that doesn't need the bandwidth, it is possible to achieve it.

for e.g.
- 256x212 256colors with 65k colors palette

Quote:

V9990 compatible screens?

V9990 is incompatible with v9958.
In FPGA of OCM, there is no enough LEs.

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

(vdp_package.vhd)

Quote:

I've tested other Microcabin games an intro demo in all of them work and with music. I've tested XAK2, XAK Tower of Gazzel and Tower or Cabin. I don't know if they all share the same music driver (or different versions) though. English translation of Illusion City did not work for me because of "Illegal FAT" message of EP.

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

Quote:

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

Quote:

- 256x212 256colors with 65k colors palette

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

Quote:

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

You are close... that is very good!

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.

Quote:

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

Quote:

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!

Quote:

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

Quote:

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

Hi everybody! First of all thanks to HRA! and all of you for your efforts in improving OCM
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

Quote:

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?

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.