ZEMMIX NEO & MFRSCCSD

Página 2/2
1 |

Por gdx

Enlighted (5478)

Imagen del gdx

09-05-2022, 11:43

I do not understand those who are resistant to the possibility of having the choice to install what we need. Those who already have an SCC+ cartridge would probably prefer to have an OCM that has the SN76489. No need for PS/2 mouse support when we have an MSX mouse. There are plenty of other examples. This would prevent us from having scattered projects of which we would not know which is the best. Having the choice of devices to install would also allow you to choose the best among other projects if there are any.

However, this may not be possible as the devices are nested inside each other, or maybe the sound input from the OCMs is too bad, or the +/-12V is missing. It is on these points that we should discuss. Opinions don't matter.

Por sdsnatcher73

Prophet (3203)

Imagen del sdsnatcher73

09-05-2022, 12:27

Opinions of course also matter, even if they are different from yours or mine. But I know that is not what you mean. I think the difficulty here would be testing all different combinations. Probably there currently is also not a modular setup through the whole build and tools. So even if you could probably build the “software” without the SCC stuff. All tools that are meant to be run on MSX now expect that an OCM has SCC. So these would require changing as well.

In my opinion therefore it is probably too much work to get to any meaningful results. But we could learn from this for future developments. Say if anyone would ever want to design a new multipurpose cartridge.

Por ducasp

Hero (550)

Imagen del ducasp

09-05-2022, 15:10

It isn't that simple. FPGA currently can't be loaded dynamically, as there is no micro-controller to control FPGA loading like MiSTER or Multicore do. FPGA will always load from flash memory associated to it, and flash memory size on first gen devices is not even large to hold copies on different places of FPGA PLDs. Also, you can't simple enable/disable blocks of functionality on the fly, I mean, you can't flash something that has everything but the kitchen sink and then select the pieces you want to have working / occupying FPGA space. You can surely disable on the fly (like you already can disable SCC), but that won't lower resource usages unless that block has not been built into the PLD/JIC (so if it is not built, you can't ever use it).

The only real option, due to not having a micro-controller / separate device loading the FPGA at power up, is to make a different build without the features you do not want and adding the features you want. This is exactly what I'm doing for second generation devices, KdL is doing the right thing on reserving FPGA resources/space so his second gen builds can accomplish a full Turbo-R in the future. Same can be done for Zemmix Neo. Removing SCC should not free up much resources, the real resource hog for first gen devices is VDP and OPLL, OPLL can free up quite some cells to be used for something else.

On the other hand, I wouldn't expect (but I'm not talking in his place, this is just my oppinion) that KdL will take extra builds to make and test. As it is, it is time consuming, as he has to test every keyboard layout and every combination of Zemmix and OCM firmwares as once FPGA is about to hit its limit, Quartus version that supports OCM/Zemmix neo fpgas is not as much reliable routing connections and sometimes routing doesn't work and you need to try rebuilding it telling it to try to route things in a different way (changing a seed value in the project), I know that KdL takes extra care testing those builds, one by one, and that takes quite a lot of time, specially when you have to adjust seed values to get it working properly... Adding extra variants will add extra effort and time and, again, don't take my word as KdL's words, but I think it is too much to ask him to take even more time and testing and efforts supporting niche builds.

On the other hand, nothing prevents anyone doing it themselves and publishing their builds, just be conscious to test the versions you generate to make sure you are not generating a PLD that might lock the device of someone that doesn't have an USB blaster to recover with a JIC file. I'm doing this on my own for second gen devices, adding features I want to have and it is absolutely ok if no one else wants those features and no one downloads it, I've published it just in case someone also wants the same extras I wanted and built to my enjoyment... Wink

Just answering the question about resource usages:

VDP takes 3068 logic cells and 1280 logic registers, OPLL 1863 logic cells and 775 logic registers, psg 467 and 219, megaram 448 and 271, each SCC takes about 390/231, megasd takes only 97/63... I currently don't have Altera Quartus 11 to build OCM firmware, so those figures were taken from Quartus 13 building a second gen device, but the hardware description of those devices is absolutely the same, but perhaps Quartus 11 would make different choices and have resource usages differently, since I don't have a first gen device I don't even have Quartus 11 since I would have no use for it (using Intel Quartus 17.1 and planning on moving to Intel's latest version, 22.1

So, VDP is quite out of question to remove, but if you want a MSX2 only build there is a good chance 9938 will occupy less resources, OPLL is the one that will free up more resources, removing both SCC's and the related mapers will free up less than a half of what OPLL uses... But then, again, all depends upon what you intend to add and how much resources you need to free up... Wink

Por ducasp

Hero (550)

Imagen del ducasp

09-05-2022, 15:40

giuseve wrote:

Another example. If I have SCC and FMPAC, could be possible to have a zemmix firmware with OPL4 implemented instead of SCC and FMPAC?

Something like taht...

