Correct usage of VDP ports following the standard

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

By Grauw

Ascended (8310)

Grauw's picture

06-06-2017, 10:12

38H jumps to a routine in page 3 which changes the stack pointer and then does an interslot call.

By DarkSchneider

Paladin (854)

DarkSchneider's picture

06-06-2017, 10:18

OK, now I have all the info I needed. I'll test it. Thanks.

The idea is:

IM2 routine:

do what I did on H.KEYI, removing it from the H.KEYI
JP 38H

Before program exit, clean the hook (just like before but now only the H.TIMI needed), and return to IM 1 mode.

By ARTRAG

Enlighted (6228)

ARTRAG's picture

06-06-2017, 18:58

DarkSchneider wrote:

What I meant are a good ammount of calls (27 LDIRVM + setting the VDP registers) in only the ISR time, notice the 212 lines are used, so it had to finish before or it would have tearing. So not much penalty for the calls themselves. But as always everything is seen from the bad side.

@Grauw you could check this if interested, I think is enough. The MSX Datapack in Japanese could be too much, and I think is more device oriented (like MSX-Music).
http://www.konamiman.com/msx/msx-e.html
At MSX2 Technical Handbook

@ARTRAG I supposed something like that, VDP moving the current content to the backbuffer, and CPU generating the borders at the same time. The main concept of that is not the direct access itself, is the use of paralelism CPU/VDP. If with direct access, plus overriding the 38H is what you need to get the exact time for make it to work in a Z80A, with max of the sprites already shown and etc.etc. then fine, I will not discuss it.

Fine.

DarkSchneider wrote:

But also think that following the official way (even not overriding the 38H) you can reach the same, but with at some minor speed (it would slows down sometimes to wait for border generation probably, or at a lower step fps like 20 instead 30, or 30 instead 60, to give it room, in this case it will have more room also to do other things as there is too much extra room). That is not the same it can't be made at all. Because the real speed up of the process is the use of paralelism, the others gets you the timming to run it at certain fps in the base Z80A. So the real gain is, as said, because you look at architecture and see, at higher level, how to take advantage.
It would be interesting to see the result of using the blitter ops of BIOS, the VDP access with OUT (C), and not overriding the 38H result. Probably you are not interested on testing it, so don't worry.

Not fine. You are discussing. 60fs are not the same of 20 or 30fps. We do not agree on this elementar thing, so hardly we can continue some kind of technical discussion.

DarkSchneider wrote:

Also think that, targeting something so specific, you are closing to only ROMs (the only where you can override the 38H) for 64KB RAM computers. But I talk from the beginning about SOFTWARE, only SOFTWARE, not ROMs for a certain computer config.
So I put the official way to use it, and the topic of the thread was much varied. Even with little related things, specially I'm not religious. For me the topic is over. End of off-topic.

I do not fully understand your objection about the use of 64K of ram and the rom, and how the things are related, but it is clear that we do not look for the same things while coding.
I want to explore any possibility to get jaw dropping results exploiting any resource the HW has, you want to follow your rules for the sake of you now what, at cost of professing that it is better to have a shoot'em up at 20/30 fps respecting a dead sick standard instead of opening its coffin and updating the screen at 60fps.
Two points of view not conciliable. To me, 60fps are much better.

By ToriHino

Champion (348)

ToriHino's picture

06-06-2017, 20:26

Quote:

I do not fully understand your objection about the use of 64K of ram and the rom, and how the things are related, but it is clear that we do not look for the same things while coding.
I want to explore any possibility to get jaw dropping results exploiting any resource the HW has, you want to follow your rules for the sake of you now what, at cost of professing that it is better to have a shoot'em up at 20/30 fps respecting a dead sick standard instead of opening its coffin and updating the screen at 60fps.
Two points of view not conciliable. To me, 60fps are much better.

I agree, the interface and handling speed towards the VDP on MSX using I/O ports is already slow enough, so when you really want the best performance make it at least as fast as possible (and yes this means bypass the BIOS). The ports already are a de facto standard for years and not going to change.

By ARTRAG

Enlighted (6228)

ARTRAG's picture

06-06-2017, 20:38

Anyway, to be fully honest, in general, the most part of the code, using ram patcing, should work as it is or with minimal changes.
It is only matter of spending time and energies for a task that is essentially without purpose.

Maybe modern hw producers willing to not use the usual ports should also invest their time on a software tool able to process roms and com files replacing all the possible occurrence of 98h and 99h with 88h and 89h or whatever.
Same for audio ports, despite of the fact none can access to the ay8910 ports.
The new MA-20's could come with a pc tool to translate ports supporting in this way 30 years of games with hardcoded addresses

By DarkSchneider

Paladin (854)

DarkSchneider's picture

06-06-2017, 21:49

But do not put it as 60 to 30/20 fps because is not that. Really is very similar, same fps with a bit more slowdowns. If you target a lower fps in not to fit the same content precisely. The extra room gives much more.

