Problems compiling Uzem on Windows -- Solved

[uze6666]

Hi guys,

Yesterday, I tried to update the emulator to work with the latest kernel update. However for some reasons it won't compile at all:

Code: Select all

**** Build of configuration release for project uzem ****

make release 
process_begin: CreateProcess((null), sh -c "uname -s 2>/dev/null || echo not", ...) failed.
makefile:142: *** Unsupported platform!.  Stop.

Back then I was able to compile it, but I probably did some changes to my system since but, now, I can't seem to remember what it was. In the makefile, I noticed UNIX commands like "mkdir" which, I assume were working before since I have generated binaries lying in the folder. Somehow these commands are not available in the cmd.exe shell right now. So perhaps I'm missing a component of MinGW (C:\MinGW\bin is still on my path btw)? Can't find info on the Wiki, so...anybody...any ideas?

Thanks

-Uze

[uze6666]

Never could find what was wrong, so I reinstalled everything: MinGW, WinAVR, AVRstudio, SDL, etc. It somehow fixed the problem . I'm now working on fixing the emulator.

-Uze

[D3thAdd3r]

Awesome, I already need the cycles bad

[uze6666]

Hey Lee,

I managed to fix the emulator but I have more testing to do (and some cleanup). In the mean time, here's a compiled binary that should work well. Let me know if you find any bugs.

*update*: I used the latest version of MinGW and it uses GCC 4 and by default requires an external DLL. I recompiled using the static option to avoid "missing DLL" errors. It's a tad bigger but doesn't require external dependencies (not even SDL.dll it seems!).

-Uze

[D3thAdd3r]

Hi Alec,
Of no urgency, is there a way for a program to detect if it is running in uzem or on actual hardware? Otherwise would it be easy to add a small bit before the next release? What about 1 extra byte of ram the Uzebox doesn't really have, so a program could try writing it and read the value back. Or reading the string "UZEMULATOR" that's outside of real uzebox flash space, or any other hardware impossible thing that easy to implement. Have a patch creation program that at some point I would like to output to eeprom file for easy copy/pasting as opposed to manual copying from screen. User's accidentally destroying their save games on real hardware might earn me some enemies

[uze6666]

Hi Lee,

You can easily test in a variety of ways, the simpler being a read-write to an unssuported I/O port (i.e: 0xff). For simplicity, the emulator just uses a 256 bytes ram array so it will hold anything written to it. The real hardware, will return a fixed value. You can use something like this:

Code: Select all

IsRunningInEmulator:
	ldi r26,0xaa
	sts 0xff,r26
	lds r25,0xff
	ldi r24,1
	cpse r25,r26	
	clr r24
	ret

I would not advise making this an official function because that could cause bad habits and games that runs only on the emulator. I'm open to counter-arguments though. As for the eeprom, eesh, I agree is risky. I'd go with the SD card or make a PC based editor instead.

-Uze

[D3thAdd3r]

Thanks! Bad habits and all that well...you can give a guy a hammer,saw,drill,etc., it's their own fault if they do stupid things with it! I can't fathom trying to hack together a PC program from kernel+uzem that sounds *exactly* like the Uzebox will sound so that's why I need such a nasty tool

[Harty123]

Hi,

this UZEM detection works fine. I've used this in the new version of Uzetherm... Now Uzetherm can detect the emulator...

I putted this code as inline assembler in a C function:

Code: Select all

static inline u8 detect_emulator()
// detect if program run in UZEM
{
   u8 x_out = 1;	

   asm volatile (
   	"ldi r26,0xaa"   "\n\t"
   	"sts 0xff,r26"   "\n\t"
   	"lds r25,0xff"   "\n\t"   	
   	"cpse r25,r26"   "\n\t"   
   	"clr %[out]"   "\n\t"
	: [out] "+r" (x_out)
	);
	return(x_out);
}

-Harty

[uze6666]

Indeed that's the best way to detect the emulator. Btw, following Lee's request I standardized such a function in the kernel upgrade. The function is:

Code: Select all

bool IsRunningInEmulator(void);

The way Harty used such a function, to enable a demo mode to simulate hardware, is pretty much the only valid use case IHMO. This and for development/debugging purposes.