Checking interest for DalSoRi version 2

Page 9/11
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11

By JunSoft

Rookie (19)

JunSoft's picture

17-02-2017, 04:44

@I_oliveira

I can't understand what the toggle register is. Sorry.

By current specification, you can determine which mode (ROM+RAM or RAM) is selected at reset.
There will be four switches:
1: disable/enable BIOS memory
2: disable/enable FM I/O port on C0H-C3H
3: disable/enable FM I/O port on C4H-C7H
4: memory configuration (2MB ROM + 2MB RAM or 4MB RAM)

Above switches determine the default configuration. Thus, you can't the configuration during operation.
Any problem? Then let me know.

By Langoor2

Supporter (12)

Langoor2's picture

17-02-2017, 13:48

I am reluctant to post in this thread again because of sd_snatchers aggressive and disingenuous posts.
I don't understand why he is using personal attacks and accussations of trolling to defend his opinion. It looks like a religious war.

However, it must be made clear that his claims about the MSX standard are taken out of context, just like he tries to apply my words out of context. There seems to be a problem with reading and understanding.

We are talking about a device here that is not part of the core MSX standard. Nowhere does the MSX standard claim that external devices can't be I/O only. It merely suggests to prefer memory mapped I/O instead. Nowhere does it require that external devices require a BIOS.

Only when one accepts sd_snatchers dogma that MoonSound should be a form of MSX-AUDIO does anything he says make a little sense. Either way, history has made any hardliner interpretation irrelevant. Even Konami's MSX1 games did not follow the MSX standard literally and caused problems for future generations.

Relax and use common sense, please.

By sd_snatcher

Prophet (2328)

sd_snatcher's picture

17-02-2017, 14:05

@l_oliveora, my friend, don't get me wrong but: are you kidding? Smile

That would require a CPLD (or FPGA) with 31 extra pins to decode all the required signals, not to mention the 31 extra tracks in such a small cartridge. Seriously, for the price of a CPLD/FPGA this big, there are way more interesting things to do (like the ADPCM) than just to appease the desires of those who don't want to comply to the standard. And with a much lower PCB complexity too.

The standard was designed the way it was because it's the most cost effective way to maintain compatibility/expansibility without having to resort to insane hardware contraptions. Otherwise the computer hardware ends up becoming a [url=https://en.wikipedia.org/wiki/Rube_Goldberg_machine ]Rube Goldberg machine[/url].

If the application software had been programmed as it should, this sound card would have been much cheaper to produce. Instead of an > €300 hardware solution to have an ADPCM+OPLL hardware translation plus €130 to decode addresses in the SampleRAM bus, it could be easily done with these features programmed in software, for the "option-2" €130 cartridge price. Not to mention the difference in cartridge size.

The hidden cost of ignoring the software coding guidelines is that it pushes the complexity to where it hurts more (both effort and money) to change anything: the hardware realm.

By l_oliveira

Champion (501)

l_oliveira's picture

17-02-2017, 15:06

Honestly you guys are doing this wrong. I *thought* you were using a big SDRAM memory to save costs. Instead, you guys take expensive SRAMs to make a cart simpler. The FPGA + SDRAM costs less than just the 4MB of SRAM you guys intend to use.

By sd_snatcher

Prophet (2328)

sd_snatcher's picture

17-02-2017, 20:06

Quote:

I am reluctant to post in this thread again because of sd_snatchers aggressive and disingenuous posts.
I don't understand why he is using personal attacks and accussations of trolling to defend his opinion. It looks like a religious war.
However, it must be made clear that his claims about the MSX standard are taken out of context, just like he tries to apply my words out of context. There seems to be a problem with reading
and understanding.

And now trying to play the victim. You're the one who are discussing behind a puppet account. You're the one who entered the thread in a very aggressive way. You're the one who tried to impose your way through irony, fallacies, dogmas, personal attacks, self depreciation, misconceptions and trying to twist what others have said. You haven't been honest for a single post in this thread, and try to label my posts as "disingenuous".

Go review the thread. My arguments always targeted your false statements, your attitude, and your distorted reality. The one who did the personal attacks here was you. As in the 1st phrase that started this message.

And since you're doing it again, I have to repeat: the attitude of using the psychopath reflexive argument here won't work. All those labels you're trying to cast on others are mere projections of your own mental model.

Quote:

We are talking about a device here that is not part of the core MSX standard. Nowhere does the MSX standard claim that external devices can't be I/O only. It merely suggests to prefer memory
mapped I/O instead. Nowhere does it require that external devices require a BIOS.

Is this the same guy who was just talking big about about problems in reading and understanding? Let's review some basic logic classes then:

1) Premises mentioned on the official documentation:
a. All I/O accesses must be done using BIOS calls
b. MSX manufacturers may change some of the hardware from the standard MSX system and maintain software compatibility by rewriting BIOS
c. Do not write programs to directly handle the hardware. Use routines prepared in BIOS so as to isolate the software from the hardware and make future changes to the hardware without affecting the existing software possible.
d. By using the functions provided by BIOS, application programs can access the MSX hardware without modification, even though the hardware is different.
e. Hardware can have port mapped I/O or memory mapped I/O. The former is always preferred.

2) Corollaries

