Switch to 64bit

[emufreak]

Apple will most likely drop 32 bit support soon. See http://www.macworld.com/article/3163248/ios/the-future-of-ios-is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html. iUAE is 32bit only.

Unfortunately this is not a matter of a simple recompile. The Issue is iUAE converts certain values to pointers (Probably stuff in Amiga Memory which is 32bit)

[mithrendal]

At least others did this transition already successfully. See http://eab.abime.net/showthread.php?t=79762

@emufreak when we change compiler settings to 64bit what happens?

1.Do we get warnings/errors on code we have to adapt?
2.we dont get any warnings or errors it just crashes.

I vote for case 1. 😉

[mithrendal]

I just switched to 64 Bit only version and first I got loads of compile errors.

I made a handful of changes in order that it builds successfully and at least I can report that I can build, deploy and run it on 64Bit now.

But it crashes very early in

static void init_mem_banks (void)
{
int i;
for (i = 0; i < 65536; i++)
put_mem_bank (i << 16, &dummy_bank); //<---- here i got EXC_BAD_ACCESS
if (!savestate_state)
init_memmaps(&dummy_bank);
}

So I think emufreak is right when he says "stuff in Amiga Memory".

EDIT: I found this

https://developer.apple.com/library/prerelease/content/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html

It explains all the pitfalls.

And this

https://developer.apple.com/library/content/documentation/General/Conceptual/CocoaTouch64BitGuide/Major64-BitChanges/Major64-BitChanges.html#//apple_ref/doc/uid/TP40013501-CH2-TPXREF103

https://developer.apple.com/library/content/documentation/General/Conceptual/CocoaTouch64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013501-CH1-SW1

Which describes the changes when going 64bit on ios in general

and one non apple article which shows the padding problem very nicely https://www.bignerdranch.com/blog/64-bit-smorgasbord/

[simontoens]

Thanks @mithrendal - given what you looked at so far, do you think we can get this running in 64 bit mode? Would be a pity to not be able to run this emulator anymore.

[mithrendal]

I think we have two ways here to go.

first way "Stick with the old emulator gp2x core and migrate it to 64Bit":
tasks:

• read and understand the apple migration guides to 64Bit
• do the migration to be able to successful compile it. (I think this task has to be done very carefully otherwise we be will haunting countless runtime bugs)
• do the runtime debugging

second way "migrate to a modern 64Bit uae core"

• analyse the junctions between our iAmiga and the old gp2x uae core
• insert the new modern 64Bit amiga uae core into the project
• remove the old 32Bit gp2x core
• reconnect the junctions to the new modern 64Bit
• do the runtime debugging

I can't say which one is more time consuming. But I would say the second way is more fun and as a big plus we get a nearly 100% amiga compatibility (because frodes emulator is frequently patched with Toni Wilens WinUAE.)

What do you think?

[simontoens]

@mithrendal yes definitely from a high level, option 2 sounds way better. Would be good to get @emufreak 's thoughts here...

[mithrendal]

Hi @simontoens

I played a bit with the 64Bit conversion of our existing emulator core.

It runs now 64Bit without a crash. the cpu is up and running opcodes in the memory , the menus are there and fully functional.
Custom chip graphic output is also there.
but on booting up the amiga it shows

on kickstart 1.3 a gray screen with a flashing red status LED (the one left to the df0: LED).

On kickstart 2.0 upwards the amiga screen flashes red 1 second red the next second black and so on... And also the red status led flashes.

I still got 282 compiler warnings though. I bet they have something to do with the flashing. But hey, at least the amiga hardware (cpu wise and some custom chips) is running a bit now
although not very usable. ;-)

The amiga is already communicating with us, what does the kickstart amiga OS code like to tell us with the red blinking?

Would be nice if @emufreak has some advice on this matter. Which direction should we go?

[simontoens]

Nice to see you are making progress! Did you have to make a lot of changes so far and was it very time consuming? I remember when the red Amiga light was blinking on my real Amiga, it usually meant something horrible was about to happen :)

[mithrendal]

I did spent 3 sessions each about an hour or so. Made changes in 40 to 70 lines of code so far don't know exactly.

First session it didn't compile.
Second session I made it build and compile, but it crashed.
Third session I removed two crashes one in memory the other in the fame cpu code.

Maybe I should concentrate now on the warnings? Or should I determine the exact step where the amiga is not going forward to show the workbench screen?

[emufreak]

What about the uae4all2 code. Is this 64bit? The gp2x is very similar because it's based on it.

[emufreak]

Sorry for my short answers (or lack of them). I'm working on something else at the moment. I plan to spend more time on iUAE next month though.

[emufreak]

64bit is implemented and ready for testing in dev

[emufreak]

There is one issue that still prevails.
There are now hundreds of warnings about type conversion issues.

The reason for this is that type conversions can be a serious issue when switching to 64bit. "Lacy" coders just assumed a pointer to be the same size as an integer (32bit). This is right for 32bit architecture but not 64bit. This warnings helped me a lot to fix some serious issues with pointer arithmetics.

Unfortunately there are still 100 of warnings. Most of them are probably harmless. Conversion from long to int for the number of thiskdrives for example are unlikely to cause some dataloss for example.

I don't know how to handle this at the moment. Just suppressing them seems to be a bad Idea. Fixing them manually is a pain in the ass and we might have to redo it if we upgrade our core to a newer version.

[mithrendal]

Thanks 🙏 so much for this work @emufreak I found one bug so far. Virtual joypad is not working.

[mithrendal]

@emufreak @simontoens
Hundreds of warnings are a bad thing to have in code because you will not see new problems you are about to add to the code. Because of the hundreds of warnings that new created warnings will not track your attention anymore. But in this particular case I think we should be rather conservative and leave them as they are for the following reasons:

• the emulator runs stable now in 64Bit, in changing hundreds lines of code we may risk serious compatibility to Amiga software. So better not change it.
• When we like to migrate to the 64Bit-FS-UAE core which is nearly 100% compatible with all Amiga software ( it derives from current WINUAE) that work would be obviously done without earning any credits. That is the second reason I can think of to just leave the warnings ignored for now.

@emufreak BTW just out of curiosity: How long did it take for you to find out all necessary modifications (17 changed files in your commit) to make it running so well in 64 Bit ?

@emufreak found so far just one issue: the virtual joypad seems not to be working anymore. The virtual mouse is working fine though.

[emufreak]

It took me around 10 hours. For the errors it was enough to change the coversion from (uint) (uiptr_t) m. Last one is a datatype that has the same length as a pointer. This means its kength is 32bit on a 32bit system and 64bit on a 64bit system. I mostly looked at the errors individually but I did search and replace for the opcodes file as there were so many.

I had to look at the warnings individually and make changes if pointers were affected.