Assembly experiment: bouncing block | MSX Resource Center (Página 5/7)

Ascended (10707)

11-05-2021, 18:16

thegeps wrote:

ToriHino wrote:

... if you don't really really need the highest performance, you can just do a LDIRVM BIOS call. The overall overhead is really not that big and it even works on those exceptional machines that don't have the VDP at port 98...

that can be easily fixed by:

     ld a,(6)
     ld c,a

in this way c will have the right vdp data port number

Yeah, it is a good practice to do that.

For @Pbk71’s information, all machines have the VDP at port 98H, but there exist “MSX2 upgrade cartridges” which replace the internal VDP with an MSX2 VDP in the cartridge on a different port. The base read port can be found on BIOS address 0006H, and the base write port on BIOS address 0007H. Although they are uncommon, if you can spare the effort it is nice to support them.

Por Pbk71

Expert (101)

13-05-2021, 07:49

Ok, good to know. My intention is to only program for MSX 1, but in this case I guess I have to be "forward compatible"

Por pgimeno

Champion (328)

13-05-2021, 14:10

Grauw wrote:

For @Pbk71’s information, all machines have the VDP at port 98H, but there exist “MSX2 upgrade cartridges” which replace the internal VDP with an MSX2 VDP in the cartridge on a different port. The base read port can be found on BIOS address 0006H, and the base write port on BIOS address 0007H. Although they are uncommon, if you can spare the effort it is nice to support them.

Wait, if it is a cartridge, how does it replace the BIOS?

Por ToriHino

Paladin (826)

13-05-2021, 15:36

You can find a bit more information about this upgrade here. In general this is mostly a theoretical issue but hey, why not stick to the standard :). Thegeps showed already another approach so also direct writing to the out ports is possible when needed. But to be fair, I also don't think it's even a big issue to just use port #98 directly.

Por Pbk71

Expert (101)

13-05-2021, 15:52

Made a little adjustment by adding a simple soundeffect ("boing..."). Took me some time to figure out how to do this, but now it works on the timer hook. I'm writing directle to the PSG registers using OUT. Also changed the sprite to a familiar ghost

See result here: https://msxpen.com/codes/-M__zL0NAKKgJ0l-gAeK

Por santiontanon

Paragon (1770)

13-05-2021, 16:12

I hope this is not too much of an off-topic, and I think it's been discussed before, but I see @Pbk71 put all the code in the interrupt. Do you guys tend to use this method (I heard Konami used to do it like this iirc)? I always put all the code on a regular loop and only the music playing code in the interrupt.

Por ToriHino

Paladin (826)

13-05-2021, 16:58

I usually place the music and refresh cycle of the graphics (so mostly updates from RAM towards VRAM) in the interrupt. All the other logic I try to keep on the main loop.

Por Pbk71

Expert (101)

13-05-2021, 16:52

I think that's a good question. I'm quite new to assembly but I guess that you can not "store" too much code in a hook. That may cause problems if your code is not finished and the next interrupt starts?
I wonder how you handle joystick input and other things that should not go to fast. Do you use a timer that is updatet by the hook to "manage the speed"?

Por ToriHino

Paladin (826)

13-05-2021, 17:03

Yes, things that need a certain pace I usually time by updating a counter in the interrupt hook. And indeed you have to make sure you're interrupt code is finished before the next one starts. I normally tend to program for 'worst case' i.e. update always the same amount of data (sprite positions, characters patterns, colors...) to VRAM even if not changed, to have a steady refresh rate. As long as that still fits within the interrupt you know for sure there is no frame skipping.
Actual update of these values is than done outside the interrupt on the main loop

Por ARTRAG

Enlighted (6933)

13-05-2021, 22:27

Very nice! And the code has improved a lot.
Actually I have an additional suggestion. If you want that the sprites enter in the screen smoothly from the left side of the screen you should use the EC bit in the color byte in the SAT

The EC decrements by 32 the X of the sprite. This allows the sprite to enter progressively in the visible area from the left border of the screen.

In this case you need more than 8 bits (at least 9 bits, better if 16) to store the X coordinate.

The logic is:
for X = -32 to 255

If X<0 then
set EC, and add 32 to X while writing the SAT
else
reset EC and use the lower 8 bits of X while writing the SAT
end
[...]
next

Have a look at plot_enemies.asm here
https://github.com/artrag/Uridium-msx1/blob/master/plot_enem...