@ToriHino slow is really accessing the master bus (can try any in/out compared to ram i.e.), VDP even slower. Precisely because that, the fixed cost of bus accessing, the use of the IN/OUT (C) version is near nothing compared to the IN/OUT (#).

By sd_snatcher

Prophet (3031)

sd_snatcher's picture

06-06-2017, 21:52

DarkSchneider wrote:
Grauw wrote:

Sorry, I edited my previous post after you quoted it…

Grauw wrote:

So there you’re not using the BIOS to switch slots, or am I mistaken?

IMO switching slots manually is a way worse offense than hardcoding the VDP ports… It’s tricky, quite an elaborate dance, and too many software didn’t get it right and does not work in subslots or in the same subslot as RAM as a result. Testing all possible configurations is difficult, bit easier nowadays with emulators but nevertheless you would need to do quite an exhaustive test. There I definitely recommend everyone to use the BIOS.

(Also on a side note the standard does not allow accessing I/O port 0A8H directly Big smile.)

In fact, it allows:
http://www.konamiman.com/msx/msx2th/th-5b.txt
Point 7.1.2. In this case it is really hardcoded in the system. Also notice that the function checks for expanded bit. "Not recommended", but possible, but for page 0 there is no other alternative but using the ISR, the other one way.

Sorry DarkSchneider. But it the standard doesn't allow direct I/O to any of the PPI ports. What that part of the MSX2 Technical Handbook literally states is:

(1) "Selecting slots is different for the basic slot than for the expansion slot. For basic slots, it is done through the I/O port at A8H (see Figure 5.38), and for expansion slots, it is done through the "expansion slot selection register (FFFFH)" of the installed expansion slot (see Figure 5.39).
(2) "It is not recommended to change them directly, so the user should not switch the slots without careful planning. When the program switches the slot of the page in which it resides, the action is not always predictable. To call the program in another slot, use the inter-slot call described in the next section."

As you can see, in part (1) of that paragraph, the author gives technical information on how things happen in the background. IOW, how the system does it. Then, in part (2), the author makes it clear that it's nor recommended to change these registers directly. Then it explains that it requires planning before switching slots with this restriction.

I take the opportunity to highlight an important part of the standard that was also subject of other heated discussions:

"The slot where MAIN-ROM or RAM is installed and the slot number of the slot for the cartridge depend on the machine. Refer to the appropriate manual to see how slots are used on your MSX. But the MSX standard guarantees the normal operation no matter what is in the slots, so it is not necessary to worry about the slot use, as long as you are following the standard."

Here, the MSX2 Technical handbook clearly states that both the MainROM and the RAM can be in any slot. Than it goes on to explain how that works:

"In some cases, however, it is required to know the slot number of the specified software. For example, in the previous version, BASIC MAIN-ROM was placed in basic slot #0 or in expansion slot #0-0 when basic slot #0 was expanded. So when MSX1 is upgraded to have the MSX2 functions by installing MSX-VIDEO and BASIC ver 2.0 ROM, the MAIN ROM should be placed somewhere other than slot #0 or slot #0-0. The slot where MSX2 SUB-ROM resides depends on the machine, but the information about the slot where BASIC interpreter ROM resides can be obtained by referring to the work area described below:

When calling BIOS from DOS, examine the slot of MAIN-ROM in this way.

* EXPTBL (FCC1H, 1) the slot of MAIN-ROM
* EXBRSA (FAF8H, 1) the slot of SUB-ROM (0 for MSX1)"

ARTRAG wrote:

Sd, the commercial life of msx standard has ended about 30 years ago.

I couldn't agree more with that. We're all here because of what? To me, it's because of a hobby, for +20 year old friendships, and to show what's possible with this little forgotten peculiar machine. :)

Quote:

I do not see as an urge to be compatible with new Frankenstein HW. All the msx machines I care, have been produced in 80's and 90's and are using the ports I use.
Those are the machines I coded when I was a child, not new monsters.

Ok, I understand that you have your drives and desires regarding the MSX. We all have. To me it's already very clear that we base our opinions in different premises. And it's a fact that when premises are not aligned, no discussion will ever reach a conclusion. If I understood your POV correctly from this thread and the innumerous previous discussions, the factors of Performance, Compatibility and Hardware Flexibility are prioritized like this. Please correct me if I'm wrong:

- Performance: first and uttermost important
- Compatibility is not of much relevance
- Hardware flexibility: near zero. The RAM slot can be different and that's it. Even the T6950 VDP is considered a problem. Machines with split-RAM, or RAM in slot-0 are aberrations that should be modded to fix them. Everything not build in 1983~1992 is considered a monster/Frankenstein. Turbos are inadmissible.

Corollary: as long as the software runs on your machines, it's fine.
Personal challenge: extract the most of the very same hardware. To prove what the hardware of that generation could have done if properly programmed.
Bottom line: Efficiency lies in micro-optimized code

In my case and DarkSchneider's, it's the opposite:

