Correct usage of VDP ports following the standard

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

By PingPong

Prophet (3438)

PingPong's picture

01-06-2017, 21:57

Manuel wrote:

How much slower is out(c) again compared to out 0x98?

2 cycles but the problem is that you have to do first ld a,(...) ld c,a or ld hl, xxxx ld c,(hl) for each vdp access. if accesses are scattered there is a huge penalty

By ARTRAG

Enlighted (6240)

ARTRAG's picture

01-06-2017, 22:06

sd_snatcher wrote:
ARTRAG wrote:

Ports 98h and 99h are hardcoded in msx2+ and TR definitions and adopted by all existing stand alone machines.

Can you cite the official references for this affirmation? Otherwise it can be said that it's just misinformation being repeated from mouth to mouth.

Without that, it would be more honest to put a disclaimer "This software doesn't follow the MSX standard strictly and may not run on all MSX compliant models and extensions."

This way the user will know that their hardware is not faulty.

Ah a proud standard defender here, are you going to put out of your standard the 95% of the existing software? You should emend also the whole web, not only the existing software. Let's say that if you want to support MA-20 you need to look at the 6h and 7h address and stop here this dull religion fight
http://problemkaputt.de/portar.htm#vdpioports

By ARTRAG

Enlighted (6240)

ARTRAG's picture

01-06-2017, 22:34

PingPong wrote:
Manuel wrote:

How much slower is out(c) again compared to out 0x98?

2 cycles but the problem is that you have to do first ld a,(...) ld c,a or ld hl, xxxx ld c,(hl) for each vdp access. if accesses are scattered there is a huge penalty

And you loose one register. You need also to swap in the rom and store the value in ram if you use dos or roms without bios

By zeilemaker54

Master (246)

zeilemaker54's picture

01-06-2017, 22:45

Using selfmodifing code could solve that problem (only works if code is in RAM).
init:
ld a,(7)
ld (vdpwrite+1),a
...

ld a,040H
vdpwrite: out (098H),a
...

By gdx

Prophet (2984)

gdx's picture

02-06-2017, 01:04

Get the base ports from BIOS is standard only for MSX2 (for MSX1 + MSX2 cartridge upgrade). In fact, many games for MSX2 do not respect this rule.

By Wlcracks

Champion (321)

Wlcracks's picture

02-06-2017, 08:44

zellenmaker, Thanks for that but what would be the most efficient for ROM? As in byte usage and speed. I guess there is already something out there? I am not trying to invent the wheel here. The konamis are using a lot of ex,ex'. Call the bios for setting and out(c). But these are 16kb roms with already the bios enabled in page0.

By DarkSchneider

Paladin (866)

DarkSchneider's picture

02-06-2017, 09:15

Hi, I think the best way is to make a copy into RAM. Even can create the all ports table, precomputing all them. Are only 8 bytes.
Takes some more cycles (39 vs 17 for the first access), but what about using?

LD IX, (nn)
LD C, (IX+d) ; d = port number if we had defined the ports table

Very organized and clear. As noted, for the first access, because later if you don't modify the IX it takes only 19 as the 1st instruction is not needed and with no need to make a copy of A if want to preserve its value.
You can also use anyway INC/DEC C to travel through ports.

About the topic of hardcoding or not, this is what the MSX manual says, think that is intended for making software for MSX platform. We usually confuse machine with platform. It is true that most MSX use fix ports to the values of the V9938 manual, but that is merely by circunstances. We can say that because the system was discontinued, and we are based on already immovable existing data.

The only thing we can suppose for and open architecture like MSX is that we have to suppose nothing.

In fact, take a look at the MSX-Video specification (specification, not implementation like particulary is the V9938). It allows bidirectional transfers, it defines one port for write and another for read. The V9938 implementation joint both into one as it has only one bus.
But that does not prevent for any other to create its own implementation MSX-Video compliant, with dual bus, and DMA for parallel read/write from DMA/CPU at the same time.
This would be the same that what we have today with video cards manufacturers, each one with its own implementation. That is the power of an open architecture, but the software must be care of it.

So, fine the real case was that almost everyone mounted the same MSX-Engines and that is in that way for most MSX machines, but as I say, "machines", not MSX platform.

Then, at the end that is a personal preference, I only expose the way the platform designer says it should be used. Because all this is in a "looking at the past" environment, that greatly determine it. But as said at begin, this is for those who like to "follow the standard" AKA "follow the manual". Simply that.

By Wlcracks

Champion (321)

Wlcracks's picture

02-06-2017, 09:32

Darkschneider that was my first thought too. I am developing something stupid for msx1 16kvram. I love msx1 machines, with the coming of these Flashroms, crosscompilers, compressors, sprite editors, Tiles and Multipaint you can do a lot on MSX1. This workflow with a pc as an tool was almost impossible in 1984 something when I started with MSX.

The c64 scene has a lot of programmers who get every cycle and hardware bit out of this machine. I am almost "jealous" about this like a young boy in the 80s looking at games for the c64 not available on MSX. :-P I think a lot of people in the MSX scene are focussing on hardware like 10 people have in the world. I think the basic MSX machines are fun and have in 2017 a lot of potential. Building programs for ROMS have great portably and its fun to burn them in real hardware and insert them into the old machines. When not using the keyboard in your software and build a ROM this works great in Retropie boxes or other standalone emulators.

I need this 16kb RAM really bad. My VDP routines are build for "speed" in ROM so a lot of (grauw) vdp techniques like unroll and not for low ROM memory count. Moving these to RAM could be a pain in the butt, thats why I am so focussed on how many machines used today and this 99 98 direct approach doesn't work.
Just my thoughts.

EDIT: I just saw you new answer!! Thanks

By ARTRAG

Enlighted (6240)

ARTRAG's picture

02-06-2017, 09:55

I agree that at the very beginning of the msx life the ports were intended to be in a variable position and there was more room for better video HW, but during the commercial life of the standard, all the hardware producers have selected ports 98h and 99h and use one bidirectional bus. It's an historical fact that none can change. For me, coding on msx is archeology on machines that have been already produced more than 30 years ago, trying to exploit any HW feature and undocumented glitch of the chips squeezing the most of any single cycle.
About the module MA-20, it is just an expansion module for msx1 machines, you can unplug it and use your machine as it is.
If you want to run msx2 games today, pretending to use an msx1 with an expansion module instead of a full msx2 machine, is just a geek oddness. Find on ebay a cheap msx 2 if you have the urge.

Ah, there is the issue of the new modern machines that to be eventually produced nowadays by fans and homebrewers. Well, IMHO it has to be their care to preserve compatibility with 30 years of existing software. I would not produce a new stand alone machine with ports in e.g. 28h and 29h knowing that a large part of the games wouldn't work, but you can put your ports wherever you like, just do not pretend to run any game.

By Wlcracks

Champion (321)

Wlcracks's picture

02-06-2017, 10:56

Maybe this ascii guy can give a lecture about this :-)

Ok another question. As using the pT3 musicplayer, this is outputting to

psgport0xa0 .equ 0xa0 ;0xa0 0x10
psgport0xa1 .equ 0xa1 ;0xa1 0x11
psgport0xa2 .equ 0xa2 ;0xa2 0x12

directly. Is this "forbidden" too by the msx standards?

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