Correct usage of VDP ports following the standard

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

By Grauw

Ascended (8707)

Grauw's picture

04-06-2017, 21:02

ARTRAG wrote:

Axel, it is a matter of your goals, if supporting ma-20 users is more important of having smooth scroll and screen split, go ahead. I'm using a paradox, but the idea is do what you like provided you know what you do and what can get and what you cannot.

santiontanon wrote:

I don't think there is a definitive answer. As someone said above, the important thing is to know what you are doing and be aware of the tradeoffs. If you really need to speed, and are ok with not targeting 100% of the machines, then direct port access is the right thing to do, otherwise, using BIOS should be preferable. But again, I think that that should be a choice of the developer, and what is important is that when we make that decision, we do so knowing exactly what using the ports directly or using the BIOS might imply for compatibility and for speed.

I think these two remarks made a lot of sense. The most important thing is to be aware of all the facts, so that you can make an informed decision.

If your game has a lot of bulk transfer to the VDP, like bitmap data, and sprites data prepped in RAM like hit9918 likes to advocate, then using the BIOS for everything will probably be the better choice.

If your game relies a lot on screensplits, or is cutting it close to the capabilities of the CPU / VDP, then direct I/O may be a more obvious choice.

In VGMPlay for example, some songs have a lot of data and I don’t want playback to slow down, the SFG is memory-based I/O in page 0 so I can not use the BIOS to page it in, and the song data is not formatted to set registers in bulk so I have to slot switch for every command, so I do not use the BIOS for communicating with the sound chips and slot selection, as I don’t want the music to sound irregular due to not being able to keep up with the data stream.

Although I have to admit, I’m used to this direct access way of developing, so to use the BIOS is not the first thing on my mind even if it would make sense for a particular project. But I’m definitely considering getting at least the I/O port base address from the BIOS, as well as updating mirror values (I often do this already), but I’ll deal with that when one of my project nears completion, for now I’m keeping it simple Smile.

Anyway, everyone has their preferences; like some really prefer to use the BIOS for everything, I for example am rather obsessed with developing in object-oriented style with a lot of IX / IY register usage, and only in the end optimising the routines which really need it, some people also find that quite a strange choice… Big smile

By sd_snatcher

Prophet (3202)

sd_snatcher's picture

04-06-2017, 21:48

ARTRAG wrote:

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.

I wish everyone lived in a developed country like you do. In Brazil, there are many users coming back recently and joining groups on social media websites.

All they have is their Hotbits and Experts that were stored in some wardrobe. Buying an MSX2 from eBay is something that not exactly everyone can afford, given the huge shipping costs and excruciating taxes for both the credit-card transaction (6.5%) and customs (60% or more).

Not to mention the emotional attachment to the machine itself.

But they can afford to buy extensions built in Brazil. Usually they buy SD-mappers from PalMal or Luis Luca, and IDEs or FM-stereo cartridges from Tecnobytes.

The news that an MA-20 clone would be built arrived like a storm. For many, it's a way to finally have access to MSX2 games on a real machine. The estimated cost of this expansion is a fraction of the cost of an imported MSX2. And requires it zero kill to be installed.


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.

It seems that, while being a gifted programmer, you have no experience at all in hardware development.

There are some points to clarify:

- Don't fool yourself: doing direct I/O might seem "efficient" on the surface. But what it really does is to push the inefficiency under the carpet, where the hardware lies.
- Anyone who would build a new hardware today would have to resort to an expensive FPGA or complimentary microcontrollers to do the bidding that "direct I/O" didn't. But FPGAs that are 5V compatible are getting very rare. Soon we don't have that luxury anymore, so here comes the bus level translators (expensive). The new FPGAs also come only in BGA encapsulation. It's impossible to solder BGA chips in small scale at a decent cost.

- Is everyone's keyboards working fine? No machines with lost keyboards? Let me give you some background info on this topic:
1) The OCM VHDL code wastes a lot of space to do the keyboard translation. It could have been *way* simpler and more powerful if it could be implemented just as an USART chip, and the BIOS keyboard driver changed to talk the PS/2 protocol directly. Doing the translation in hardware on the OCM has made it inflexible and with a lot of layout and key-combination issues.
2) Real MSX machines that lost their keyboards: Similarly, it could have been easy to fix the same way: A simple USART connected to the MSX keyboard port. The BIOS driver would be replaced with one to talk the PS/2 protocol directly via PPI. But because of direct I/O, the only solution is to attach a microcontroller in the middle to do the translation. This microcontroller is many times more powerful than the MSX itself.

When someone asks, direct I/O advocates can reply: Oh, this is the MSX machine. It can be coded in a very efficient way: These are my machine specs:

- A 3.58MHz Z80A for the main CPU
- A 16MHz ATmega-328 for the keyboard
- A 16MHz ATmega-328 for the mouse
- A 72MHz ARM CortexM3 CPU inside a Chinese floppy emulator, because it's much more efficient to do direct FDC I/O, of course
- A huge FPGA to glue everything together, and do in hardware the abstraction that the BIOS would have easily done in software

But the solution is simple: we all just have to pray that all MSX hardware lasts forever: the computers, mice, keyboards, etc etc etc. Or we can always resort to emulation. Its also very efficient to convert a GHz CPU into a 3.58MHz one. :)

By Grauw

Ascended (8707)

Grauw's picture

04-06-2017, 21:43

