ubox MSX lib

Page 3/4
1 | 2 | | 4

By ~mk~

Champion (275)

~mk~'s picture

11-01-2021, 16:30

Hi reidrac,
Not only you share your work but also explain how it works... awesome! thank you Smile

Yesterday I got a bit further compiling on Windows.
It still has a few problems, some I understand how to fix, some others I still need to figure out.
Long story short, I am now getting a game.rom which boots, initial screen showing fine, accepting input, however when I press a key to start a game, MSX resets.

I took a few notes hoping they can be useful to improve the compile scripts.
First problem I had was compiling the new "apultra" tool. I was missing "divsufsort" libraries. It took a while but I managed to compile it using cmake and gcc. However, I had to clone the apultra repo, because apultra included in your repo was missing the "apultra/src/libdivsufsort/lib" folder.

Other problems I faced were "easy" to solve.
First 3 of the next issues I forgot to mention them in my first post, but they are still relevant.

1) when a directory is being created with "mkdir -p" I had to customize it to use full path to mkdir.exe within UnxUtils folder, because no matter how priority I have within the PATH environment variable, it fails -I think- because mkdir is an internal command of windows "cmd" and it does not accept the -p parameter

2) when a binary file was being copied, I had to add .exe extension:

#cp $(APP) ../../bin
cp $(APP).exe ../../bin

3) to compile rasm, I had to use -lrtm instead of -lrt
from ubox-msx-lib-1.1.1\tools\rasm\Makefile:

#	gcc -s -O2 $< -o $@ -lm -lrt -march=native
	gcc -s -O2 $< -o $@ -lm -lrtm -march=native

4) every time $(command) is used in the Makefiles, I had to rewrite that, for example:
from ubox-msx-lib-1.1.1\Makefile:

#export PATH := $(shell realpath ./bin):$(PATH)
export PATH := $(./bin):$(PATH)

from ubox-msx-lib-1.1.1\game\src\Makefile:

#OBJS = $(patsubst %.c,$(OUTPUT)/%.rel,$(wildcard *.c)) $(OUTPUT)/akm.rel
OBJS = $(OUTPUT)/data.rel $(OUTPUT)/game.rel $(OUTPUT)/helpers.rel $(OUTPUT)/main.rel $(OUTPUT)/akm.rel
#UBOX_LIBS = $(wildcard ../../lib/*.lib)
UBOX_LIBS = ../../lib/ap.lib ../../lib/mplayer.lib ../../lib/spman.lib ../../lib/ubox.lib

5) tools\mkdeps.py still not producing a valid Makefile.deps

I think the issue of game.rom not fully working could be related to issue #4 I mentioned. There could be a few more places which I forgot to fix. I will let you know if I get any further, either sticking to Windows or switching to Linux and probably live a happier life, right? Running Naked in a Field of Flowers

By reidrac

Expert (96)

reidrac's picture

11-01-2021, 17:35

~mk~ wrote:

Hi reidrac,
Not only you share your work but also explain how it works... awesome! thank you Smile

You're welcome!

~mk~ wrote:

First problem I had was compiling the new "apultra" tool. I was missing "divsufsort" libraries. It took a while but I managed to compile it using cmake and gcc. However, I had to clone the apultra repo, because apultra included in your repo was missing the "apultra/src/libdivsufsort/lib" folder.

Oh, that was my fault! I added the missing files, the gitignore got in the way Sad

I fixed it and compiled from a fresh git clone; the code in master is fine now.

~mk~ wrote:

1) when a directory is being created with "mkdir -p" I had to customize it to use full path to mkdir.exe within UnxUtils folder, because no matter how priority I have within the PATH environment variable, it fails -I think- because mkdir is an internal command of windows "cmd" and it does not accept the -p parameter

It is indeed a command that is part of the shell. I think it could help if you run the build process from bash (if you have it).

I'll see if I can make those directories in a more portable way.

~mk~ wrote:

2) when a binary file was being copied, I had to add .exe extension:

#cp $(APP) ../../bin
cp $(APP).exe ../../bin

Oh, dear. OK; I'll see how I can make this portable as well.

~mk~ wrote:

3) to compile rasm, I had to use -lrtm instead of -lrt
from ubox-msx-lib-1.1.1\tools\rasm\Makefile:

#	gcc -s -O2 $< -o $@ -lm -lrt -march=native
	gcc -s -O2 $< -o $@ -lm -lrtm -march=native

I have no idea why. I'll investigate!

~mk~ wrote:

4) every time $(command) is used in the Makefiles, I had to rewrite that, for example:
from ubox-msx-lib-1.1.1\Makefile:

