Any interest in a DIY MSX hardware group

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

Par Lord_Zett

Paladin (807)

Portrait de Lord_Zett

28-07-2015, 23:51

why not a v9958 and a more modern gfx chip? my problem with msx vdp is the lack of memory for my gfx.

Par anonymous

incognito ergo sum (116)

Portrait de anonymous

29-07-2015, 01:37

I think we are slightly straying from the subject if our intention is to discuss about an affordable MSX computer design not our dream MSX Wink .V9990 is great, OPL4 as well but they are not an feasible options. These IC are practically impossible to find nowadays unless they would be implemented by FPGA, something that seems really complicated seeing that the V9938 and V9958 implementation is not accurate yet. Perhaps a dual V9958 in FPGA would a possible solution. MSX-AUDIO? Of course, but I assume that the FPGA implementation would also be needed.

tvalenca: In my opinion we shouldn't remove the YM2413 chip here. It is one of the most importants parts of the MSX standard. As the PSG and SCC, the MSX-MUSIC has its charm and a supposed MSX wouldn't be the same without it.

As I said earlier, we have been discussed this topic many times in several forums with no result. I know that this time will not be different but at least starting a forum again is a very valuable input. I'm not a hardware nor software guru but I think if some people were REALLY interested, I'm sure we could reach a satisfactory and real solution. Splitting the work, this would become a reality.

Par uberjack

Champion (321)

Portrait de uberjack

29-07-2015, 06:12

I'd be happy with a 1 cartridge port, 128Kb MSX - floppy drive a bonus Smile

Par AxelStone

Prophet (3108)

Portrait de AxelStone

29-07-2015, 11:32

tvalenca wrote:
AxelStone wrote:

Yes but really 9978 was cancelled so we can never know if final version of 9978 should be compatible with 9958. Since 9978 project was cancelled and they switch to 9990, the original desing was lost.

You are right, MSX3 was intended to be a powerfull 16bit machine with unlocked R800 (equivalent to z80@40mhz, not z80@28mhz as the actual R800, and SIMD instructions), an according VDP like 9978 (V9990+V9958) and OPL4 sound chip. Since it was going to be backwards compatible I supposse that finally they should use the most cheap solution: 9978 with 9958 modes built in or 9990 + 9958.

Finally everything was dropped, they launched the remains of the original project using old 9958, limited R800, standar FM-PAC and they called it MSX turbo R.

What a pity. One MSX like that would be superb.

Do you remember where you learned about those MSX3 specifications?

I'll try to remenber and I'll link it. As far as I know, the main guilty of MSX3 project failure was precisely V9978. The computer was intended to be launched in 1990, but when Matushita asked Yamaha for VDP they answered there were still 2 years until finish it. Obviously Matsuhita couldn't wait to 1992 for launching MSX3 since 16bit consoles were dominating market, so they made the difficult decission of dropping the original project and launching MSX turbo R during 1990. They knew that hardware of turbo R was not ready to compete against 16bit consoles, so it was really a computer stillborn.

Par Grauw

Ascended (10581)

Portrait de Grauw

29-07-2015, 20:00

tvalenca wrote:

As you can tell, this would be a problem as some software was written ignoring BIOS and direct accessing YM2413 I/O port. If weren't for that we'll had just the OPL4 at its full capacity.

tvalenca wrote:

@RetroTechie thinks there's too much software that does direct keyboard scanning, And I think this is something worth testing, as SD-Snatcher already provided an Acid-Test that would detect that. (http://frs.badcoffee.info/MSXAcidTests.html).

Likewise the YM2413 issue, I would like to see the software being patched over such hardware translation solutions (two FM chips and two BIOS extensions on a single MSx on the YM2413 issue).

I think there is a mismatch between how some people think things should work, and how things do work.

There is no point to try and correct it, or keep hammering down how terrible others (e.g. me) are for not using the BIOS. I know I can bypass the BIOS in certain cases simply because, due to the giant existing library of software which does it as well, it is unfeasible to release any hardware which does not use the standard I/O ports and protocols. Which is great, cause it allows me to achieve more.

Patching all existing MSX software which does not obey your standards is a totally crazy, unfeasible and impractical endeavour. The negative impact on compatibility would make the hardware nearly useless. And why, for some theoretical objection? Do you have nothing better to do than patching software and distributing said patches to everyone who then has to apply it all the time to play the software they want to play? You can just implement translation logic in FPGA and have everything work out of the box…

As you can probably tell from my tone of voice, I’m getting a bit tired of people advocating this fairy tale world of accessing everything through the BIOS, and whoever doesn’t is a “gambiarra” :).

tvalenca wrote:

But the worse of it is that we're doing a gambiarra and we still have the ghosting problem, which is worse on PC keyboards.

There are plenty of gamer PC keyboards which have no ghosting. Even my normal PC keyboard also succeeds “the Nemesis test” so it’s definitely not the case that all PC keyboards have such issues. Like on MSX, ghosting is not a problem of the protocol but of the keyboard itself. Most importantly, if it does it is easy to replace it with a better model because USB keyboards are actually easy to come by.

In the contrary, nearly all MSX keyboards have terrible ghosting, way worse than anything ever experienced on PC, and you’re stuck with it. I can’t type even type CD+space on my MSX computers without it generating a ghost HOME or F1 key press half of the times. Play some chords on the alphanumeric keys in Synthesix? Half of them are impossible and fail horribly. A nice USB-to-PPI FPGA translation can get rid of that ghosting, good riddance.

