New dev using sjasm for MSX2, requesting aid :)

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

By shram86

Rookie (27)

shram86's picture

24-04-2019, 16:51

ARTRAG wrote:

In sjasm 1: 2: 3: etc. are temporary labels. They have to appear on the 1st column of the text.
They can be referred to as 1b if you mean 1: backwards or 1f if you are referring to 1: forward
It is sjasm specific, if you feel uncomfortable with them, replace the couple 1: and 1b with labels you like

Cool thanks, I didn't see that in the docs, I will probably use them. I like sjasm a lot but there are some things like this that seem to conflict with other standards BA-team

By ARTRAG

Enlighted (6150)

ARTRAG's picture

24-04-2019, 17:17

They can be very handy for small cycles repeated often in the code
But they can also cause problems because it is possible to remove one of them and get your code perfectly compiled but with a wrong jump

By shram86

Rookie (27)

shram86's picture

24-04-2019, 18:15

One more question regarding di and ei:
Is there any reason to perform them so many times?
I understand if you have an interrupt routine going while performing VDP access you want them off for as little time as possible, but is there any reason to waste cycles on them when performing initial load/setup?
I read somewhere that the cpu has an interrupt routine that can be negated, but this seems like the whole point (so I didn't take much stock).
In my original code I disabled them once and only re enabled when finished all writes to $99.

By ARTRAG

Enlighted (6150)

ARTRAG's picture

24-04-2019, 19:38

It is a matter of what you do in your custom ISR code and of you do between ei/di. The longer you spend with interrupts disabled, the longer your ISR routine will be delayed.
One good reason to minimize the delay is that when the VDP asks for an interrupt, it could be for a custom line interrupt that you have defined to do e.g. a raster trick or a screen split.
Moreover, the standard interrupt is cast after that the last useful line of the screen has been traced (Vblank). On plain msx2 it should be less relevant, but during vblank the CPU has always access to the VRAM at max speed. Thus using part of the blank time elsewhere could be not efficient.

By NYYRIKKI

Enlighted (5250)

NYYRIKKI's picture

24-04-2019, 21:15

shram86 wrote:

Is this just writing a 0-byte to it? e.g. ld a,0 : out ($99),a : ld a,11+128 : out ($99),a ?

Yes, these are the high bits of sprite attributes that did not fit to register 5

Quote:
NYYRIKKI wrote:

Tip:

In the beginning, do something like:

	LD A,4
	CALL #5F

This will clear your screen, select correct screen mode and give you memory layout of:

Awesome, I will do this instead of re-setting all the 9938 addresses Smile

Yes, MSX BIOS-routines can be helpful. On MSX & MSX2 this call works like SCREEN-command in BASIC. (While A=mode)
More information here

By shram86

Rookie (27)

shram86's picture

24-04-2019, 22:29

NYYRIKKI wrote:

Yes, MSX BIOS-routines can be helpful. On MSX & MSX2 this call works like SCREEN-command in BASIC. (While A=mode)
More information here

I've been looking for a resource that has the BIOS routines defined but I couldn't find one. I have been using a combination of resources (9938 technical spec, ChibiAkumas, grauwl.nl) but only got as far as you see. The link you listed has slightly more information than some, thanks for that.

By ARTRAG

Enlighted (6150)

ARTRAG's picture

24-04-2019, 23:35

Here you can see much of the bios rom exposed

By NYYRIKKI

Enlighted (5250)

NYYRIKKI's picture

25-04-2019, 00:27

At some point you may want to take a look at the Programming Wiki as well... It should be able to answer pretty much any possible question at least with a link, but sometimes it may be a bit hard to navigate to a correct page there.

By shram86

Rookie (27)

shram86's picture

25-04-2019, 01:11

ARTRAG wrote:

It is a matter of what you do in your custom ISR code and of you do between ei/di. The longer you spend with interrupts disabled, the longer your ISR routine will be delayed.
One good reason to minimize the delay is that when the VDP asks for an interrupt, it could be for a custom line interrupt that you have defined to do e.g. a raster trick or a screen split.
Moreover, the standard interrupt is cast after that the last useful line of the screen has been traced (Vblank). On plain msx2 it should be less relevant, but during vblank the CPU has always access to the VRAM at max speed. Thus using part of the blank time elsewhere could be not efficient.

Thanks for taking the time to explain, that's what I thought. Sounds very similar to gameboy and c64.

ARTRAG wrote:

Here you can see much of the bios rom exposed

Ugh, thanks, that is what I was looking for. Grauw is a great resource but it is terribly organized.

NYYRIKKI wrote:

At some point you may want to take a look at the Programming Wiki as well... It should be able to answer pretty much any possible question at least with a link, but sometimes it may be a bit hard to navigate to a correct page there.

Yeah... that's where I started, so you can imagine why I didn't get very far. I couldn't find any examples at all, and the only page that really helped me understand anything was the OR color page.

At any rate, I got a sprite displaying! It must have been the way I was initializing the graphics mode. Thank you both very much for your help :murdock:

By shram86

Rookie (27)

shram86's picture

25-04-2019, 02:16

Another question, this time regarding sprite attribute tables.

The 9938 reference is unequivocally terrible in this regard.

Quote:

The sprite attribute table is an area in the VRAM that defines display coordinates for all the possible 32 sprites, pattern numbers used for display and some other flags.

In the table given, it simply says the fourth byte is "Reserved", with no other information in the entire document. I've searched around and can't find any information on this mysterious 4th byte.

If it's "reserved", then it shouldn't be modified by the user. If that's the case, rapid bulk writing to OAM on vblank should be heavily discouraged, unless you write a special routine that writes 3 bytes and then resets the VDP registers to skip one byte - something that would probably be very slow.

Does anyone know what this fourth byte is, and why it doesn't seem to matter if we write to it, and yet is "reserved" for "some other flags"?

Page 2/7
1 | | 3 | 4 | 5 | 6 | 7
My MSX profile