Z280 to Z80 adapter revisit

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

By Edevaldo

Master (143)

Edevaldo's picture

23-11-2018, 16:34

Quote:

What information do you need?

Understand the problem a little better. I need to understand how the Z280 bus cycles work and what is the incompatibility with M! in regards to the wait generation. I'll check the Z280 docs, but if you can point me more directly to the problem it helps.

By Edevaldo

Master (143)

Edevaldo's picture

23-11-2018, 17:21

Quote:

why not work on a fpga r800. would be nice for the future of fpga msxing. its always more future proof.

And r800 is proven to be work see turbo R.
so why reinventing ?

Well, it is a whole different level in effort. Designing a bug free CPU take specialized knowledge and takes significant time.

Designing an R800 is the actual re-invention here.

Easier than that would be to take the CPU on the OCM and design a machine around it that can run at >28MHz.
It has been used for many years and it is proven.

It is not that it should not be done. There seems to be people doing it right now. But comparing to hooking a Z280 to and Z80 bus it is a much more demanding task.

But when somebody is adding a different CPU to an MSX machine he is not thinking only about running old software better. This is really about extending the capabilities of the machine. Enabling new software to be written. Forgetting about the R800, going to a modern FPGA it is possible to design a Z80/R800 alike CPU that is about 500-4000x faster than the original Z80 in the MSX. And it can be made in a software compatible manner and accelerating the rest of the system by a similar amount while still offering the cartridge slots for legacy.

The problem I see is... The Turbo-R already hinted at something that should have been done in late 80's. When they designed the Turbo-R, there is effectively a Z80 already there for assured software compatibility. The R800 could have been anything else they wanted. At that point they could have switched to a different CPU architecture. R800 was already only delivering the performance of 10-12 year old CPUs at the time of launch. A high end PC of the time was already delivering 20x the performance.

If the efforts to develop the R800 were used to complete the V9978 on time and improve other aspects of the system we would have a machine that could deliver on the hopes we had for the turbo-R at the time.Cpus like the 386sx already existed for many years, were relatively cheap and offered 32-bit linear memory addressing. A lot easier to develop software for and with good high level languages support.

So while it is possible to design a 1000x faster Z80/R800 in a FPGA, you will be stuck in the slot memory management and will have no C compiler support or a good way to support a real multitasking operating system with memory protection. We could even make it Z380 compatible, get all the 32-bit features. But we still would have no C compiler.

The funny thing is, the Z80/R800 is actually more complex to design than a simple 32 bit RISC cpu. And RISC-V is already all you could hope for in that front. It is open source, proven, ready to be used. Has compilers, memory management and everything else we may wish for.

It is just an opinion of course, but my impression is that while designing a R800 into an FPGA could be a nice thing and a lot cheaper than buying a real turbo-R, it would not bring anything new to the MSX in terms of capability. The same effort could be spent in redesigning the system to evolve the MSX into a 32/64 bit architecture and achieve 200-500Mips in an FPGA. Risc-V chips may soon be readily available allowing for even more performance.

Another possible vision is... lets make the Turbo-R with V9990 and OPL4 as common as possible so there is more motivation to target those for newer software. Making it a de-facto standard. A large part of the community would love that. This would probably look like a redesign of the OCM with a >3-4x larger FPGA, possible faster memory to cope with the two new chips and allowing some form of HDMI output/s.

By Grauw

Ascended (10561)

Grauw's picture

23-11-2018, 19:36

Edevaldo wrote:

Another possible vision is... lets make the Turbo-R with V9990 and OPL4 as common as possible so there is more motivation to target those for newer software. Making it a de-facto standard. A large part of the community would love that. This would probably look like a redesign of the OCM with a >3-4x larger FPGA, possible faster memory to cope with the two new chips and allowing some form of HDMI output/s.

This line of thought really connects with me, and I think this is the highest end MSX I would like to see and would like to program for.

Anything more than that, well… not something I’m interested in. I like MSX because it’s MSX, if I want to make software for something more powerful then I’ll just do it for PC or mobile, my life will be easier and I’ll have many times more users.

