RunInUAE r8 beta 6 (JIT) please test!

@Amigo1, @Raziel:

Thanks, guys [blushing]

Best regards,

Niels

@Raziel

The boring solution to your problem is to use a hardfile.
It will not lock up your machine when writing to the "harddisk" but it will come with the hardfile limitations (it is slow, 2gb max size, and not as easy to write to from your host os).

As it's so easy to spot this problem it must be a well known problem but nobody has bothered for ages to fix it.

@smf

Ah, thanks a lot for the hint about hardfiles.

I don't really need more than 2 GB anyway...it will just be the OS partition...

edit: That did it, cheers mate

Does anyone know how to use RunInUAE with hardfiles only?

It seems to always rely on a directory with OS3.1 in it to boot from.

Right now i'm jumping through hoops by write-protecting the .uaerc file, accepting the error message (and the following waring window about AmigaOS not responding), but it would be nice to be able to use it without crashes (see my post about writing to filesystem2 partitions).

@Raziel

I don't get way everyone is trying to mess with WinInUAE, RunInUAE is designed to do its own thing, so if you wont to do another thing, it its like trying to do something else.

I have 3 or more, EUAE installations.

On my systems etch does its own thing,
one is A1200 and another for A500, and another is for AmigaOS3.1.4 and so on, this works well for me..

I have some older versions of EUAE that I know work more or less without any issues. I have newer version of EUAE for speed, I don’t use too often due to its buggy nature, but 1.0 was too bad (but I do not like some of latest changes..),

@LiveForIt

Because i like how RunInUAE is integrated and how it does nearly everything automatic.
But i also like to have some freedom of choice on matters regarding volumes and/or screenmodes or the emulated hardware details.

RunInUAE is nearly perfect (i think), except that it forces me to use a WB drawer which will crash the whole system AND AmigaOS4 when writing to it (from within RunInUAE).
That may not be RunInUAE's fault, but the underlying UAE implementation...hence my question, if i can workaround it by using a completely hardfile-based RunInUAE (since this won't ever crash and is, apart from the writing speed, as fast as a filesystem2-based RunInUAE).

Oh...and i really like to mess around with stuff

But, i guess it's not possible, so back to ingnoring the error messages...

"RunInUAE is nearly perfect (i think), except that it forces me to use a WB drawer which will crash the whole system AND AmigaOS4 when writing to it (from within RunInUAE)."

Sounds pretty annoying.

So is this only with fastfilesystem2?
(ok with SFS?)

Is it possible to mount a hard disk image and assign runinuae to use that?

IMO: solid 68k compatibility is/should be important part of "AmigaOS".

I hope to boot into AOS4 during holidays & to try:
http://os4depot.net/?function=showfil ... ulation/utility/gluae.lha

@KimmoK-rebirth

I never tried with sfs.

RunInUAE only has the options to use filesystem=, filesystem2=, hardfile= and hardfile2=.

I tried using only hardfile2 with OS3.1 installed, but RunInUAE always checks for a WB31 directory and, if not found, force-add it to your .ini file (hence why i write-protect it).

You can boot a hardfile WB, but, as i wrote, it will throw an error on start and after approx. 20 seconds into the emulation, throw you back to AmigaOS4 for another warning requester that AmigaOS in UAE seems to be stuck (which it isn't.)

I don't do that much with classic anymore...some editing and games now and then, so i don't really care.
But it would still be nice to have a setup i can choose to configure.

I have my joystick working in OS4 but for the life of my cant get it to work in RunInUAE. I have set it up in prefs, selected it in shared settings and it just doesnt seem to ever work. Cant figure out what I am doing wrong here.