It's really a quite impressive device, a real alternative to MFR SCC+ SD.

Yes, it is. The relevant differences are:

MFRSCC+SD:

• Up to 512KB RAM
• Second PSG
• Two card slots
• Uses SD cards

Carnivore2:

• 1MB RAM
• FM-PAC
• One card slot
• Uses CompactFlash cards

Even without considering the price, the Carnivore2 wins, especially for users of MSX1/MSX2 machines.

The most important difference between this and MFRSCC+SD is that this is fully open source. It allows me, or anyone else, to change what this device does, making it future proof.

The only downside to me is the CompactFlash slot, because CF is three times more expensive than SD cards. I have *a lot* of (micro)SD cards that are too small for my other devices, but would be perfect for MSX. CF cards I would have to buy specifically for this thing.

That said, the advantages far outweigh the CF issue. In worst case I'll just not use the CF, or repurpose the slot for something else, and it will still be good! ^_^

That's a very good point. If we can update the FPGA code then this can be used for a lot of different functions...

...at least in theory. In practice, somebody will have implement those. :-)

Yes it's curioous the choice of CF instead SD... About open source, as @Javi Lavandeira says I'm sure that most peopleo don't use it, however it's a very interesting open door.

If I wouldn't have a MFR SCC+ SD with 512Kb and 2 slots, most probably I'd give a try to this.

At the very least you're not dependent on the original manufacturer for bugfixes. And let's be honest, MFRSCC+SD is full of bugs. The manufacturer constantly denies all responsibility, even claims that perfectly fine software is the cause of bugs in his hardware.

So for me, MFRSCC+SD was never an option. I'm going to order this Carnivore2 ASAP.

I'll probably get one too :D. I wonder if it is possible to turn off the msx-music part in situations where you already have a "real" OPLL (for example FM-PAC cartridge or build in MSX music).

Also, I hope this one doesn't have the volume problems like the Megaflashrom SCC+ has (the FPGA SCC to have some problems with volume in certain MSX models while a "real" SCC does not).

If you guys are interested then go ahead and order it already. The first batch is going to be very limited (only 10 units) and I'm taking two of them.

Like Patriek said, one of the interesting things of this cartridge is that third party developers can release new firmwares to either fix bugs or update/replace the functionality.

About the comparison with MFR, from a flash point of view it is indeed quite similar for a comparison. If you leave the flash part away (for example because you use it less, or you don't mind using a separate flash cart for it), i personally think gr8net is also a good competitor. With gr8net you can also make use of: up to 1024kb, fmpac, scc, msx-audio, sdcard and (of course) network functionality :)

Really GR8NET is the most powerful cartridge. It has a lot of features not present in other devices as multimedia capabilities and network support. However is the most expensive, so it's your decission.

Yes, but GR8NET is very closed. The developer has entitlement issues and does not want to do anything in return for the people that helped him develop his device. And he needed that help, because he's not very knowledgable about MSX himself.

Just last week there was an API change that, as far as I understand it, breaks existing software. I consider this device to be more of a personal play-toy, than a device for MSX users. At the very least it must be considered beta.

Why are the GR8NET MSX-BASIC extensions not available for UNAPI, so that they can be used with Denyonet as well?

This guy may have a MSX License, but he does not have MSX knowledge, nor any desire to advance the MSX standard. He doesn't care about the community, but he does care about being "a businessman" (his own words)...

What a waste...

Yes, but GR8NET is very closed. The developer has entitlement issues and does not want to do anything in return for the people that helped him develop his device.

I agree. I've had a similar experience with Evgeny before. I contacted him to ask for information about his devices, and he said he wouldn't tell me anything because maybe I'm trying to compete with him, when all I wanted was to write about his products.

If that's how he wants it, cool. I won't report on any of his stuff.

@axel: it's always everybodies own decision, isn't it? :) About the price, is gr8net the most expensive? Because on msxcartridgeshop a MFR with scc / sd / 512kb is still 149 euro's.

Indeed it's a pity that it seems to be a "closed" approach (as far as i read here). But, obviously it's the developers desicion , similar to for example apple products or the symbos platform, whether we like it or not. Therefore they're no less good products, in my opinion.

Futhermore, i don't understand why gr8net has to be considered as a beta product?? Just because of a single change, the whole cartridge is directly not usable as a functional device for msx users? In my opinion most of the cartridge functionality works perfectly, and that is what counts for me, as a user....

Beta doesn't mean unusable. It means that you can't trust it to remain stable. It is a moving target.

If you create a game for GR8NET, and then the API changes, your game breaks. So you will get a lot of angry users that blame your for the game not working.

Look for Agile development......

