In the VDL code of the VDP you have to mofiy the frame buffer used to display
the lines on VG A screen so it can work at a higher frequency, the frame buffer size increase. (maybe there is an other way to achieve this ).
I did it to have a 42MHz VDP , but it is useless if the SRAM is too slow.

pinpong: I took VDP from this site and Z80 from FPGA arcade and wrote my TOP level to instanciate this with a ROM and a SRAM interface plus some function like PPI/ wait states generation. But there is still problem because acces to the unique sram from VDP or CPU are not completly separated.

Quote:

In the VDL code of the VDP you have to mofiy the frame buffer used to display the lines on VG A screen so it can work at a higher frequency, the frame buffer size increase. (maybe there is an other way to achieve this ). I did it to have a 42MHz VDP , but it is useless if the SRAM is too slow. pinpong: I took VDP from this site and Z80 from FPGA arcade and wrote my TOP level to instanciate this with a ROM and a SRAM interface plus some function like PPI/ wait states generation. But there is still problem because acces to the unique sram from VDP or CPU are not completly separated.

But, there is a issue that i do not understand. If original HW worked with ram with wait time of 300ns (very long) and worked well, how can be timing issues with sram timings? (What is the access time of SRAM)

How about this, use a 21.5MHz bus to SRAM (40ns or better) and give odd cycles to the VDP and even cycles to the CPU. That should be enough bandwidth for the VDP to double the number of lines and output VGA (deinterlacing might be tricky). The speed of SRAM shouldn't be a problem since you can get 12ns chips, but you'd have to be careful with the PCB layout also at those frequencies.

basially that is the idea i am trying to implement , but it is not that easy because
I dont have a debugger with a model fpga +external sram.
I use modelsim to simulate the vhdl and a model of sram but that does not work like the real thing.
There are many exeception to this even/odd mechanism.
For instance when CPU and VDP try to acces sram at the same time I have to give priority to VDP and I rechedule the CPU access, generate wait.
Image also that the CPU access to SRAM but before the end of access VDP try to access also
to sram , the should be a wait on CPU but also a rechedule of access.
An other case, when CPU writes to sram and vdp wants to write just after , I need to insert
a state to prepare address - ie the WEN of sram has to to go high in between this two access
with WEN low .

Quote:

basially that is the idea i am trying to implement , but it is not that easy because I dont have a debugger with a model fpga +external sram. I use modelsim to simulate the vhdl and a model of sram but that does not work like the real thing. There are many exeception to this even/odd mechanism. For instance when CPU and VDP try to acces sram at the same time I have to give priority to VDP and I rechedule the CPU access, generate wait. Image also that the CPU access to SRAM but before the end of access VDP try to access also to sram , the should be a wait on CPU but also a rechedule of access. An other case, when CPU writes to sram and vdp wants to write just after , I need to insert a state to prepare address - ie the WEN of sram has to to go high in between this two access with WEN low .

Original VDP could not probably have no more time to :

a) augment speed of commands.
b) allow more sprites on scanline.


Releasing the SRAM problems allow us to overcome quickly these limits? ( 32 sprites x max line? , 3xQuick command speed?)
Actually in FPGA:
How the vdp engine is implemented? it uses spare clock to achieve vdp commands? how much % time is available to command compared to screen build up.?

Hi,

I would like to inform you of the fact that the OCM project is still not dead. A new hardware prototype is under development. Can't say more right now.

As for the education/experimentation boards from vendors like Altera: this is indeed an alternative as well. There are several boards from several vendors. Though, keep in mind that those boards do not have MSX cartridge connectors, so inserting a real MSX cartridge will be problematic. Unless you make an adapter from the expansion connector to an MSX cartridge style connector. If you want to do this properly, the adapter should have a simple analog sound-mix circuit that mixes the sound-signal from the MSX cartridge connector with the output signal from the DA converter that will be used for the FPGA generated sound.

