PUAE 2.4.0 beta series

[Daedalus]

@Mequa

Cool, I'll have to give that build a try on my Linux machines! Thanks

[Mequa]

SCSI is not working yet, so you can't actually play CD32 games on PUAE. It bombs if you set chipset mode to CD32, the above uses generic.

One fall-back solution I discovered for testing purposes is to run the e-uae binary from the same directory (now included). It will then use the same .uaerc configuration and do things currently broken in PUAE (such as boot CD32 games, work with AROS ROM and its "relokick" ADF, mounting directories without major bugs [HDFs still work in PUAE, make_hdf is included], and allow editing of the config file with a working GUI).

Caution: If you disable the GUI and set fullscreen mode in .uaerc, PUAE will indeed work in fullscreen, but you may find it *very* difficult to exit without powering off the PC!

One notable point regarding building: I built it on a 32-bit Ubuntu VM *without* hardware virtualisation and enabled GCC optimisations (and bsdsock support).


Update: I added E-UAE 0.8.29-WIP4 x86 binary to the archive to allow for easier fallback for testing (it's "./e-uae", PUAE is the default "./uae").

[Daedalus]

Cool, I'll bear that in mind! I'm really looking at using it for having an AmigaOS machine on the go, so CD32 support isn't that much of an issue. Picasso96 and JIT would be more useful for me anyway. E-UAE would probably do, were it not for how it decides to absolutely crawl after a few minutes for no apparent reason, so I'm hoping PUAE solves that issue for me...

[Daedalus]

@Mequa

Okay, I can't seem to get that build to boot. I'm using the included .uaerc file (updated for my setup). I haven't defined any hard drives or floppies, just the ROM. E-uae starts and shows the purple insert floppy screen as expected, but uae gets to the point where I'd expect the purple screen, but simply quits. Just as it does so, there's a small chirp from the speakers, similar to what you get with a corrupted MP3, i.e. digital noise. Any ideas?

Running it in the terminal, I get this line when it quits:

(UAE:5719): Gtk-CRITICAL **: gtk_box_pack: assertion `GTK_IS_BOX (box)' failed
Assertion 'pa_atomic_load(&e->pool->stat.exported_size) >= (int) b->length' failed at pulsecore/memblock.c:1106, function pa_memexport_process_release(). Aborting.
Aborted

[Mequa]

Try changing sound_interpol=sinc to sound_interpol=none if the error is with pulseaudio.
(Now updated in the archive's .uaerc, since sound interpolation seems unstable.)

First line looks like a GUI bug.

If that still crashes, try setting use_gui=yes to use_gui=no.
Also watch out for any duplicate settings.

[Mequa]

Update: I also did a FreeBSD x86 build of PUAE (tested on PC-BSD 9.0 x86), using the same build configuration file as for Linux, and included E-UAE as before:

PUAE-f2fc773 FreeBSD binary (zip archive)

I'm trying to use my old Amiga RDB file, which works well under WinUAE and E-EAE with PUAE on OSX, but PUAE refuses to use the file. It's over 2gigs in size. Looking through gdb, and tracing the code, I see lseek() is being called from hardfile_unix.c:hdf_open_target(), but the return is size_t (?), which ends up being a large negative number in my case.

Shouldn't size_t be off_t instead? I've haven't tested my theory yet, as I have yet to compile my own PUAE.

- Mark.

Originally Posted by mgandalf

I'm trying to use my old Amiga RDB file, which works well under WinUAE and E-EAE with PUAE on OSX, but PUAE refuses to use the file. It's over 2gigs in size. Looking through gdb, and tracing the code, I see lseek() is being called from hardfile_unix.c:hdf_open_target(), but the return is size_t (?), which ends up being a large negative number in my case.

Shouldn't size_t be off_t instead? I've haven't tested my theory yet, as I have yet to compile my own PUAE.

- Mark.

Ok, size_t is fine here. I was thinking of lseek(). It seems fseek() is 32bit only, and -D_FILE_OFFSET_BITS=64 has no effect. I replaced fseek() with fseeko() and ftell() with ftello() everywhere, and now the hardfile opens.

- Mark.

[GnoStiC]

@mgandalf:
fseeko64 is even better, you should also change (long)offset parameter.
i don't have such a big hdf so i never had any problems

[chiark]

You're back!

When are you going to push a 2.4.0 to Github?

[Mequa]

Welcome back, GnoStiC! Excellent news!

I need an incentive to make Ubuntu my primary OS on my dual-boot system. Right now thanks to WinUAE, Microsoft owns my soul.

Originally Posted by GnoStiC

@mgandalf:
fseeko64 is even better, you should also change (long)offset parameter.
i don't have such a big hdf so i never had any problems

By setting -D_FILE_OFFSET_BITS=64, all that should be taken care of. However, I've read xcode ignores it. I've also read off_t is 64bit.

I don't fseek64 or fseeko64 exist on osx (at least not on gcc 4.2).

- Mark.

Ok, on to the next issue. I've read where a few people are having issue with Picasso96 modes not showing up. I'm having the same issue.

My RDF file was used on E-EAE (Ubuntu) with Picasso96 working, but I verified all the P96 files were in place anyway. I've set my gfxcard_size to 8meg. My cpu_type is set to 68040. The output from puae looks promising, as it lists P96 modes available, but non show up in screenmode preferences.

Also, when I enable JIT by setting cache_size to 8meg, PUAE dumps pretty quickly with:

JIT_APPLE: can't handle access!
JIT: instruction byte 713984166 is 8b
JIT: instruction byte 713984166 is b7
JIT: instruction byte 713984166 is 08
JIT: instruction byte 713984166 is e0
JIT: instruction byte 713984166 is e4
JIT: instruction byte 713984166 is 16
JIT: instruction byte 713984166 is 0f
JIT: instruction byte 713984166 is ce
JIT: instruction byte 713984166 is 8b
JIT: instruction byte 713984166 is 2d

- Mark.

[Mequa]

I've noticed some signs of life at http://github.com/GnoStiC/PUAE

2.4.1 beta
commit 9aa5c89e61
GnoStiC authored 7 days ago

The latest version doesn't appear to be buildable yet though, but it seems there is still some work going on with PUAE.

[demether]

What about overall PUAE performance ? How is it compared to WinUAE ?

I' m running linux, and I'm not happy with e-uae or fs-uae for my purpose (emulating a high end classic amiga).

On e-uae, I always had some full screen modes problems (especially for native ecs-aga modes, for rtg/p96 it works OK), causing out of range lcd problems, or in the best case, displaying the games and demos on a tiny black window.


thanks !


edit : I tried to install it from a converted rpm file on my mint linux PC, it's working BUT :

no uaer config file in /home
saving new config file does not work
if I try using a .uaerc (putting it by hand in /home), puae does not launch

[Philantrop]

demether, you do realise that fs-uae can emulate a high end classic Amiga just as well as a plain old Amiga 500?

Emulation-wise, fs-uae can do everything puae can and more.

[FrodeSolheim]

Originally Posted by Philantrop

demether, you do realise that fs-uae can emulate a high end classic Amiga just as well as a plain old Amiga 500?

Emulation-wise, fs-uae can do everything puae can and more.

Except the one thing demether is especially interested in, namely JIT (http://eab.abime.net/showthread.php?t=64014)! (Of course, with a modern fast CPU, such as an i7, the emulated Amiga in fastest-possible-mode is fast even without JIT, but not as fast as it would be with JIT). I am considering adding JIT (for x86), but it is not at the top of my todo-list.

[Philantrop]

Frode, implement JIT for x86_64 and eternal fame among the Amiga emulation scene will be yours!

[demether]

@philantrop :

Try to run FS-uae on an old athlon 2400+ 1gb nvidia gfx5600 128mb to emulate a 68040 fastest speed amiga and you'll see what I mean

I know the potential of fs-uae, I saw for example the scaling integration wich is really great. No question about the software quality.

But it stills too slow by fair comparison (trying each system, using 060 demos as benchmark) with winuae JIT enabled or even e-uae JIT enabled for my needs (= running 060 demos and use production tools on os3.x).

I want to create a sort of "x86 amiga". A pc able to boot and run amigaOS 3.x, without seeing the host OS behind. For now, and compared to my needs and available hardware, only windows XP + winuae can (sadly) do the trick. I'd like to install a minimal linux + fs-uae jit enabled, one day, since I'm pretty sure it will be at least as good, probably better.



@FrodeSolheim :

You perfectly understood my needs

[Mequa]

Originally Posted by Philantrop

Frode, implement JIT for x86_64 and eternal fame among the Amiga emulation scene will be yours!

Now THAT would be non-trivial!

And there's ARM and PPC too.