- Compatibility: first and uttermost important
- Hardware flexibility: very important. It's what allowed we easily to skip out of floppy disks to SCSI, then IDE, and now SD-cards. No clunky hardware floppy emulators and almost no software had to be rewritten. Turbos are wonderful.
- Performance: the best you can get without infringing the rules. After all a turbo is cheap, easy to install, and allow the extra power to be used for many other things

Corollary: as long as everyone respect the rules, it's fine. Like living in a developed society.
Personal challenge: To prove that the MSX philosophy was wonderful since it's inception: it's possible to write software that will still run regardless of the changes in the hardware underneath.
Bottom line: The MSX was all about compatibility, flexibility and hardware independence

Given such dismal differences in the premises, let's just agree to disagree, shall we? :)

ARTRAG wrote:

Grauw, it is a religious matter, you must obey to the sacred standard, do not think or discuss.
Ascii said that in the sacred book, believe and obey, the msx faith first.
No matter if those rules were set in a totally different context, 30 years ago, while the msx were produced by multiple manufacturers and that today they have more archeological value than other, as the last msx computers have ceased their production and commercial life in 90's.
Ah, I committed blasphemy! I will burn in the hell now... oO

Heheheheh! Yes, it might sound this way, but that couldn't be far from the truth. And in the case of this thread, the zealot attitude didn't come from the OP. He was posting his knowledge in a constructive way in a clear intend to help others, when he suddenly faced torches, hot oil and barricades to make that objective impossible.

And, since I develop both software and hardware, to what rules should I stick to assure compatibility for both types of projects and know how far I can go? To the flexibility guaranteed by the MSX official documentation, or to some arbitrary hardware/software restrictions out of the mind of each random guy that decides to rant?

Personally, I feel safer with the flexibility provided by the official documentation. If something doesn't run, it's not my responsibility to fix it. I did my best according to a common set of rules. The very same rules that define what the MSX is.

Quote:

Do you want more Mhz, colors or RAM? Use a PC.
PCs have won the computer battle of 80's, not the msx.
New HW not using ports or non using those ports will not run the existing software. This is just a fact.

What I see written above are very strict rules. And since the philosophy of this new set of rules is "the hardware has to run existing software", maybe should ban those damn expanded slots, plus the CX-11, HB-10P, HB-F500P, HC-95A, HX-23, HX-23F, HX-51, MB-H50 too? A lot of existing software doesn't run because of them. Maybe should also ban the C-BIOS, since it's so different form the original BIOS that it can't be acceptable? Existing software that bypass the jump table to save some cycles won't ever run on the C-BIOS.

What I mean with this parody is that dealing with this kind of absolutes is complicated. Similarly, someone the opposite mind set could state personal rules like these:

"Do you want direct access to the hardware? Use a console like the SG-1000 or Master System! Use a ZX-Spectrum!"
Video-games have won the battle for gaming against the Home Computers, not the MSX.
New SW that don't respect the rules will not run on a lot of existing hardware. This is just a fact."

But don't get me wrong because we're sitting at the opposite sides of the table in this specific subject. The fact is that I have a lot of admiration for your work, ARTRAG. You have created really impressive things that I'm proud to present on MSX meetings, like the "doom like engine", Uridium (MSX1/MSX2) that ISR sampled voice routine that is being used everywhere now, and the multi-layer smooth scroll on MSX2. If I ever visit Italy again, I would like to share some beer, and talk with you about how those things were created and the algorithms you used.

By hit9918

Prophet (2864)

hit9918's picture

06-06-2017, 22:10

an example where bios is much slower is when the nametable is not a plain copy

        ld a,(hl)
        inc hl
        add e           ;for pixelscroller
        out (0x98),a

replacing the OUT with a bios call ldirvm or something, it gets hell a lot slower.

but when it's in RAM one can poke the port number and that's it, retargeted to the other VDP at original speed.

By AxelStone

Prophet (2663)

AxelStone's picture

06-06-2017, 23:01

sd_snatcher wrote:

And, since I develop both software and hardware, to what rules should I stick to assure compatibility for both types of projects and know how far I can go? To the flexibility guaranteed by the MSX official documentation, or to some arbitrary hardware/software restrictions out of the mind of each random guy that decides to rant?

Personally, I feel safer with the flexibility provided by the official documentation. If something doesn't run, it's not my responsibility to fix it. I did my best according to a common set of rules. The very same rules that define what the MSX is.

I totally agree. At the end, it should be really cool to share some beers and have a nice discussion about different points of view.

About the main topic, don't be wrong, use of modern programming techniques is not exclusive for PC. MSX evolved a lot during 80's, at the end we had a DOS2 system with official compilers like MSX-C. A MSX with DOS2 and massive storage device is a really cool piece of hardware, very different to original MSX1 from 1983.

By Grauw

Ascended (8310)

Grauw's picture

06-06-2017, 23:31

@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.

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.

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.

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”.

---

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.

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