Sorry, what? :-)

It applies to the previous reaction.

Do accept that things will/can change, also in short(er) cycles (which is kind of applicable to gr8net the last period, with frequently released updates imo) , and accept the risk that sometimes things will fall apart, which can be a trigger to fix things asap or keep an eye on in the future.

...and accept the risk that sometimes things will fall apart, which can be a trigger to fix things asap...

I don't think that translates very well when you've been releasing software in, say, cartridges. Or in any other media, for that matters. Fixing things after you've released means that you have to start to digitally distribute an updated version of your game, regardless of the original media. This may not be what you want when you're developing for a retro platform.

In short: I think Agile makes sense when developing internally in your corporation for a modern platforms with a modern deployment infrastructure. In the retro scene? Not so much.

...on the unstable product that you are a fanboy of?

Patriek:

This is a moderation warning.

Please keep the tone down. Regardless of whether the suggestion was good or not, nobody has attacked you personally.

Sure @robby, GR8NET is more expensive than 149€. The closed approach is a developer decission, perhaps is a disadvantage compared with Carnivore2. The only advantage is that if Eugeny has defined himself has a "businessman" perhaps he feel forced to get the best device in order to be an interesting purchase.

I've not tested in depth, I received it yesterday, as far as I have used during a few weeks I'll post my impressions. At this point I only see 2 main issues to improve:

• Price, a bit expensive for me specially considering price for Carnivore2.
• Excessive BASIC support compared to BIOS support. For me BIOS is more important than BASIC, since it's universal to any language (Pascal, C, ASM). BASIC extensions are useless for me, I'm not going to use them.

Axel, about the price, i didn't knew that. Then indeed it's more expensive. The businessman point of view is a nice one :)

Thanks for your explanation / considerations.

If the product has a steady base for developers to work with, keeping things up to date without breaking already released software for it. Things like UNAPI or a simple jump entry list like a BIOS will help greatly into improving development for a product. If GR8NET doesn't have that, developers will either update their software for it, which can be a big problem when it comes to physical releases on cartridge for example, or they will discard the product completely because it's too much of a hassle to constantly having to update their software for the product.

That said, I do like the open source system of the Carnivore 2, as it allows to simply remove the one thing I dislike the most about these multi cartridges these days: the built in slot expander. I understand it's much easier for developers to do without having to modify the firmware that comes with it, but it also greatly reduces the flexibility the MSX system provides.

Definitely, and it would be a nice gesture if GR8NETs BASIC extensions would become available for adoption on other network products, like DenYoNet. Especially given that GR8NET does make use of community-oriented software like Nextor.

Sadly, it seems that giving back is not Eugenys strong suit. Of course he can still change his mind, and I would welcome that change, and the credits that he owes you and me :)

Agreed on the internal slotexpander thing, btw :)

I wonder if it is possible to turn off the msx-music part in situations where you already have a "real" OPLL

If you can't, you can always remove it from the FPGA source and recompile the new firmware if you're capable of doing that.

Also, I hope this one doesn't have the volume problems like the Megaflashrom SCC+ has (the FPGA SCC to have some problems with volume in certain MSX models while a "real" SCC does not).

This is an unfortunate design flaw in the MegaFlashROM SCC+ (SD), which is somewhat fixed by adding a resistor to the circuit on request. I think it would have been better if the resistor was included in the initial design in stead of a cut in the board just to have it added on request.

If you can't, you can always remove it from the FPGA source and recompile the new firmware if you're capable of doing that.

Since the code is open source, we only need one person able to recompile the firmware. Once it's done we can host it here so everybody can download it.

And let's be honest, MFRSCC+SD is full of bugs. The manufacturer constantly denies all responsibility, even claims that perfectly fine software is the cause of bugs in his hardware.

Sorry but I'm not agree with you. I tested it and no bugs found. With 9mhz msx1 computer f.e. (Yes 9mhz!) Is the most stable flashrom/sd msx device made for msx machines

That just means you haven't tested the problematic parts :P

Just because your personal experience is different, doesn't mean the experience of others, as well as the facts, do not exist...

The above-mentioned volume problem, for example. But also the fact that it doesn't work as advertised with regards to support for ASCII mappers. It only supports games that are 1MB or smaller!

Pazos was not even aware of this limitation and instead blamed the authors of Pointless Fighting (2MB) for writing a buggy game!? Then, instead issuing a firmware update, he "fixed" it by adding a hack in OPFXSD that modifies the game to make it work on his bugged device. And every time a large ROM comes out, OPFXSD will require new hacks to make it work!