#export PATH := $(shell realpath ./bin):$(PATH)
export PATH := $(./bin):$(PATH)

Are you using GNU Make? I'll investigate how I can make this portable; I thought that make would do those bits for us.

~mk~ wrote:

from ubox-msx-lib-1.1.1\game\src\Makefile:

#OBJS = $(patsubst %.c,$(OUTPUT)/%.rel,$(wildcard *.c)) $(OUTPUT)/akm.rel
OBJS = $(OUTPUT)/data.rel $(OUTPUT)/game.rel $(OUTPUT)/helpers.rel $(OUTPUT)/main.rel $(OUTPUT)/akm.rel
#UBOX_LIBS = $(wildcard ../../lib/*.lib)
UBOX_LIBS = ../../lib/ap.lib ../../lib/mplayer.lib ../../lib/spman.lib ../../lib/ubox.lib

Yes, that sounds to me like you may not be using GNU make. I think those are internal functions, but I'll investigate just in case I'm wrong!

~mk~ wrote:

5) tools\mkdeps.py still not producing a valid Makefile.deps

Can you share what is the error?

~mk~ wrote:

I think the issue of game.rom not fully working could be related to issue #4 I mentioned. There could be a few more places which I forgot to fix. I will let you know if I get any further, either sticking to Windows or switching to Linux and probably live a happier life, right? Running Naked in a Field of Flowers

I didn't plan to support windows because as you can see there are a lot of small steps that would be a pain to do in a different way; but if you're happy to keep trying, I think we can get to a point where you can just run make and it will work.

Thanks for your feedback!

By reidrac

Expert (96)

reidrac's picture

12-01-2021, 08:45

@~mk~: well, I've been checking and there are not many options to make this work.

Looks like the most safe option is to install cygwin or mingw's MSYS, so you run this from BASH + the POSIX shell tools (not many, but we still need some).

Unfortunately I can't provide detailed instructions because I don't have a Windows machine myself for testing.

By psxdev

Resident (40)

psxdev's picture

12-01-2021, 09:08

wsl2 can be an easy option on windows for linux "like" development.

By Timmy

Master (132)

Timmy's picture

12-01-2021, 12:22

I'd like to say Thanks, and that even though I don't use SDCC, I'd probably have a look at it one day. I wrote my own library, but it's not ready for release (yet). At the moment I'm more busy with playing games than making them, but I hope I will go back doing it soon.

By ~mk~

Champion (275)

~mk~'s picture

18-01-2021, 03:41

Hi reidrac,

No problem! It is a bit of a struggle but I am learning quite a few things in the process.
I totally forgot such things as Cygwin and MSYS exist, so I am now using Cygwin.
Issues 1 and 4 I mentioned are now solved (the mkdir problem and the $(command) problems), so while still not working "out of the box", Makefiles now requires less changes.
However I am still dealing with issues 2,3 and 5, and the result is same as before, I get a partially working game.rom (title screen comes up and game resets after space key is pressed).

2) when a binary file was being copied, I had to add .exe extension
I think we can rule this out as the cause of the problem.

3) to compile rasm, I had to use -lrtm instead of -lrt
I think we can rule this out too, but perhaps you should try it too to confirm.

5) tools\mkdeps.py still not producing a valid Makefile.deps
To answer your previous question, it does not raise any error but the contents of Makefile.deps are:

../build\1 data.c ../generated/tiles.h ../generated/player.h \

 ../generated/enemy.h ../generated/map.h

../build\1 game.c ../../include/ubox.h ../../include/spman.h \

 ../../include/ubox.h ../../include/mplayer.h ../../include/ap.h \

 helpers.h main.h game.h ../generated/map.h ../generated/player.h \

 ../generated/enemy.h

../build\1 helpers.c ../../include/ubox.h helpers.h

../build\1 main.c ../../include/ubox.h ../../include/mplayer.h helpers.h \

 game.h main.h ../generated/tiles.h

which are clearly wrong and I replaced it by:

../build/data.rel: data.c ../generated/tiles.h ../generated/player.h ../generated/enemy.h ../generated/map.h
../build/game.rel: game.c ../../include/ubox.h ../../include/spman.h ../../include/ubox.h ../../include/mplayer.h ../../include/ap.h helpers.h main.h game.h ../generated/map.h ../generated/player.h ../generated/enemy.h
../build/helpers.rel: helpers.c ../../include/ubox.h helpers.h
../build/main.rel: main.c ../../include/ubox.h ../../include/mplayer.h helpers.h game.h main.h ../generated/tiles.h