sd_snatcher, all well and good, but that plea is about 30 years too late Big smile. Today it is not possible to produce a compatible machine without sticking to the I/O ports that have been in use for decades.

That said you make a good case for MA-20 support! Please keep us up to date on those developments, I’m sure if there is actual hardware out there, it will convince at least some people to take it into account.

By sd_snatcher

Prophet (3202)

sd_snatcher's picture

04-06-2017, 21:43

Louthrax wrote:

I see passing FRS' Acid Tests as a challenge. Trying to achieve that is interesting too. That can be seen as a waste of time (well, like most of the coding activities for 80's machines Smile), but personally I enjoy it !

Also, trying to stick to official guidelines is a good exercise for "professional coding" (not saying here that people hard-coding things on MSX are amateurs !).

Very well said, Louthrax. Because that's how I face it myself. While some like the challenge to squeeze every single cycle from the CPU, I like the challenge of being compatible with every possible MSX design that can exist. Smile

I don't think anyone *must* comply. I just try to explain the advantages and disadvantages of each approach. Everyone here is an adult and know how to make their choices. Smile


Enlighted (6330)

ARTRAG's picture

04-06-2017, 23:56

Sd, the commercial life of msx standard has ended about 30 years ago. 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. 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.

By syn

Paragon (1937)

syn's picture

04-06-2017, 23:13

So the MA-20 works with just a small portion of the existing software? How many of those devices are in circulation and actively used right now?

By hit9918

Prophet (2883)

hit9918's picture

04-06-2017, 23:21

bios graphics, it's not just a speed question, but that whole idea that it leads to a better architecture is mislead.
the TurboR is fast without asking to degrade the entire MSX1 MSX2 fleet to bios graphics. That's the better architecture roadmap.

By DarkSchneider

Paladin (896)

DarkSchneider's picture

05-06-2017, 09:13

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

@ARTRAG I think the 2 first cases are more about how you use the VDP instead hardcoding or using BIOS. I mean, the bitmap copies work the same in both cases, a minimal overhead compared with the copy itself is not the problem. And that is precisely what I mean about focusing in a higher level instead worring too much about microcode. We faced a similar problem with the sprites in mode 2 (multi-color) and the solution was not moving some asm intructions or hardcoding the numbers to get a few cycles, it was looking at the architecture itself and solving the real bottleneck. So IMHO the time was best used.

For the 3rd one, don't know as not tried. Anyway I love it, those computing implementations draw my attention a lot.

Not mentioned much but for RAM based programs the solution of patching the code on load is great.

Please test this (!AhQqCoPY5hXqjodkwn3VxFag2eZccA
Move with cursors and change speed with Q/A keys.
It was the 1st result after reading the V9938 manual. Yes, it's the Galious rock (inserted by hand). To avoid confusion, it is not a cycling scroll reg [0-8], it is a real map, if you move you can reach the borders, but as it was for internal test, the simplest way was used to create the map (repeating always the same).
Everything is done using the BIOS, and is not double buffered, so everything is updated on the ISR, and there is no tearing at all (test it on the real hardware).
We also have split screen even with mode change (SC5/SC4) without problems, using the hardware features (V9938 allows it). So for using the hardware features itself the BIOS is not really the problem. The problems come when adding the logic, map decompression, sprite handling, etc. Are those which need solutions.

By PingPong

Prophet (3499)

PingPong's picture

05-06-2017, 21:44

DarkSchneider wrote:

Everything is done using the BIOS, and is not double buffered, so everything is updated on the ISR, and there is no tearing at all (test it on the real hardware).
We also have split screen even with mode change (SC5/SC4) without problems, using the hardware features (V9938 allows it). So for using the hardware features itself the BIOS is not really the problem. The problems come when adding the logic, map decompression, sprite handling, etc. Are those which need solutions.

Everything? you basically manipulate only 700 bytes of vram on each interrupt. Not nearly what ARTRAG does.
where is the split screen ?
Of course writing the name table is not so a big achievement. A matter of ordinary job.
ARTRAG does scrolling in screen5/8! have you noticed? It's a matter of other magnitude. I NEVER EVER SEEN PARALLAX SCROLLING in SCR 5 & Smooth Scrolling on MSX2!


Enlighted (6330)

ARTRAG's picture

05-06-2017, 21:59

Dark, you are very far from the true. All the 3 examples are the joint result of high level analysis on the algorithms and of microcode optimizations. Expecialy the Uridium 2 and the Total parody engine relies on exact timing to build on fly the borders on the active page using the z80 while the vdp is rendering a certain part of the screen and the copy engine is moving a slice of the screen in order that anything is completed before the screen split occurs.
Add a cycle per pixel and the z80 will miss the line, add a pixel in the copies and the vdp engine will not end its task in time (and you cannot execute vdp commands and change R#18 at the same time without corrupting the copy).
As matter of facts or you patch your code in ram using direct i/o ports or you will not get what you see.
And as I told, I do not see any reason to waste my spare coding time with those issues provided that what I do is already complex and it does not exist a single know machine that uses different ports.
This to not tell about audio access and to the isr code. Needless to say, I replace the isr code with mine directly at 38h to save only the registers I use and guarantee minimal lag.

In your scrolling, you are far from the machine limits and you can allow all the overhead you like.
Mine are different cases, Uridium 2 is moving a 64kB screen at 1 pixel per frame.

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