Hi Glyn, After fighting with VirtualBox for a few hours I was able to get a usable development environment up and running, so I've now been able to debug and fix the issues that were stopping ArcEm from working on 64bit hosts.
The main cause of the problems was that there were a few places where 64bit types (e.g. FastMapUInts) were being unintentially truncated to 32bits, either causing flags to be lost or pointers corrupted. I've also merged arcem-fast to trunk, as suggested. Cheers, - Jeffrey On Fri, 11 May 2012, Glyn Edwards wrote: > Hi Jeffrey, > > I did try and track down the issue myself but I'm not a C++ programmer. > > Through many printf statements I'm pretty sure it is to do with the > FASTMAP_RESULT_FUNC and FASTMAP_FLAG macros and > the fact that the FastMapInt and FastMapUInt in armdefs.h have a type or > intptr_t which is 32bits long on 32bit linux and 64bits long on 64bit > linux. > > I'd given up for the moment though. > > I hope that helps you as this is the only open source linux emulator > that can run RiscOS 3.1 which is the version I played my games on as a > kid. > > Best regards, > > Glyn > > On Fri, May 11, 2012, at 12:55 AM, Jeffrey Lee wrote: >> Hi Glyn, >> >> I'll try and find some time to look into this this weekend. I have a >> hunch >> for what could be causing the problem, so hopefully it won't be too hard >> to fix. >> >> Cheers, >> >> - Jeffrey >> >> On Tue, 1 May 2012, Glyn Edwards wrote: >> >>> >>> Hi, >>> >>> I've been playing with the arcem-fast branch and it works fine on my >>> 32bit linux installation. However, it does not work on my 64bit linux >>> installation. >>> >>> arcem-fast appear to work better than the trunk CVS so thanks for that. >>> It might >>> be easier for other users if this branch could be made trunk now. >>> >>> on 64bit linux I get >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> >>> repeated rapidly >>> >>> on 32bit linux I get >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 0x0, 4000000Hz (CR 0 ClockIn 24Mhz) >>> New mode: 640x-20, 25Hz (CR 0 ClockIn 24Mhz) >>> New mode: 640x291, 50Hz (CR b2 ClockIn 24Mhz) >>> New mode: 640x256, 49Hz (CR b2 ClockIn 24Mhz) >>> New mode: 640x480, 57Hz (CR 18bb ClockIn 24Mhz) >>> >>> This was mentioned >>> https://sourceforge.net/mailarchive/message.php?msg_id=28300992 but it >>> doesn't look like there was a resolution. >>> >>> I've attached the results of: >>> (strace ./arcem 2>&1 ) > log >>> on each of the 64 and 32 bit builds for comparison >>> >>> The file the lines are being printed from is arch/stddisplaydev.c. >>> >>> Can anyone help? I can do some more diagnostic work but nothing I've >>> tried so far works. I'm assuming it is some bitwise operation that is >>> going wrong or some integer being stored in 64bit when it should be >>> 32bit but I'm not familiar enough with C++ to get much further. >>> >>> Thanks, >>> >>> Glyn >>> > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