As far as the SRAM is concerned: the ESE-MSX prototype version 2 used dual-port SRAM chips, so CPU and VDP could access memory simultaneously. The ESE-MSX prototype version 3 used dual-port SDRAM chips. Same advantage but cheaper (an SDRAM chip is a DRAM chip with build-in refresh circuitry and a memory interface similar to the one of an SRAM chip, so you don't have to worry about RAS/CAS set-up)

Regarding VDP command speed: at this moment the VDP command engine in the VHDL code is significantly faster then the VDP command engine of a real MSX. Don't remember the exact numbers anymore but it is somewhere between 5 and 10 times as fast, depending on the command. One of the reasons is that I can keep executing commands during line-rendering. Another reason is that I have used a dedicated adder|incrementer per register while I have the feeling that real VDP has only one adder|incrementer (in some kind of ALU) in the command engine so that increasing for example SX, DX, NX during a horizontal iteration will take multiple clock-cycles on the real VDP versus only one clock cycle on the ESE VDP.

Kind regards,
Alex Wulms

Quote:

Regarding VDP command speed: at this moment the VDP command engine in the VHDL code is significantly faster then the VDP command engine of a real MSX. Don't remember the exact numbers anymore but it is somewhere between 5 and 10 times as fast, depending on the command. One of the reasons is that I can keep executing commands during line-rendering.

Nice to know, Alex

So the real vdp process command only during vblack or hblank? Now i know because it' s slow.!

Quote:

Regarding VDP command speed: at this moment the VDP command engine in the VHDL code is significantly faster then the VDP command engine of a real MSX. Don't remember the exact numbers anymore but it is somewhere between 5 and 10 times as fast, depending on the command. Kind regards, Alex Wulms

There are also improvements about the number of sprites per scanline? If no, have you clock cycles to allow more sprites per scanline?

What do you think about reading all SAT in internal register at start of frame? This way allow you to skip accesses on VRAM to compare current scanline with sprite x/Y pos pattern number because data are on the registers. this way you can recycle the spare cycles to fetch more than 8 sprites pattern/color definitions.

IMHO the most important improvement about sprites would be to have
colour definitions independent by the SAT, and directly associated to the
sprite patterns (like for characters).

Now, when you do animations, or when you cross the left border (damn CE bit), you need to
write in vram 4+16 bytes!!! it is a huge amount of time !

Having a sprite color generator table associated to the sprite pattern generator table,
when you do animations, you do not need to change all the colour definitions but only
the pattern number in the SAT, and you need to modify only 4 bytes!


All you need is a Sprite colour generator table !! (it would cost 16*64 = 1024 bytes in
Vram, only 512 bytes more than the current colour section of the SAT)

This is by far more important than having 12 or 16 sprites on the same line, as would
free a huge amount of CPU time during in sprite management.

It would be a big improvement also in msx1 -> msx2 upgrade of existing games
(as the CE bit now is mapped in only one bit and not in 16!!)

Quote:

IMHO the most important improvement about sprites would be to have colour definitions independent by the SAT, and directly associated to the sprite patterns (like for characters).

I agree, also great with only a 4 colour schema and indipendent pixels colors (not line scanline based) (like screen 6)!

Quote:

Now, when you do animations, or when you cross the left border (damn CE bit), you need to write in vram 4+16 bytes!!! it is a huge amount of time !

I absolutely agree!

Quote:

Having a sprite color generator table associated to the sprite pattern generator table, when you do animations, you do not need to change all the colour definitions but only the pattern number in the SAT, and you need to modify only 4 bytes!

I absolutely agree!

Quote:

All you need is a Sprite colour generator table !! (it would cost 16*64 = 1024 bytes in Vram, only 512 bytes more than the current colour section of the SAT) This is by far more important than having 12 or 16 sprites on the same line, as would free a huge amount of CPU time during in sprite management.

Not at all, sometimes you need a larger size than 16 pixels (especially for width). This consume quickly the number of sprites available on a single line...