Correct usage of VDP ports following the standard

Page 10/18
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15

By ARTRAG

Enlighted (6240)

ARTRAG's picture

07-06-2017, 01:07

SD my scale of priorities is not far from the one you have depicted, but actually I care of compatiblity much more than it could seem, at least when it is important to care of. There is no point in banghing your head with exotic slot configurations for a tech demo or a proof of concept project.
It is different with the cartridges sold for real money. Our games should be compatible with all the machines documented in openmsx and as we tested them on all the "critical" configurations (physical or emulated) we were able to. About the Toshiba vdp, we added an apposite option in the Uridium menu to reduce the smoothness of the scrolling and be able to run also in the presence of this vdp, so we supported them.
This to say that compatibility is important when it is a mean to produce cartridges, bat not among the goals of my work.

Said that, I have to stress that I have no interest supporting what you could get today by grafting a NVIDIA card on an msx1 or by upgrading the cpu with a Core I5...
You can also think that your new frankenstein HW is compliant to the sacred msx standard but you will not be able to run the vast majority of the existing software if you do not support the ports it uses and you do not provide a plain z80 at 3.58MHz.
At this regard, why do you think that the msx TR has a z80 mode ? Nostalgy or need of compatibility with the existing SW base ? Wasn't Panasonic aware that is sufficient to put the correct I/O ports at 6-7H and provide valid bios entries to run all the msx software?
As I told earlier, if you want more MHZ, faster RAM, more colors, use a PC. If you want to run the msx software put the vdp at 98h-99h and the AY8910 at A0h,A1H, A2h and provide a z80 at 3.58Mhz.

By DarkSchneider

Paladin (862)

DarkSchneider's picture

07-06-2017, 10:57

Please do not convert the topic to a "I am right" or "and you more" and things like that. Not interested in that way, really. Try to be always constructive. I am not talking to anyone in particular (please notice that) but as general rule.

What @sd_snatcher is saying is exactly the same I feel and tried to explain. I see the MSX as a "small PC", or a "cheap PC", that indeed was its original concept.

