ubox MSX lib

Страница 2/4
1 | | 3 | 4

By reidrac

Expert (98)

Аватар пользователя reidrac

04-01-2021, 08:36

Thanks! I released 1.0.3 with those changes; may or may not fix all issues building on windows, but I think they are good changes and definitely don't affect Linux builds.

Also I suspect now you won't need GNU utilities for Win32 (the makefiles only use mkdir that is part of the shell; not sure how it will work in Windows though).

By pizzapower

Resident (42)

Аватар пользователя pizzapower

06-01-2021, 16:31

Hi reidrac.

I was the one that told you about the missing Disark dependency on Twitter. I was wondering if ubox_set_sprite_pat16 should preferably read the sprite table address from 0F3E5h instead of having it hardcoded. Anyway, nice work! I think you've hit a nice balance of power and simplicity.

By reidrac

Expert (98)

Аватар пользователя reidrac

06-01-2021, 17:19

Thanks pizzapower Big smile

Yes, I'll look into it. As I was focusing on MSX1 and, to be honest, it was my first contact with the MSX; I'm sure I can do things better.

I'll look into it. What I have in my initial MSX2 support is a configuration file for those addresses, but checking the BIOS is probably better.

By JMeric

Resident (51)

Аватар пользователя JMeric

06-01-2021, 17:37

Hi Reidrac,

Thanks for sharing your work Smile

By ren

Paragon (1909)

Аватар пользователя ren

06-01-2021, 17:44

Hi Juan, not an MSX developer myself, but I think it's pretty cool you're sharing this Smile

I wondered about something (and probably related to your lib as well?): your games support both PAL & NTSC. Can one be considered preferable over the other (if one has the option to choose)? Cheers! Smile

By reidrac

Expert (98)

Аватар пользователя reidrac

06-01-2021, 19:01

@ren: I usually work on NTSC. Basically because you have less time; if all "fits" with no slowdown, then PAL will be OK.

In Uchusen Gamma I wrote the music on NTSC, and then I made PAL sound the same. That's another reason to choose NTSC first.

Other than when you're tracking time, NTSC and PAL is pretty much the same.

By reidrac

Expert (98)

Аватар пользователя reidrac

06-01-2021, 19:03

@pizzapower I looked into that and is not worth adding that indirection as in screen 2 that value is harcoded in all models and generations; so I think in this case is justified to use 0x3800 directly and save some cycles.

By pizzapower

Resident (42)

Аватар пользователя pizzapower

06-01-2021, 20:41

Just so you now, you can change it by writing on the VDP register R#6 like this:

    __asm
    ld b, #6
    ld c, #6
    call #0x47
    __endasm;

That would put the sprite pattern table at the address 0x3000 for instance.

By reidrac

Expert (98)

Аватар пользователя reidrac

06-01-2021, 21:23

I'm happy to say that's not supported for now.

If you want to change the base address of anything using regs 2 to 6, and you have a good reason to do that, you may not need to use these libraries anyway Wink

As you said, I tried to find the right balance between simplicity and features; and these libraries won't be for everybody. And that's OK!

(although being open source, you can adapt it to fit your needs, so feel free to do that if you use a different VDP configuration)

By reidrac

Expert (98)

Аватар пользователя reidrac

10-01-2021, 15:31

I published a video explaining the project: https://youtu.be/PF4xI9xg93U

English, with strong accent!

Страница 2/4
1 | | 3 | 4