Z280 to Z80 adapter revisit

Page 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

By zett

Hero (608)

zett's picture

29-11-2018, 07:51

ore make a cardrige as coprocessor. make a rom with it that have lots of extra pre set calculations and thing you can better let a coprossesor handle then a z80. own memory is cool for it.

By gdx

Enlighted (5333)

gdx's picture

29-11-2018, 10:38

Edevaldo wrote:

But Grauw I have a question for you. What if such Turbo-R/V9990/OPL4 OCM existed but had improvements over the Turbo-R:
-A much better transfer rate to the VDP?
-What if running z80 code it could be as fast as a Pentium 100?
-256k Vram for the V9958?

I want to answer too. Smile
For me FPGA and emulators that have different performances/behaviours are a problem when I develop programs. We believe to make a good program but this one does not always work on the real MSXs.

Edevaldo wrote:

-Had no limitation in terms of number of sprites?

I think it's a good thing if we have the possibility to select the normal/enhanced mode.

Edevaldo wrote:

- A DMA to transfer from the SD card to memory at 10x the speed?

It's interesting.

Edevaldo wrote:

- Play PCM samples? Transfer to the VDP?
-Longer buffers for the MIDI interface, maybe using the DMA as well for buffering.

This is not interesting because I do not think it is feasible without maintaining compatibility with what already exists.

Edevaldo wrote:

-What if that Z80/R800 cpu had hardware division? Or floating point?

That would almost not used because the software that would use it would be very specific.

By Edevaldo

Master (143)

Edevaldo's picture

29-11-2018, 23:04

Quote:

Edevaldo wrote:

- Play PCM samples? Transfer to the VDP?
-Longer buffers for the MIDI interface, maybe using the DMA as well for buffering.

This is not interesting because I do not think it is feasible without maintaining compatibility with what already exists.

You mean the MIDI buffers? I have a few ideas on how to make that in way that is software compatible with what existed originally for the MSX. To be honest I do not see a reason why we could not make a MIDI interface that is compatible with the Turbo-R one, MSX-Audio and the Yamaha one at the same time. As long as the program running uses just one of them.

A 64 byte buffer could go a long way in enabling the MSX in dealing with more complex MIDI applications. And the software won't be able to tell the difference.
Now the DMA is only interesting for new software.

By Edevaldo

Master (143)

Edevaldo's picture

29-11-2018, 23:18

Quote:

gdx wrote:
I want to answer too. :-)
For me FPGA and emulators that have different performances/behaviours are a problem when I develop programs. We believe to make a good program but this one does not always work on the real MSXs.

Hehe, the more the merrier...

I certainly understand that. I see a new FPGA machine also as a way to improve software development using the MSX. And for that, trying to reproduce the performances of the original machines is important even if the machine has lot's more performance to offer when, let's say, assembling/compiling/editing code...

Of course OpenMSX already does a lot of that. But it would be an interesting application/justification for an enhanced MSX machine. One thing that comes relatively easily with a fresh FPGA design is to have debugging features built into the hardware and be able to step/trace edit registers etc.

By erpirao

Paragon (1250)

erpirao's picture

01-12-2018, 14:55

hello, following the investigation, in this link cpu280
this benchmark of the z280 is seen with the Dhrystone 1.0.
really interesting what this CPU performs.

Quote:

While I'm going to have my own run, I found results from Stefan Nitschke, who ran dhrystone 1.0 on the CPU280 under the Unix-like UZI280. Here are his numbers:
Code: [Select all] [Show / hide]
Benchmarks testing the HiTech Compiler using Dhrystone 1.0 (12.5 MHz):

z80 Version: 847
z80 Version + z280 Lib: 1041 (22%)
z80 Vers + Optim + z280 lib: 1219 (44%)

Is there a benchmark of z80 in that version of dhrystone?

By Grauw

Ascended (10560)

Grauw's picture

01-12-2018, 18:07