a. From (1a), (1c) and (1d) it becomes obvious that, if any application wants to access a device, this device must have BIOS API. After all, state "access only through a BIOS without a BIOS being present" would be paradoxical, don't you think? The lack of such comprehension sounds like asking if you can walk on the moon without a space suit.
b. From (1c) and (1d), it's obvious that the maker wants his hardware is to be accessible to an application, it must provide some sort of BIOS.
c. From (1a to 1e) and (2a to 2b), if becomes obvious that there can't be an I/O only device, regardless of being I/O mapped or port mapped, because it wouldn't just bee seen by any compliant application software

The corollaries probably aren't explicitly stated in the book probably because the Japanese have this cultural thing against stating something that can be obviously deduced from the premises. They always say that people must think before they say something. You'll see this cultural aspect in nearly all technical documents from Japan.

You seem to suggest that you're technically skilled. But given your arguments, would you enlighten me of what is the case happening here? Because I can't come to a conclusion of which situation is going on: if it's ignorance or malice over the documentation.

If you don't want to follow the rules, don't try to create fake ones or twist the existing. Just be honest and state out loud that you don't care about compatibility, or the MSX standard, or other people software/hardware. You just want things to work in your own machine and that's enough. It's the others that must change their ways, modify their hardware or software to be adequate to your machine specs.

Quote:

Only when one accepts sd_snatchers dogma that MoonSound should be a form of MSX-AUDIO does anything he says make a little sense. Either way, history has made any hardliner interpretation irrelevant

First, let me tackle the attitude in this one: Yet another fallacy, now argumentum ad lapidem. Not to mention another cheap psychopath reflexive argument again. You're the one stating dogmas here, remember? You haven't proven anything you stated yet, and when proven wrong you begin ad hominem attacks like these.

Now, the argument itself: You know, I had a professor at the university that used to state "The grass changed its color, the donkey starved to death." I'm sure you can you deduce the meaning. But with that logic I really wonder if you consider the TMS9918 and the V9958 to be related.

Quote:

Even Konami's MSX1 games did not follow the MSX standard literally and caused problems for future generations.

Wow. This one is sophisticated. Many fallacies clustered one upon another, what makes it a shotgun fallacy itself, composed of: Appeal to authority, appeal to common practice, and Historian's fallacy.

If I earned a penny for each fallacy I've read from you, I would became a rich man. Are you sure you want to expose yourself like this in public just for the sake of imposing your dogmas? Are you usually welcome at MSX meetings? Depending on the answer, maybe you should rethink your attitude. Or can it be that everyone is wrong except you?

Quote:

Relax and use common sense, please.

I'm pretty much relaxed. And have another tip for you: The common sense in this community is not to use puppets, and not to think that the users of the site are fools who will believe in loads of fallacies.

By mars2000you

Enlighted (5024)

mars2000you's picture

17-02-2017, 20:21

@sd-snatcher: probably the real reason of Langoor2's behaviour is the fact that he's coding a Moonsound application that will not support MSX-AUDIO, at least in the way you have proposed. So, he's seeing your proposal as an attack against his personal coding project.

By Grauw

Enlighted (5491)

Grauw's picture

17-02-2017, 20:26

Well, JunSoft’s introduction to the western forums is a good one, with all the bickering going on Shocked! .

By sd_snatcher

Prophet (2328)

sd_snatcher's picture

17-02-2017, 21:09

@mars2000you

Interesting to know that. What proves that he wants the rest of the world to be bend to conform to his hardware configuration and his own incompatible way of coding his pet project.

By JohnHassink

Ambassador (4711)

JohnHassink's picture

17-02-2017, 21:35

This ongoing discussion is very confusing for people reading along who aren't that tech-savvy. I mean, I can't be the only one who's confused, right?
I thought the DalSoRi was simply an MSX OPL4, like the Moonsound. So if this new version will have backward compatibility with OPL1/MSX-Audio and contain its BIOS, it's somehow a problem?
Again, really confusing what the actual problem is. You'd think, as long as it's a proper OPL4, then just not use the parts you don't want to use?
But I'm probably seeing it too simple, as I lack the knowledge to follow all this technical talk. I just don't see the problem.

By Grauw

Enlighted (5491)

Grauw's picture

17-02-2017, 21:45

A BIOS opens nice opportunities, and for those who want / need to program bare-to-the-metal, a BIOS has never held me back. There should be no conflict here.

Though I think it is unreasonable to demand from hardware that it supports I/O expanders which are by their very nature a hack. If a cartridge works in an I/O only slot, great, lucky, but IMO hardware should not be designed to support them. Our I/O address space is swamped, and memory-mapped I/O is a good thing; though requiring a bit more effort to use, there’s never any conflict with other hardware.

As for all this discussion about standards, it’s important but it’s not holy. I see the opportunities when everything goes through a BIOS (compatibility, expandability, built-in Basic extension, etc.), but there are also opportunities lost, in terms of getting the best performance out of our systems and having direct access to the hardware capabilities. This is why it’s great that programmers have a choice to use what is most suitable for their project.

I think we should be happy with this hardware development. A MoonSound with 4MB sample RAM has been a long standing wish of Guyver’s (or should I say Langoor2), and a MoonSound with a BIOS is a long standing wish of sd_snatcher. These don’t bite.

Props to JunSoft for expanding this hardware into new realms. Props to Guyver for working on a great tracker. Props for sd_snatcher for exploring how far he can develop the MSX-AUDIO BIOS. Hardware is at its best when it has software support, and JunSoft can count himself lucky to have two parties interested in working on software for the new hardware features he is developing.

Page 9/11
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11
My MSX profile