One chip MSX improvement project

Page 100/105
93 | 94 | 95 | 96 | 97 | 98 | 99 | | 101 | 102 | 103 | 104 | 105

By Grauw

Ascended (8683)

Grauw's picture

04-12-2019, 22:44

Hey HRA, will you also implement the S1990 bus timing control to keep the cartridge slots timing standard (and with a 3.58 MHz clock), just like the turboR does? Would be nice if that was brought to the classic OCM as well, ’cause right now its Z80 turbo modes can be problematic with cartridges.

By HRA!

Master (199)

HRA!'s picture

05-12-2019, 04:57

Grauw wrote:

Hey HRA, will you also implement the S1990 bus timing control to keep the cartridge slots timing standard (and with a 3.58 MHz clock), just like the turboR does? Would be nice if that was brought to the classic OCM as well, ’cause right now its Z80 turbo modes can be problematic with cartridges.

Currently, there is no timing control at all.
Since OCM shares one SDRAM with CPU and VDP, it is not known at this time whether it can be configured to access at the same time as turboR R800.
We will try to get closer to real turboR, but if it is not possible, it may end with a combination of high-speed T80a and low-speed T80a.
Currently, T80a is used instead of R800, but I would like to refine this too.

By HRA!

Master (199)

HRA!'s picture

05-12-2019, 05:05

I want to put weight on only the external cartridge slot.
If you know the timing of the problem, it may be quick to respond if you provide the information.

By HRA!

Master (199)

HRA!'s picture

05-12-2019, 05:06

weight --> wait Wink

By HRA!

Master (199)

HRA!'s picture

05-12-2019, 14:19

http://hraroom.s602.xrea.com/ocm/index.html

I have released emsxcv-20191205.

[Update contents]
(1) Fixed S1990 read port connection
(2) The CPU to be stopped is modified to wait on BUSREQ_n.

https://twitter.com/thara1129/status/1202574920691011585

By Grauw

Ascended (8683)

Grauw's picture

05-12-2019, 20:04

HRA! wrote:

I want to put weight on only the external cartridge slot.
If you know the timing of the problem, it may be quick to respond if you provide the information.

Z80 bus timing for memory and I/O fetch/read/write cycles is described in the Z80 manual figures 5, 6 and 7 on page 13 and on. MSX bus follows that, plus the extra M1 instruction fetch wait cycle described in figure 19 on page 30.

In short, MREQ and RD should signal for 2 Z80 cycles @ 3.58 MHz (0.56 µs), WR for 1 cycle (0.27 µs), IORQ for 3 cycles (0.84 µs). Clock pin should output 3.58 MHz.

All R800 memory access is single-cycle, so for any access that is not to internal memory the S1990 inserts 4-5 wait cycles for MREQ and 6-7 wait cycles for IORQ. The extra cycle depending on how the 7.16 CPU clock aligns with the 3.58 MHz bus clock. (I guess it samples MREQ / IORQ on either the rising or falling edge to determine if a wait is necessary?).

If you would implement a Z80 at 7.16 MHz you would add 2 wait cycles during MREQ and 3 wait cycles during IORQ. For a 10.7 MHz Z80, 4 and 6 wait cycles correspondingly, etc.

Of course all access to internal devices does not need to be throttled, though you could for simplicity of circuit design. The internal memory is the most important to access full-speed, then you will get 95% of the CPU’s performance. The external bus timing only has a small impact on total performance.

The S1990 has special treatment for VDP access. It ensures with an internal counter that any I/O access to 98H-9BH is 54 cycles apart (@ 7.16 MHz, or 27 @ 3.58 MHz). If another I/O occurs while this counter has not finished, it inserts waits until the 54 cycles are reached.

Lastly, the S1990 never inserts waits in Z80 mode. In Z80 mode the T9769C MSX-ENGINE does insert one (unnecessary) wait on VDP access.

By the way, I read you implemented a 2nd T80 core. Do you plan to adjust the second core to R800 timing, or will you simply run it as a sufficiently higher-clocked Z80 core? In the latter case, do you need a separate core? Couldn’t you adjust the 1st core’s CPU input clock frequency? The CPUs are never simultaneously active, and that seems like it could fit in the OCM FPGA.

p.s. I assume you are aware of these documents:

http://map.grauw.nl/resources/z80instr.php (“Timing R800 + wait” column)
http://map.grauw.nl/resources/z80instr.php#waits
https://github.com/openMSX/openMSX/blob/master/doc/internal/...
https://github.com/openMSX/openMSX/blob/master/doc/internal/...
https://github.com/openMSX/openMSX/tree/master/doc/internal
https://www.msx.org/forum/msx-talk/development/uncovering-th...

By HRA!

Master (199)

HRA!'s picture

05-12-2019, 22:19

Thank you for the information.

As for the scale of FPGA, I think there is capacity to implement R800.
I think that the same access as R800 is difficult because of SDRAM access problem.

Even though SDRAM has a lot of command overhead, it is structured to be accessed from both the CPU and VDP at about 4x speed.
The only idea is to create a new FPGA board with separate CPU SDRAM and VDP SDRAM, or clock up more.
In order to manage with the current device, it is necessary to raise the clock, but the current double speed exceeds the SDRAM specification.
I want to carefully consider how to respond.

In any case, there is currently a problem of runaway with turboR BIOS.
First of all, I would like to give priority to being able to boot with turboR BIOS.

The second Z80 will eventually be replaced with something different from T80a. In addition to the timing of memory access, the R800 has many differences and is easier to maintain separately.

By HRA!

Master (199)

HRA!'s picture

06-12-2019, 09:28

The video output of DE0CV is only VGA OUT. In addition, R: 4bit G: 4bit B: 4bit up to 4096 colors. This limits the color reproduction of the video.

By erpirao

Paladin (995)

erpirao's picture

06-12-2019, 10:35

would it be possible to use y80e or nextz80 cores for the r800?
nextz80
y80e

By lintweaker

Master (172)

lintweaker's picture

06-12-2019, 12:23

erpirao wrote:

would it be possible to use y80e or nextz80 cores for the r800?
nextz80
y80e

These are both written in Verilog while the current T80 and the rest of OCM is written in VHDL. Mixing them is (should) be possible but I think it makes things more difficult.

Page 100/105
93 | 94 | 95 | 96 | 97 | 98 | 99 | | 101 | 102 | 103 | 104 | 105