@kas1e Since multi-disk games can be named any way possible, it would be a bit difficult to detect automatically whether you were loading a second disk or a new game.
The best I can suggest is this, although relies on the game being written to handle external disk drives.
@LiveForIt Yeah, although according to the readme it has problems guessing the disk number, as I would expect. Might still be worth implementing, since "sometimes auto loads the extra disks" would still be better than "never auto loads the disks".
To be honest, I don't have enough multi-disk games that this was much of an issue, so never occured to me. Plus my main focus had been HD installed programs, and the ADF functionality was a more recent addition.
hi Chris, I tried installing RunInUAE again and the install went great again but still get that guru when I run it from AmiDock? I just sent you an email with my crash log so hopefully it's something minor on my end?
How do I change the default screen size? I hate having to scroll the page around to see the whole screen.
If you don't mind a suggestion, it would probably be better NOT to have the main program installed on the SYS: partition. OS updates usually recommend installing on a clean partition, and a user may forget to re-install RunInUAE (and wonder why it doesn't work).
If you don't mind a suggestion, it would probably be better NOT to have the main program installed on the SYS: partition.
* "Sys:Utilities" is only a SUGGESTED location for the main program, you can choose anywhere you like! I can't be psychic & guess where the user installs his programs... * "Sys:C" is used for WHDLoad & JST redirectors, because that is the only place guaranteed to be in the command search path, and is where WHDLoad/etc would have been installed on OS3. * "Sys:Prefs/Env-Archive" is the standard location for program preferences.
Quote:
OS updates usually recommend installing on a clean partition, and a user may forget to re-install RunInUAE (and wonder why it doesn't work).
That problem is hardly unique to RunInUAE - anything which installs 3rd-party libraries, or stores settings in Env-Archive, may stop working when the OS partition is wiped.
To be honest, this is a problem with OS4 & all previous Amiga OSes, and could be solved to a great degree by putting all the "base" OS4 files in a separate folder, along the lines of how MorphOS does it. Then you'd "only" need to wipe that folder when installing a revised version of the OS.
When I install RunInUAE, I get an error message "no device in IDF9" ... what does this mean ?
Sounds like it may have failed to (temporarily) mount AmigaForever's Workbench 3.1 disk image, and so failed to copy it to where you specified.
You say it still works. Does that mean you can click on RunInUAE in AmiDock, and Workbench 3.1 appears after a while? Or do you only see an "insert disk" animation?
How do I change the default screen size? I hate having to scroll the page around to see the whole screen.
Do you mean on the Workbench 3.1 screen? You aren't meant to use it, except perhaps to run installers. The whole point of RunInUAE is that you use OS4's Workbench to start old games.
If I stopped Workbench from scrolling, by using a 640x512 screenmode, then (AFAIK) games would appear half-size (in a 320x256 screen) or else run slowly (due to being upscaled to 640x512).
HOWEVER, if you are wanting to use a non-game application under E-UAE, then it would be best to create a "per drawer" config file that specifies 640x512. Copy the ".uaerc_RunInUAE" file into your applications drawer, then edit it to add these lines: Quote:
gfx_width_windowed=640 gfx_height_windowed=512
edit: An alternative might be to make Workbench 3.1 open an RTG screen, but I haven't experimented with that yet...
When I install RunInUAE, I get an error message "no device in IDF9" ... what does this mean ?
Sounds like it may have failed to (temporarily) mount AmigaForever's Workbench 3.1 disk image, and so failed to copy it to where you specified.
I'd say it is pretty much permanently...
Quote:
You say it still works. Does that mean you can click on RunInUAE in AmiDock, and Workbench 3.1 appears after a while? Or do you only see an "insert disk" animation?
In my case I was only getting a shell window, no workbench showed up until I manually copied over the system files.
Valiant@Camelot AmigaOne XE, 800Mhz, 1GB, 9250 Radeon, OS4.1u7 Sam440ep, 666Mhz, 512Mb, 9250 Radeon, OS4.1u6 A1-X1000, 1.8Ghz, 1GB, 9250 Radeon, OS4.1x A1-X5000/40 2.2Ghz, 2GB, Radeon HD 7700, OS4.1 FE ud 2
@ChrisH: Effectively, WorkBench 3.1 is not installed. when I do no specify a floppy disc image, it simply open an amigados window ... no cli command work (no loadwb, no setpatch, no dir, etc ...)... only "endcli" work. I have Amiga Forever 2008 Premium edition version. The Amiga Forever 2008 CD icon appeared on the Amiga OS 4 workbench so, it was correctly detected?
I will try to reinstall it RunInUAE to check if I can reproduce this error.
EDIT : Amiga Forever 2008 Premium edition CD name is : "amigaforever"
Kindest Regards, Freddix / AmiDARK
Edited by freddix on 2009/12/27 16:35:55
All we have to decide is what to do with the time that is given to us.
If you don't mind a suggestion, it would probably be better NOT to have the main program installed on the SYS: partition.
* "Sys:Utilities" is only a SUGGESTED location for the main program, you can choose anywhere you like! I can't be psychic & guess where the user installs his programs...
.
I could be wrong, but I don't think the installer asked where I wanted the main program to be installed. I doubt I would have chosen SYS:Utilities. Or is it possible the installer ignored where I told it to put the main program? (again, I could be wrong too! )
@all 328gts emailed me to say he finally found the source of his crashes - he was inadvertently using E-UAE v0.8.29 (Sam optimised version), and switching to the recommended v0.8.28 fix that. I am surprised, but "v0.8.29" was only a quick recompile & not heavily tested AFAIR.
I want to point, that latest SDL public version of e-uae (E-UAE-0.8.29-WIP4) from the os4depot or from Richard's page - are the best one becouse of stability.
Maybe for SAMs it's a bit slower if compared with no-sdl one, but on peg2 i see no differences, but, sdl one can:
1. window/fullscreen mode (i can change it in realtime by ctrl+alt+s). No-sdl version can't do that.
2. requster for the injecting image roms (ctrl+amiga+F1/f2/f3/f4) - are the system one in sdl version, and looks "nice", over the no-sdl one, which looks very ugly.
3. have no problems with stability with the SDL version.
But, the very latest developer version (E-UAE test version 2008-01-13) are buggy.. You just press ctrl+alt+f1 for choice the image, and then everything die (you can't press on any file, or on chancel, etc).
Today i write a email to the Richard, but have no answer. In general, even he have their hardware die for running os4/mos , we can setup a bounty and buy it for him, to allow continue the work).
As i see in the readme of last public version, he added experemental OpenGL support, but i can't swith it on on amigaos4. Maybe it was only for MacOC added ..
Today i write a email to the Richard, but have no answer. In general, even he have their hardware die for running os4/mos , we can setup a bounty and buy it for him, to allow continue the work).
Of course, no problems
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
@kas1e I still recommend the v0.8.28 for Sam users, because of better speed, despite instability after quitting for some (including me). Maybe 733MHz Sam is fast enough to use E-UAE-0.8.29-WIP4, but I can't check on my 667MHz Sam.