FS-UAE Stable Series - Questions, Feedback and Bug Reports

[BastyCDGS]

Another question, in older(?) WinUAE versions, using hard_drive_x_label = HD0 caused the device name of DH0: to be HD0: (if x = 0) for non-RDB images. Is it possible to do this in FS-UAE, too?
Relabel the actual drive label does not make sense here, since this is stored (and thus can be changed) in the filesystem layer.
Yes, I know I could simply use RDB for that, but I use partition images across multiple configurations and not every partition should always be visible on each configuration, but there are partitions which are shared among multiple configs.

[BastyCDGS]

Next bug:
PAL/NTSC is sometimes not handled correctly. This bug is pretty hard to explain, but lemme try:
If I use WB1.3 as harddisk installation, I sometimes have the problem, that WB suddenly boots in NTSC mode. This seems to happen more often, if I use mouse_integration = 1 in my config and another case (see below).
I know that the original Amiga can also be affected by this problem, but there are differences anyway. On my original A500 in the past, the PAL part (height pixels 200-255) were just blanked out (i.e. rendered blue on standard WB1.3 bg color). Within FS-UAE that region is completely discarded and the whole screen looks exactly like NTSC.
I however, remember this only happening on original Amiga with either having the Jeff or Byte Bandit-Virus (not sure about that).
However, none of those can be on my HDD (they're bootblock viruses), yet still it happens.
I might be wrong, but it might be that this bug appears within FS-UAE if I reboot with CTRL+LAMIGA+RAMIGA and it currently has an NTSC screen opened in front.
I encountered this bug way more often when using the GFA-BASIC interpreter (Version 3.52D).
And it way more often happened with configuration: gfx_linemode = double2

I changed that recently to:
gfx_linemode = double

which seems to reduce the issue massively, but it's still happening.

[BastyCDGS]

GUI refreshing problems:
Some of the newer options (for example, accelerator options) don't get updated if you select a new configuration.
Internal state, however is correct.
This means, that if you switch from a config (let's say WB13 with 68020 to WB39 with Cyberstorm PPC), the accelerator in the GUI is still shown as none, although it should display Cyberstorm PPC. Internally this is no problem, i.e. starting PPC works, but GUI element doesn't get updated. This can be really confusing.

[BastyCDGS]

Screen dragging and mouse integration with 1.3:
Upon developing with GFA-BASIC, screen dragging sometimes gets very ugly. That is mouse pressing and trying to move screen down or up has glitches. Input events seem to be discarded under certain situations, which results in I can't move screen y-pos to certain position. Screen just sometimes seem not to recognize dragging (also happened with mouse_integration = 1, didn't try with = 0).
This never happened on original A500.

Another maybe bug:
Screen changing using AMIGA+N or AMIGA+M works differently than on original within OS1.3.
I'm not really sure about that, but if I'm not wrong, I could cycle all screens on OS1.3 with that key combination on original Amiga, where I have only two screens for choice in FS-UAE.

[BastyCDGS]

General ideas for improvements:
On the fly-GUI changing of all things you could do on real amiga on the fly, should be possible.
As already mentioned, write protection for floppy.
Idea for implementation:
Normal is pressing ENTER for selecting new ADF. If you select by CTRL+ENTER it is mounted read-only.
Already mounted stuff is selectable by now and pressing CTRL+ENTER on it will eject / re-insert by toggling read-/write and read-only flag.

Currently, I have to terminate current session, if I decide to insert an alien ADF and restart.
There should be an option to choose a completely new disk image on-the-fly.
Could be implemented by adding a "CHOOSE ..." to default "SAVE DISK".

[BastyCDGS]

Display could be ADF name + (RO) in parenthesis or sth. like that.

[ztronzo]

Does anyone know if there is a way to make FS-UAE run an Amiga CPU with speeds precisely as with a 68030 at 50Mhz or 68040 at 28Mhz? (Not running as fast as possible)

[jbl007]

Originally Posted by ztronzo

Does anyone know if there is a way to make FS-UAE run an Amiga CPU with speeds precisely as with a 68030 at 50Mhz or 68040 at 28Mhz? (Not running as fast as possible)

Dunno if it works for 030/040 but for 020 + CE you can use uae_cpu_multiplier=8 for 28MHz (and perhaps 16 for 56Mhz?)

[ztronzo]

Thanks again Jbl007! Those options seem to be ignored in FS-UAE..
But your reply pointed out for me try to use different settings.. since I had WinUAE installed I tried every option adding uae_ prefix

amiga_model = A1200
uae_cpu_throttle=3000.0

Finally these options worked for me :-)

