search

emufreak / iAmiga

iAmiga sources
47 stars 17 forks source link

Switch to 64bit #67

Open emufreak opened 7 years ago

emufreak commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I think we have two ways here to go.

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

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

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 commented 7 years ago

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

mithrendal commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

emufreak commented 7 years ago

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 commented 7 years ago

64bit is implemented and ready for testing in dev

emufreak commented 7 years ago

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 commented 7 years ago

Thanks šŸ™ so much for this work @emufreak I found one bug so far. Virtual joypad is not working.

mithrendal commented 7 years ago

@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:

@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 commented 7 years ago

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.

simontoens commented 7 years ago

Thanks @emufreak - I am glad we can keep using this emulator.

Regarding the warnings, maybe we should suppress them? I remember going through something similar way back: https://github.com/emufreak/iAmiga/commit/59b7307e6de39ded185154449766a8f0bfd8be84

mithrendal commented 7 years ago

something completely different ...

https://www.zdf.de/dokumentation/zdfinfo-doku/die-amiga-story-100.html

;-)

mithrendal commented 7 years ago

Hi guys, I did a bit more testing an 64 Bit only build of the latest dev branch.

Restoring previously saved states is still broken. It does not restore.

I fixed it in memory.cpp line 992 -> STATE_RESTORE was int outSize=allocated_chipmem; int inSize=compressed_size; only the second line gave one warning about long to int conversion losses. No warnings in first line.

but both lines must be changed to long outSize=allocated_chipmem; long inSize=compressed_size;

now the 64 Build can save and restore savestates. @emufreak I am happy that it works fine now but do you think it is the correct way to fix this issue? Long works fine but maybe it should be still another type like uintptr_t ? I saw in your commits you converted a lot of int types into uintptr_t ...

Virtual Joystick Controller movement is not working. Virtual mouse works fine but no joystick movements. It seems that it can't get the controller mapping number from the settings... If I bypass the mapping stuff and do some hardcoding in the MultipeerConnectivityController.mm then I joystick movement works fine.

simontoens commented 7 years ago

@mithrendal thanks for testing/fixing! I am sorry that recently I did not have much time to spend on iAmiga. I am hoping we can sort all these issues out over time...

mithrendal commented 7 years ago

yes you are right we sort the little bugs all out over time.

But I also already found the fix for the controller mapping bug.

it was in

otherwise the following test in the same method is never true if(kmNumber == NSNotFound) {

now I have no more 64Bit issues so far. Will prepare a pull req for @emufreak to merge soon....

emufreak commented 7 years ago

@mithrendal The nice thing about uintptr_t is, that it always fits the length of a pointer no matter if it is 32bit or 64bit or in the future maybe 128bit. This ensures forwards and backwards compatibility.

voji commented 6 years ago

I try 1.3.0 iUAE 64 bit version on IOS 11 (installed from cydia). Everything is work fine, but when i try to restore emulator state (any game) the app crash... So, I think the 64bit bug in state restoration rutine still exists

eduo commented 3 years ago

Hello, all.

I see communication stopped three years ago. I there a fork thatā€™s been able to keep the port up to date with released IPAs? I see a renewed interest in retroemulation in iPads due to the improved joystick, keyboard and mouse support and while Iā€™ve been able to provide an IPA that I use to friends I am not confident at all that it is really the latest version.

Normally githubs that get less attention end up having a more active forked repository. Is this the case for iUAE/iAmiga?

I see a nice fork from @mOoNsHaDoOo but that seems to have stopped some time ago, and his changes were not merged into @simontoensā€™s fork which seems to be kept up to date but has no IPAs in the releases.

If Iā€™m not missing anything, I can go off from Simontoensā€™s to build IPAs but since I wouldnā€™t be adding anything else I donā€™t think thereā€™s much added value in forking it just for that.

mdbergmann commented 3 years ago

Seems there are: https://github.com/emufreak/iAmiga/network

mithrendal commented 3 years ago

I see a renewed interest in retroemulation in iPads due to the improved joystick, keyboard and mouse support

I found a nice clean codebase for accurate and high performant amiga emulation at https://github.com/dirkwhoffmann/vAmiga ... the code is excellent and compatibility shouldn't be lower than the old uae core in iAmiga ... I would bet it is much higher still... and the best ... it is actively maintained

@dirkwhoffmann did also an emulation of the c64 which I already ported to a PWA (progressive web app) ... the advantages over the native app is that we don't have to deal with code signing, side loading etc... The performance hit by the port to webassembly is roughly only 10 to 20 % which is neglectable given the power of todays phones ... In fact the c64 port still works very well without stuttering on a iPhone 6s or iPadAir 2 from 2014/2015 ...

For the c64 emu which I did as a first thing I brought over some of the concepts of @simontoens ... escpecially his nice concept of adding custom keys ... You can install a PWA by just adding it to the homescreen, I made it offline capable... so you don't even need network to play ... @eduo and it works with real game controllers connected to the iPad or iPhone šŸ˜šŸ˜Ž

https://https://vc64web.github.io/

or see here how it runs a cool demo https://vc64web.github.io/#http://csdb.dk/getinternalfile.php/190343/monstre.prg

In the next week I probably will start with the vAmigaWeb project which will be very similar to the vc64web as the codebase is nearly identical in terms of structure and also API wise

eduo commented 3 years ago

@mdbergmann That's where I pulled the forks I mentioned from. The network precisely seems to show only the two I mentioned have had any activity in years.

Thanks, @mithrendal . I don't particularly care for PWAs, but I'll take a look. For C64 I run the excellent Ready (which also has Spectrum emulation and spectacular hardware emulation all in all).