One chip MSX improvement project

Page 107/123
100 | 101 | 102 | 103 | 104 | 105 | 106 | | 108 | 109 | 110 | 111 | 112

By HRA!

Champion (289)

HRA!'s picture

07-05-2020, 00:39

AxelF wrote:

It would be nice if you could reset the OCM with a key combination, for example CTRL + ALT + DEL.

In the ocmkai-20200507, the SDRAM clear circuit runs at the time of power-on reset or when the reset button is pressed for a long time (more than 1.5 seconds).

By caro

Hero (513)

caro's picture

07-05-2020, 06:29

AxelF wrote:

It would be nice if you could reset the OCM with a key combination, for example CTRL + ALT + DEL.

Reset by CTRL+ALT+DEL implemented in firmware for OCM on DE1, DE0 and DE0nano starting in April 2018.

By msx fan finland

Champion (500)

msx fan finland's picture

09-05-2020, 09:15

Hello all,
At last i got my own 1Chip too. Smile

Mika

By Parn

Paladin (833)

Parn's picture

09-05-2020, 15:35

I'm sorry if this is a stupid question, and please stop me on my tracks if so, but I remember being told by Luís Luca (who was responsible for the Brazilian Zemmix Neo) that one of the outstanding problems with the OCM code was its memory interface. He said to me that it is kind of a house of cards, where many devices (mainly Z80 and the VDP) contend for memory use and this limited both speed and expandability. Speed because memory couldn't keep up with Z80 and the VDP both trying to use it too fast, and expandability because the way Z80 and the VDP used memory didn't leave much room for other devices to use it as well. My question is this: it is possible to improve the memory interface so these limitations could be lifted, enabling us to, maybe, speed up Z80 or extend graphics and sound capabilities?

By HRA!

Champion (289)

HRA!'s picture

13-05-2020, 00:05

Parn wrote:

I'm sorry if this is a stupid question, and please stop me on my tracks if so, but I remember being told by Luís Luca (who was responsible for the Brazilian Zemmix Neo) that one of the outstanding problems with the OCM code was its memory interface. He said to me that it is kind of a house of cards, where many devices (mainly Z80 and the VDP) contend for memory use and this limited both speed and expandability. Speed because memory couldn't keep up with Z80 and the VDP both trying to use it too fast, and expandability because the way Z80 and the VDP used memory didn't leave much room for other devices to use it as well. My question is this: it is possible to improve the memory interface so these limitations could be lifted, enabling us to, maybe, speed up Z80 or extend graphics and sound capabilities?

The Z80 and VDP use random access to DRAM in a way that targets older DRAM structures. On the other hand, recent DRAMs are designed to operate at high speed by accessing as many consecutive addresses as possible, and recent devices that use DRAM are changing their access methods to be more conscious of this structure.
As a result, improving DRAM access efficiency to speed up DRAM access is a very difficult problem.
It's easiest to design a new FPGA board with independent SDRAM for the Z80 and VDP, but unfortunately, existing OCMs and their derivatives have only one SDRAM, so we think it's difficult.

By DarkSchneider

Paladin (983)

DarkSchneider's picture

19-05-2020, 11:30

A question, what exactly does the "Fast VDP" option? I mean at hardware level, if it improves VRAM speed, VDP clock, removes wait states...

By ducasp

Paladin (677)

ducasp's picture

19-05-2020, 13:24

DarkSchneider wrote:

A question, what exactly does the "Fast VDP" option? I mean at hardware level, if it improves VRAM speed, VDP clock, removes wait states...

It disables the artificial wait on vdp commands execution (Hmmm hmmv, ymmm, line, etc) that tries to get the general execution speed of commands at the same speed of a 9938, so you can have faster fills as an example

By Parn

Paladin (833)

Parn's picture

19-05-2020, 14:20

HRA! wrote:

(...)As a result, improving DRAM access efficiency to speed up DRAM access is a very difficult problem.
It's easiest to design a new FPGA board with independent SDRAM for the Z80 and VDP, but unfortunately, existing OCMs and their derivatives have only one SDRAM, so we think it's difficult.

I understand, thank you very much for taking your time in answering my question. It's a bit frustrating, but I get it. Still, it's amazing to see that even with so many difficulties and limitations, people can still find so much room for improvement so many years later. Hats off to people like you, KdL and Trucco (not an extensive list, please forgive me for not listing everyone).

By HRA!

Champion (289)

HRA!'s picture

19-05-2020, 15:08

DarkSchneider wrote:

A question, what exactly does the "Fast VDP" option? I mean at hardware level, if it improves VRAM speed, VDP clock, removes wait states...

In OCM, the DRAM bandwidth given to the VDP is greater than that of the real MSX. The full use of this bandwidth is called "Fast VDP mode".
The clock is 21.48MHz, the same as the Real MSX.

By HRA!

Champion (289)

HRA!'s picture

19-05-2020, 15:14

Parn wrote:
HRA! wrote:

(...)As a result, improving DRAM access efficiency to speed up DRAM access is a very difficult problem.
It's easiest to design a new FPGA board with independent SDRAM for the Z80 and VDP, but unfortunately, existing OCMs and their derivatives have only one SDRAM, so we think it's difficult.

I understand, thank you very much for taking your time in answering my question. It's a bit frustrating, but I get it. Still, it's amazing to see that even with so many difficulties and limitations, people can still find so much room for improvement so many years later. Hats off to people like you, KdL and Trucco (not an extensive list, please forgive me for not listing everyone).

OCM's compatibility is still inferior to that of software emulators.
However, it does have the advantage of being able to access the cartridge slot in the same way as the Real MSX.
Improving the OCM to be closer to the real MSX is a very fun endeavor. Wink

Page 107/123
100 | 101 | 102 | 103 | 104 | 105 | 106 | | 108 | 109 | 110 | 111 | 112