[ztronzo]

I cant seem to find any documentation but I have found the option "download_file ="
Would anyone know how it really works?

I tried using it with the fs-uae-launcher
download_file = http://www.amiga.xyz/disks/test.zip
and seems to download the file in the cache\downloads\(random 3 letter folder):

Now Im not able to figure out how to use it yet.. is there any way to load the disk named "Disk 0 - (Boot).adf" located inside the zipfile?

[jbl007]

Originally Posted by ztronzo

I cant seem to find any documentation but I have found the option "download_file ="
Would anyone know how it really works?

Ah, some secret magic of the launcher... AFAIK "download_file" is used by oagd.net-feature. You can use http/ftp URLs with floppy_drive_x to archive a similar effect, eg.:

floppy_drive_0 = http://www.amiga.xyz/disks/test.zip

(if .zip contains a single file) or

floppy_drive_0 = http://www.amiga.xyz/disks/test.zip#subdir1/subdir2/game.adf

to use subdir1/subdir2/game.adf inside test.zip for DF0

[ztronzo]

Originally Posted by jbl007

Ah, some secret magic of the launcher... AFAIK "download_file" is used by oagd.net-feature. You can use http/ftp URLs with floppy_drive_x to archive a similar effect, eg.:

floppy_drive_0 = http://www.amiga.xyz/disks/test.zip

(if .zip contains a single file) or

floppy_drive_0 = http://www.amiga.xyz/disks/test.zip#subdir1/subdir2/game.adf

to use subdir1/subdir2/game.adf inside test.zip for DF0

Wow! Thanks!!! Works great!!!!!
This method also corrected the bug with the Disk name being displayed inside the FS-UAE menu (cause I was using the links method with %20)
Im using it from now on all my online configs with 2 disks and more... :-)
Thanks again!

To take it a step further... Would you happen to know how to load or add a saved_state file from the config using the same http://.. method??
I know it would be read only, but I dont mind
:-)

I have just finished rebuilding my old A4000 together with a brand new install of OS3.9. I received an email offer to upgrade Amiga Forever during the rebuild and I thought it would be good to get the latest Personal Paint.

Both are now working, but I thought I would report my findings.

The motor in the old A4000 hard drive failed just as I was finishing. I installed a replacement and could not get PFS3 to work. I used the latest FFS. I used the OS3.9 Boing Emergency CD to install the OS. It installed an Emergency CD driver in Devs/DosDrivers which caused problems. It also installed my Cybergraphx drivers for the graphics card. Once I had reinstalled the bulk of the programs, the hard drive light came on almost all of the time. That was FFS doing the house-cleaning. It took several hours to finish.

I installed the latest FS-UAE and launcher in Kubuntu 15.10 and updated it by adding the FS-UAE repositories. I decided to use HDF files rather than directory disk entries for Work and Workbench because both Windows and Linux have problems with FFS files (file length and the characters used). For instance, there are a couple of "What's New?" file names in my system and some catalog file names that can't live with Linux. I have no HDD light for my little Intel Atom, but the processor is shown as working almost flat out and has been for two days. It will be worth it when finished as I will have efficient Work and Workbench hdf files for use in both Amiga Forever and FS-UAE. In the mean time both FS-UAE and Kubuntu are very slow. Perhaps I should have started with Amiga Forever on a much more powerful desktop.

I tried the FS-UAE graphics cards with my version of Cybergraphx V4 and Picasso 'cards'. No enhanced graphics modes appeared, although the AGA higher resolution modes handled 256 colours. The AGA modes look just as horrible as on the A4000 with a flicker fixer. Picasso96 from Aminet solved the problem. It has graphics drivers for the UAEGFX 'card' which is what I am now using. The display is a match for the sharp graphics on the A4000.

At startup, a 'Cannot open UAEGFX.device' message held the screen in low res until cancelled. This was due to the OS3.9 Boing CD leaving that 'Emergency CD' DosDriver in Devs. When the Boing CD image was emulated, the Boing CD icons are duplicated. One needs to get rid of that driver on both real and virtual A4000s

I just saw the processor activity dip and restart. That means it has moved on to the Workbench volume. I'm going to turn the screen off in a minute and let it do its thing.

