Uzem modifications

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post by uze6666 »

I get nothing but errors when I try my modifications to the emulator, pretty much when trying to do any FAT reads to the SD card from any rom that does that sort of thing.
Uzem was tested and known to work on linux 32/64 bit, MacOS and Win XP, 7 and 8.1. The binary on Google was compiled on Window 7 32-bit using MinGW and GCC 4.6.1.

Can you elaborate a bit on the issues you have compiling the vanilla version? Also can you post your OS and GCC version?
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

I can compile it ok, but it seems to not produce any reads that the roms like. They either say "sd error" or just freeze up tje emulator.

I will check the versions of things in the morning.

Are you compiling with the GCC from Mingw?

Also, I run Windows 7 64bit, but the exe produced is 32bit. Not sure if that matters.

Sorry for any terseness, I am posting from my phone just before bed.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

uze6666 wrote: Uzem was tested and known to work on linux 32/64 bit, MacOS and Win XP, 7 and 8.1. The binary on Google was compiled on Window 7 32-bit using MinGW and GCC 4.6.1.

Can you elaborate a bit on the issues you have compiling the vanilla version? Also can you post your OS and GCC version?
OS: Windows 7 64bit
MinGW Version: 2013072300
GCC: mingw-gcc 4.8.1-4
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem modifications

Post by D3thAdd3r »

I can confirm the Uzem I just built fails for Alter Ego immediately at the pf_open(). Using the emulator version I had from before that I did not compile myself(no idea when it was actually compiled, but latest version number) works fine. The source files look like they haven't been modified since march 2014 so I have no clue. Windows 8.1 x64 latest mingw setup
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

D3thAdd3r wrote:I can confirm the Uzem I just built fails for Alter Ego immediately at the pf_open(). Using the emulator version I had from before that I did not compile myself(no idea when it was actually compiled, but latest version number) works fine. The source files look like they haven't been modified since march 2014 so I have no clue. Windows 8.1 x64 latest mingw setup
Ok, so I'm not crazy. I do need to figure out the setup for getting GDB to debug the ROM through uzem, but I'm sort of glad I'm not the only one that has seen this. Now if I can figure out why... I guess I'll try to attach GDB to the ROM in uzem and see if I can figure out a pattern. Tracing the source in uzem doesn't really help, it seems to basically be doing the right thing until it just... doesn't. :?:
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post by uze6666 »

I'd do some research on gcc 4.6, 4.7 vs. 4.8. I recall something on Slashdot a while ago that mentioned it has issues like you are experiencing. Perhaps you should just revert to an earlier version of MinGW with GCC <4.8.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

From what I can gather from some initial debugging, the "bootsector" variable on the SDEmu struct is getting either overwritten or changed. The init_with_directory() function has:

Code: Select all

	memcpy(&bootsector.bootjmp, bootjmp, 3);
	memcpy(&bootsector.oem_name, oem_name, 8);
	bootsector.bytes_per_sector = 512;
	bootsector.sectors_per_cluster =64; //32K cluster size
	bootsector.reserved_sector_count = 1;
	bootsector.table_count = 2;
The typedef reads:

Code: Select all


typedef struct fat_BS
{
	uint8_t		bootjmp[3];
	uint8_t		oem_name[8];
	uint16_t	        bytes_per_sector;
	uint8_t		sectors_per_cluster;
	uint16_t		reserved_sector_count;
	uint8_t		table_count;	//number of copies of FAT
But when I run the emulator, and it reads the bootrecord via SPI, in the byte output from SPI_READ_SINGLE_BLOCK in update_spi() looks like:

Code: Select all

0000: EB 3C 90 75 7A 65 6D 53 44 65 00 00 00 02 40 00 | .<.uzemSDe....@.
from my understanding, that should read:

Code: Select all

0000: EB 3C 90 75 7A 65 6D 53 44 65 02 00 40 00 01 02 | .<.uzemSDe..@...
Which is very odd, especially if I am reading the code right and doing my math right.

Thoughts? Am I completely off base on that?

By the way, this was all on the code checked out via svn from the google site.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

CunningFellow wrote:If it helps narrow it down t2k does not do any "FAT" reads.
That's pretty hard core. Looks like you did some of your own sd/mmc assembly in there.

I do find it odd that that fails as well but I need to dig deeper into your assembly to see if I can figure out why. If it's an issue of bits changing in transit through the SPI on the emulator, that could explain it, but that then begs the question of why those bits are changing...
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy »

uze6666 wrote:I'd do some research on gcc 4.6, 4.7 vs. 4.8. I recall something on Slashdot a while ago that mentioned it has issues like you are experiencing. Perhaps you should just revert to an earlier version of MinGW with GCC <4.8.
I'm beginning to think that too. I wonder if it's some very strange struct alignment or something even worse... Time to go hunt down an older version of mingw....
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post by uze6666 »

Saw some posts on the net saying 4.8.1 may have some issue due to the optimizer. Can you try lowering or removing the -O optimization to see what happens?
Post Reply