I don't mind optimizations?, that's not true. I make many benchmarks to get results and focus on which I get more benefit. I would not use something if it really "destroyed" the thing.
Bypassing the rules to get some extra juice, in the case of our software, which has much other kinds of logic and complexity, the "API calls" (let's name in this way) could be about an improvement of 1-2% AS MUCH. Pure math, adding the extra cycles it takes, the number of calls, the total cycles we have per interrupt (more than 60K). We already have computed all of that. And then decided if worth or not.

In a computer environment, also you can't do that things of overriding the 38H, expect an exact behavior (as a device can be attached generating its own interrupts to be handled in H.KEYI), etc.etc. So the exact fit way is NOT even an option, as can be seen.

I think I told many messages before. It is simply using the MSX as a videogame console (even the closed environment is required) or as a computer.

About "then why not using a PC?", easy, not interested. I want to make software for MSX, for PC is a complete different story, as we have OpenGL, DX, Unity, Unreal Engine...for making completely different games. Is a personal decision to make the software for MSX.

By hit9918

Prophet (2866)

hit9918's picture

07-06-2017, 14:36

the whole thing is like this.
you want it like "PC coding".
you saw MS DOS running in a window. and believe that bios coding is the basis.
while it never ran without a 386 ***MMU*** that retargets OUTs to an emulator!
the whole basis for the bios coding promotion is an error.

and the same was in the MSX C thread with the same error as basis.
the irony is that the protagonists of bios coding thread and MSX C thread are the same people
and that by your own idea the horray horray MSX C is evil. because its ldirvm does port IO. which wrecks on 6Mhz.

By sd_snatcher

Prophet (3055)

sd_snatcher's picture

07-06-2017, 21:48

Grauw wrote:

@sd_snatcher For me it’s:

- Performance: important
- Compatibility: important
- Hardware flexibility: near zero

Note that compatibility for me includes machines with split RAM, different VDPs, turbo CPUs and all kinds of odd slot layouts. Please do not mistake me that I don’t find compatibility important! I often go through great lengths for it. E.g. I spent quite some time debugging VGMPlay on the OCM and making a workaround, and got in touch with KdL for a real fix. I don’t think I display an I-don’t-care attitude there Smile (although I could’ve just said “it’s not my responsibility”). So if you’re putting it so black/white as if I do, not being in the BIOS camp… (Although you were addressing ARTRAG) I feel the urge to respond Smile.

Sorry, it wasn't my intention to be offensive. It's not easy to express every detail of the problem, and the post was already gigantic. I've met you in person in Netherlands, and and could confirm that you're a great person with a keen mind and very open to dialog. I have very fond memories of my trip to Netherlands and even more of the nice people I met there.

Too sad my trip to Italy was much more rushed. I couldn't find time to meet any MSX users there. I'm think it would have been another great evening if I had met ARTRAG in person too.

Quote:

But just like I may make exceptions on the performance aspect (like I use ix/iy and OOP a lot), I also may make exceptions on the compatibility aspect (like I access all sound chips directly in VGMPlay). I think VGMPlay supports much more sound expansions than any BIOS would provide me, but yes there is no automagic future-proofability if people are going to make new hardware on god knows what I/O address and with god knows what kind of specs.

The majority of those sound expansions fall in the same category as the SCC. They're proprietary extensions that the standard doesn't has anything to say. It would have been better if such soundchips used memory I/O like the SCC instead o port I/O, just for the sake of saving this scarce resource and avoiding I/O conflicts. But that's just a thought.

Quote:

Finally, I am not really interested in following theoretical rules to achieve theoretical benefits. I only care about hardware that people actually have. And such hardware must have at least decent compatibility with the existing software base or people won’t be using it anyway! (And if a few do — that’s a choice they made). This is why I say: hardware “flexibility” near zero. I don’t need to be ultra flexible, because in practice I know that the hardware needs to obey certain rules to be compatible with the existing software and hardware base.

But take a look in retrospective. If everyone did that in the 80's regarding the disk access, the MSX disk interface wouldn't have evolved as much as it did. The MSX went smoothly from floppies to SAS, then SCSI, then IDE, and now SD-cards and USB interfaces. We could have done exactly the same with keyboards and mice couldn't we? The light-pen could be easily replaced with touchscreen using exactly the same BIOS interface. We could use our MSX with touchscreens these days! 34 years later! That talks a lot about a platform that was envisioned to be flexible and last through the test of time, doesn't it? Smile
It's just the same as if back in 1983 when the MSX1 was released, some old computing platform from 1949 had been so well designed that it could be easily connected to floppies, TVs, mice, tape recorders, etc.

OTOH, in Brazil, direct FDC access was "the hottest thing" to do in the 80s, specially because Microsol had become a de-facto standard. Magazines promoted that, stating all the advantages and that you could squeeze every drop of performance from the drives. They criticized Sharp because their disk interface was had memory access instead of the "same I/O ports that everyone used". Lots of disk utilities, copiers and hacked games only worked with the Microsol-compatible interfaces. I myself was convinced that this was the way to go, ditched my Sharp interface and replaced it with a Microsol clone from Racidata.

Well, the history speaks for itself. Those utilities, copiers and hacked games are long forgotten and unusable. Their "fantastic direct I/O performance" pales against any modern IDE or SDcard interface accessed via BIOS. Up to these days, those softwares are still limited to the hard-to-find DS/DD floppy disks, while the "slow and bureaucratic" software that used the BDOS/BIOS can happily enjoy large capacity drives in sizes and transfer rates that were unimaginable even for the most powerful PCs of the days.

And I feel that we're following very same path regarding mice and keyboards, for example. Personally, I have second thoughts on having to attach powerful peripheral computers to my MSX (more powerful than even the PCs of the time) to spoon-feed it like a decrepit old guy.

Quote:

Of course if a user requests something that would make the software work on their system with their hardware, I’ll always be happy to look into it if it’s not too much trouble. I think that applies to most developers. I think the core of my motivation is to make my software nice for the users, run smooth, works without effort, not too much configuration, etc. What is completely counter to my beliefs is e.g. to require users to mod their modules with BIOS ROMs “because they’re not made to standard”.

Since you mentioned it, I think I might have passed the wrong message regarding this topic before. While is fun and even nostalgic to speak it as a "fix of the past", this saying should be taken with a grain of salt. It's to be taken as seriously as when someone says "this is what could be done to the MSX back in the 80s if it was properly programmed".

But in reality, to me the BIOS upgrade for the Music Module just like the SampleRAM upgrades that existed before it: it's something that the user might want to do mod/install to enjoy the benefits that it can provide. There aren't many software that makes use of none of the two upgrades, but the BASIC extension contained in the BIOS instantly gives it access to the whole MSX-Music library of songs written in BASIC. Not to mention the instant support on most of the Compile games and the games from ASCII that use the FM. This is way more software than the SampleRAM upgrade provides, but nobody criticizes the SampleRAM upgrade, do they? Smile

Quote:

Some other thought;

An example where I actually dearly miss a BIOS universally deployed in all hardware, is the RS232 / MIDI situation. There are so many different devices and no standard, it’s a ton of work to support all of them, and you need the actual (or emulated) hardware to test with. For Synthesix I went through great lengths to support a bunch. Having some universal API there would’ve been great.

However at the same time I fear the BIOS would probably have been implemented with 1200 baud modems in mind, and not be performant at all (it always tends to end up that way). I think I would just prefer a good library which I can tweak, or a driver system like the Ethernet UNAPI which can be expanded without modifying hardware.

The good news is that the original MSX-Audio BIOS had provisions for MIDI since its inception. It even provide new hooks for that. The bad thing is that it's not complete. And unfortunately, to complete it on a version >1.3 would require way more free time than I have available right now. Sorry. I would love to be able to help you.

By sd_snatcher

Prophet (3055)

sd_snatcher's picture

07-06-2017, 20:04

Quote:

SD my scale of priorities is not far from the one you have depicted, but actually I care of compatibility much more than it could seem, at least when it is important to care of. There is no point in banghing your head with exotic slot configurations for a tech demo or a proof of concept project.
It is different with the cartridges sold for real money. Our games should be compatible with all the machines documented in openmsx and as we tested them on all the "critical" configurations (physical or emulated) we were able to. About the Toshiba vdp, we added an apposite option in the Uridium menu to reduce the smoothness of the scrolling and be able to run also in the presence of this vdp, so we supported them.
This to say that compatibility is important when it is a mean to produce cartridges, bat not among the goals of my work.

Ok. considering your premises, I agree that it's a valid point of view.

I just reserve the right of having my point of view, that sees this same subject from a different perspective. Each POV has advantages and disadvantages, and I think everyone here (myself included), has their mind made about this subject. I also can't see anyone (again, including myself) here changing their minds because of any argument that could be said, other than to try to reinforce his/her own POV again and again.

All I ask is for thread to be allowed proceed undisturbed and without fruitless criticism, so those who like to code according to the guidelines can exchange their ideas on techniques and algorithms to get the best out their machine this way without worrying about tomatoes, torches and stones.

Quote:

Said that, I have to stress that I have no interest supporting what you could get today by grafting a NVIDIA card on an msx1 or by upgrading the cpu with a Core I5...

hehehehe! If such machine was build, I would join sides with you to say that it's a Frankenstein that doesn't resemble the MSX the slightest. But come on, that's a bit of an exaggeration of what I said, isn't it? I'm talking about turbos, disk interfaces, V99x8 and classic OPL soundchips here.

Quote:

At this regard, why do you think that the msx TR has a z80 mode ? Nostalgy or need of compatibility with the existing SW base ? Wasn't Panasonic aware that is sufficient to put the correct I/O ports at 6-7H and provide valid bios entries to run all the msx software?

I have some funny views and did a bit of archeology on this topic that would be nice to share. But the tempers here are a bit too heated right now, and I fear it would sound like just confrontational argument, instead of a friendly chat on a pub as it should be. Maybe in another opportunity.

By Grauw

Ascended (8398)

Grauw's picture

07-06-2017, 21:58

sd_snatcher wrote:

Sorry, it wasn't my intention to be offensive.

Don’t worry, I wasn’t offended at all Smile. And it was a pleasure meeting you in person! I understand your reasoning, just felt the desire to respond because I think two different things (coding by the book and compatibility) were more or less presented as being the same thing while they are quite different goals with different considerations and solutions.

sd_snatcher wrote:

Since you mentioned it, I think I might have passed the wrong message regarding this topic before. While is fun and even nostalgic to speak it as a "fix of the past", this saying should be taken with a grain of salt. It's to be taken as seriously as when someone says "this is what could be done to the MSX back in the 80s if it was properly programmed".

But in reality, to me the BIOS upgrade for the Music Module just like the SampleRAM upgrades that existed before it: it's something that the user might want to do mod/install to enjoy the benefits that it can provide.

Actually I think it was DarkScheider who expressed something like that in another thread that I disagreed with Smile. Definitely, I think the MSX-AUDIO BIOS upgrade is great and adds plenty of value on its own! I like that kind of improvement project, just like Nextor. I think it’s also neat when it makes it into hardware.

(On a complete side note, my only concern is whether it wouldn’t conflict; OPL is a subset of OPLL because it lacks a waveform, also the damping works a bit differently. So for Basic music, which uses _MUSIC, wouldn’t it result in inferior playback if there’s an internal MSX-MUSIC? Same for MSX-MUSIC BIOS emulation.)

(Secondly, on your site you mention Yamaha's recommended algorithm for sound chip detection, got some link? Interested.)

sd_snatcher wrote:

The good news is that the original MSX-Audio BIOS had provisions for MIDI since its inception. It even provide new hooks for that. The bad thing is that it's not complete.

Aren’t the MSX-MIDI BIOS, MSX-AUDIO BIOS, MSX-MUSIC BIOS and SFG MBIOS all very similar and based on / evolutions (/ hackjobs) of the same codebase?

sd_snatcher wrote:

I have some funny views and did a bit of archeology on this topic that would be nice to share. But the tempers here are a bit too heated right now, and I fear it would sound like just confrontational argument, instead of a friendly chat on a pub as it should be. Maybe in another opportunity.

Curious now! Big smile

By DarkSchneider

Paladin (862)

DarkSchneider's picture

08-06-2017, 08:49

It could be problematic if devices uses memory instead I/O because when using compilers you don't know if that address will be used or not.

@Graw the good thing of APIs is the HAL (hardware abstraction layer) giving standarization transparent to the software (needed for an open architecture with multiple device manufacturers, and evolving mantaining compatibility), and versatility of everything.
Just an example, the OPLL is a minor version of OPL2 https://en.wikipedia.org/wiki/Yamaha_YM2413, having access to both modes probably needed to use different ports to be detected and used like really the old MSX-Music. If you put a MSX-Music BIOS in that device with OPL2 (probably with a switch selector to select the mode), it could work internally as both, the old MSX-Music and the new "MSX-Super-Music" with OPL2. It is its "driver" (give access to device low-level usage) and can provide also the API (like some extensions or build-in player).

Then it is something about defining standards and then any hardware that could achieve that could be used. This is exactly the way the computing science has evolved.

By Wlcracks

Champion (321)

Wlcracks's picture

08-06-2017, 16:24

if this topic was msx code lines, it was a neat application or game!

By PingPong

Prophet (3437)

PingPong's picture

08-06-2017, 20:50

Wlcracks wrote:

if this topic was msx code lines, it was a neat application or game!

and maybe does not fit in msx memory

By ARTRAG

Enlighted (6240)

ARTRAG's picture

08-06-2017, 21:54

Maybe older compilers do not allow to specify address ranges for dedicated uses, but hitech-c v7.8 allows full control of the memory mapping, defining what goes where

Page 10/18
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15