The bottom line is that there is little difference between FS-UAE and an A4000 other than the FS-UAE on a good Atom being a little slower and the mouse lagging a little. Oh, and the HDD motor doesn't burn out.

Originally Posted by royleith

The bottom line is that there is little difference between FS-UAE and an A4000 other than the FS-UAE on a good Atom being a little slower and the mouse lagging a little. Oh, and the HDD motor doesn't burn out.

I spoke too soon. The high processor activity is nothing to do with FFS housekeeping. I installed AmiKit which I really like and plan to try in the real machine. However, it uses a directory hard disk rather than an HDF and still consumes most of the processor power.

I installed Amiga Forever in Wine and the processor use is much lower for AmiKit. My version of Kubuntu is 64bit, but the Wine environment is 32bit. I suspect that AF is running JIT.

I will watch the progress on 64bit JIT with interest to see if that resolves the problem. I find it amazing that Amiga Forever running an Amiga hardware emulation in WINE (WINE Is Not an Emulator) interfacing Windows programs is so much faster than our native emulator. I hope that the much nicer FS-UAE can match the performance once JIT is working.

I will use the real thing for the time being. I am preparing a fresh OS3.9 Workbench for AmiKit. If that works well, I will make that the partition for the future.

[jbl007]

Originally Posted by royleith

I hope that the much nicer FS-UAE can match the performance once JIT is working.

Hm, actually it IS working! Add the line "jit_compiler=1" to custom configuration.

When I add jit_compiler=1 or uae_cachesize = 8192 I get the message,

MMU Emulation requires 68030, 40 or 60 and is not JIT compatible.

I have been matching my current A4000 config with an accelerator, but perhaps I need to drop back to a 68020 (which, I think, may have been the original processor).

Then I will have to experiment with the 'not very accurate' setting to get the speed up.

[ztronzo]

Originally Posted by royleith

When I add jit_compiler=1 or uae_cachesize = 8192 I get the message,

MMU Emulation requires 68030, 40 or 60 and is not JIT compatible.

You can try just this

amiga_model = A4000/040
jit_compiler = 1

[ztronzo]

This is an A1200 setting to run at speeds as an A4000 040/25Mhz:

amiga_model = A1200
accuracy = 1
jit_compiler = 1
uae_cpu_throttle=3000.0


you can also try this:

amiga_model = A1200
accuracy = 1
jit_compiler = 1
uae_cpu_type = 68040
uae_cpu_throttle = 1000.0

FS-UAE does a good job at re-editing the custom settings. It does mean that one may not be testing what one expected.

Works: (A4000 - 3.1ROM, 68040CPU)

accelerator = 0
graphics_card = uaegfx
graphics_memory = 16384
jit_compiler = 1
motherboard_ram = 65536
sound_card = toccata

Does Not Work (JIT not compatible with 030, 040 or 060)A4000 - 3.1ROM, 68040CPU)

accelerator = 0
cpu = 68040
graphics_card = uaegfx
graphics_memory = 16384
jit_compiler = 1
motherboard_ram = 65536
sound_card = toccata

The real processor activity is still very high in both cases and I cannot be sure that the JIT is really working even though the warning messages don't appear.

I tried with an A1200, making sure that it was using default settings. As expected, RAM: filled up and the A1200 could not boot up into the HDD-based Workbench. Expanding any of the memory failed because extra chip RAM was incompatible with UAEGFX and other expansions required a 32bit processor.

Amiga Forever running in Wine on the same machine is usable, even though it is on a lowly Intel Atom. FS-UAE has a much higher background processor occupancy and is a little too slow for big-box emulation. It occurs to me that the processor instruction emulation (with or without JIT) would not create continuous processor usage. It must be the Amiga executive taking the time, and I would have thought that JIT would not be key, but what would I know?

I think only Frode Solheim and his coding collaborators would know the real answer.

[jbl007]

There is a little pitfall with the "cpu"- and the "jit_compiler" options: For example if you set cpu=68040, FS-UAE also enables MMU. The problem is MMU+JIT is not possible. To use 040 cpu and JIT just set "cpu=68040-NOMMU"
See here: https://github.com/FrodeSolheim/fs-u...oc/options/cpu


A1200 + jit + accuracy=1 is bad because "accuracy=1" means cycle exact emulation (does not work with jit) Edit: Better use accuracy=0 and amiga_model=1200/020 (or cpu=68020) to use a "real" 32bit cpu instead of 68EC020 of a stock A1200.


You can check fs-uae.log.txt if JIT is enabled or not.