Par tvalenca

Paladin (747)

Portrait de tvalenca

29-07-2015, 21:07

Grauw wrote:
tvalenca wrote:

As you can tell, this would be a problem as some software was written ignoring BIOS and direct accessing YM2413 I/O port. If weren't for that we'll had just the OPL4 at its full capacity.

tvalenca wrote:

@RetroTechie thinks there's too much software that does direct keyboard scanning, And I think this is something worth testing, as SD-Snatcher already provided an Acid-Test that would detect that. (http://frs.badcoffee.info/MSXAcidTests.html).

Likewise the YM2413 issue, I would like to see the software being patched over such hardware translation solutions (two FM chips and two BIOS extensions on a single MSx on the YM2413 issue).

I think there is a mismatch between how some people think things should work, and how things do work.

There is no point to try and correct it, or keep hammering down how terrible others (e.g. me) are for not using the BIOS. I know I can bypass the BIOS in certain cases simply because, due to the giant existing library of software which does it as well, it is unfeasible to release any hardware which does not use the standard I/O ports and protocols. Which is great, cause it allows me to achieve more.

Patching all existing MSX software which does not obey your standards is a totally crazy, unfeasible and impractical endeavour. The negative impact on compatibility would make the hardware nearly useless. And why, for some theoretical objection? Do you have nothing better to do than patching software and distributing said patches to everyone who then has to apply it all the time to play the software they want to play? You can just implement translation logic in FPGA and have everything work out of the box…

As you can probably tell from my tone of voice, I’m getting a bit tired of people advocating this fairy tale world of accessing everything through the BIOS, and whoever doesn’t is a “gambiarra” :).

Well, this wasn't directly aimed to anyone. Sorry if you felt offended, @Grauw. I extend my apologies to anyone who felt offended about what I said. I won't say anything again about this matter. But is still a "gambiarra"! LOL! ;) :RNFF:

Grauw wrote:
tvalenca wrote:

But the worse of it is that we're doing a gambiarra and we still have the ghosting problem, which is worse on PC keyboards.

There are plenty of gamer PC keyboards which have no ghosting. Even my normal PC keyboard also succeeds “the Nemesis test” so it’s definitely not the case that all PC keyboards have such issues. Like on MSX, ghosting is not a problem of the protocol but of the keyboard itself. Most importantly, if it does it is easy to replace it with a better model because USB keyboards are actually easy to come by.

In the contrary, nearly all MSX keyboards have terrible ghosting, way worse than anything ever experienced on PC, and you’re stuck with it. I can’t type even type CD+space on my MSX computers without it generating a ghost HOME or F1 key press half of the times. Play some chords on the alphanumeric keys in Synthesix? Half of them are impossible and fail horribly. A nice USB-to-PPI FPGA translation can get rid of that ghosting, good riddance.

Maybe I'm not the fastest typer (so I never got anything else when I typed "CD+space"), but I'm aware that MSX keyboards are also prone to ghosting. But I do get lots of it on PC keyboards. Maybe because decent keyboards are expensive here in Brazil (a good "gamer keyboard" costs more than EUR 100 in brazilian currency! That's way too much money for just a keyboard!) So some of us just stick to the shitty ones.

If reality is so different where you guys live that a "gamer keyboard" is less than 25% more expensive than a regular keyboard, then my argument isn't valid for your reality, and like you said, "A nice USB-to-PPI FPGA translation can get rid of that ghosting, good riddance."

Par Grauw

Ascended (10581)

Portrait de Grauw

29-07-2015, 21:52

Sorry for being so grumpy Smile.

Par sd_snatcher

Prophet (3505)

Portrait de sd_snatcher

29-07-2015, 23:09

Grauw,

Please don't get me wrong when I advocate for following the MSX coding guidelines. It's not the "you should be burned at the stake for not following this rules" mindset, but rather a "hey guys, I found that this is an awesome challenge to be good at. It forces you to think out of the usual. Come and join us! Smile "

The only thing that makes me sad is that I indeed face the kind of reaction "you should be burned at the stake for promoting this" . Not from you (ever), but it unfortunately already happened elsewhere. But there's always the other side, I also get a lot of support from other friends too. It kinda compensates. Smile

But I always say that MSX is our hobby. A guy must code as he pleases. I just try to convince people that:

- There are many advantages on following the standard. I.e.: Easy to redirect devices. Like PSG to SCC. OPLL to OPLn. Floppy to HDD/Flashcards, etc etc etc
- People tend to only look (and overestimate) the disadvantages of using the BIOS.
- People tend to ignore the disadvantages of not following the standard. I.e.: It pushes the burden to the hardware the development side, turning it limited, complex, expensive and easy to break the compatibility.

While compatibility/flexibility was the main reason for the MSX birth.

That said, nowadays coding without following the guidelines makes me feel like I'm coding a Colecovision, or a SG-1000, and not a MSX. But that's *me*. I'm the weird sheep. Wink

Par Dirty Harry

Resident (45)

Portrait de Dirty Harry

07-08-2015, 10:49

What hardware is currently being developed for the MSX ?

Par syn

Prophet (2096)

Portrait de syn

07-08-2015, 11:29

plenty

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