Query: emulation switches to ECS - Agnus mode when direct loading OCS floppy images?

[giantclambake]

AFAIK, the base amiberry configuration is Amiga A500, OCS chipset, 512Kb chipram/512Kb slowram, using Kickstart v1.3 rev 34.5

You can see this by launching GUI -> Start (or amiberry -G) and checking Chipset options --- OCS chipset is selected

http://ftp2.grandis.nu/turran/FTP/Non%20TOSEC%20Applications/Disk/ADF/SysInfo%20v4.0.adf

Download, direct load the above .adf --> when sysinfo gets to its UI, it says "ECS Agnus - 1meg"

Hit F12 -> Chipset panel --> it has decided to flip to ECS mode??

If this is a bug, then the following applies;

Expected: amiberry to retain the base configuration, and sysinfo to boot on that config...ie; OCS chipset, 512Kb/512Kb

Else ... something is going on here that's yet to be documented ;) I checked the logfile for any 'usual' conflicts..

Floppy... /home/gcb/Downloads/SysInfo v4.0.adf
No configuration file found for /home/gcb/Downloads/SysInfo v4.0.adf, inserting disk in DF0: with default settings

...it initializes a 1Mb slice for custom chip, but as the emulator comes up, the 512Kb of slowram appears to be mapped in ~ perhaps sysinfo itself is not 'seeing' the emulation correctly... BUT....

How on earth did the Chipset options get changed in the GUI?....ie; I left them default (OCS), but it boots ECS instead...and the GUI selection 'changed behind my back' so to speak...

Could you please explain this behavior?

TIA

[giantclambake]

Additional: after checking some OCS only .adf images, it seems in those cases, the base amiberry config is retained...

OTOH, starting an OCS/ECS .adf image, sees amiberry do as described above ~ it switches to ECS chip (as reflected in the GUI Chipset panel) ....

So it seems to me that we are doing a measure of auto-configuration, dependent on if the floppy image title is OCS only, or ECS capable... can you confirm?

[midwan]

The reason for this, is that the default prefs use ECS Agnus, while the Quickstart options (or the --model option as well) will use the OCS version.

Not sure about why, but this is how it's configured on WinUAE as well.
If you use the GUI to select the model, then you'll get the config showing there. If you use the command line and specify the model parameter, then you'll also get the relevant setting. But if you skip those and just use the default prefs when it starts up, it will use ECS Agnus, among other things.

[giantclambake]

Thanks ~ that does seem to be the case, ergo, the Bug label is deserved IMHO ....

...primarily because it gives rise to the follow text .... "You cannot direct load OCS floppy disk images ~ you must first start the amiberry GUI and load the floppy image using the GUI, for OCS chipset setting to be applied/used"...

...which obviously is nowhere near ideal, consider a good majority for floppy disk titles are indeed OCS only =)

[giantclambake]

I just tested the case with older OCS only floppy images ~ direct loading of these is indeed broken by this, if they absolutely require an OCS chipset emulation ..... updated subject line...

[giantclambake]

Circling this like a vulture, and after doing some more testing .... I have to consider the hypothetical ~ perhaps Toni did this deliberately? The overview would go something like this;

(A) The number of OCS only floppy titles
(B) The number of OCS/ECS floppy titles //most prevalent
(C) The number of ECS/Full-ECS floppy titles

If you view this from the aspect of 'user convenience' when direct loading floppy images, the current logic only 'inconveniences' the scenario when direct loading images from group (A)...

Conversely, if the current logic is changed...ie; direct loading keeps the default OCS profile, then that logic would 'inconvenience' the scenarios when direct loading images from both groups (B) & (C)...supposing such titles work better in ECS mode, which can often be the case....

The 'inconvenience' would be realized by direct loading a floppy image, have it crash & burn, and need to hit the F12 key to bring up the GUI, change Amiga model:, and then Reset the emulation.....

...if we change the current logic, the hypothetical suggests the users will be more often that not, 'inconvenienced' by having to do this for (potentially) most titles in the (B) & (C) groups ....

With the current logic, only direct loading titles from group (A) causes this 'inconvenience' ...and after my testing here, that's at least 'understandable' ...ie; titles in group (A) may want kickstart 1.2, or only 512kb of chipram (slowram needs to be disabled), etc etc tweaks to get right (and TBH I had trouble with OCS images in .adf form, often raising the best guru ever for mine, the infamous #00000004.00001970 ... retesting the same titles with .ipf images worked =)

Given the above para, it might actually be preferable to leave the current logic intact, and just document the operation. If you take one step back and look again at this, it could be said the current operational premise, is promoting the notion that one should manually construct an OCS machine type, because it's very difficult to correctly guess the emulation setup, when dealing with OCS (only) floppy images....given the results I got here, that would be 'sage' practice ...ie; at it's most base level, you can't guess when some of these older titles, require ks-1.2 specifically -- everything in groups (B) & (C) are happy with ks-1.3 by comparison...

...ergo, that's why I just spent some time, working through a number of titles from all three groups, to see what the user experience is like at this level... and if the following words held merit enough to make me happy....maybe fodder for the wiki/FAQ ?...

Q. Why does amiberry default to ECS, when direct loading OCS floppy disk images?

A. Direct loading of OCS only floppy images is not supported by amiberry, due to the fact it's impossible to determine which kickstart version, or what specific chipset configuration, is required to run these older OCS titles correctly. For this reason, you should always start the amiberry GUI to load OCS only floppy images using the Quickstart panel, and configure the Amiga OCS model type/kickstart/ram settings, to suit the title in question.

Problem solved... B^)

Does that seem 'sensible' to you? It does very much accurately report the facts...as tested here. I know and agree, that at first blush it does appear to be a bug technically speaking, however given the facts, it may be more a deliberate choice....

...know I was going to cover floppy disk handling in my EAB thread, and hit this hurdle ~ I'm happy enough to post the above, and leave things as they are...because it 'makes sense' to me ...not to mention that when available, you'd be better off using the whdload version instead anyway...(less configurata) ...you could of course pop the above in the wiki/FAQ area to cover documentation off (I can't think of any other appropriate wiki page)....and then this could be closed, as the behavior is documented =)

What say you?

[midwan]

I've asked Toni about this, waiting on a reply.
It could be that it's just something that was missed, and perhaps the default prefs should be updated to reflect the default option shown in Quickstart as well (which is in fact, the most common).

[midwan]

In the meantime, I've changed the default prefs to what I think they should be (OCS)

[giantclambake]

Yeah, that's fine -- it now 'works as expected' so to speak ~ we'll see what Toni says about it (obviously I've no problems with amiberry being technically correct =)

...I just went on a little sortie within HOL search....

(A) The number of OCS only floppy titles //second most prevalent
(B) The number of OCS/ECS floppy titles //most prevalent, but will run on base OCS config most times
(C) The number of ECS/Full-ECS floppy titles //least prevalent by far

So for the most part, the corrected logic might only inconvenience those titles in (A) & (B) ...where some don't like ks-1.3/slowram, whilst others require 1Mb chipram....

...that's actually 'good' emulation for mine ~ it's why my A500 machines had switches to control the machine makeup for certain titles... ie; it's realistic to need muck about with machine setting for certain titles...in emulation or real hardware ;)

[midwan]

I think I'll close this issue, until we hear back from Toni (might be a while). If there's a reason to change the behavior, we can revisit this, otherwise I'll consider it "done" for now.