New dev using sjasm for MSX2, requesting aid :)

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

By Maggoo

Paragon (1195)

Maggoo's picture

25-04-2019, 04:26

That 4th byte is mostly used in MSX1 graphic modes. The 4 lower bits are used to define the color since on MSX 1 there is no color table for sprites. The highest bit is used for "Early clock", it shifts the sprite 16 (or is it 32?) pixels to the left to make it "exit" the screen without showing up on the right side of the screen.

By ARTRAG

Enlighted (6253)

ARTRAG's picture

25-04-2019, 07:02

In msx2 modes you can use it as you like, the vdp will not use it

By DarkSchneider

Paladin (870)

DarkSchneider's picture

25-04-2019, 08:45

Another mistake of the SM2 on MSX2. It is a damn to set ALL the bits of the sprite color attribute instead only 1 byte for things like the early clock. I suppose that is a reason why few games have smooth sprite transition in/out the screen from/to left side.

By NYYRIKKI

Enlighted (5394)

NYYRIKKI's picture

25-04-2019, 12:37

shram86 wrote:

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"?

This byte is just left over from TMS99xx compatible display modes and you can safely write over it. In case you need to skip some address without changing it, just use IN A,(#98)... the byte received is not useful, but it will anyway increase the counter by one.

By shram86

Expert (88)

shram86's picture

25-04-2019, 16:43

Ohh, so it's legacy, awesome, thank you guys for your help.

I got vblank wait and attribute flush working last night but reading from status registers seems really ineffecient (write status number, read byte, shadow register, write back 0, unshadow). Is there mirrors or a more efficient way to catch the v and hblank flags?

At least input is nice and easy.

By ARTRAG

Enlighted (6253)

ARTRAG's picture

25-04-2019, 23:57

I use the code at _scroll: in the ISR here to distinguish between vblank and line interrupt

By shram86

Expert (88)

shram86's picture

26-04-2019, 01:06

ARTRAG wrote:

I use the code at _scroll: in the ISR here to distinguish between vblank and line interrupt

Very elegant, thanks
Also, Uridium 2 on MSX, yummy

By NYYRIKKI

Enlighted (5394)

NYYRIKKI's picture

26-04-2019, 08:14

shram86 wrote:

I got vblank wait and attribute flush working last night but reading from status registers seems really ineffecient (write status number, read byte, shadow register, write back 0, unshadow). Is there mirrors or a more efficient way to catch the v and hblank flags?

Unfortunately it is what it is... Sooner or later you need to read both status registers, but since I have hard time figuring you would need more than 180 VDP interrupts / second the time loss in total is not that significant.

I guess one could ditch the vblank interrupts and start using hblank only. This way you could get rid of the status register swapping, but MSX BIOS does not like this so you need to make your own interrupt handler from scratch then.

BTW for future reference may I ask what environment you are coding in? Are you making program under BASIC or DOS or are you making a ROM?

By shram86

Expert (88)

shram86's picture

26-04-2019, 14:50

NYYRIKKI wrote:
shram86 wrote:

I got vblank wait and attribute flush working last night but reading from status registers seems really ineffecient (write status number, read byte, shadow register, write back 0, unshadow). Is there mirrors or a more efficient way to catch the v and hblank flags?

Unfortunately it is what it is... Sooner or later you need to read both status registers, but since I have hard time figuring you would need more than 180 VDP interrupts / second the time loss in total is not that significant.

I guess one could ditch the vblank interrupts and start using hblank only. This way you could get rid of the status register swapping, but MSX BIOS does not like this so you need to make your own interrupt handler from scratch then.

BTW for future reference may I ask what environment you are coding in? Are you making program under BASIC or DOS or are you making a ROM?

That makes sense.

For now I am not using interrupts and simply watching the flag. I'm using the same method I used on GB, which is to flip a toggle when my per-frame code has been run once, then it polls the status register / waits for vblank before doing all the VDP reads and writes then loops.

I'm coding in VB Code, assembling to a .bin (I couldn't figure out how ROM headers work using sjasm), and using an autoexec.bas on a .dsk image. It's working well so far.

Thanks again for all the replies and help Smile

By ARTRAG

Enlighted (6253)

ARTRAG's picture

26-04-2019, 17:24

In case you want a working example on how to build a megarom you could download this subdirectory
https://github.com/Maneldemo/Uridium-2-for-msx/tree/master/s...

Just edit compila.bat to make your own make script to run SJASM under Linux
In this project I've used a Konami SCC mapper, but changing the definitions of the bank labels, it could be arranged to any 8K mapper easily.

You can find the description of the main mappers here:
http://bifi.msxnet.org/msxnet/tech/megaroms

Be aware that rom header does not indicate the mapper used by the coder.
Emulators try to auto detect the mapper type using heuristics by they cannot always get the right one. In case you get strange results try to force the mapper type in the emulator.
IIRC openmsx allows to chose it in the command line, it should be
openmsx -cart romfile.rom -romtype Konami

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