So with MFRSCC+SD, you are dependent on the service support of a person that, every time so far, starts by denying responsibility, and then does not truly fix the problem, but only offers hacks like an added resistor, or a software patch.

Instead of fixing his hardware in subsequent versions, he continues to sell the broken ones.

But it's absolutely great that it works for you! Good for you! Have fun!

And let's be honest, MFRSCC+SD is full of bugs. The manufacturer constantly denies all responsibility, even claims that perfectly fine software is the cause of bugs in his hardware.

Would you mind writing a (big) list of bugs? I would like to fix them.

Also, can you prove that I constantly deny all responsibility? AFAIK, most users are really happy with the cartridge and support.

The above-mentioned volume problem, for example.

Do you mean the problem with some Sanyo machines (i.e.: Philips 8250/55/80)? Those machines have a serious design fault in the audio mixer, reported by user's with good hardware knowledge after checking the schematics.

Pazos was not even aware of this limitation and instead blamed the authors of Pointless Fighting (2MB) for writing a buggy game!?

Can you prove that?

In this link I admit the limitation, reported by BiFi.

Then, instead issuing a firmware update, he "fixed" it by adding a hack in OPFXSD that modifies the game to make it work on his bugged device. And every time a large ROM comes out, OPFXSD will require new hacks to make it work!

That's false. As soon as the bug was reported I fixed the firmware, as you can read in the previous link.

So with MFRSCC+SD, you are dependent on the service support of a person that, every time so far, starts by denying responsibility,

Can you prove that?

and then does not truly fix the problem, but only offers hacks like an added resistor, or a software patch.

Can you prove there is a problem in the audio output of the cartridge?

Can you prove the audio mixer of those Philips machines is right?

Can you prove that I don't fix the reported hardware problems?

パトリく, アルバート:

Looks like there's a disagreement here.

Can you please provide a description of the bugs/issues you've found and a way to reproduce them so Manuel can have a chance to look at them and try to fix what he can?

Let's try and keep the conversation as productive as we can.

I welcome all new hardware and software and I respect all of the developers that spend their time working on new stuff.

I just wonder how can one say that an untested and unrealeased prototype can be better than another that has been here for years.

Also, I miss a reference to the new Rookie Drive, which may have less functionalities but it would be an option for many people.

@Warmize:

I just wonder how can one say that an untested and unrealeased prototype can be better than another that has been here for years.

That's not what パトリく said. Please do not misrepresent others.