OPL4 is not currently possible even on 2nd gen devices. What we have currently is OPL3 through an open source OPL3 implementation based on Nuked OPL3 (which is quite good). And OPL3 is currently the top resource hog on second gen devices using more logic cells and quite a lot of built in memory cells. It takes 3329 logic cells, which can't be obtained even if you take out OPLL and the two SCCs and SD reading... If you take out OPLL you can have ~1800 cells available, and each scc takes ~390 cells, mega sd is very low on resource usage and won't take much more than 100 cells or so.

The only known FPGA implementation of OPL4 has been done by Eugeny, but that is closed source (which is absolutely fine and he has my utmost respect, it is his own work and he should do whatever he wants with it), and is used on GR8NET. Since it is closed source, we can't evaluate the possibility of adding it to Zemmix/OCM or even Second Gen devices. My initial thought is that probably Eugeny design of OPL4 is more efficient on resource usages than the current Nuked OPL3 based design used on Second Gen devices. Perhaps his OPL4 could fit in place of two SCCs and OPLL, but that is something that I don't think we are going to ever have an answer due to the closed source nature of it, unless some other very talented engineer like Eugeny takes this task and create an open source OPL4 that is really efficient on resource usage. I'm sure that I don't have the qualities to do it even if that task was interesting to me (which doesn't mean a lot, I'm really a beginner on this subject that likes to toy around).

R800 is something HRA! and KdL have been working on so they should be better positioned to tell what they expect it to consume resource wise... Wink For other MSX related device, like 9990, since those have no FPGA implementations, it is difficult to me to answer, but give the current resource usage of 9958 implementation, my guess is that 9990 would require quite more resources, and that wouldn't be the only impeding factor, it would require quite a lot of ram and ram bandwidth too, and ram bandwidth is a serious problem that take us to the current limit speed of about 8MHz to Z80 so 9958 doesn't starve, there is only SDRAM that has its bandwidth shared, and 9990 is way hungrier memory bandwidth wise, so that would be quite a challenge....

Por AxelStone

Prophet (3105)

Imagen del AxelStone

09-05-2022, 15:46

ducasp wrote:

It isn't that simple. FPGA currently can't be loaded dynamically, as there is no micro-controller to control FPGA loading like MiSTER or Multicore do. FPGA will always load from flash memory associated to it, and flash memory size on first gen devices is not even large to hold copies on different places of FPGA PLDs. Also, you can't simple enable/disable blocks of functionality on the fly

And basically, this is the key to this topic. MSX has so many expansions that are basically impossible to cover all possible combinations. No matter what firmware you do, someone would miss a different combination, and you can't select on the startup. The firmware has to provide closed features, different features mean a different firmware.

Por Parn

Paladin (781)

Imagen del Parn

09-05-2022, 16:17

My 2 cents.

I can see the appeal of having both multipurpose cartridges and FPGA-based MSX machines and wanting to leverage the FPGA to add other features not present in the multipurpose cartridges. But this negates the main advantage of the FPGA-based MSX machines, which is exactly their completeness in terms of base MSX features. You just take the machine with you and you have a fairly complete MSX which you can plug anywhere. No need for multipurpose cartridges and clunky slot expanders, unless you want something like OPL4, V9990, MSX-Audio or even ObsoNet.

The other side of the coin is that you can go the other direction, like @ducasp has been doing with his sound chip oriented builds for SM-X: adding unusual stuff that is otherwise not common in multipurpose cartridges, like SN76489 and OPL3, and even stuff common in multipurpose cartridges but previously not natively available on FPGA MSX machines, like dual PSG. And what does the future has in store? I'm excited and looking forward to it.

Por ducasp

Hero (550)

Imagen del ducasp

09-05-2022, 21:23

AxelStone wrote:
ducasp wrote:

It isn't that simple. FPGA currently can't be loaded dynamically, as there is no micro-controller to control FPGA loading like MiSTER or Multicore do. FPGA will always load from flash memory associated to it, and flash memory size on first gen devices is not even large to hold copies on different places of FPGA PLDs. Also, you can't simple enable/disable blocks of functionality on the fly

And basically, this is the key to this topic. MSX has so many expansions that are basically impossible to cover all possible combinations. No matter what firmware you do, someone would miss a different combination, and you can't select on the startup. The firmware has to provide closed features, different features mean a different firmware.

My take on this is: original MSX hardware is dying, is failing, not easily available for much stuff... So, while we still have real hardware to compare with and base the FPGA design, it will be a blessing if some people start to develop devices they would like on FPGA, so it is not something lost in the future... Also, great projects like Djankovic Arkapad are part of this, keeping old / inacessible hardware alive. As much everyone likes the real stuff, we better be prepared with good replicas because those devices are not as easy to find as before, and it is just getting worse... So, the more people wanting to join the hobby, making retro compatible devices or recreations on FPGA, the better for everyone, future is unavoidable... Tongue

Página 2/2
1 |