By lintweaker

Champion (431)

lintweaker's picture

23-11-2018, 19:43

I wish my FGPA skills were up to speed, but alas...maybe someday....
If I could do FGPA I would start with (re)creating a 'MSX engine' for my DIY msx to save on chip count and perhaps added functionality. After that maybe tackle CPU stuff.

So for now I'll try the Z280 route and see how for it will get me...

By zett

Hero (608)

zett's picture

23-11-2018, 22:00

Big smile yeah but if you want to find out a easy way to implement the z180 look ad the tech doc of the victor hc-95. it got 2 cpus

By Edevaldo

Master (143)

Edevaldo's picture

24-11-2018, 00:04

Quote:

This line of thought really connects with me, and I think this is the highest end MSX I would like to see and would like to program for.

Anything more than that, well… not something I’m interested in. I like MSX because it’s MSX, if I want to make software for something more powerful then I’ll just do it for PC or mobile, my life will be easier and I’ll have many times more users.

Until about a year ago my thought was that nothing better than an MSX 2+ was an MSX (I'm exaggerating). But I had no interest in the Turbo-R, it was not part of my reality when I was a more active MSX user 25 years ago. I never had anything better than a MSX 1 myself until very recently.

But I keep thinking about what still makes MSX interesting for me and to people in general, besides nostalgia. Nostalgia alone can be serviced very quickly. No need to develop new hardware or software. In the end for me, particularly, it is the simplicity of the system and the ease of developing basic hardware for it that is very appealing. But I'm an odd one as I was never very interested in games, with the possible exception of Elite.

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.

My question is, in reality, when the improvements go too far? Everyone will have a different answer. But nobody is really thinking about making the MSX a fully capable modern platform. The best we can hope to design in a low-end FPGA of today, will barely touch the performance of the original Raspberry PI and cost 10x as much. There is no point in doing that.

Funny enough, in the Amiga platform, you had from the beginning a 32bit cpu with very few restrictions in terms of memory, etc. Today, they have FPGA accelerators that run at 100MHz and deliver 3-5x more performance than the fastest real MC68060 ever could. In that platform/community it makes sense. But would a Z80 executing 2-4 instructions per clock, running at 166MHz make any sense for an MSX? Th thing can execute 1000 instructions in the time a regular MSX runs a NOP . That's a lot of software sprites...

By lintweaker

Champion (431)

lintweaker's picture

24-11-2018, 09:01

zett wrote:

Big smile yeah but if you want to find out a easy way to implement the z180 look ad the tech doc of the victor hc-95. it got 2 cpus

I have played with the Z180, the only 'issue' is that it's internal devices take a lot of I/O ports (64!). Software wise the Z280 instruction set is more Z80 compatible then Z180. I'll revisit the Z180 once I am done trying with the Z280 Smile

By Manuel

Ascended (18718)

Manuel's picture

24-11-2018, 13:56

If I read the articles on WIkipedia, it sounds like eZ80 is much more suitable to replace Z80 than the other variants.

By lintweaker

Champion (431)

lintweaker's picture

24-11-2018, 15:51

Manuel wrote:

If I read the articles on WIkipedia, it sounds like eZ80 is much more suitable to replace Z80 than the other variants.

Next to it being a 3v3 part so it will need level translators to talk to MSX 5V peripherals. It seems that all I/O ports are in use for internal devices. The docs are not very clear on that.

Quick recap:
- Z180: upto 33MHz, 5V, I/O space overlaps with MSX. CPU to bus speed ratio changeable. Missing support from some 'undocumented' Z80 opcodes.Availability: good
- Z280: upto 20MHz, 5V, I/O space of internal devices does not overlap (uses special instructions). CPU to bus speed ratio changeable. 100% Z80 compatible opcodes. Availability: poor
- EZ80: fastest option, 3V3. I/O space 100% overlaps with MSX (?). Availability: okay. Z80 opcodes compatibility: not sure.

By Manuel

Ascended (18718)

Manuel's picture

24-11-2018, 16:57

And Z380?

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