One chip MSX improvement project

Page 116/118
109 | 110 | 111 | 112 | 113 | 114 | 115 | | 117 | 118

By Pencioner

Scribe (1465)

Pencioner's picture

03-04-2021, 21:55

I've read that problem is about timings of HSP DDR because it is not connected directly to FPGA core. But maybe some very smart hardware design Guru could find an optimization to make through this... otherwise, another option would be to multiplex bus signals for that external SDRAM board so it uses less pins and left some pins for other hardware extensions. the board itself would become little bit more expensive though, but it might be worth it in our case

By HRA!

Champion (271)

HRA!'s picture

03-04-2021, 23:25

AxelStone wrote:
HRA! wrote:

I don't have a MiSTer, so I can't promise anything, but I believe it is possible to port it.
I have had some communication with a MiSTer on Facebook. He seems to be interested in the R800 core that I am trying to build.

I know, someone interested should make the port Wink . You comment that some Mister developer already contacted you, should be nice also some Mist developer porting it. In fact, right now Mist and Mister MSX cores are a direct port from Zemmix neo one.

Just for curiosity: considering that original OCM with old Cyclone I and 12KLEs has reached up to MSX2+@8Mhz, 4Mb Ram, FM, double SCC, VDP Turbo mode...how far do you think you can go with this one? MSX Turbo R could fit with 9990 and / or OPL4?

Thanks Smile

As for the scale of the FPGA, I think the V9990 will be included.
However, since the memory is realized with a single SDRAM, I am not sure if the access bandwidth will be sufficient.
Since the R800 core will increase the amount of SDRAM access, I imagine that it will be difficult to add the V9990.

I don't know about OPL4, I don't know the details.

By AxelStone

Prophet (3030)

AxelStone's picture

04-04-2021, 13:45

HRA! wrote:

As for the scale of the FPGA, I think the V9990 will be included.
However, since the memory is realized with a single SDRAM, I am not sure if the access bandwidth will be sufficient.
Since the R800 core will increase the amount of SDRAM access, I imagine that it will be difficult to add the V9990.

I don't know about OPL4, I don't know the details.

Turbo R with GFX9000...superb!!!! Thanks a lot and really very good luck! Smile

By HRA!

Champion (271)

HRA!'s picture

11-04-2021, 23:31

I have never controlled a V9990.
Even if the circuit fits in the FPGA, it cannot be realized if there is not enough DRAM bandwidth.
Currently, I cannot promise to be able to reproduce the V9990.

However, I already have Powergraph and PowergraphLight.
I don't know if it's some or all of them, but I will try to reproduce it. Wink

By AxelStone

Prophet (3030)

AxelStone's picture

12-04-2021, 15:11

I remember that you also mentioned that wanted to fix some issues with the current V9958 implementation but in old OCM / Zemmix there is almost no space for this, maybe?

By HRA!

Champion (271)

HRA!'s picture

17-04-2021, 00:01

AxelStone wrote:

I remember that you also mentioned that wanted to fix some issues with the current V9958 implementation but in old OCM / Zemmix there is almost no space for this, maybe?

Yes. I have heard that in the original OCM and in Zemmix, the FPGA usage has already reached 100%.
My own development targets are DE0CV and SX-2.

The number of LEs used will vary with improvements to the V9958 clone. It may increase or decrease.
If it decreases, KdL may adopt it for the OCM-PLD.

The work on improving V9958, which we had been working on since the end of the year before last and the beginning of last year, is now temporarily on hold.
I had been working on improving the timing of sprites and scan line interrupts, but on the other hand, it caused another problem, so I had to cancel it.
I will carefully sort out the timing related information and then retry.

Before that, I'd like to finish the R800 clone. Wink

By HRA!

Champion (271)

HRA!'s picture

01-06-2021, 10:26

I have updated a vdp_register.vhd
https://github.com/hra1129/one-chip-msx-kai/blob/main/source...

Fixed an issue where the screen display collapses in Fighter's Ragnarok.

By Grauw

Ascended (10018)

Grauw's picture

01-06-2021, 11:02

If I understood Twitter correctly, it had to do with wrapping around of the indirect register access counter, right?

By AxelStone

Prophet (3030)

AxelStone's picture

01-06-2021, 12:23

HRA! wrote:

I have updated a vdp_register.vhd
https://github.com/hra1129/one-chip-msx-kai/blob/main/source...

Fixed an issue where the screen display collapses in Fighter's Ragnarok.

Great! Fighter Ragnarok was one of the few games with problems in Zemmix Neo. Let's hope that KdL can apply this fix in the OCM / Zemmix firmware ;)

By HRA!

Champion (271)

HRA!'s picture

01-06-2021, 15:48

Grauw wrote:

If I understood Twitter correctly, it had to do with wrapping around of the indirect register access counter, right?

Yes.
The 1chipMSX has a 6-bit address counter with address auto-increment by VDP R#17.
The VDP command register is held in BlockRAM, and the register is identified by the lower 4 bits of the address counter.

R#32. .R#46 is 0000... R#32...R#46 corresponds to 0000...1110.

There is a program bug in Fighter's Ragnarok that causes OTIR to write to R#32-R#46 and then write an additional 00h and 8Fh.
This causes the addresses to progress to 47 and 48.
This corresponds to 1111, 0000 in BlockRAM, and by writing 8Fh to R#32 and destroying the SX of the VDP command, the screen collapsed.

On the real MSX, I don't know if it doesn't advance the address or ignores it when I write to #48, but since it doesn't destroy SX, the screen didn't collapse.

This time, I avoided the problem by stopping the auto-increment at 47.

I plan to investigate the behavior of R#17 in real MSX a bit more and come up with a more correct fix.

Page 116/118
109 | 110 | 111 | 112 | 113 | 114 | 115 | | 117 | 118