He said that he sees an advantage in the fact that the source code for Carnivore2 is open source (it's here), so if he finds a bug in the device he can fix it himself, which he can't do with the MFRSCC+SD.

@Warmize:

Also, I miss a reference to the new Rookie Drive, which may have less functionalities but it would be an option for many people.

Regarding the Rookie Drive, I'd also like to write about it and review it in the future. However, I haven't heard much in the form of technical information yet (and I haven't asked the author because of lack of time).

I'll try and correct this, buy one unit (assuming it's still available) and review it as soon as I have the chance.

@Manuel Pazos: I see you indeed, eventually, say you'll fix it in new produced cartridges in that particular, secondary, thread. I have no idea whether or not this was actually done, or when the new production started or starts. In any case, your first reaction, in the original thread, was still that there must be some bug in Pointless Fighting.

Excuse me for not searching or following that site you link to closely, for known reasons.

As for the volume issue, as far as I understand it, the problem is not the known faulty hardware mixers, but the fact that MFR's volume is bad compared to a real SCC on the same machine. I may be misunderstanding this, but I seriously doubt the reporters on this bug haven't taken that into account.

It is not up to me to provide proof of something that is between you and your users. And your users report to me that you do not fix their problems. What good is a fix in new hardware, when the existing hardware that is in users hands remains faulty?

How can a user tell which MFRSCC+SD is faulty and which isn't? Is there some sort of indicaton on the cartridge?

My only reason to bring up these issues with MFR is to highlight that the Carnivore2 cartridge, being open source, does not have the problem of depending on the original manufacturer for updates and fixes.

It's not my fault that people turn up that need to be explained the specifics, and then cause a derailment of the thread. If you would be more open about the bugs and fixes you've made, other people wouldn't need to educate these people.

And no, a small message hidden in some thread in some forum, posted under an alias, is not sufficient information.

First of all, as reminder, please post a list of such big a amount of bugs you stated the cartridge has.

You said it is a device "full of bugs". So if you can't post that list, I could suppose you are difaming the product.

Also you said "The manufacturer constantly denies all responsibility". Please, prove it.

I see you indeed, eventually, say you'll fix it in new produced cartridges in that particular, secondary, thread. I have no idea whether or not this was actually done, or when the new production started or starts.

I told you I did it. Any reason to not belive it? No one can know it better than me.

As for the volume issue, as far as I understand it, the problem is not the known faulty hardware mixers, but the fact that MFR's volume is bad compared to a real SCC on the same machine. I may be misunderstanding this, but I seriously doubt the reporters on this bug haven't taken that into account.

It sounds like you ring the bell and then run like hell.

Actually you said "does not truly fix the problem, but only offers hacks like an added resistor"

Well, the fact is that those machines have a well known and proved fault desing in the audio mixer. But you insist in that the problem is related to the cartridge. Why?

The volume of the cartridge is right, otherwise it would sound lower in all other MSX machines.

It is not up to me to provide proof of something that is between you and your users. And your users report to me that you do not fix their problems.

It is not up to you to prove anything, but you can affirm that the problem is in the cartridge? Just because you hear it or someone told you?

So if I heard something about you I can state it is true and I don't need to prove it? Really?

"Those users" should be the ones that explain why they say I don't fix the problems.

Tell "those users" to contact me and explain me why they said that.

How can a user tell which MFRSCC+SD is faulty and which isn't? Is there some sort of indicaton on the cartridge?

What do you mean with faulty? The ASCII mapper limitation? All cartridges produced since the bug was reported are fixed.

My only reason to bring up these issues with MFR is to highlight that the Carnivore2 cartridge, being open source, does not have the problem of depending on the original manufacturer for updates and fixes.

Really? What about other non open souce hardware and software?

Also, what about open source VHDL lincenses for non comercial use?

And no, a small message hidden in some thread in some forum, posted under an alias, is not sufficient information

It seems you use two different yardsticks for your source of information depeding on you interest.

@Manuel Pazos, the problem with sound is that there is usually an input impedance (resistance) on a port. On a cartridge with a real SCC this impedance is preset by the resistor array the cartridge contains. Usually, when measuring this, the result value would be the same both ways. When I measured the impedance of the MegaFlashROM SCC+ and MegaFlashROM SCC+ SD, I noticed a 0 Ohm impedance one way and an infinite impedance the other way. This is how a diode works and this could very well affect the way some circuits react. People with knowledge of that kind of stuff confirmed there's a serious design problem in the hardware mixer of those machines. However, the internal PSG is still audible with those hardware. Because of the very low impedance level of the MegaFlashROM SCC+ (and SD) every other sound from the machine (internal and external) are completely overruled by the cartridge. I think the added resistor is a design flaw in the board, unless you have taken something like that into account (I haven't seen the SD board, so I can't be sure). After all, you can never be sure the cartridge will not end up in such a machine when someone takes it to a meeting or something.

As for the ASCII16 mapper, is this updated now to allow 4 MB ROM images as well, like the real chip does?

Something that really bothers me is that no action was taken, aside from implementing a work-around in OPFXSD to handle bigger ASCII16 mapped ROM images, to unroll some sort of firmware update for MegaFlashROM SCC+ SD cartridges sold before the ASCII16 mapper bug was fixed. We are not defaming the cartridge, since it's still a very useful device to own and use. Being able to release fixes in newly produced devices is good, but being able to put those fixes in already sold devices would greatly improve the popularity of the device. I'm sure you cannot expect every user to send back their device to have one with the fix in return. I really hope you have provided with some sort of solution to allow firmware updates by the users, in stead of having to update OPFXSD with work-arounds for possible later releases using ASCII16 mapper.

Manuel, パトリく:

I'm afraid I have to step in at this point. Let's try and keep the conversation constructive.

@パトリく:

It is not up to me to provide proof of something that is between you and your users.

Actually, at this point it is, because you've claimed that these problems exist and you know what they are. Manuel is asking you to tell him what they are so he can look into them.

Please do so. Pointing out the bugs will help Manuel fix the problems in his product. Withholding this information won't be helpful.

@Manuel Pazos:

How can a user tell which MFRSCC+SD is faulty and which isn't? Is there some sort of indicaton on the cartridge?

This is a valid question from パトリく. How can a user know whether he's buying a cartridge that hasn't been fixed (such as when buying a used product in an auction)?

@Manuel Pazos:

Also, what about open source VHDL lincenses for non comercial use?

Can you please clarify what you mean? I don't understand what you mean.

To both:

Please leave aside any personal issues you may have with each other. Starting a fight isn't going to solve anyone's complaints nor fix any problems with the hardware. Please try to keep the conversation as productive as you can, and if that's not possible, I'd ask you to continue the discussion with each other via email.

@アルバート:

@Manuel Pazos, the problem with sound is that there is usually an input impedance (resistance) on a port. On a cartridge with a real SCC this impedance is preset by the resistor array...

Thanks SO MUCH for the detailed explanation. This is how I'd like all conversations to be around here.

I can't agree to any "attack" to Pazos or MegaflashROM. For me,this cartridge is the best piece of hardware for the MSX,at this moment.

Since I fixed the mixer sound of my Philips,I don't have any problems with sound. And in other MSX I never had problems.

And Pazos,ALWAYS was here when I needed something about his cartridge. ALWAYS.

@BiFi: According to hardware experts, usually when you mix two audio signal there is some attenuation because all the sound signals must be mixed to a common bus using a decoupling capacitor and a resistor to attenuate, so all signals have the same level. To avoid that attenuation you need a preamplifier (i.e.: a transistor).

So, to keep it simple you need every sound signal connected to a capacitor and resistor and mixed into a transistor.

If you check the schematics of those faulty machines, you will notice several faults.

Those faults can produce:

-Non balanced volumen

-Only one sound source is amplified

-Both sound signals of the slots are mixed (short circuited!) This is a severe problem since two sound cartridges inserted at the same time can be damaged.

-Finally, since the sound of the cartridge are directly mixed in the output of the preamplied internal sound, the PSG is weakened. Moreover, the sound cartridge(s) in the slot(s) will received that preamplified sound!

Also, there is any requisite in the standard to add resistance to the signal. Adding it is optional, like adding a 5V regulator to the 5V signal just in case you computer output a higher voltage. Moreover, adding only a resistance to the sound signal will not fix/prevent the problem in that machines.

I hope the "problem" with the sound is clear now. If you have a faulty machine, be carefull when connecting sound cartridges.

About the ASCII mapper. It is limited to 2MB. As you should know, most common real ASCII mappers ASC1 and ASC4 (LZ93A13 and MR6401) can address up to 2MB in 16K mode.

This is a valid question from パトリく. How can a user know whether he's buying a cartridge that hasn't been fixed (such as when buying a used product in an auction)?

Just load Pointless Fighting using /A16. If does not work, the cartridge is not updated.

Can you please clarify what you mean? I don't understand what you mean.

VHDL code used in some projects (i.e.: SCC or FM implemenations) have terms and conditions. I.e.:

Redistributions may not be sold, nor may they be used in a commercial product or activity without specific prior written permission.

AFAIK, some projects that use that VHDL code have been / are being sold without permission.

Please leave aside any personal issues you may have with each other. Starting a fight isn't going to solve anyone's complaints nor fix any problems with the hardware. Please try to keep the conversation as productive as you can, and if that's not possible, I'd ask you to continue the discussion with each other via email.

I have no personal problems with Patriek (AFAIK). But since he publicly stated the cartridge is full of bugs, that I denie all responsibility, and that the sound problem is caused by the cartridge, I would like an also publicly prove of what he affirmed.

@Pablibiris: Thanks, mate. Nice to hear that from a MFR SD user.

@Pablibiris:

I can't agree to any "attack" to Pazos or MegaflashROM. For me,this cartridge is the best piece of hardware for the MSX,at this moment.

I think it's nice that you're so loyal to Manuel and his products.

However, there's an ongoing conversation here between three very experienced developers (BiFi, Manuel and GuyveR800). They're discussing objectively whether there are any issues that need to be fixed, and if there are, how to identify them.

If you can contribute to that conversation then great!

Otherwise, I'd ask you to stay aside and not to interfere.

Nice...I can't say that I'm very happy with my MegaflashROM...

Welcome to another dictatorial forum.

Please,erase my account.

@Pablibiris:

You can say whatever you want. However, there's one thing you won't find in MSX Center: sacred cows.

Everybody, and every product is open to constructive criticism. And I more than any other person here. That's how products improve and how people grow up: by pointing out what's wrong and fixing it.

It doesn't matter whether you agree with the discussion or not, and whether Manuel has helped you whenever you needed it. Developers are talking about possible issues with the cartridge here in order to have them fixed. If you don't agree with this kind of discussion then you're welcome to post somewhere else.

If you still think this position is comparable to a dictatorship and still want your account to be erased then let me know and I'll gladly do so.

If you can contribute to that conversation then great!

I don't think it is a matter of being loyal (?!)

Probably he wanted to mean that always he asked for support or reported any problem with the cartridge (i.e.: loading a game) I helped him, an not "denied any responsability". That could prove Patriek is not telling the true.

He also explains that after fixing the cause of the sound problem (his computer) he had no more problems with the sound in any computer.

I think real MFR SD users experiences, are a good source of information. Probably a better source than Patriek, that does not own the cartridge and just talk "about what he heard or someone told him"

@Manuel Pazos:

Probably he wanted to mean that always he asked for support or reported any problem with the cartridge (i.e.: loading a game) I helped him, an not "denied any responsability". That could prove Patriek is not telling the true.

Yes, this is true. The part I don't like of his comment was I can't agree to any "attack" to Pazos or MegaflashROM for two reasons:

1. Yes, GuyveR800 starts with a hostile message. You've already replied to him, but he hasn't had the chance to reply with a more objective/productive message. I don't think it's appropriate to add fuel to the fire.
2. As I said, nobody and no product are going to be free from criticism here, when the criticism is justified.

I'm trying to keep this site productive and free from the tribalism that is affecting other MSX sites and groups on Facebook.

I think real MFR SD users experiences, are a good source of information. Probably a better source than Patriek, that does not own the cartridge and just talk "about what he heard or someone told him"

I think that regarding this, both you and GuyveR800 are correct. You're right in that he doesn't own the cartridge and can only comment on what people have told him. However, those telling him that Pointless Fighting doesn't work are trying to make his own game work, and the fact that it doesn't run on these cartridges isn't his fault.

Please try not to blame each other. That won't achieve anything. Let's try and identify the issues and see whether what he was talking about still exists in the current version or not. Give him some time to reply.

And the reason I do not own a MFRSCC+SD is exactly this non-professional behaviour as a manufacturer.

In my opinion, one of these things should have happened:

1. a firmware update for all users
2. a voluntary recall of each sold device for firmware update

The list of known(!) bugs is above. Pazos was already aware of them, so while I guess it's good that アルバート posted the technical explanation here, it's not news.

The mapper issues with the MFRSCC+SD are two-fold:

1. the ASCII8 mapper does not support games larger than 1MB, due to some bug
2. the ASCII16 mapper does not support games larger than 2MB, due to this mapper being emulated internally as an ASCII8, which is max. 2MB.

アルバート asked whether or not point 2 was fixed as well, but no answer was given.

Again, the first denial of responsibility was posting on that other site that Pointless Fighting must have some bug. It took quite a while for Pazos to admit that his product (or is it Tsujikawa's product?!) was flawed. Someone who is not banned on MRC can find the thread to prove this, but Pazos knows very well what he said.

The second denial of responsibility is the insistence that the audio issues are purely due bad mixing hardware, while as I stated before (but was thoroughly ignored by Pazos) the problem is that there are differences between MFRSCC+SD and other (SCC) cartridges on the same hardware.

I guess it's temperament, but it's really hard to talk to people about facts when all they do is shout and ignore 90% of what the other is saying.

@パトリク:

Looks like you replied while I was writing my post. It's 4:42am here and I can barely stay awake, but I'll try one last message:

I'm not going to engage in a discussion with someone who doesn't even read my posts and just sends ranting replies that do not actually address what was said.

You made some claims about Manuel. He asked you to justify them, and from what I can see in the thread, you haven't addressed those.

Under these conditions I have to say, as a moderator, that Manuel is right in asking you to clarify.

I don't appreciate when people make claims about others and later don't back them up when asked to do so. I've been on the receiving end of similar situations and it's not pleasant.

From what I've been able to understand, the problem with the ASCII mapper was reported to Manuel and he fixed it in later versions of the MegaFlashROM cartridge. I think it's reasonable to accept that he, as an indie developer, isn't going to issue a full product recall and fix all other MFR cartridges in circulation.

So, since the issue with the mapper is fixed, what other issues/bugs do you think are still present in the MFR?

@Manuel:

VHDL code used in some projects (i.e.: SCC or FM implemenations) have terms and conditions. I.e.:

Redistributions may not be sold, nor may they be used in a commercial product or activity without specific prior written permission.

AFAIK, some projects that use that VHDL code have been / are being sold without permission.

Thanks for the explanation. Do you know whether the FM implementation in the Carnivore2 is copyrighted and used without permission? If so, then I'll update the post to clarify that.

In both MSX hardware and MSX software development, there are things that are not strictly required by the MSX standard, or are not documented, but which you are still required to do in order to achieve proper compatibility.

Other well-known hardware developers have also had products that were problematic due to such reasons. And yes, this includes the likes of Sony and Philips.

I'm not a God of MSX hardware or software,sorry. I can't contribute anything here,and I don't deserve to be among MSX gurus :(

Yes...you can erase my account. Thanks.

Best regards.

パトリク, Manuel:

I feel as if there's still room for conversation regarding the mapper implementation in the MegaFlashROM.

Instead of commenting about these in this post (which is after all about the Carnivore2 release), would it be a big problem for you to open a new thread in the development lounge?

Perhaps we can address each of the issues one by one there and see which ones can be fixed and how, and which ones can't (or won't) and why.

Personally, I don't see the 1MB limitation in the ASCII8 mapper as such a big issue, because of the limited number of games using so much memory. Under that assumption, and while understanding that the issue in the hardware exists, I think that modifying OPFXSD to make Pointless Fighting usable is a reasonable compromise.

@Pablibiris:

Understood. Give me a few days to implement user account deletion.

アルバート asked whether or not point 2 was fixed as well, but no answer was given.

Having read Pazos' answer more carefully I see he did address this. So I retract this statement.

I still feel any 16K mapper should work up to 4MB, especially on a 8MB or more flash device.

I think it's reasonable to accept that he, as an indie developer, isn't going to issue a full product recall and fix all other MFR cartridges in circulation.

I think it's reasonable if Pazos would allow MFR owners to fix their own device, by providing the fixed firmware, and instructions on how to update it.

But my whole point was that with open source devices like the Carnivore2, this is not a problem to begin with! THAT IS ALL

Of course I'm not a professional hardware developer XD

Users are free to send their cartridges back to me and they will updated for free. No problem about that. In fact, some already did it.

It seems you don't read my posts, since I answered BiFi in a previous post.

You stated that the sound problem is in the cartridge. Your argument is than on a real SCC the PSG is not atenuated so much. That does not mean that the fault is not in the computer. As I explained, and others proved, the problem is in the computer. Bad designed. Really bad designed. But you can't recognize you are wrong. Perhaps you already know that, but keep on saying that he problem is in the cartridge.

I'm still waiting the "full of bugs" list. It is clear to me that you don't have any big list of bugs, and just try to difamate the cartridge for resons you only know.

Also, you can't prove I constantly denie all responsibility. Just because it is false.

You can keep repeating your false statements as much as you want. But that will not convert them in truth.

You are ignoring 100% of my request and explanations. You are difamating my work and service. I'm starting to understand why you were banned from MRC.

Thanks Javi for your positive remarks. I think I'll not continue the discussion since it seems an endless loop. I think I explained my point, my arguments and tried to prove them. Patrienk have not proved ANY of his statements. For me, hi just try to difamate MFR SD cartridge and/or trying to create controversy.

Thanks for the explanation. Do you know whether the FM implementation in the Carnivore2 is copyrighted and used without permission? If so, then I'll update the post to clarify that.

Carnivore 2 uses SCC, FM and other VHDL with that terms and conditions.

AFAIK, they have not written permission, but I have not verified it.

Try to contact Okazaki-san and Tsujikawa-san. They are the best source of information in this case.

I never claimed the list was big. What you claim are explanations, is proof of denying responsibility to me.

I'm surprised to hear users can send you the carts for updating, because a MFR user told me you had told him this was not possible. Do you have proof of this? Have you advertised this option anywhere?

You know, just because you reconsider your standpoints at a later moment, doesn't mean your original standpoint disappears.

I have not ignored your requests, I just refuse to search the MRC, for obvious reasons. If you would just stop being so childish, you can just admit that you blamed Pointless Fighting first, before accepting it was a bug in your device.

Claiming I have not proven any of my statements is simply untrue and as usual you are just trying to hide your responsibility. Who is defaming who exactly?

@Manuel Pazos: Speaking of defamation, why exactly did you throw Carnivore2 under the bus just now?

Do you feel threatened by it?

@パトリク:

Stop, now.

Manuel has already said he's not going to continue the discussion here. It's unfair for you to keep pushing, especially when your point is about what he initially said years ago while ignoring his later position.

If you have any constructive criticism about the MFR cartridge then by all means write a post in the development lounge and, if you can, propose solutions.

Your last comment about feeling threatened was way out of line. Manuel raised a valid point that I'm going to try and confirm.

This is the final moderator warning. Do not continue with this conversation on this tone.

So he gets to have the last word just because he said he won't continue discussion? Class A moderation there ^^;

Note that I didn't start the discussion on the MFR. I'm not on a crusade against the MFR. All I said was that an open source device like the Carnivore2 avoids the issues that the MFR has, which is dependent on the original manufacturer for updates.

I never meant to point out specific problems with the MFR, since that is off-topic in this thread about Carnivore2. When people came in here claiming there was nothing wrong with the MFR, I tried to provide them with an informative response. I had no idea this would derail the discussion so much.

It seems that the slight exaggerations "is full of" and "constantly" caused much of today's problem. Let me nuance those to "has some" and "initially", respectively.

In any case, it is commendable that Pazos allows people to send in their MFR for updates. This is news to me, and certainly changes my opinion on his customer service.

On that positive note, I'll call it a day and eagerly await the moment the Carnivore2 goes back into production.

Sorry but I don't see a constructive criticism here. If you talk about "lot of bugs" you should provide them in order to confirm that efectively there are a lot of them.

A positive read of this new is simple: we have real alternatives to MFR. At this point, can anyone ensure which device is better? Is there any in depth review of them with dozens of games tested? I don't think so.

So let's be constructive, wellcome Carnivore2 and wellcome MFR.

This looks like a very nice (almost) all-in-one artridge for your MSX.

It would be nice if MSX-Audio was added to it as well (I have no idea if there is still enough room left on the FPGA for this?

I have dreams of a 4 or 8 channel sample player that uses the internal RAM for storage :)

If you don't implement it, I might :)

it requires 32 bytes extra RAM for the indepedent 5th channel wave and some tiny bits of logic to switch between SCC and SCC+, that's all.

Although if you want to go for a real Sound Cartridge implementation, it should operate on RAM and not ROM. That way you can use it for Snatcher and SD-Snatcher (and ROMLOAD).

@パトリク

If you'd want to build a 4 channel sample solution you could consider taking a look at the Amiga custom Paula chip. I know the VHDL code exists, but I don't under what license or if it could easily be adjusted to work on an MSX architecture.

Having thought about what happened before in this thread, I must post a final statement.

1. Don't shoot the messenger. If the mere mention of the factual existence of problems is "hostile" and "defaming a product", that is ridiculous. Me repeating reports of MFR user's experience with its author is valid, because he denies responsibility. His reactions here are clear, this is how (some?) users reporting a problem are treated too!
2. The "explanation" about the lack of 4MB support is based on a lie. I can't think of any game which uses MR6401 (max. 1MB ROM), so I don't believe it's common at all. The other 3 ASCII chips, which are commonly used, all address up to 4MB, although LZ93A13 has this addressing space split between ROM and SRAM.
3. If the commonality of hardware is so significant, the Philips NMS82xx series is so common in europe, it could be considered the DEFACTO standard. So whatever the MSX standard says about audio mixing circuits is irrelevant. You gotta make your stuff work, or at least not work worse than other hardware on the market, on at least the most common MSX models. MSX software developers deal with this all the time.
4. There are various other bugs in the MFR, particularly concerning the SCC+ implementation, but also physical bugs like the holes in the cartridge being too big causing lost microSD cards. However, I cannot be expected to take hours of my busy schedule to compose such a list, for a device I do not own, just because the manufacturer denies responsibility. It is unreasonable to demand this from anyone, especially in such an aggressive way.

Finally, I demand an apology from the staff, to be posted here, for this quote: "Yes, GuyveR800 starts with a hostile message." because it adds to the framing of alleged bad intentions. There were none, and I have no financial or political reason to speak anything but the truth.

I don't understand you, パトリク....

This thread is supposed to be about the new Carnivore 2 cartridge. Instead of talking about this new hardware and its possibilities it has been used to "attack" (!!!!???) the MFR!!!

I have to say that I am a happy owner of the MFR. I load lots of games. I know many people that uses it and are happy with the hardware. I have asked Pazos some times for help and I have always been answered very quickly. Maybe there are bugs, maybe some bugs are unsolved (or maybe not the way you have preferred) but....it's an excellent and useful NON-COMMERCIAL hardware! But...is this the place to argue about it?

I hope Carnivore 2 is, at least, as good as MFR with less bugs and more functionalities. Good luck with it!

Warmize is right. This thread is about the Carnivore2 release. Please stop discussing the MegaFlashROM here.

If you really want to keep talking about it, I've opened a thread here summarizing what we've learnt and with a few guidelines on how to continue the conversation. If you do post in that thread remember to do so with the purpose of helping solve any problems in the product. Propose solutions.

Also remember that even if the MegaFlashROM works fine for you (or any other hardware, for that matter), it may not work properly for other people for a variety of other reasons: the computer they're using it with, the software they're using, or a multitude of different factors. If you want to help troubleshoot, then do so by providing a description of your environment so problems can be isolated.

パトルク is also right in that pointing out flaws in a product isn't an attack, if the flaws are really there. "Don't shoot the messenger" makes sense in this situation.

Also:

Finally, I demand an apology from the staff, to be posted here, for this quote: "Yes, GuyveR800 starts with a hostile message." because it adds to the framing of alleged bad intentions.

You're right. My choice of words was bad and implied that your intentions were bad. I apologize.

I've locked this thread to avoid an ongoing offtopic discussion. Feel free to post in the conversation lounges or mail me directly if this is a problem.