Using BIOS vs. I/O ports in VDP programming

By janghang

Expert (120)

janghang's picture

13-01-2013, 07:23

Like this article (http://map.grauw.nl/articles/vdp_tut.php), we can directly access VDP I/O ports when creating some VDP programs, instead of simply using MSX BIOS calls. Hacking I/O ports looks definitely more difficult but I guess the I/O port access allows for more finer and low-level controls of VDP.
Apart from the programming usability, how much of performance benefit can we see from accessing VDP I/O ports? If there is no any performance gain from accessing VDP I/O ports, why do we have to use it?

Login or register to post comments

By Marq

Champion (387)

Marq's picture

13-01-2013, 09:54

Let's put it this way: you have to do it directly to do anything realistic Smile The performance difference and the improved control are significant.

By Edwin

Paragon (1182)

Edwin's picture

13-01-2013, 10:12

It's not really that much more complicated. And the speed difference can be substantial if you need an interslot call for MSXDOS. For things like screens splits it's probably necessary. For the rest it's more of a choice to not want to deal with BIOS.

By ARTRAG

Enlighted (6515)

ARTRAG's picture

13-01-2013, 10:23

Add that you can assume that vdp ports are and will be forever 0x98 and 0x99 in 99,99% of the cases.
The sole relevant case where vdp ports are different (within the 0,01% of the existing and used HW) is for some Brazilian chart to expand msx1 to msx2.
Anyway I would safely assume that the owners of such and exotic expansion, if still running msx SW of their real HW, have probably bought also a real msx2 in the last 30 years.
;-)

By msd

Paragon (1461)

msd's picture

13-01-2013, 11:22

You do need to use the bios when you want to be compatible with these "exotic expansion", you can make your own program in such a way that it supports the vdp on different ports. You can read out the vdp base ports in the Main ROM.

By Manuel

Ascended (18086)

Manuel's picture

13-01-2013, 12:43

As msd said: that's exactly how it's defined in the MSX Technical Data book. Do it like that, and it's both compatible and FAST.

The expansion I know is the NEOS MA-20 Version Up Adapter.

By hit9918

Prophet (2904)

hit9918's picture

13-01-2013, 18:19

Not only is bios copy two times slower, when actualy doing something else than copy, you would need ultraslow vpoke.
Another nice thing is that vram is always there, no matter what slot situation.
Instead of the video chip snipping the 64k space, you got an extra space to stream to.

In my diskloader game using BLOAD I had the problem that the bigger my code gets, the smaller gets the BLOAD area, the maximum filesize one can load.
So for a bload I save the code in vram, lol!

By hit9918

Prophet (2904)

hit9918's picture

13-01-2013, 18:59

In RAM code, you can selfmodify the immedate loads to standard conforming VDP ports.
Running at 100% speed.

I wonder whether a nice way to do a ROM is a diskloader game that loads files from ROM.

The nice load situation of ROM is payed later with 32k RAM covered by cartridge and 8k mapper ado.
And DOS game/demo too seems to exist just because of a nicer load situation. But then calling bios seems to have issues.

In a bload game, got to solve some issue, from then on rest of the code is happy straight 64k.
Like poke at 38h some code to have interrupts slotswitch to BIOS.

By Marq

Champion (387)

Marq's picture

14-01-2013, 13:10

It's a good idea to set the screen mode initially with bios so that you can be sure all the registers are correctly initialized. Direct access isn't any trickier than BIOS calls, IMO, when you just hide it a bit behind a couple of functions or macros.