Linux Uzebox how-to
Re: Linux Uzebox how-to
Thanks! No more complaints about the bin dir missing. But, there was a ']' missing on the roms folder creation, on windows didn't create the folder but instead a file! Fixed. Now I need to know how to commit to GitHub!
Edit: Done!
Edit: Done!
Re: Linux Uzebox how-to
I just built an UZEBOX kit that I purchased from Adafruit, and I ran into the same:
error when trying to compile the emulator on Linux.
The solution is to add:
to the top of the SDEmulator.h file, because it is trying to use the memset function without including its header file.
Code: Select all
SDEmulator.h:134:30: error: ‘memset’ was not declared in this scope
The solution is to add:
Code: Select all
#include <string.h>
Re: Linux Uzebox how-to
Alchemist reported the same error and was sure I had fixed it. My bad. I fixed that and commited.The solution is to add:
CODE: SELECT ALL
#include <string.h>
to the top of the SDEmulator.h file, because it is trying to use the memset function without including its header file.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Linux Uzebox how-to
OK - I am trying to compile everything under Debian 8.x so I can build a live CD that has everything someone needs for development on it (to help me teach people)
I just did a git clone this morning - so I assume I have the most up to date uzem source
Trying to compile uzem and I keep getting
'strlwr" was not declared in this scope
now from reading strlwr is not a standard part of C, but might be part of SDL.
If I just write my own local function
void strlwr(char* strToConvert){
then I can compile OK.
Does anyone else have this problem. Is it caused by some -ansi-strict switch or something I have done wrong with SDL ?
I just did a git clone this morning - so I assume I have the most up to date uzem source
Trying to compile uzem and I keep getting
'strlwr" was not declared in this scope
now from reading strlwr is not a standard part of C, but might be part of SDL.
If I just write my own local function
void strlwr(char* strToConvert){
then I can compile OK.
Does anyone else have this problem. Is it caused by some -ansi-strict switch or something I have done wrong with SDL ?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Linux Uzebox how-to
follow up.
All the HEX files for games compile fine under Linux, but Uzem seg faults even after I provide my replacement strlwr() function to get it to compile.
All the HEX files for games compile fine under Linux, but Uzem seg faults even after I provide my replacement strlwr() function to get it to compile.
Re: Linux Uzebox how-to
Interesting...is anybody else using Linux can reproduce the segfault?
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: Linux Uzebox how-to
Actually, I am using Linux for my environment. I applied the same above fix. I just had to make sure that avr-gcc and some other things were installed.Artcfox wrote:I just built an UZEBOX kit that I purchased from Adafruit, and I ran into the same:
error when trying to compile the emulator on Linux.Code: Select all
SDEmulator.h:134:30: error: ‘memset’ was not declared in this scope
The solution is to add:
to the top of the SDEmulator.h file, because it is trying to use the memset function without including its header file.Code: Select all
#include <string.h>
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Linux Uzebox how-to
OK - did some printf debugging.
Found out the segfault came from the read diretory command in SDL being handed a NULL.
It was being handed a NULL because there is something wrong with the "get default directory from HEX file" functionality in the linux build.
Under windows if you dont specify
-sd <path>
then it takes the path from the HEX file.
On the linux build it just took the NAME of the hex file and then crashed non gracefully.
I can now get the emulator to work under Linux (by specifying "-sd ./") for T2K. However quite a few other games that are working under Win32 freeze.
Will keep investigating as I would love to make a live CD for people to just be able to boot and fire up eclipse and write a game (for a classroom / lesson)
Found out the segfault came from the read diretory command in SDL being handed a NULL.
It was being handed a NULL because there is something wrong with the "get default directory from HEX file" functionality in the linux build.
Under windows if you dont specify
-sd <path>
then it takes the path from the HEX file.
On the linux build it just took the NAME of the hex file and then crashed non gracefully.
I can now get the emulator to work under Linux (by specifying "-sd ./") for T2K. However quite a few other games that are working under Win32 freeze.
Will keep investigating as I would love to make a live CD for people to just be able to boot and fire up eclipse and write a game (for a classroom / lesson)
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Linux Uzebox how-to
in SDEmualto.cpp should the
be
?
This at least makes uzem fail with an error message for me rather than a seg fault.
I know nothing about SDL though so it might not be the right thing to do.
BTW if I specify the relative path in the hex file name
uzem ./hexfile.hix
With the dot slash at the front it works OK and the opendir() command gets handed "./" if I just type
uzem hexfile.hex
then it passes "hexfile.hex" to opendir() and the SD Emulation fails.
Code: Select all
if(dir < 0) {
return -1;
}
Code: Select all
if(dir == NULL) {
return -1;
}
This at least makes uzem fail with an error message for me rather than a seg fault.
I know nothing about SDL though so it might not be the right thing to do.
BTW if I specify the relative path in the hex file name
uzem ./hexfile.hix
With the dot slash at the front it works OK and the opendir() command gets handed "./" if I just type
uzem hexfile.hex
then it passes "hexfile.hex" to opendir() and the SD Emulation fails.
Re: Linux Uzebox how-to
I really like your live CD idea!
If you think you can fix that path thing to work both under windows and linux using conditionals, you can submit a patch (pull request) via GIT and I'll merge it.
If you think you can fix that path thing to work both under windows and linux using conditionals, you can submit a patch (pull request) via GIT and I'll merge it.