Edevaldo wrote:

But Grauw I have a question for you. What if such Turbo-R/V9990/OPL4 OCM existed but had improvements over the Turbo-R:
-A much better transfer rate to the VDP?
-Had no limitation in terms of number of sprites?
-256k Vram for the V9958?
-Faster commands? Maybe polygon fills?
-A DMA to transfer from the SD card to memory at 10x the speed? Play PCM samples? Transfer to the VDP?
-What if that Z80/R800 cpu had hardware division? Or floating point?
-What if running z80 code it could be as fast as a Pentium 100?
-Longer buffers for the MIDI interface, maybe using the DMA as well for buffering.

Not interested in any of that Smile. If I’d make use of any of that it wouldn’t work on a real MSX anymore. I don’t see the point in writing any software for things beyond what the turboR can do with real hardware expansion cartridges. Already I really prefer to support the lowest of MSX1, 2 or 2+ if the project doesn’t need any more, to get the largest target audience, and I guess this applies to most people, which is why there’s so few turboR and 2+ software around.

In some cases you could argue that a program could make use of something if it’s available and fall back on something else if not. Progressive enhancement. But it introduces extra work, and really usually you have to write for the lowest common denominator and make it performant there, so if that’s already performant there’s not much point in writing special code. E.g. my game project is designed around the speed and VDP capabilities of the MSX2+, so running it on turboR has 0 benefit, nor would divide instructions or extra VRAM or uncapped sprites or faster commands.

FPGA like the 1chipMSX to be honest is really more of a hassle than a benefit from a programmer’s point of view, since the emulations will be imperfect and the software has to work around it. Both VGMPlay and my game project suffered from that, though luckily KdL has been very receptive to bug reports, but they can be time consuming to research and tricky to resolve. Emulators have the same problem of course, but the development team for e.g. openMSX is much larger and consistently made many improvements over the years, so it puts me more at ease (also I use it daily).

But if FPGA would make the turboR platform more widely available, so that I could write turboR software with more confidence that there will be a sufficiently large user base, that’s something I would sign up for definitely. And I think there are plenty of people who would like a turboR, and this could give them a more affordable one.

For such a platform, I think an FPGA which just focuses on the MSX-ENGINE / S1990 / R800 and all the rest is implemented with original chips may be even better. Then development effort can focus on perfecting the emulation of the CPU timing and glue logic, timers, etc., and the sound and video chips will be bug-free. AY-3-8910, YM2149, YM2413, V9958, all still available. OPL4 and V9990 cartridges exist so those are really optional for me to have built in, although an integrated V9990 superimposing on the V9958 could probably reduce the number of cables so that might be nice.

By АIеks

Paladin (949)

АIеks's picture

01-12-2018, 18:11

Z280 - interesting, maybe it's time to use it.

By erpirao

Paragon (1250)

erpirao's picture

01-12-2018, 18:34

АIеks wrote:

Z280 - interesting, maybe it's time to use it.

actually we have been using the "z280" since 91, but without taking advantage of it.
z280 wikipedia

Quote:

As the R800 is not based directly on the Z80, but stems from the Z800 family, it lacks some of the other undocumented Z80 features. For instance, the undocumented flags represented in bits 3 and 5 of the F register don't assume the same values as in Z80 (causing it to fail ZEXALL tests) and the undocumented opcode often called SLL is replaced by another undocumented opcode called TST.

By АIеks

Paladin (949)

АIеks's picture

01-12-2018, 19:11

ок

By erpirao

Paragon (1250)

erpirao's picture

01-12-2018, 19:15

АIеks wrote:

ок

I mentioned that we already had the technology in hand, and that by design it was not possible to use the R800 with all the features that would have meant a jump on the Z80 (it has only been used as a z80 faster).
Until recently, I had not looked at the Z280 / Z800 and the truth is that the processor is a surprise.
but if you're right, we should use the z280 "correctly"

Page 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9