I am not sure what I will try next, but I am sure something will come to mind next time I look at it.

By reidrac

Expert (96)

reidrac's picture

18-01-2021, 09:10

Thanks for the report, I can fix mkdeps.py with this, I know what is it!

I'll see about the other Makefile issues as well. What is weird is that the binary builds, but is not correct. That suggests some data is not generated correctly. I use pipes in some of the commands; although solutions like MSYS handle that automatically (IIRC), I suspect windows may be adding '\r' in there. I'll change all the tools to support providing an output filename instead.

Keep an eye on the repo for these changes and thanks again for your feedback!

By reidrac

Expert (96)

reidrac's picture

18-01-2021, 20:54

That was easy.

2) May be fixed, I can't test it, but it should add the .exe extension if you have an OS env variable that contains Windows_NT.

3) Is confusing, because -lm and -lrt is what the rasm dev suggests; I changed the compilation line in case it is related. If it doesn't work, we'll have to find why.

5) Was my mistake; now it should work fine.

Now; why is your ROM corrupt? I reviewed my data tools and turns out I don't use pipes to process binary data, so that's not the issue (and for text is OK).

I would suggest you run a "make cleanall" or even better get the latest code from the repo and start in a clean directory. I wonder if any of the tools is incompatible with your compiler doing something smart to support windows. In any case, if you have a POSIX sell, the makefiles should work without changes.

It is a shame I don't have a system to test this Sad

By reidrac

Expert (96)

reidrac's picture

27-01-2021, 21:38

Until msx.org enables some sort of notifications, I'm not going to monitor any threads here.

Any bug reports, please use GitHub. Thanks!

By ~mk~

Champion (275)

~mk~'s picture

09-02-2021, 00:10

Hi reidrac,
Hope you are reading this, if not I will drop you an email later.
So I had another go at compiling on Windows, after switching to a different computer.
Good news: It is now working! With a few more changes in the Makefiles, which I will describe below.
Bad news: I can't tell what was going wrong on my previous setup. I guess it does not matter much anyway...

My current setup is:
- Windows 10
- Latest version of Cygwin64 with package for gcc-core 10.2.0-1
- SDCC 4.0.0
- Python 3.9.1

Latest ubox 1.1.3 works almost out of the box.
I have successfully compiled the example game after fixing the following (sorry I am not creating issues on Github- these are all small things which are obviously Windows-only related so I think it easier to mention everything here).

1) Replace "ifdef" with "ifeq"
In the Makefiles for the tools, you used "ifdef" to determine if running under Windows to add the .exe extension to binaries. I had to change those to "ifeq". It is worth mentioning that I tried again the standard -lm -lrt flags to compile rasm and it worked ¯\_(ツ)_/¯ so you can go back to LDFLAGS := -lm -lrt unconditionally.

2) Compile hex2bin with -fcommon
It seems with the latest GCC, if not specified, it defaults to -fno-common and this causes a lot of link errors when compiling hex2bin. I confirm this is solved by going back to GCC version 9.3.0-2, or by adding -fcommon to CPFLAGS.

3) Run python scripts with "py"
I thought this was working for me before, but for some reason it now isn't. Evertime a python script is invoked in the Makefiles, I had to add "py" to the command and pass the .py file as parameter, otherwise I was getting "/usr/bin/env: 'python3': No such file or directory". Easy fix, not a big deal.

4) Makefile.deps
This one still giving me headaches. I think the file is now being generated as expected:

../build/data.rel: data.c ../generated/tiles.h ../generated/player.h \

 ../generated/enemy.h ../generated/map.h
../build/game.rel: game.c ../../include/ubox.h ../../include/spman.h \

 ../../include/ubox.h ../../include/mplayer.h ../../include/ap.h \

 helpers.h main.h game.h ../generated/map.h ../generated/player.h \

 ../generated/enemy.h
../build/helpers.rel: helpers.c ../../include/ubox.h helpers.h
../build/main.rel: main.c ../../include/ubox.h ../../include/mplayer.h helpers.h \

 game.h main.h ../generated/tiles.h

However, if I leave it as is, I get a "Makefile.deps:2: *** missing separator. Stop." error.
The only way I could overcome this problem is by manually editing the file, getting rid of the line continuation backslashes, and making sure there are not extra spaces, tabs, or anything. I think Makefiles are great but this "include" feature is not that good.

Anyway, as I said it is now working Smile
It will be fun to tinker with the code and understand how it works.
Thanks for your support!

Page 3/4
1 | 2 | | 4