Correct usage of VDP ports following the standard | MSX Resource Center (Page 6/18)

Ascended (10711)

04-06-2017, 14:11

DarkSchneider wrote:

V FINE:
set bios at page 0
loop {
direct calls
}
set RAM at page 0

Have you tried it? To my knowledge you can not change page 0 permanently with the BIOS, only interslot calls work. ARTRAG ran into that when coding Uridium as a 48K ROM iirc. Louthrax’s solution is a decent workaround.

By DarkSchneider

Paladin (989)

04-06-2017, 14:13

Grauw wrote:

DarkSchneider wrote:

V FINE:
set bios at page 0
loop {
direct calls
}
set RAM at page 0

Have you tried it? To my knowledge you can not change page 0 permanently with the BIOS, only interslot calls work. ARTRAG ran into that when coding Uridium as a 48K ROM iirc. Louthrax’s solution is a decent workaround.

Hi, yes it works. Use this function. Tested even on systems with RAM on the same main slot than the BIOS.
https://www.msx.org/forum/msx-talk/development/safe-set-bios-and-restore-ram-on-page-0-from-msx-dos?page=3
And yes, using the ISR for BIOS access is also my prefered one.

By Grauw

Ascended (10711)

04-06-2017, 14:20

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

DarkSchneider wrote:

@Graw the operation was precisely LDIRVM, using the BIOS one and using the steps (but the setting expanded VRAM, I skip that one, supposing the VRAM will be always in non-expansion VRAM, bad for me ) indicated in the V9938 manual.

Expansion VRAM is quite useless anyway, it can not be used for display, only data storage. No machine has it built in, only few people modded their machines to have it. I think FastCopy is the only software which uses it.

By DarkSchneider

Paladin (989)

04-06-2017, 14:20

Grauw wrote:

Cool.

DarkSchneider wrote:

@Graw the operation was precisely LDIRVM, using the BIOS one and using the steps (but the setting expanded VRAM, I skip that one, supposing the VRAM will be always in non-expansion VRAM, bad for me ) indicated in the V9938 manual.

Expansion VRAM is quite useless anyway, it can not be used for display, only data storage. No machine has it built in, only few people modded their machines to have it. I think FastCopy is the only software which uses it.

Yes, that was my dissapoint when upgraded the MSX2+ to 256KB and wanted to upgrade VRAM to 192KB (with the idea of using SC8). After reading that, I didn't upgraded the VRAM.

By Grauw

Ascended (10711)

04-06-2017, 14:59

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

By Grauw

Ascended (10711)

04-06-2017, 14:42

For example one could make the mistake to always write to 0FFFFH, even when the slot is not expanded. This can destroy the last byte in nonprimary mapper pages, but you will only encounter that issue in quite specific slot configurations and when supporting multiple mappers. I’ve ran into an extremely hard-to-find crash bug with this myself in VGMPlay (where I’m kind of forced to switch slots manually).

By PingPong

Prophet (4096)

04-06-2017, 15:06

Quote:

PingPong wrote:

there is also another thing that stop the use of the BIOS when doing time critical operations: the fact that the bios implements functions that are 'trusted' to do a task (I/O, set graphic mode, set a point, draw a line, set psg etc) does not mean that the BIOS IS THE SAME on every machine, implementation could vary.
plus the interrupt handler of the BIOS is 'sensitive' to hw configuration (floppy drive or hw that do interrupts).
the BIOS is fundamentally not only slow, but also timing-unreliable.

say we need to write a charater on screen at a specific time: the BIOS guarantees that the charater will be printed but say nothing about the time it spend to achieve the result. If you talk to bare metal directly you can have a control even on this aspect, (or more precisely you can have better control on timing).

Again, it is NOT slow. Sometimes I think BIOS is confused with BASIC. At the end they are machine code small functions with an extra JP, there is no much difference.

You confused slow with speed unreliable .
About slowness do your test better, try to compare the BIOS routine used to set VDP write vram address with grauw's routine to do the same on map. Both are machine code but they take different time. And more important, with map, you can rely on a time taken to execute. with bios instead you cannot be sure because depends on hw manufacturer.

Quote:

And about the HW configuration dependant, you also have it for direct code. Unless you only target ROMs, you can't override the 38H routine, or the system will crash or freeze. And we can't limit ourselves to only making ROMs for 64KB RAM machines (to override the 38h in RAM at page 0).
Think also that if trying to fit so exactly in a hw, what about if it has a 6MHz CPU? or any other change? Is that predicted?

yes, but i can handle configurations in a very custom and more efficient way.
for 6mhz CPU i think it is a flaw to handle different speed in BIOS, they should be handled by hw directly.

Quote:

Why you need to write the character at exact time? Maybe because writing on-the-fly to VRAM SAT and expect to be at time? Well, that could be fine on videogame console, but for computer a better solution is to work on double buffer and swap when characters are ready. There is also a better solution, but I think is off-topic.

double buffering also have tradeoffs in terms of complexity and memory usage.

Quote:

Most of the worries here about it I start to think that is because a wrong idea of BIOS. And moreover, the topic here is to put a RAM read and using the IN/OUT (C) operation, that is even much lighter. Surprised about it seems the idea of if you write a 99h instead it will run at double speed or something.

i've already explained why this out(c) approach is slower. and some one point me that we also loose a valuable register 'c' adding the need to save and restore it and thus more slowness.
And again, i think a good coder will ALREADY optimize the code he/she wrote and only want to not loose the gain achieved with effort with a call to a slow BIOS subroutine expecially when there are also interslot calls involved.

By PingPong

Prophet (4096)

04-06-2017, 15:19

Quote:

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

Fully Agree. to solve a problem you kick in a bigger ONE 8-|

By ARTRAG

Enlighted (6933)

04-06-2017, 17:40

DarkSchneider I really eager to see how you would code this
https://www.youtube.com/watch?v=Za9tPEgOAgk
or this
https://www.youtube.com/watch?v=NK68rKW7Wmk
or even this
https://www.youtube.com/watch?v=8ffvdvpePY8
using bios and all the cumbersome related stuff.

Paging bios for accessing audio and keyboard and indirect access for accessing video cost about the 20% of the resources.
This waste sometimes for normal applications can be tolerated, some other times it cannot.
Sometimes it simply makes impossible to reach certain achievements (e.g. all cycle accurate code).

You may think that I/O ports will change their position in next generation of HW, I am quite sure of the contrary.
If new machines will somehow be developed, they will have the very same identical I/O ports, as their developers will guarantee compatibility with the existing software base.
Do something different and will have to accept to not run the majority of the existing products.

So, feel free to waste coding time and extra resources using bios and all the rest, but be sure that nothing will happen if you hardcode ports 98h and 99H or you access the Ay8910 at A0h,A1h and A2h. All existing machines use them and any eventual new machine will use them.

About MA-20 and its clones, you may be interested to cover its user base or not, your choice (I would know how many collectors have it and how many of them do not have a proper msx2 and still play physical games).

By Louthrax

Prophet (2436)

04-06-2017, 20:09

ARTRAG wrote:

DarkSchneider I really eager to see how you would code this
https://www.youtube.com/watch?v=Za9tPEgOAgk
or this
https://www.youtube.com/watch?v=NK68rKW7Wmk
or even this
https://www.youtube.com/watch?v=8ffvdvpePY8
using bios and all the cumbersome related stuff.

True, but let's not forget that most Konami games have been coded using BIOS :)

Artrag and DarkSchneider, you both are right on what you are saying. Choosing the BIOS vs. hard-coded options is a matter of interest or taste in most of the cases.

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 :)), 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 !).